Toplantıların Yerini Alan Asenkron Yazım: Yüksek Verimli Ekiplerin Kullandığı 5 Doküman Formatı

Kısaca. Asenkron çalışmaya en çok dayanan kuruluşlar, sabit bölümleri, adı belli bir karar vericisi ve sabit bir yorum süresi olan birkaç doküman kullanır. Python önerileri yaklaşık 200 kelimelik bir Abstract (özet) ve bir Rejected Ideas (reddedilen fikirler) bölümü ister. Rust’ın son yorum dönemi (final comment period) “on takvim günü sürer; böylece en az 5 iş günü açık kalır.” Bir IETF Last Call süreci en az iki hafta sürer. Amazon slaytların yerine “anlatı yapısında kurgulanmış altı sayfalık notlar” koydu. Hız gerekçesi sıklıkla iddia edildiğinden daha mütevazıdır: yetişkinler İngilizce kurgu dışı metni dakikada yaklaşık 238 kelime hızla okur (Brysbaert, 2019), sesli kitaplar ise dakikada 140-180 kelimeyle seslendirilir; yani okumak yalnızca yaklaşık 1,3 ila 1,7 kat daha hızlıdır (CEOtudent hesaplaması). Asıl kazanç, birçok kişinin tek bir dokümanı farklı zamanlarda okuyabilmesi ve dokümanın geride bir kayıt bırakmasıdır. Bu rehber, kopyalanmaya hazır beş şablon (karar dokümanı, anlatı ön okuması, pitch, haftalık güncelleme notu, olay incelemesi), bir format seçim tablosu ve bir kontrol listesi sunuyor. CEO hamlesi: her dokümanın en üstüne karar sahibini ve yanıt son tarihini yazılı olarak koyun. Öğrenci hamlesi: her dokümanı net düşünme alıştırması olarak görün ve göndermeden önce soğuk gözle yeniden okuyun.

Bu yazı, async öncelikli çalışma mimarisinin altındaki uygulama katmanıdır. Toplantıları azaltmaya neden değdiğini hala göstermeniz gerekiyorsa toplantıların gerçek maliyeti yazısıyla başlayın. Bir işin insanları aynı odada toplamayı gerektirip gerektirmediğine karar vermek için eş zamanlı mı, ajan mı karar protokolünü kullanın.

Yazmak neden toplantıların yerini alır ve kanıt nerede zayıf?

Marc Brysbaert’in Journal of Memory and Language’da yayımlanan 2019 tarihli meta-analizi, 18.573 katılımcılı 190 çalışmayı bir araya getirdi. Çalışma, “İngilizcede yetişkinler için ortalama sessiz okuma hızının kurgu dışı metinde dakikada 238 kelime (wpm), kurguda dakikada 260 kelime” olduğunu tahmin ediyor. Sesli okuma ortalaması dakikada 183 kelime. İngilizce kurgu dışı metnin sessiz okunmasında “yetişkinlerin çoğu dakikada 175 ila 300 kelime aralığına düşer.” Makale ayrıca okuma hızlarının “en yüksek dinleme hızıyla uyumlu” olduğunu söylüyor ve sesli kitapların dakikada 140-180 kelimeyle seslendirildiğini belirtiyor. Dolayısıyla dakikada 238 kelimelik sessiz okuma, dakikada 180 kelimelik konuşmanın yaklaşık 1,32 katı, dakikada 140 kelimelik konuşmanın ise 1,70 katı hızındadır (CEOtudent hesaplaması): gerçek bir kazanç, ama on katlık bir kazanç değil.

Bu rakamlar ayrıca “tüm süre boyunca göreve odaklı kalan kişiler için” geçerlidir; daha az kısıtlı ortamlardaki hızların ise “zihnin dağılması ve görev kesintileri nedeniyle muhtemelen daha düşük” olduğu belirtiliyor. Bu nedenle aşağıdaki okuma süreleri en iyi senaryo rakamlarıdır.

Yazmanın daha güçlü gerekçeleri yapısaldır:

• Zamandan bağımsızlık. Bir doküman, takvim izin verdiğinde değil, okurun ayırabileceği dikkat olduğunda okunur. Rust süreci bunu açıkça ortaya koyar: yorum süresi en az beş iş gününü kapsayacak şekilde belirlenmiştir, böylece “tüm paydaşlar bir karara varılmadan önce son itirazlarını iletme şansına sahip olur.”
• Bir yazar, çok okur. Bir toplantı her katılımcıya aynı dakikalara mal olur. Bir doküman ise yazara bir kez saatlere, her okura dakikalara mal olur.
• Bir kayıt. Python’un PEP 1 belgesi, PEP’ler sürümlenen bir depoda tutulduğu için “revizyon geçmişlerinin, özellik önerisinin tarihsel kaydı” olduğunu belirtir.
• Düşünme. Yazmak, bir argümandaki boşlukları okurlar bulmadan önce ortaya çıkarır; kanıtlar düşünme aracı olarak yazmak yazısında.

Ciddi bir karşı ağırlık var. Yang ve meslektaşları, 2020’nin ilk altı ayında 61.182 ABD’li Microsoft çalışanının e-postalarını, takvimlerini, sohbetlerini ve görüşmelerini inceledi. Şirket genelindeki uzaktan çalışmanın iş birliği ağlarını “daha durağan ve daha silolaşmış” hale getirdiğini, “eş zamanlı iletişimde bir azalma ve asenkron iletişimde bir artış” yaşandığını buldular (Nature Human Behaviour, 2022; yalnızca özet). Dokümanlar ekipler arasında ancak biri onları oraya gönderirse dolaşır; bu yüzden şablonlarda bir dağıtım satırı bulunuyor.

Hangi kuruluşlar zaten dokümanlarla çalışıyor?

Aşağıdaki her sistem kendi birincil metninde anlatılmıştır. Amazon, Basecamp ve Google metinleri şirketlerin kendi yayınlarıdır; Python, Rust ve IETF metinleri açık yönetişim belgeleridir.

Sistem (yayımlayan)	Doküman	Zorunlu bölümler, yayımlandığı haliyle	Zamanlama kuralı, yayımlandığı haliyle	Kim karar verir
Python (PEP 1)	Python Enhancement Proposal	Preamble, Abstract (~200 kelime), Motivation, Specification, Rationale, Rejected Ideas, Open Issues ve diğerleri	Başlık 44 karakterle sınırlı	Steering Council veya bir PEP-Delegate
Rust (RFC süreci README)	Request for Comments	Summary, Motivation, Guide-level ve Reference-level explanation, Drawbacks, Rationale and alternatives, Prior art, Unresolved questions, Future possibilities	On takvim günlük son yorum dönemi, en az 5 iş günü	Alt ekip; son yorum döneminden önce tüm üyeler onay verir
IETF (RFC 2026, RFC 7322)	Internet-Draft ve RFC	“Kendi içinde eksiksiz” bir Abstract	Taslak en az iki hafta kamuya açık; Last Call en az iki hafta, bir çalışma grubu başlatmadıysa dört hafta	IESG
Amazon (2017 hissedar mektubu, SEC eki)	Altı sayfalık anlatı notu	“Anlatı yapısında kurgulanmış”; slayt yok	Toplantının başında sessizce okunur; iyi bir notun yazılması “muhtemelen bir hafta veya daha fazla sürmeli”	Mektupta belirtilmemiş
Basecamp (Shape Up, 6. bölüm)	Pitch	Problem, Appetite, Solution, Rabbit holes, No-gos	Appetite altı hafta, küçük işlerde iki hafta olarak belirtilir	Projeleri planlayan kişiler
Google SRE (SRE kitabı, 15. bölüm ve D eki)	Postmortem	Etki, alınan aksiyonlar, kök nedenler, takip aksiyonları; örnek ayrıca tetikleyici, tespit, çıkarılan dersler ve zaman çizelgesi ekler	Tanımlı tetikleyicilerden sonra yazılır; kıdemli mühendisler taslağı inceler	İnceleme oturumları kesinleştirir; aksiyon maddelerinin adı belli sahipleri vardır

Kaynaklar: PEP 1; Rust RFCs README ve 0000-template.md; RFC 2026 bölüm 6.1.1 ve 6.1.2; RFC 7322 bölüm 4.3; Amazon.com 2017 hissedarlara mektup, 18 Nisan 2018’de sunulan Form 8-K’nin 99.1 numaralı eki; Shape Up 6. bölüm; Site Reliability Engineering, 15. bölüm ve D eki. Rakamlar yayımlandığı haliyle.

Üç örüntü tekrar eder: okurlar nereye bakacaklarını bilsin diye sabit bölümler; yorumlar bir karara aksın diye adı belli bir karar verici; ve son tarihten sonraki sessizlik bir anlam taşısın diye bir zamanlama kuralı. GitLab el kitabı, hala yapılan toplantılar için dördüncü bir örüntü ekler: gündemlerin “72 saat (en az 24 saat)” önceden paylaşılması ve varsayılan toplantı sürelerinin 25 veya 50 dakika olması.

Her formatı okumak ne kadar sürer?

Tablo, Brysbaert’in hızlarını her formatın üst kelime bütçesine uygular. Bütçeler aşağıdaki CEOtudent çerçevesinden gelir. 25 dakikalık süre, GitLab’in “hızlı toplantı” sürelerinden biridir.

Format	Üst kelime bütçesi	238 kelime/dk ile okuma (dakika)	175 kelime/dk ile okuma (dakika)	180 kelime/dk ile dinleme (dakika)	140 kelime/dk ile dinleme (dakika)	Okuma süresinin 25 dakikalık toplantıdaki payı
Haftalık güncelleme notu	300	1,3	1,7	1,7	2,1	%5
Pitch	1.000	4,2	5,7	5,6	7,1	%17
Karar dokümanı	1.200	5,0	6,9	6,7	8,6	%20
Olay incelemesi	1.500	6,3	8,6	8,3	10,7	%25
Anlatı ön okuması	3.000	12,6	17,1	16,7	21,4	%50

Brysbaert (2019) okuma ve konuşma hızları ile GitLab’in 25 dakikalık varsayılan toplantı süresine dayanan CEOtudent analizi. Kelime bütçeleri ölçülmüş veri değil, bir CEOtudent editoryal çerçevesidir. Okurlar bölündüğünde gerçek okuma daha yavaştır.

Buradan iki sonuç çıkar. Dakikada 175 kelime okuyan biri, dakikada 180 kelime dinleyen biriyle yaklaşık aynı süreyi harcar; dolayısıyla yavaş okurlar için dokümanların gerekçesi hıza değil, zamandan bağımsızlığa ve kayda dayanır. Bütçeler de önemlidir: 3.000 kelimelik bir not, 25 dakikalık bir toplantının yarısını doldurur; Amazon’un okuma süresini toplantının içine yerleştirmesinin nedeni budur.

Hangi format hangi toplantının yerini alır?

Format	Yerini aldığı toplantı	Kelime bütçesi	Kim okur	Karar sahibi	Yanıt son tarihi
Karar dokümanı	Karar toplantısı, onay toplantısı	600-1.200	Karardan etkilenenler ve veto hakkı olan herkes	Adı belli tek bir kişi	Geri alınabilir kararlar için 5 iş günü; geri alınması zor olanlar için 10
Anlatı ön okuması	Slayt sunumu, çeyreklik veya proje değerlendirmesi	1.500-3.000	Yalnızca toplantı katılımcıları	Toplantı sahibi	Toplantıdan önce veya ilk dakikalarında okunur; sorular kenar notlarına
Pitch	Başlangıç toplantısı, beyin fırtınası, kapsam belirleme toplantısı	500-1.000	Zamanı ve bütçeyi kim dağıtıyorsa	Bahsi finanse eden kişi	Bir sonraki planlama döngüsü
Haftalık güncelleme notu	Durum toplantısı, düzenli kontrol görüşmesi	150-300	Ekip ve doğrudan paydaşları	Yok; bilgilendirir ve kararlara bağlantı verir	Yanıt gerekmez; isimle yapılan talepler verilen tarihe kadar
Olay incelemesi	Suçlu arama toplantısı, olay sonrası plansız görüşme	800-1.500	Ekip, ardından daha geniş bir mühendislik veya operasyon kitlesi	İncelemeyi kapatan gözden geçirenler; her aksiyon maddesi için bir sahip	Taslak 5 iş günü içinde; yorumlar inceleme oturumundan önce kapanır

CEOtudent editoryal çerçevesi. Yorum süreleri Rust son yorum döneminden (en az 5 iş günü) ve IETF Last Call alt sınırlarından (iki ve dört hafta) uyarlanmıştır. Bütçeler ve son tarihler araştırma bulgusu değil, ekiplerin uyarlayabileceği editoryal tercihlerdir.

Bir toplantı bu satırların hiçbirine uymuyorsa, muhtemelen kalması gereken toplantılardan biridir. Aşağıdaki sınırlar bölümü bunları listeliyor.

Format 1: Karar dokümanı nasıl yazılır?

Karar dokümanı, insanların anlaşmak için toplandığı toplantının yerini alır. Üç kaynaktan ödünç alır. PEP 1, yazarın “muhalif görüşleri” belgelemesini ve insanların “aynı reddedilmiş fikri yeniden gündeme getirmesini” önlemek için reddedilen fikirleri kaydetmesini şart koşar. RFC 7282, “anlaşmazlığın olmamasının anlaşmadan daha önemli” olduğunu ve kabaca uzlaşmanın, sorunların “ele alındığı ama mutlaka karşılanmadığı” anlamına geldiğini söyler. Amazon’un 2016 mektubu, çoğu kararın “muhtemelen sahip olmayı dilediğiniz bilginin yaklaşık %70’iyle verilmesi gerektiğini” söyler ve geri alınabilir “çift yönlü kapıları” geri alınması zor kararlardan ayırır.

KARAR DOKÜMANI: [tek satırda karar, en fazla 12 kelime]
Karar sahibi: [tek bir isim]          Durum: [Yoruma açık | Karara bağlandı | Geri çekildi]
Yorum son tarihi: [tarih, saat, saat dilimi]     Karar tarihi: [tarih]
Geri alınabilirlik: [Çift yönlü kapı: kolayca geri alınır | Tek yönlü kapı: geri alınması zor]
Dağıtım: [diğer ekipler dahil, bunu görmesi gereken ekipler ve kişiler]

1. Talep (en fazla 3 cümle)
   [X] konusunda [tarih] tarihine kadar karar vereceğiz. Karar sahibi [seçenek] seçeneğini öneriyor.
   Son tarihe kadar itiraz gelmemesi onay sayılır.
2. Bağlam: [ne değişti, rakamlarla ve verinin bağlantısıyla]
3. Değerlendirilen seçenekler
   A. [seçenek]: fayda [ ], maliyet [ ], ana risk [ ]
   B. [seçenek]: fayda [ ], maliyet [ ], ana risk [ ]
   C. Hiçbir şey yapmamak: fayda [ ], maliyet [ ], ana risk [ ]
4. Öneri ve diğer seçeneklerden neden üstün olduğu: [ ]
5. Henüz bilmediklerimiz (istediğimiz bilginin kabaca ne kadarına sahibiz): [ ]
6. Reddedilen fikirler: [fikir], şu nedenle reddedildi: [neden]
7. Muhalefet kaydı: [isim]: [itiraz] | [nasıl ele alındığı veya neden karşılanmadığı]
8. Karar kaydı (karar tarihinde karar sahibi doldurur):
   Karar: [seçenek]   Karar veren: [karar sahibi]   Tarih: [ ]   Gözden geçirme tarihi: [tarih]

Okumayı 1. bölümden sonra bırakan bir okur bile neye, kimin tarafından ve ne zamana kadar karar verildiğini bilmelidir. Ders çıkarmaya değer kararlar için 8. bölümü kişisel bir karar günlüğüne kopyalayın.

Format 2: Anlatı ön okuması nasıl yazılır?

Ön okuma toplantıyı ortadan kaldırmaz. Sunumu ortadan kaldırır. Amazon’un 2017 mektubu bunu şöyle anlatır: “Amazon’da PowerPoint (ya da başka herhangi bir slayt odaklı) sunum yapmıyoruz. Bunun yerine anlatı yapısında kurgulanmış altı sayfalık notlar yazıyoruz.” Aynı mektup notların kalitesinin “büyük farklılıklar gösterdiğini” söyler. Ayrıca iyi notların “yazılıp yeniden yazıldığını, işi iyileştirmeleri istenen meslektaşlarla paylaşıldığını, birkaç gün kenara bırakıldığını ve ardından taze bir zihinle yeniden düzenlendiğini” belirtir.

ÖN OKUMA: [konu]
Yazar: [ ]   Toplantı: [tarih, saat]   Okuma süresi: yaklaşık [kelime / 238] dakika
Bu toplantı şunları yanıtlamalı:
  1. [soru]
  2. [soru]

1. Özet (150 kelime, kendi içinde eksiksiz): [tüm argümanın minyatürü]
2. Neredeyiz: [olgular, rakamlar ve eğilim, kaynaklarıyla]
3. Ne öğrendik: [her biri kanıtıyla birlikte üç bulgu]
4. Ne öneriyoruz: [plan, sahipler, tarihler]
5. Neler ters gidebilir: [riskler ve bizi neyin durduracağı]
6. Her okurdan ne bekliyoruz: [isim]: [belirli soru]
Ek (isteğe bağlı okuma): [tablolar, ham veri, arka plan]

Özet kuralı, bir Abstract’ın sıklıkla tek başına göründüğü için “kendi içinde eksiksiz olması gerektiğini” söyleyen RFC stil kılavuzundan gelir. Göz gezdiren okurlar 1. bölümden sonra bırakabilmelidir. 5. bölüm burada yeniden kurulmak yerine ön otopsi protokolü kullanılarak doldurulabilir.

Format 3: Pitch nasıl yazılır?

Pitch, ucu açık başlangıç toplantısının veya beyin fırtınasının yerini alır. Basecamp’in Shape Up kitabı “bir pitch’e her zaman dahil etmek istediğimiz beş bileşeni” sıralar: Problem, Appetite, Solution, Rabbit holes ve No-gos. Appetite (iştah), çoğu önerinin atladığı kısımdır. Shape Up bunu “ne kadar zaman harcamak istediğimiz ve bunun çözümü nasıl sınırladığı” olarak tanımlar ve “iştahı pitch’te belirtmenin verimsiz konuşmaları önlediğini” söyler.

PITCH: [proje adı]
Finansman talep edilen: [kişi veya grup]   Karar tarihi: [tarih]
Problem: [belirli bir kullanıcı için mevcut yöntemin başarısız olduğu tek ve somut bir hikaye]
İştah: [harcayacağımız en fazla süre, ör. 2 hafta veya 6 hafta; kapsam
          süreye sığacak şekilde küçülür, süre kapsama sığacak şekilde uzamaz]
Çözüm: [kısa bir liste veya kaba bir taslak olarak temel unsurlar]
Tavşan delikleri: [zamanı yiyebilecek ayrıntılar ve her birinden nasıl kaçınacağımız]
Kapsam dışı: [bilerek kapsam dışında bırakılanlar]
Bunu finanse etmezsek ne olur: [ ]

İştah satırı soruyu “bu iyi bir fikir mi?” sorusundan “bu kadar zamana değer mi?” sorusuna çevirir.

Format 4: Asenkron durum güncellemesi nasıl yazılır?

Ekiplerin çoğu asenkron güncellemenin nasıl yazılacağını sorduğunda kastettiği format budur. Düzenli durum toplantısının yerini alır. Shape Up ana tasarım ilkesini verir: yöneticiler durum sormaktan hoşlanmaz, ekipler de belirsizliği saklar çünkü “kimse elini kaldırıp yönetime” bir sorunu nasıl çözeceğini bilmediğini “söylemek istemez.” Çözüm önerisi, görevleri saymak yerine işin yokuş yukarı ve yokuş aşağı evrelerini kullanarak “neyin bilinmediğini ve neyin çözüldüğünü” raporlamaktır.

[Ekip veya proje] güncellemesi, [tarih] haftası
Durum: [Yolunda | Risk altında | Yolunda değil]   Yazar: [ ]   Sonraki güncelleme: [tarih]

Özetle (2 cümle): [okurun bu hafta bilmesi gereken tek şey]

Son güncellemeden bu yana tamamlananlar (aktivite değil, sonuçlar):
  - [bir kullanıcı veya bir rakam için ne değişti]
Sırada, [tarih] tarihine kadar:
  - [ ]
Yokuş yukarı (yaklaşım hala netleşiyor):
  - [madde]: açık soru şu: [ ]
Yokuş aşağı (yaklaşım belli, uygulanıyor):
  - [madde]: beklenen bitiş [tarih]
Engellenenler veya belirli bir kişiden ihtiyaç duyulanlar:
  - [isim]: [belirli talep], son tarih [tarih]
Bu hafta alınan kararlar: [karar dokümanı başlıkları]
Metrik: [ad]: [değer], hedef [değer], eğilim [yukarı | yatay | aşağı]

Notu 150 ila 300 kelime arasında tutun ve her hafta aynı gün, aynı kanalda yayımlayın. Yokuş yukarı satırı, Shape Up’ın tepe grafiğinde hareket etmeyen bir noktaya verdiği rolü üstlenir: “fiilen kaldırılmış bir el.” İki güncelleme üst üste yokuş yukarıda kalan bir madde, kısa bir toplantının tetikleyicisidir.

Format 5: Olay incelemesi nasıl yazılır?

SRE kitabı postmortem’i “bir olayın, etkisinin, onu hafifletmek veya çözmek için alınan aksiyonların, kök neden(ler)in ve olayın tekrarlanmasını önleyecek takip aksiyonlarının yazılı kaydı” olarak tanımlar. Suçlamasız olmalıdır: “hiçbir bireyi veya ekibi kötü ya da uygunsuz davranışla itham etmeden, olaya katkıda bulunan nedenleri belirlemeye odaklanmalıdır.” Aşağıdaki bölümler kitabın örnek postmortem’ini izler.

OLAY İNCELEMESİ: [kısa başlık] (#[kimlik])
Tarih: [ ]   Yazarlar: [ ]   Durum: [Taslak | İncelemede | Tamamlandı]
Özet: [2 cümlede ne oldu]
Etki: [kimler, kaç kişi, ne kadar süreyle etkilendi]
Kök nedenler: [kişilerde değil, sistemlerde ve süreçlerde katkıda bulunan nedenler]
Tetikleyici: [olayı ne başlattı]
Çözüm: [olayı ne durdurdu]
Tespit: [nasıl fark edildi ve bu ne kadar sürdü]
Aksiyon maddeleri:
  - [aksiyon] | tür: [hafifletme | önleme | süreç] | sahip: [isim] | son tarih: [tarih]
Çıkarılan dersler:
  İyi giden: [ ]
  Kötü giden: [ ]
  Şansımızın yaver gittiği yer: [ ]
Zaman çizelgesi: [saat, saat dilimi]: [olay]
Gözden geçirenler: [isimler]   Yorumların kapanışı: [tarih]   Paylaşılan kitle: [kitle]

“Şansımızın yaver gittiği yer”, ekiplerin en sık atladığı ve kıl payı atlatılan durumları kaydeden bölümdür.

İnsanların gerçekten okuduğu asenkron güncelleme nasıl yazılır?

Göndermeden önce bu kontrol listesini beş formatın hepsine uygulayın:

1. Mesajı ilk iki cümle taşır. Orada bırakan bir okur durumu, talebi ve son tarihi bilir.
2. Son tarihin bir günü, saati ve saat dilimi vardır. “Hafta sonuna kadar” farklı yerlerde farklı anlamlara gelir.
3. Karar verici veya sahip olarak tek bir kişinin adı yazılır. Sahibi olmayan bir doküman bir tartışma zincirine dönüşür.
4. Kelime bütçesinin içinde kalır. Bütçeyi aşan her şey bir eke veya bağlantıya taşınır.
5. Aktiviteyi değil, sonuçları raporlar. “Ödeme hataları azaldı”, “ödeme üzerinde çalışıldı” ifadesinden iyidir.
6. Bilinmeyenler bilinenlerden ayrılır. Yazıya dökülen belirsizliğe yardım edilebilir; saklanan belirsizlik risk olarak birikir.
7. Her talep bir kişinin adını taşır. “Biri buna bakabilir mi?” yanıtsız kalır; “[İsim], perşembe 15:00 UTC’ye kadar onaylayabilir misin?” yanıt alır.
8. Tek bir doğru kaynak vardır. GitLab el kitabı, “birden fazla gündeme” sahip olmanın hiç gündem olmaması kadar kötü olduğu konusunda uyarır. Kopyalar yapıştırmak yerine asıl dokümana bağlantı verin.
9. Şablon değişmez. Okurlar nereye bakacaklarını öğrenir; her hafta aynı başlıklar onlara zaman kazandırır.
10. Soğuk gözle yeniden okunmuştur. Amazon’un en iyi notları “birkaç gün kenara bırakılır.” Haftalık bir güncelleme için ondan bir saat uzak kalmak yeterlidir.

Sistemin işe yarayıp yaramadığını görmek için, bir dokümanın işini gördüğü için iptal edilen düzenli toplantıları sayın. GitLab el kitabı daha da ileri gider ve sonuç veya hazırlık eksik olduğunda “toplantıların kabaca %1’inin ilk dakika içinde bitmesi gerektiğini” söyler.

CEO ve öğrenci bu dokümanları nasıl kullanır?

CEO hamlesi, sahipliği yazıya dökmektir. Yukarıdaki her dokümanın en üstünde bir sahip satırı ve bir son tarih satırı vardır. “Karar sahibi: [isim], karar tarihi: [tarih]” yazmak, pek çok toplantının çözmek için var olduğu şeyi çözer ve sessizliği anlamlı kılar. Rust süreci, “genellikle imkansız” dediği “tüm katılımcılar arasında uzlaşmayı” şart koşmaz, ama karar penceresi açılmadan önce argümanın “açıkça ifade edilmiş” olmasını şart koşar. Amazon’un 2016 mektubu buna, oybirliği olmadan ilerlemenin bir yolu olan “katılmıyorum ama bağlanıyorum” (disagree and commit) ilkesini ekler.

Öğrenci hamlesi pratiktir. Her doküman, net düşünme üzerine kısa ve tekrarlanabilir bir alıştırmadır: problemi ortaya koy, seçenekleri tart, bilinmeyeni adlandır. Bezos not kalitesini yetenekten çok bir kapsam meselesi olarak görür. Yazarlar “yüksek standartlı, altı sayfalık bir notun bir ya da iki günde, hatta birkaç saatte yazılabileceğine yanlışlıkla inanır; oysa gerçekte bir hafta veya daha fazla sürebilir.” Kendi dokümanlarınızı üç ay sonra yeniden okuyun; reddedilen fikirler ve muhalefet bölümleri, muhakemenin nerede gelişebileceğini gösterir.

Bu ne anlama gelmiyor

Yazmak toplantıları ortadan kaldırmaz ve yukarıdaki sistemler de bunu iddia etmez:

• Postmortem’ler hala bir toplantıyla biter. SRE kitabı, “devam eden tartışmaları ve yorumları kapatmak” için “postmortem’ler için düzenli inceleme oturumlarını” teşvik eder. “İncelenmemiş postmortem bırakılmaz” kuralı altında doküman önce, inceleme oturumu sonra gelir.
• Amazon’un notu toplantının içinde okunur ve Rust hala görüşme planlar. Not tartışmanın değil, slaytların yerini alır. Rust README’si, alt ekibin “yazarla ve/veya ilgili paydaşlarla toplantılar planlayabileceğini” ve bir özetin tartışma zincirine geri gönderildiğini belirtir.
• Bazı işler gerçek zamanlı temas gerektirir. Çatışma, bir kişinin işiyle ilgili kötü haber, yeni bir ekipte güven inşası ve hala süren hızlı gelişen olaylar ses ve yüz yüze iletişim ister. Kaydedilip özetlenen bir toplantı da bunun yerini tutmaz; bkz. yapay zeka toplantı notlarının neyi değiştirdiği.
• Asenkron çalışma ekipleri yalıtabilir. Microsoft çalışması, iletişim asenkron kanallara kaydıkça ağların “daha durağan ve daha silolaşmış” hale geldiğini buldu. Dağıtım satırları ve ekipler arası okurlar ekstra değil, tasarımın parçasıdır.
• Dokümanlar yazma zamanına mal olur. Okunması 5 dakika süren 1.200 kelimelik bir karar dokümanının yazılması saatler alabilir. İki kişilik bir soru için kısa bir görüşme daha iyi olabilir.

Sıkça sorulan sorular

Asenkron bir durum güncellemesi ne uzunlukta olmalı?
Bu çerçevede 150 ila 300 kelime arasında; 300 kelime, dakikada 238 kelime hızla yaklaşık 1,3 dakikada okunur. Ayrıntıları bağlantılara taşıyın.

Okumak gerçekten bir toplantıdan daha mı hızlı?
Bir ölçüde: sesli kitap konuşmasından yaklaşık 1,3 ila 1,7 kat daha hızlı, yavaş okurlar için ise neredeyse başa baş. Asıl kazançlar zamanlama, erişim ve kayıttır.

Karar dokümanı ile pitch arasındaki fark nedir?
Pitch, sabit bir iştah içinde bir çözümü keşfetmek için zaman ve para ister. Karar dokümanı ise insanlardan, adı belli bir sahiple ve bir son tarihe kadar, birkaç seçenek arasından birine bağlanmalarını ister.

Yorum süresi ne kadar olmalı?
Bu çerçeve, geri alınabilir kararlar için 5 iş günü, geri alınması zor kararlar için 10 iş günü kullanır. Bu, Rust’ın on takvim günlük son yorum döneminden ve IETF’in iki haftalık Last Call alt sınırından uyarlanmıştır. Tam süre, onu en üste yazmaktan daha az önemlidir.

Yanıt gelmemesi onay anlamına mı gelir?
Yalnızca doküman bunu son tarihten önce belirtiyorsa. RFC 7282 “anlaşmazlığın olmamasının anlaşmadan daha önemli” olduğunu savunur, ancak bu yalnızca herkes kuralı bildiğinde işe yarar. Kimse şaşırmasın diye bunu talep bölümüne yazın.

Bu dokümanları yapay zeka mı yazmalı?
Yapay zeka bağlam ve zaman çizelgesi bölümlerinin taslağını çıkarabilir. Talep, öneri, reddedilen fikirler ve bilinmeyenler ise yazarın kendi düşüncesinin dokümanın asıl amacı olduğu yerlerdir. Önce bunların taslağını kendiniz yazın.

Kaynaklar

1. Brysbaert, M. (2019). How many words do we read per minute? A review and meta-analysis of reading rate. Journal of Memory and Language, 109, 104047. (yazar el yazması sürümü)
2. Amazon.com, Inc. (2018). 2017 Letter to Shareholders. 18 Nisan 2018’de sunulan Form 8-K’nin 99.1 numaralı eki, SEC EDGAR. (şirket yayını)
3. Amazon.com, Inc. (2017). 2016 Letter to Shareholders. 12 Nisan 2017’de sunulan Form 8-K’nin 99.1 numaralı eki, SEC EDGAR. (şirket yayını)
4. Warsaw, B., Hylton, J., Goodger, D. ve Coghlan, A. PEP 1: PEP Purpose and Guidelines (oluşturulma 2000, Active). Python Software Foundation, peps.python.org.
5. The Rust Project. Rust RFCs README (RFC süreci) ve 0000-template.md, rust-lang/rfcs deposu.
6. Bradner, S. (1996). RFC 2026: The Internet Standards Process, Revision 3. IETF, BCP 9.
7. Flanagan, H. ve Ginoza, S. (2014). RFC 7322: RFC Style Guide. RFC Editor.
8. Resnick, P. (2014). RFC 7282: On Consensus and Humming in the IETF. IETF.
9. Singer, R. Shape Up: Stop Running in Circles and Ship Work that Matters, 6. bölüm (Write the Pitch) ve 13. bölüm (Show Progress). 37signals, ücretsiz çevrim içi baskı. (şirket yayını kitap)
10. Lunney, J. ve Lueder, S. Postmortem Culture: Learning from Failure (15. bölüm) ve Example Postmortem (D eki). Site Reliability Engineering: How Google Runs Production Systems içinde. Google ve O’Reilly Media, 2017 çevrim içi baskı (CC BY-NC-ND 4.0).
11. GitLab Inc. GitLab Handbook: All-Remote Meetings; Communication (asenkron iletişim bölümü). (şirket yayını)
12. Yang, L., Holtz, D., Jaffe, S., Suri, S. ve diğerleri (2022). The effects of remote work on collaboration among information workers. Nature Human Behaviour, 6, 43-54. (yalnızca özet; dergi sayfasında 5 Ekim 2021’de yayımlanan bir yazar düzeltmesi listeleniyor)

Yöntem notu: okuma süresi tablosu, Brysbaert (2019) okuma ve konuşma hızlarının CEOtudent kelime bütçelerine ve GitLab’in 25 dakikalık toplantı süresine uygulandığı bir CEOtudent analizidir. Format seçim tablosu, beş şablon, kelime bütçeleri, yorum süreleri ve kontrol listesi, listelenen birincil belgelerden uyarlanmış bir CEOtudent editoryal çerçevesidir; araştırma bulgusu değildir. Doküman sistemleri tablosu, her kaynaktaki gereklilikleri yayımlandığı haliyle aktarır. CEOtudent herhangi bir anket yapmadı. Bilerek kullanılmayanlar: insanların dinlediklerinden birkaç kat daha hızlı okuduğu iddiası ve dakikada 300 kelimelik ölçüt (Brysbaert’in incelemesi her ikisinin de okuma hızını abarttığını savunur) ile verimsiz toplantılar hakkında yaygın biçimde tekrarlanan, birincil metinleri tam olarak açılamayan anket yüzdeleri.

---

Bu içerik, derinlemesine bir araştırmanın ardından yapay zeka desteğiyle derlenmiş ve CEOtudent editör ekibi tarafından yazılıp yayına hazırlanmıştır.