Benim 'WTF Defterim' Yazma Biçimim (2021)
(simplermachines.com)- Yeni bir takıma katıldıktan hemen sonra göze çarpan tuhaflıkları anında dile getirmek yerine WTF defterinde toplamak, şikâyet eden biri değil takıma yardım eden biri olarak güven kazanmak için gerekli bağlamı oluşturabilir
- Kayda alınacak şeyler; retrospektiflerin aksiyonsuz bitmesi, testlerin lokalde çalışmaması, sürekli kırmızı olan build board, belirli işlerde tek kişiye bağımlılık gibi takım işleyişi ve teknik akışta takılan sinyallerdir
- Liste zaman geçtikçe geçerli nedenler, hâlihazırda süren düzeltmeler, takımın düşük öncelik verdiği konular ve kolayca düzeltilebilecek maddeler olarak elenir
- Haftalar sonra hâlâ kalan sorunlar için ekip arkadaşları, takım lideri ve yöneticiyle konuşularak nedenleri ve geçmişi anlaşılır; uzun süredir rahatsız eden ama görece basit sorunlardan başlanarak birlikte çözülür
- Sorunları hemen patlatmak yerine bağlam ve öncelik biriktirmek, yeni ekip üyelerinin de güven kaybetmeden sorun çözen kişi itibarı kazanmasını sağlar
WTF defterini kullanma biçimi
- Takımda edinmek istenen itibar, “Sorunlarımı çözmeme yardım eden kişi”, “Benim önemli gördüğüm işleri tamamlayan kişi” olmaktır
- Her yeni takıma katılışta bullet journal'da yeni bir sayfaya
WTF - [Team Name]yazılır ve tuhaf gelen her şey görüldükçe not alınır - Değiştirilmek istenen şeyler ortaya çıktığında bunlar ayrı işler olarak da kaydedilir
- İlk 2 hafta boyunca odak sadece not almaktır
- Takımın yanlış yaptığını düşündüğünüz her şeyi hemen söylemezsiniz
- Retrospektifte değiştirilmesi gerekenler listesini ortaya dökmezsiniz
- Gördüğünüz, duyduğunuz ve derinden tuhaf gelen şeyleri yazarsınız
- Bu yöntem, takımda değişim yaratırken aynı zamanda kendinizi yönetmenize ve sadece şikâyet eden biri gibi görünmemenize yardımcı olan bir tekniktir
Yeni takımda yakalanan tuhaf sinyaller
- Yeni bir takımda her zaman “wtf” dedirten şeyler vardır
- Tipik örnekler şunlardır
- Takım, retrospektifte ciddi bir problemi bir saat boyunca konuşur ama aksiyon maddesi çıkmadan bitirir
- Testler lokalde çalışmaz ama sanki kimse bunu umursamıyordur
- Build board'un büyük bir bölümü sürekli kırmızıdır
- Önemli ve zaman açısından kritik bir işi yalnızca tek bir kişi yapabiliyordur
- Takım bir özelliğe çok zaman harcar ama bunun neden önemli olduğunu ya da müşteriye nasıl fayda sağladığını kimse net olarak bilmiyordur
Listeden silinen maddeler
- Liste yeterince büyüdüğünde maddeler tek tek silinmeye başlanır
- Bunun genelde dört nedeni vardır
- Aslında geçerli bir neden vardır
- Takım zaten düzeltme üzerinde çalışıyordur
- Takım bu konuyu önemli görmüyordur
- Gerçekten çok kolay düzeltilebiliyordur
- Lokal testlerin çalışmaması da bağlama göre büyük bir sorun olmayabilir
- Bu zaten bilinen bir issue olabilir ve çözüm için çalışma sürüyor olabilir
- Takım tüm işini sanal makinede yapıyor olabilir ve bu makine bir sohbet komutuyla kolayca provision edilebiliyor olabilir
- Sürekli entegrasyon sistemi güçlü olabilir ve küçük değişiklikleri sık sık deploy etme alışkanlığı sayesinde, lokal test eksikliği günde birkaç kez deploy yapmayı engellemiyor olabilir
- Bazı maddelerde basit bir çözüm açıkça görünür
- Yeri biliniyorsa dokümantasyon yazılabilir
- Doğru script bulunursa değişiklik kolay olabilir
- Kolay bir çözüm görünüyorsa hemen düzeltilir
Kalan sorunları takımla birlikte ele almak
- Birkaç hafta geçmesine rağmen hâlâ tuhaf ve çözülmemiş sorunlar kalıyorsa ekip arkadaşları, takım lideri ve yöneticiyle konuşmalar başlar
- Soruların odağı, bu maddelerin neden böyle olduğu ve bu noktaya nasıl geldiğidir
- Amaç, içtenlikle merak eden ve empati kuran biri, sabırlı olan ve ekip arkadaşlarının uzmanlığına saygı duyan biri olarak güven kazanmaktır
- Sorunların kalmasının nedenleri çoğunlukla birkaç gruba ayrılır
- Takım bunun farkına varmamıştır
- Takım buna alışmıştır
- Sorun görece yenidir ve ondan önceki sorun çok daha kötüydü
- Nasıl düzeltileceği bilinmiyordur
- Daha önce düzeltmeye çalışılmış ama başarısız olunmuştur
- İlk birkaç tür sorun, sadece soru sormakla bile hemen çözülebilir
- Karşı taraf ya hemen düzeltir ya da birlikte bir çözüm yolu bulunur
- Teknik bir sorunsa birlikte bir story ya da ticket yazılır ve üzerinde çalışılır
- Süreçsel veya sosyal bir sorunsa retrospektifte tüm takımla konuşulur
- Bu noktada, yeni ekip arkadaşlarından birini bir süredir rahatsız eden ve görece basit bir çözümü olan bir ya da iki sorun bulmak iyi olur
- Retrospektif panosuna getirildiğinde sadece sizin rahatsız olduğunuz bir sorun olmayan bir şey seçilir
- Takım konuşması sırasında o ekip arkadaşının önerdiği şeyi hemen deneyebilecek bir aksiyon maddesine dönüştürülür
- Takım, yeni ekip üyesinin kendi sorunlarını çözmelerine yardımcı olduğunu hissetmeye başlar
Daha zor sorunlar ve yöneticiyle konuşma
- Zamanla takımın bildiği ama ele almaktan çekindiği yapışkan sorunlara gelinir
- Bunlar, “o kadar da kötü değil” diye görülen ama kimsenin dile getirmek istemediği şeyler olabilir
- Gerekli teknik yetkinlik eksik olabilir
- Merkezinde karmaşık insan ilişkileri sorunları olabilir
- Bu aşamada şimdiye kadar oluşturulan liste yöneticiye götürülüp konuşulur
- Birkaç haftadır görülenler
- Bazılarında ilerleme olduğu ama bazılarının daha uzun sürecek gibi göründüğü
- Gözden kaçan bir şey olup olmadığı
- Hangi alanlara odaklanılmasının istendiği
- Yönetici de aynı sorunlardan endişe ediyor olabilir ama takım çok rahatsız görünmediği için fazla zorlayamamış olabilir
- Sonrasında yöneticinin kaygıları ve sorunlar birlikte netleştirilir, geçmişte neyin işe yarayıp neyin yaramadığı konuşulabilir
- Yönetici sizi, iyi muhakemeye sahip ve daha zor sorunların çözümüne yardımcı olabilecek biri olarak görmeye başlar
Neden hemen dile getirmemek gerekir
- İstenen itibar, “Nat sorunlarımı çözmeme yardım eder”, “Nat benim önemli gördüğüm işleri tamamlar” şeklindedir
- Bu itibar, gelecek yılki performans değerlendirmesinde istenen sonucu almaya ve birkaç yıl sonra tavsiyelere dönüşmeye yardımcı olabilir
- Eskiden sorun fark edilir edilmez hemen dile getirilirdi
- Sonuç olarak “hep şikâyet ediyor”, “bizim hiçbir şeyi asla düzgün yapmadığımızı düşünüyor” itibarı oluşurdu
- İnsanlar dinlemeyi bırakır, kişi özel olarak hayal kırıklığı yaşar ve profesyonel olarak da etkisiz hale gelirdi
- Yeni bir ekip üyesi; aslında gerçek sorun olmayan, takımın sorun saymadığı, zaten çözülmekte olan ya da ilk bakışta fark edilmeyen basit bir çözümü bulunan bir konuda büyük gürültü koparırsa güven çok hızlı yıkılır
- Takımlarda her zaman iyileştirilebilecek çok sayıda sorun vardır ama gerçekten çözülebilecek olanlar bunların yalnızca bir kısmıdır
- Bir sorunun fark edilme sırası, onu çözmek için en etkili sıra nadiren olur
- WTF defteri, “bunu hemen şimdi düzeltmek istiyorum” dürtüsünü bir süreliğine kenara koyup neyle başlanacağına karar verecek bağlam oluşana kadar beklemeyi sağlar
1 yorum
Hacker News görüşleri
Bu yazının bir noktayı yeterince vurgulamadığını düşünüyorum: yeni bir kişinin bakış açısı yalnızca bir kez olur.
Ürün kullanılabilirliğini değerlendirmekte zorlanmamızın nedeni, onu nasıl kullanacağımızı zaten biliyor olmamız ve hatalara, kusurlara karşı duyarsızlaşmamızdır.
Yeni ekip üyesi henüz bu durumda değildir; bu yüzden ne sorduğuna, nerede takıldığına ve nerede gerçekten yardıma ihtiyaç duyduğuna bakmak ekibe çok fazla içgörü sağlayabilir.
Not defteriyle oturup not alıyor, kullanıcı ürünü kullanırken onunla konuşuyoruz.
Ne kadar çok terabayt telemetri verisi toplarsanız toplayın, gerçek kullanıcılarla konuşmak kadar ürünün nasıl kullanıldığını anlamanızı sağlamaz.
Teknoloji sektörü, diğer insanlardan korkma tutumunu biraz aşmalı.
Bu, deneyimli bir profesörün, yeni öğrenen bir öğrenciye bazı şeylerin açıklanmasının zor olduğunu unutmasına benzer.
Ancak herkes bunda aynı derecede kötü değildir; yeni başlayanın yerine kendini koyacak kadar empati ve ilgi sahibi olup olmamak büyük rol oynar.
Bash kabuğunu sayısız kez kullanmış iki kişinin bile, acemilere neyin tuhaf ve sezgisel olmadığını anlaması tamamen farklı olabilir.
Taze gözlerle bakmak da bir beceridir; tıpkı gerçek ışığı ve nesneleri gözlemleyip çizmeyi öğrenmek gibi eğitimle geliştirilebilir.
Hemen dile getirmek yerine not etmek, işlerin neden öyle olduğunu öğrenmek ve organizasyonun arazisini tanımak için zaman kazandırır.
Hesaplar, izinler, onaylar gibi şeyler düzene girdikten sonra o listeye dayanarak harekete geçebilirsiniz.
Böylece ekip de sizi “sürekli ortaya atılıp WTF diye bağıran kişi” değil, yardım etmeye çalışan biri olarak görme olasılığı daha yüksek olur.
12–15 kişilik ölçekte çok iyi çalışıyordu, ama daha büyük ölçekte iyi ölçeklenir mi bilmiyorum.
Not etmek ve beklemek anlık ve düşük yük getirir; “liste uzadı” gibi küçük bir ödülü de vardır, bu yüzden sistemli biçimde pratik yapılırsa kolayca yeniden öğrenilebilir.
Fark etme ve kaydetme aşamasını; daha sonra harita çıkarma, raporlama, öğrenme ve aynı sorun bilincine sahip insanları bir araya getirip yönlendirme aşamasından sürekli ayrı tutmasını seviyorum.
İş günlüğü tutmak her zaman iyi bir fikirdir, ama bu yazının tonunda rahatsız edici bir şey var.
Borg gibi davranan ya da 『How to Win Friends and Influence People』dan alınmış gibi duran bir senaryoyu izleyen biriyle çalışmak istemem.
Birinin beni manipüle etmeye çalıştığı izlenimini alırsam, en azından bunu fark ettiğim andan itibaren ona güvenmek zorlaşır.
Yine de yalnızca o ilk reddetme hissine kapılmamak iyi olur.
Benim de paydaşların beni nasıl hissetmesini istediğime dair hedeflerim var ve bunlar davranış ölçütü olarak oldukça faydalı oldu.
Teknik olarak iyi iş çıkarsam bile insan ilişkileri boyutunu görmezden gelince sorunlar çıktı; hakkımda nasıl söylentiler dolaştığı, nasıl algılandığım, işimin nasıl paketlendiği gerçekten önemliydi.
“Sadece işini iyi yapmak yeter” demek, işimin ve benim başkalarında nasıl bir his bıraktığının önemli olduğu gerçeğini ortadan kaldırmıyor.
『How to Win Friends and Influence People』ı hiç okumadım, ama yazının kendisini oldukça iyi yazılmış buldum.
İster deneyimli bir bireysel katkı sağlayıcı, ister yeni bir yönetici, ister bir subay olsun; ilk 30–90 gün boyunca hiçbir şeyi değiştirmemek, işlerin nasıl ve daha da önemlisi neden o şekilde yürüdüğünü anlamaya çalışmak gerekir.
Organizasyon açısından pek çok faydası vardır; kısaca söylemek gerekirse, pratikte bunu yapmanın yolu budur.
Mühendisler kötü yöneticilerle çalışmıştır ve neden kötü olduklarını tam açıklayamasalar bile çoğu zaman bunu hissederler.
O “kötü yönetici” hissi çoğu zaman taktik düzeyde iyi liderlik yapamamaktan kaynaklanır; mühendislik gibi liderlik de öğrenilebilir bir beceridir.
Sorun, ordu ya da üst düzey yönetici eğitimleri gibi bunu bilinçli olarak öğreten yerlerin çok olmaması.
İyi bir yöneticinin altında çalışmak istiyorsanız aslında iyi bir liderin altında çalışmak istiyorsunuzdur; liderlik de verimli C++ kodu yazmak gibi taktik bir beceridir.
Ekip üyelerinin tek tek ortaya koyabilecekleri toplamdan daha büyük hedeflere ulaşması için insanları koordine edip yönlendirme işidir; bazı açılardan manipülasyon gibi hissedilebilir.
Yine de ekibi dışarıdan gelen saçmalıklardan koruyan, gerekli kaynakları sağlayan, herkese açık şekilde övüp özelde eleştiren, aşırı mikro yönetim yapmadan yön veren, başarıyı tanıyıp ödüllendiren ve standardın altında performansı görmezden gelmeyen kişi genelde mühendislerin sevdiği liderdir.
Buna karşılık, teknik bilgisi olmayan MBA çıkışlı karizmatik bir siyasi oyuncu bu teknikleri kötü nedenlerle kullanırsa birlikte çalışmak istemeyeceğiniz biri olur.
Teknik rolden yönetici pozisyonuna yükselmiş ama yönetimin teknik beceriden farklı olduğunu kabul edemeyen kişiler de sık sık sevilmez.
Sonuçta sektörde yetkin liderlerin çoğalması için, bu tür yazıların yaptığı gibi liderliği belirsiz, doğuştan gelen bir sezgi değil, nasıl yapılacağı açıklanabilir taktikler olarak ele almak gerekir.
“Nat benim sorunumu çözer” diye bir itibar kazanmak tavsiye edilmek için iyi olabilir, ama kariyer açısından riskli olabilir
Bunu 20 yıl boyunca çeşitli departmanlarda yaptım; her seferinde beni sorun çözücü olarak elde tutmaya çalıştılar ama terfi adayı olarak öne çıkarmadılar
40 yıl çalışıp emekli olan bir meslektaşım da her türlü sorunu çözen biriydi ve yöneticilerden çok daha yetkindi, ama terfi edemedi
Herkesin kozuydu ama neredeyse hiç takdir görmedi; sorun çözmesi “zaten olması gereken” bir şey sayıldı ve ödüllendirilmedi
Aynı seviyedeki diğer insanlara çok daha düşük standartlar uygulanıyordu; son performans değerlendirmesinde bile yönetici “seni iş arkadaşlarınla değil, hedeflere karşı performansınla değerlendiriyorum” dedi
Ben de başka bir yöneticiden aynı şeyi duydum, yani tesadüf değildi
Her şeyden önce, yöneticim kendisinden gelmeyen talepleri engellerken her zaman benim tarafımdaydı
Tanımadığım biri önemsiz olmayan bir iş istediğinde zamanım ya da ilgim yoksa “Şu anda buna bakacak vaktim yok. Önceliklendirme gerekiyorsa lütfen yöneticimle konuşun” demem yeterliydi; 100 seferin 99’unda konu yöneticime kadar gitmiyordu
Bir departmanda ya da şirket genelinde başvurulan kişi olmanın en büyük avantajı, tanıdıklar ve bağlantı ağının birikmesidir
Ekip dışından bilgiye ihtiyaç duyduğunuzda ya da önemli bir iş için bürokratik süreçleri aşmanız gerektiğinde küçük bir süper güç gibi çalışır
Yeni fırsatlar ararken ulaşabileceğiniz bir ağ da oluşur; özel sektörde 15 yıl boyunca bulduğum işlerin tamamı bu şekilde bağlantılarla geldi
Ancak iki yaklaşımdan birinin terfi sürecinden iyi geçtiğini, diğerinin ise geçmediğini söyleyebiliriz
Kolay değil, ama sınır koymak önemli bir beceri
“Sorunu görür görmez hemen dile getirince Nat’in sürekli şikâyet eden ve ne yaparsak yapalım yanlış bulduğumuzu düşünen biri olduğu yönünde bir itibar oluştu” kısmı yazının en üstlerine yakın olmalı
Bu düzeyde öz farkındalık, öğrenmeye değer gerçek bir beceri
Eski astronot Chris Hadfield da kitabında yeni bir göreve ve ekibe katılırken benzer bir yöntem kullandığını söylüyor
Önce gözlem moduna geçip WTF anlarının gerçekten geçerli olup olmadığını öğrenmek ve yeni ekip üyesini sinir bozucu biri hâline getirmemek anlamına geliyor
Okumaya değer
Uzun süre aynı pozisyonda çalışınca, gürültüyü süzüp koyacak bir yer oluşturuyor; en azından kafanızın içinde olduğu gibi kalmıyor
Bu yalnızca sorunların geçerli olup olmadığını değerlendirmek değil, bazı şeyleri bırakmayı öğrenmekle de ilgili
Hangi kitap olduğunu söyleyebilirsen iyi olur
Zaten var olan bir ortama girerken genelde böyle bir yaklaşımla hareket ettim
İlk hafta her şeyi gözden geçirirken soruları ve gözlemleri not ederim
Yalnızca “WTF” anlarını değil, iyi çalışan şeyleri ve gerçekten iyi bir fikir gibi gelenleri de kaydederim
Ancak ondan sonra gözden geçirip önceliklendirir ve tartışmaya geçerim
Bu, Chesterton’ın çiti ile iyi örtüşen bir ilke gibi görünüyor
Bir çiti kaldırmak isteyen kişiye “Ne işe yaradığını bilmiyorsan kaldırmana izin veremem. Git düşün; ne işe yaradığını anladığını söyleyebildiğinde kaldırmana izin verilebilir” denmesi hikâyesi
Daha açık söylemek gerekirse, bir şey tuhaf görünse bile sizden önce gelenlerin akıllı insanlar olduğunu ve bunun bir nedeni bulunduğunu varsaymak daha iyidir
O neden artık eskimiş olabilir, ama dikkate almazsanız aynı hatayı tekrarlarsınız
Düzeltmek istediğiniz şeylerin listesini tutmakla kalmayıp, zamana bıraktığınızda neyin neden öyle olduğunu anlayabildiğiniz için iyi bir fikir
Aceleyle yapılmış ya da hata içeren pek çok durum olabilir, ama bazen yalnızca tek bir kod satırına bakarak hemen anlaşılması zor olan gizli karmaşıklık gerçekten vardır
İlki bariz bir başarısızlıktır; ikincisi ise o ortama yeterince gömüldüğünüzde genelde çözülür
Yine de ikisini de not etmek faydalıdır
Tam da bu hafta iki meslektaşıma bilgisayarımda “How the F” dosyası tuttuğumu söylüyordum
Yazarın anlattığıyla tamamen aynı değil ama çok benzer; yeni bir ekibe girdiğimde sorun çıktıkça “Bunu yine nasıl yapıyorduk?” dedirten her şeyi not ediyorum
Orijinal metindeki gibi yöneticime götürmüyorum, ama ekibin ve şirketin takıldığı noktaların ne olduğunu anlamak ve zamanla çözmek için bir bakış açısı sağlıyor
Aklıma gelen tüm fikirleri bir listeye yazarak yaşıyorum
Özel bir sırası yok; kâğıda ya da bir metin dosyasına sürekli ekliyorum
Fikirler ihtiyaç duyduğunuz anda pek gelmiyor; başka işler yaparken gün boyunca geliyorlar ve yazmazsam en azından ben hatırlamıyorum
Bir şey yapmam gerektiğinde tek tek silmem yeterli oluyor; böylece sırada ne yapacağımı düşünmem gerekmiyor ve fikirler tükenmediği için oldukça büyük bir üretkenlik patlaması mümkün oluyor
Kişisel yapılacaklar listesini düzenlemekten bahsediyor gibi; oysa orijinal metin ekip içinde uyum sağlama ve iletişim kurma yöntemiyle ilgili
Hayat notları düzenlemek için çok kısa; bence her şeyi yazıp ters kronolojik sıralamaya ve aramaya güvenmek daha iyi
İronik biçimde, harika fikirlerden oluşan bir hazine sandığım olduğunu biliyorum ama bu yaşa gelince onları 20’li yaşlarımdaki gibi hayata geçirecek kadar umursamıyorum