Özellik fabrikasında çalışıyor olabilir misiniz?
Özellik Fabrikasında takımlar düzenli olarak işlerinin etkisini ölçmezler, büyük resimden haberleri olmaz, ne yöne gitmeleri gerektiğini bilmezler ve değerlerini ölçmek için ellerinde hiçbir metrik yoktur.
“Değerli olanı yapmak” serisinin son yazısını yazmadan önce, ara bir yazı ile ne olunmaması gerektiğini yazmak istedim.
Şirketler çevik dönüşüm sürecinden geçerken çoğunlukla teslimata odaklanıyor. Odak bir noktadan sonra çevikliğinin artırılmasından çok yazılım geliştirme süreçlerinin çeşitli pratiklerle iyileştirilmesiyle sınırlı kalıyor.
“Waterfall” hedefler/metrikler ve farklı seviyelerdeki eski alışılmış süreçler takımları değer üretme odağından uzaklaştırıp çıktı adedine odaklı “feature factory/özellik fabrikası” haline getiriyor.
“Özellik Fabrikası” terimi Zendesk’in eski kıdemli ürün yöneticilerinden John Cutler’a ait. Ona göre, tipik bir özellik fabrikasında takımlar düzenli olarak işlerinin etkisini ölçmezler, büyük resimden haberleri olmaz, ne yöne gitmeleri gerektiğini bilmezler ve değerlerini ölçmek için ellerinde hiçbir metrik yoktur.
Cutler’a göre özellik fabrikası, çıktıların (output) sonuçların (outcome) üzerinde görüldüğü yerdir. Sadece ne kadar teslim edildiğine odaklı bir “story point” makinesi gibi çalışır. Organizasyon işin yapılmasını kutlar, tek yönde çalışan taşıma bandı gibi hissettirir. Kimse şu soruyu sormaz;
Gerçekten değerli bir şey yapıyor muyuz?
Fabrikada çalışanlarla bilgi işi yapanlar arasında temel bir fark var: Çıktı aynı şekilde ölçülmez.
“Success is not checking a box. Success is having an impact. If you complete all tasks and nothing ever gets better, that’s not success.” -C. Wodke
Cutler, bir özellik fabrikasında çalışıp çalışmadığınızı anlamanız için bazı ipuçları veriyor;
Ölçüm yapılmaz. Takımlar işlerinin etkisini ölçmezler. Ölçüm yapılıyorsa da başka bölümlerce yapılır ve sonuçlardan sadece ilgili olduğu düşünülen bölümler seçilerek paylaşılır. Takım üyelerinin yaptıkları işin çalışıp çalışmamasıyla ya da etkisiyle ilgili fikri yoktur.
Gündem sürekli değişir. Üst seviyede bir misyon ve girişimde odaklanmak yerine, takımlar sürekli değişen işler arasında gidip gelir. Aynı anda birden fazla işle ilgilenme ve kapasite üzerinde iş alınması kronik hale gelmiştir.
Etkisinden bahsedilmeden, teslim edilen işlerle ilgili başarı tiyatrosu oynanması. Bir organizasyonun neleri kutladığına bakarak o organizasyonla ilgili pek çok şeyi anlayabilirsiniz. Değerin ön planda olduğu yerde, insanlar sadece çıktı adedine bakarak işin başarılı olduğunu düşünmez.
Sorunlu işler ya da başarısızlıkların dile getirilmemesi. Ana başarı ölçüsü iş sonuçları değil, işin teslim edilmiş olmasıdır. İşler, iş boyunca toplanan veri ve öğrenmeler sonucunda hiçbir zaman iptal edilmez, yönü değişmez. Genelde takım kötü şeyleri konuşmak için yeterli güvenli alana sahip değildir.
Temel metriklerle bağlantının olmaması. İş ve müşteriye sağlanması arzulanan sonuçlar hakkında sıkça konuşulmaz. Takım yapmakta olduğu işi, müşteri memnuniyeti ve pazarla ilgili diğer metriklerle ilişkilendiremez. “En önemli olan” ile, üretilen özellikler arasında ilişki kurulamıyordur.
Önceliklendirme konusunda takıntı. Önceliklendirme konusunda titizlik (hangi işler üzerinde çalışıldığı) ve doğrulama konusunda titizlik (bu gerçekten de yapılması gereken en doğru iş miydi) arasında uyumsuzluk vardır. Önceliklendirme konusundaki özen, şirket içi çeşitli ihtiyaçlara göre insanların “kendinden emin” hissetmesi için önemlidir. Hangi işlerin üzerinde çalışılacağına çok fazla emek harcanır, veriye dayalı iyileştirmeler ve öğrenmelerden çıkacak doğaçlama kararlar için çok az zaman bırakılır. Yol haritaları net iş listesi şeklindedir, odak alanları ya da çıkması beklenen sonuçlar (outcome) üzerine olmadığından doğru bile olsa yön değiştirme plana uymamak şeklinde değerlendirilir.
İnce ayarlar yapılmaz. İş bir kez yapıldı mı, takım hemen bir sonraki projeye geçer, niteliksel ve niceliksel verileri değerlendirip iyileştirme yapmak için zaman bırakılmaz.
Elden ele kültürü. “İşin önünde yer almak” için önden tamamlanmış süreçler tasarlanmıştır, böylece geliştirilmesi gereken her şey “mühendislik için hazır” haldedir. Takımlar doğrudan araştırma, sorun alanının keşfi ya da deney ve doğrulamaya dahil olmaz. İş bir kez tamamlanıp çıkıldığında, takımın destek, müşterinin iş sonuçları ya da satışla teması olmaz.
Büyük parçalar. Deney zorunluluğu olmadığından, özellikler artarak biriken küçük parçalar olarak değil, tek büyük parçalar olarak teslim edilir. “Sprint”lerle çalışanlar bile, her sprint’in sonunda pazara sunulabilecek şekilde müşteriye yeni bir şey ulaştırmaz.
Göz alıcı nesneler. Refactoring işleri ve teknik borçun azaltılması değerli şekilde gösterilmez, böyle olunca ekibin toplamdaki değer teslimi yeteneği tam yansıtılmaz. Daha önce konusu geçtiği gibi, başarının ana ölçüsü yeni işlerin teslim edilmesidir. Parlak, göz alıcı özellikler yanında ürünün bir bütün olarak sağlığı göz ardı edilir. Var olan ürünün kullanılabilirliği, devam ettirilebilirliği ve genişleyebilirliği üzerinde yeni özelliklerin etkisiyle ilgili çok az farkındalık vardır.
Özellik fabrikasının altında yatan varsayımlardan birisi takımın neyi yapacağına kendi başına karar veremeyeceğidir, bu yaklaşım da Taylorcu, “planlayanlar” ve “yapanlar” ayrımına dayanıyor.
Yalın yönetimden hatırlayalım, işle ilgili en çok bilgisi olan kişiler işe en yakın olan kişilerdir. Yapacağı işle ilgili takımın bir sözü yoksa, sadece “backlog”’tan sırayla iş eksiltmelerini bekliyorsak onlardan tam anlamıyla faydalanamıyoruz demektir. Müşteriye ve işe en yakın olan kişilerin tecrübe ve öğrenmelerini kaldıraç olarak kullanmamız gerekir.
“… teams are just there to flesh out the details, code and test, with little understanding of the bigger context, and even less belief that these are in fact the right solutions. …If you’re just using your engineers to code, you’re only getting about half their value.” — Marty Cagan
Gerçekten otonom, kendi kendine organize olabilen takımlar yaratabilmek için, takımlara istenilen değerli sonuçlara nasıl ulaşacaklarıyla ilgili karar özgürlüğü vermemiz gerekir. Takımların hedefinin “paydaşların istediği işlerin yapılması”ndan, “üzerinde anlaşılan iş sonuçlarının başarılması” olarak değişmesi gerekiyor.
Henrik Kniberg’in takımlar için “Neden?” sorusuyla ilgili aşağıdaki görseli çok şey anlatıyor;
Size de yaptığınız işler, çalıştığınız konularda bu anlattıklarımdan birisi ya da birkaçı tanıdık geldi mi?
Septomları gördük, peki çözüm ne olabilir? Cutler doğrudan bununla ilgili bir çözüm önermiyor, ama söylediklerinden yola çıkarak aşağıdaki gibi çözümler faydalı olabilir.
Her değişiklik için ölçülebilir iş etkisi hedefi koyun. Okulda hepimize bilimsel yöntemleri öğrettiler, bir teoriniz vardır, nasıl ölçeceğinize karar verirsiniz, bir deney yapar ve sonuçlarını kaydedersiniz. Genelde teorilerimizin yanlış olduğu çıkar, bir öğrenme yaparız. Özellik fabrikasında da, iş sonuçlarını ölçmeyi bir alışkanlık haline getirmemiz gerekiyor, başarılı olursa amacımıza ulaşmış oluruz, başarısız olursa da başarılı olana kadar deney yapmaya ve öğrenmeye devam edebiliriz.
Farkındalığı artırmak adına, John Cutler’ın biraz da tahrik etmek adına yaptığı öneri gerçekten de denenebilir diye düşünüyorum.
Çapraz fonksiyonel takım çalışmasını daha ileriye götürün. Farklı departmanlardaki kişiler birlikte bir ürün yaratmaya çalıştığında, bu gayret genelde waterfall bir süreç ve holistik olmayan bir deneyim/çözümle sona erer. Çapraz fonksiyonlu bir takım aslında özellik fabrikasından çıkıp “doğru şey”i teslim etme yeteneği getirir, çünkü hem herkes bütün halinde üründen sorumlu (iyi ve kötü) olur hem de kollektif olarak ürünün başarısı üzerine odaklandığı için holistik bir yaklaşımla takım olarak değer üretir.
Üretime çıkışları/sürümleri değil iş sonuçlarını kutlayın. Sonucuna bakmadan sürekli versiyon çıktığımız bir ortamda, niceliksel olarak verimli gözüksek de her versiyon ile olumlu bir iş sonucu üretemeyebiliriz. Versiyon çıktığınız için değil (bu zaten sizin göreviniz), ürettiğiniz iş sonuçlarını kutlayın. Cutler, bunun aksini “başarı tiyatrosu” olarak adlandırıyor.
Öğrenme ve başarısızlık için güvenli bir kültür geliştirin. Bir işe başladığımızda pek çok varsayımla yola çıkarız. İş tamamlanmadan bir kıpırtı ya da öğrenme de olmayabilir. Takımların yenilikçi olabilmeleri ve gerçekten ne istendiğini keşfetmeleri için alana ihtiyaçları olur. Ekip üyeleri bunu ancak risk almayı teşvik edici ortamlar sayesinde yapabilir, hata yapabilir, öğrenebilir ve sonunda hem bireysel hem de takım olarak büyüyebilirler.
Kapasite kullanımı/verimlilik değil değere odaklanın. Eğer takım sürekli mümkün olan en çok çıktı üretmelerine zorlanırlarsa, varsayımları test edecek gerekli rahat ve yaratıcı zihin yapısına hiçbir zaman sahip olamayacaktır. Hedefimiz verimli olmak olduğunda değer üretmemiz garanti olmaz, ancak değer üretmeye odaklı olursak ekibi en verimli şekilde kullanmış, onlara değer ürettirmiş oluruz.
Daha sık, daha çok değişiklik üretime çıkın. Daha düşük ve etkili öğrenme fırsatları oluşturarak ve maddi olarak daha az “waste” yaratarak mümkün olduğunca hızlı denemeler yapıp, mümkün olduğunca erken geri bildirim alabilirsiniz. Bu hem belli büyüklüğün üzerindeki işlerin üretim aşamalarını tıkamasını engeller hem de kararlarınız ve doğrulamalarınızla ilgili çevikliğinizi artırır.
lTunes’daki pratiklerimizin pek çoğunun arkasında da sürdürülebilir değer üretme gayreti var;
- Takım dashboard’unda 25 metrik tuttuğumuzu yazmıştım, “Lean” metrikler gibi verimlilikle ilgili metriklerin yanında iş değeri, iş parçaları, öğrenme, memnuniyet, mutluluk, takımdaşlık gibi pek çok boyutta metrik tutmamızın nedeni işimizin merkezinde insan olması ve takımların değer üretim merkezleri olarak insanlardan oluşmaları…
- Backlog’taki işler için paydaşlarla “değer” değerlendirmesi yapıp, CoD’yi belirliyoruz ve önceliklendirmeyi WSJF ile yapıyoruz.
- İşler tamamlandıktan sonra müşteriye gönderilen iş bazlı anketin sadece görevimizle ilgili bir değerlendirme olduğunu biliyoruz, o yüzden Alper’in de önerisiyle en başından bu yana iki ayda bir anonim müşteri memnuniyeti anketleri yapıyoruz. Bu ankette 1–10 skalada memnuniyeti ve NPS’i ölçüyoruz.
- Her Cuma, 14–15 arası yaptığımız lTunes Talks ile sürekli öğrenmeyi bir alışkanlık haline getirmeye çalışıyoruz, bu aynı zamanda bir metrik olarak ta takım dashboard’unda takip ediliyor.
- Sürekli teslimat döngüsü içinde biraz nefeslenip, işimizi sorgulamak, yöntemlerimizi değerlendirmek, yeni şeyler denemek için Farklı Şeyler Günü yapıyoruz. Bu gün boyunca ekip üyeleri kendi iç motivasyonuna uygun şekilde bu günü rutin teslimat dışında empati, fikir geliştirme, deney, validasyon, öğrenme, teknik mükemmellik ve ürün yönetimi gibi konularla geçiriyorlar ve gün sonunda sunum yapıyorlar.
lTunes şu an kendi performans değerlendirmesini kendisi yapıyor. Bizim için bir sonraki adım gerçek iş sonuçlarıyla yapılan işi eşleştirmek… Bunu OKR kullanarak çeyrek dönemlerde kontrol edip iş/pazar boyutundaki performansımızı görmek istiyoruz.
OKR kullanımıyla ilgili yolculuğumuzu tecrübe ettikçe ayrıca paylaşacağım.
