Bir staff engineer işe değer sorunları nasıl buluyor

Verimlilik aracı Perfetto üzerinde çalışan bir staff engineer, terfiye hazırlanan meslektaşları “üzerinde çalışmaya değer sorunları nasıl bulurum” diye sorduğunda verdiği yanıtı yazıya döktü. Yöntemi takvime yazılmış “stratejik düşünme” saati değil; sünger gibi dinleme ve sorunların birikmesine izin verme alışkanlığı.

İstekleri değil sorunları emmek

İnsanlar zorluklarını sürekli anlatır: toplantılarda, sohbetlerde, sunumlarda ve e-postalarda. Bir şey onun alanına dokunduğunda yazar ipi çekmeye başlar: isteği olduğu gibi kabul etmek yerine, varsayımsal bir özelliğin sorunu çözüp çözmeyeceğini ya da mevcut bir özelliğin ihtiyacın ne kadarını karşıladığını sorar. Kullanıcılar, diye not ediyor, genellikle altta yatan sorunu anlatmak yerine belirli bir çözüm ister.

Bir sorun araştırmaya değer görünüyorsa daha etkin hale gelir: ekiple oturur, iş akışlarını izler, inceledikleri hataları kendisi yeniden üretmeye çalışır. Ayrıca kurumu ondan daha geniş gören insanları arar — kritik sistemlerin sahiplerini, birden çok ekipte çalışan mühendisleri — çünkü onlar aynı sorunu çoğu zaman birkaç yerde birden fark etmiştir.

Sorunların birikmesine izin vermek

Yüksek sesli bir ekibin isteğiyle çok hızlı hareket edip ardından neredeyse hiç kullanılmayan bir özellik geliştirdiği için yanmış. Bu yüzden not alır ve bekler. Aynı sorunun birkaç ekipte bağımsız olarak ortaya çıkması daha güçlü bir sinyaldir; farklı görünen sorunlar tek bir çözümün karşılayacağı ortak bir biçimi paylaşabilir; bazen de isteyen ekip özelliğe hiç ihtiyacı olmadığını anlar.

Bir fikir şekillenmeye başladığında, onu kafasındaki diğer sorunlarla sınar — çoğu zaman Londra'da uzun yürüyüşlerde. Zarafet hissine karşı dikkatlidir: iki sorunu birden çözdüğünü düşündüğü bir fikir, bir RFC ve prototip sonrası ikiye bölündü, çünkü ayrı ele alınmaları daha iyiydi; her iki parça da yayımlandı.

Özellik isteklerinden eklentilere

Perfetto, sistem etkinliği kayıtlarını “track” adı verilen satırlardan oluşan bir zaman çizelgesinde gösterir. Yıllar içinde ekipler dar kapsamlı arayüz özellikleri istedi: kendi trackleri en üstte kalsın, kayıt belirli bir bölüme yakınlaştırılmış açılsın, özel bir toplama gösterilsin. Yazar, gerçek ihtiyacın tek bir özellik değil, arayüzü bir ekibin tercihlerini herkese dayatmadan genişletebilme yeteneği olduğu sonucuna vardı. Eklentiler vardı, ancak tüm eklenti kodunun açık kaynak yapılmasını gerektiriyordu ve bu birçok iç ekibe uygun değildi.

Öneriyi yöneticisiyle, ekip arkadaşlarıyla ve müşteri ekipleriyle tartıştı, iki RFC yazdı, bire bir görüşmeler ve sunumlar yaptı; ardından “hafif eklentiler” olarak makroları ve ekiplerin bunları paylaşabilmesi için extension server'ları tasarlayıp yayımladı. Bugün Google içinde düzinelerce ekip makroları ve extension server'ları kullanıyor, birkaç başka şirket de extension server'ları kendi içinde kullanıyor.

Neden önemli

Ne kadar ileri gideceği güvene bağlı: bazı değişiklikleri doğrudan yapar, emin olmadığı fikirleri tek kullanımlık bir prototiple sınar, büyük olanlar ise haftalar ya da aylar süren destek inşası gerektirir. Getirisi birikir: yardım gördüğü mühendisler daha erken geri gelir ve meslektaşlarını getirir. Bir uyarı: bu yaklaşım yol haritaları üzerinde aşağıdan yukarıya özerklik gerektirir ve bunu her şirket sunmuyor.