# Küresel Ekiplerde Uzaktan Çalışma Kültürünü Yönetmek > On saat dilimi, yedi yıl, tek kural: yazılı değilse, yaşanmamıştır. Async-first çalışma için saha rehberi. > > 2024-03-12 — y7.hk ## Zoom Çağrılarının Ötesinde Uzaktan çalışma sadece ofis toplantılarını Zoom'a taşımak değildir. Gerçek uzaktan çalışma, büyük ölçüde asenkron iletişime ve titiz dokümantasyona dayanır. Saat dilimleri arasında çalışırken, sorduğun herhangi bir sorunun 12 saat boyunca yanıtlanamayacağını varsay. Bu kısıt seni daha iyi issue'lar, daha net RFC'ler ve daha kapsamlı pull request'ler yazmaya zorlar. Nadiren yüz yüze gördüğüm insanlarla yedi yıl ürün geliştirdim — 10'dan fazla saat diliminde: Avrupa ve Asya arasında bölünmüş bir kripto multisig ekibinden, şu an Güneydoğu Asya'dan bu siteyi ve birkaç Telegram botunu tek başıma yürüttüğüm işime kadar. Bu sürede 67 ülkede yaşadım — başka bir deyişle: Kırgızistan'da bir karavandaki dial-up hızındaki bağlantı da dahil, uzaktan çalışmayı neredeyse her koşulda test ettim. Gerçekten işe yarayanlar şunlar. ## Async-First Araç Değil Disiplindir Herkes "async" olduğunu söylüyor. Sonra Slack'lerine bakıyorsun — "kısa soru" ping'lerinden duvar ve çözülmemiş thread'ler. Async-first daha katı bir şey demek: - **Her karar yazılı bir eser üretir.** Ekiplerimdeki kural: karar 24 saat içinde kayda geçmeli — issue tracker'da, RFC'de ya da proje dokümanında. Yazılı değilse, olmamıştır. - **Varsayılan kanallar, DM değil.** Direkt mesajlar bağlamın öldüğü yerdir. Herkese açık kanallarda sor ki cevap sonraki kişi için aranabilir olsun. - **Yanıt süresi beklentileri açık.** Bizimkiler: engelleyiciler için aynı iş günü, geri kalanı için 24–48 saat. Kimse online olmak zorunda değil. Bu, yeşil nokta ve "sadece bakıyordum" kaygı tiyatrosunu ortadan kaldırır. 24 saat kuralı bürokratik duyulur — ta ki yeni biri üç aylık bir RFC bulup bir kararın neden verildiğini tam olarak anlayana kadar. İşte o zaman kendini öder, genelde ilk ay içinde. ## Gerçekten Uygulanabilir Issue Yazmak Ekip arkadaşın sen uyuduktan 12 saat sonra uyandığında, muğlak bir issue sana tam bir güne mal olur. O yüzden her issue'yu, atanan kişi bana ulaşamayacakmış gibi yazarım: - **Bağlam iki cümlede.** Ne bozuk ya da ne inşa ediyoruz ve neden şimdi. - **Yeniden üretme veya referans.** Bir link, log parçası, ekran görüntüsü, bunu çözmüş bir rakip ürün. - **Bitmişin tanımı.** "Daha hızlı yap" değil — "CI'da p95 build süresi 90 saniyenin altında". - **Açık hedef-dışılar.** En az değer verilen satır. "Bu PR'da parser'ı refactor etme" bana herhangi bir linter'dan daha fazla review turu kazandırdı. RFC'ler de aynı muameleyi görür: sorun, kısıtlar, gerçek tradeoff'lu iki-üç seçenek, bir öneri ve yorumlar için son tarih. Son tarihe kadar kimse itiraz etmezse öneri geçer. Toplantı gerekmez. ## Saat Dilimi Stratejisi: Bayrak Yarışını Benimse Çoğu insan saat dilimlerini sorun olarak görür. İyi yönetilen dağıtık ekip onları pipeline olarak görür — iş bayrak yarışı gibi gün boyu döner. Ama bayrak devri ancak devir yazılıysa çalışır. Kurallarım: - **Her çalışma bloğunu bir handoff notuyla bitir.** Ne bitti, sırada ne var, ne takılı. Issue'da üç satır. Uyanan kişi beş dakikada başlayabilmeli. - **Çakışma saatini bul ve koru.** 10+ saat farkta en fazla bir saat ortak gün ışığın olur. Onu gerçekten senkron gerektiren şeylere harca: anlaşmazlıklar, mimari kararlar, zor geri bildirim. - **Sormadan asla birinin beyan ettiği saatler dışında toplantı ayarlama.** "Sadece bir kere" insanları sessizce tüketme biçimindir. ```text Hâlâ kullandığım handoff şablonu: Bitti: şema migrasyonu staging'e deploy edildi Sıradaki: backfill job — çalışmaya hazır, onay bekliyor Takılı: API kota artışı (ticket #4821, vendor bekleniyor) ``` ## Dokümantasyon Varsayılan Olarak Bir bilgi sadece birinin kafasında varsa, ekibin o bilgisi yoktur — bağımlılığı vardır. Dokümantasyon üç katmanı kapsar: - **Kararlar** — RFC'ler ve issue thread'leri. Ne değil, neden. - **Süreçler** — ikiden fazla yapılan her şey için runbook: deploy'lar, rollback'ler, olay müdahalesi, onboarding. - **Bağlam** — kendi saatiyle gece 2'de katılan birine "ne yapıyoruz ve neden" sorusunu yanıtlayan proje dokümanı. Dokümanlar çürür, o yüzden dokümanların sahipleri ve gözden geçirme tarihleri vardır. Altı aydır kimsenin çalıştırmadığı bir runbook varlık değil, yükümlülüktür. ## Toplantılar İstisnadır Senkron zaman, dağıtık ekibin en pahalı kaynağıdır; para gibi harca. Toplantı için çıtam: 1. Yazının çözemediği bir karar var. 2. Önceden yayınlanmış bir gündem var. 3. Katılamayanlar yine de katkı verebilir — önceden toplanan yorumlar, sonradan notlar ve kayıt. Geri kalan her şey async güncellemedir. Gündeminde karar olmayan bir "haftalık sync" toplantı değil, takvim alışkanlığıdır. Öldür onu. ## Cargo Cult'süz Araç Seti Araçlar etraflarındaki normlardan daha az önemli, ama son birkaç kurulumumdan sağ çıkanlar: - **Linear** issue'lar için — hızlı, kanaatli, kağıt izi dayatıyor. - **Notion** dokümanlar ve RFC'ler için — vasat editör, mükemmel ortak hafıza. - **Slack** sohbet için — agresif kanal disiplini ve çoğu bildirim kapalı. - **Loom** walkthrough'lar için — üç dakikalık ekran kaydı 30 dakikalık aramanın yerini alıyor. - **GitHub** — dokümantasyon olarak PR'lar; açıklama *neyi* değil *nedeni* anlatır. Set kasıtlı olarak sıkıcı. Başarısızlık modu yanlış aracı seçmek değil — aynı konuşmayı dört araçta yapmak. ## Remote-First vs Remote-Friendly "Remote-friendly", uzaktan çalışanların ikinci sınıf vatandaş olduğu demektir: kararlar ofiste alınır, sonra yayınlanır. "Remote-first", her sürecin kimsenin aynı odayı paylaşmadığını varsayması demektir — işe alım, review'lar, planlama, kutlamalar. Terfi yolun bir ofiste "görünmeyi" gerektiriyorsa, uzaktan kültürün yok; web kameralı bir ofisin var. Testim: yarın genel merkez yansa, kararların alınma şeklinde bir şey değişir mi? Evetse, siz remote-friendly'siniz. ## Yalnızlık Sorunu Bu, mühendislik bloglarının atladığı kısım ve uzaktan çalışanların gerçekten işten ayrılma nedenlerinin başında gelir. Benim ve yönettiğim kişiler için işe yarayanlar: - **Coworking, her zaman.** Haritamda uzun süre kaldığım her ülkenin "benim" coworking alanı var. Rutin bir özelliktir. - **İş dışı kanallar.** Evcil hayvanlar, yemek, yerel meetup'lar. Bizimkiler iki şirket pivot'undan sağ çıktı. - **Önemli olduğunda çeyreklik yüz yüze zaman.** Bir haftalık yüz yüze zaman kabaca bir çeyrek güven satın alır. Onu status güncellemelerine değil, tasarım oturumlarına ve akşam yemeklerine harca. ## Yedi Yıl Sağ Kalan Kontrol Listesi - [ ] Karar 24 saat içinde kayıtlı - [ ] Issue'lar sana soru soramayan biri için yazılmış - [ ] Her çalışma bloğunun sonunda handoff notu - [ ] Toplantılar sadece gündem + karar + kayıt ile - [ ] Dokümanların sahibi ve gözden geçirme tarihi var - [ ] En az bir iş dışı kanal canlı - [ ] Çakışma saatleri status için değil anlaşmazlık için kullanılıyor Uzaktan çalışma bir avantaj ya da konum politikası değildir. Bir işletim sistemidir — ve her OS gibi, kimse izlemezken ne kadar iyi çalıştığıyla değerlendirilir.