Yazılımcılar Ürünü Sahiplenmek İstemediğinde Ne Yapılır?

Yazılımcı "Ürün Beni İlgilendirmiyor" Dediğinde Ne Olur?

Ürün ekiplerinde çalışan hemen herkesin er ya da geç karşılaştığı bir cümle vardır: "Ya ben sadece kodu yazıyorum, ürün beni çok ilgilendirmiyor." Bunu bazen bir yazılımcıdan, bazen bir testçiden, bazen de ekran tasarımına odaklanmış bir tasarımcıdan duyarsınız. Özellikle finans gibi domain bilgisi ağır basan bir üründe çalışıyorsanız, bu "sahiplenmeme" hâli ekibin temposunu doğrudan etkiler. Soru aslında sadece motivasyonla ilgili değil; ortaya çıkan iş kalitesini, koordinasyonu ve uzun vadede ekibin kültürünü ilgilendiriyor.

Kısa cevap şu: Ekibinde "ben sadece kendi parçama bakarım" diyen biri olduğunda bunu disipline edip cezalandırmaktan çok, iletişimle çözmek gerekiyor. Çünkü çoğu zaman kişi, domain bilgisinin kendi işinin kalitesini nasıl etkilediğinin farkında değildir. Bunu fark ettiği anda da tablo değişmeye başlar.

"Ben Sadece Kodu Yazıyorum" Cümlesinin Arkasındaki Yanılgı

Bu cümleyi söyleyen bir yazılımcı genelde iyi niyetlidir. Kendi alanında derinleşmek, kodun kalitesine odaklanmak istiyordur. Sorun şu ki, kodun kalitesi sandığımız kadar bağımsız bir değişken değildir.

Bir geliştiricinin yazdığı kodun kalitesini, business'ı (iş alanını) ne kadar bildiği doğrudan etkiler. Çünkü iyi kod sadece temiz syntax demek değildir; karşılaşılabilecek senaryoları, edge case'leri, riskleri öngörebilmek demektir. Domain'i tanımayan biri, kodunu ne kadar şık yazarsa yazsın, iş tarafından gelecek pürüzleri göremez. O pürüzler de er ya da geç production'a sızar.

Aynı durum testçi için de geçerlidir. Hatta testçi tarafında biraz daha kritiktir.

Testçi Aslında Ne Kadar Product Owner'dır?

Buradaki bakış açısı net: Bir testçinin ürünü, en az bir product owner kadar sahiplenmesi ve bilmesi gerekir. Kulağa abartılı gelebilir ama mantığı oldukça basit.

Testçi, ürünü tanımıyorsa etki analizini (impact analysis) sağlıklı yapamaz. Etki analizini yapamayınca, test senaryolarını da eksik kurgular. Sonuç? Bug'lı işlerin live'a çıkması kaçınılmaz hâle gelir. Sahada en sık duyulan savunma cümlelerinden biri de şudur:

"Ben önüme geleni yaptım, analizden anladığımı test ettim. Ama bunu düşünemedim."

Bu cümlenin altındaki gerçek sebep çoğu zaman yeteneksizlik değil, ürünü bilmemektir. Çünkü ürünü bilen bir testçi, analiz dokümanında yazmayan riskleri de tahmin edebilir. Bilmeyen testçi ise sadece kendisine söyleneni doğrulayan bir mekanizmaya dönüşür ki bu, testin asıl değerini yok eder.

Sahiplenmeyenle Ne Yapılır?

Bu noktada en güçlü araç, iletişim. Ekibin koordinasyonunu taşıyan kişi için iletişim bir nezaket meselesi değil, doğrudan bir silahtır. Çünkü "benim kodumun kalitesi benim için önemli, business beni ilgilendirmiyor" diyen birine kuralla, prosedürle yaklaşmak işe yaramaz. Onun yerine, business bilgisinin kendi işine nasıl geri döndüğünü göstermek gerekir.

Bunu yaparken birkaç pratik yaklaşım işe yarar:

• Sebep-sonuç ilişkisini somutlaştırın. "Domain'i öğrenmelisin" demek yerine, bilmediği için gözden kaçırdığı bir riski örnek üzerinden gösterin.
• Sahiplenmeyi rol tanımının içine yedirin. Testçinin işi sadece test koşmak değil, ürünü anlamaktır. Bu beklenti açıkça konuşulmalı.
• Ortak ritüeller kurun. Refinement, demo, retro gibi anlarda herkesin ürün hakkında konuşması, domain bilgisinin doğal yoldan dağılmasını sağlar.
• Bilenle bilmeyeni eşleştirin. Domain'e hâkim bir geliştiriciyle, sadece teknik tarafa bakan birini aynı feature'da çalıştırmak, çoğu zaman uzun toplantılardan daha etkilidir.

Bu yaklaşımların ortak noktası, kişiyi "yanlış yapıyorsun" pozisyonuna sıkıştırmamak. Daha çok, "aslında senin de işine yarayacak bir şeyden bahsediyorum" çerçevesini kurmak.

Kültür Kendi Kendini Eler

İlginç olan şu: Bu süreç bir yerden sonra kendi kendini düzenlemeye başlıyor. Ürünü sahiplenmeye direnen, domain'i öğrenmeye ilgi duymayan kişiler zamanla ekip kültürünün dışında kalıyor. Buna doğal seçilim demek mümkün.

Çünkü ürün odaklı çalışan bir kültürde, herkes ürünün dilini konuşurken sadece kendi teknik adasında duran biri yalnızlaşır. Bir süre sonra bu insanlar ya kendiliğinden yoldan ayrılır ya da ekibin temposuna ayak uyduramadığı için süreçten elenir. Bu sert bir cümle gibi durabilir ama gerçekçi olan da bu.

Gerçek Hayatta Bu Nasıl Görünüyor?

Düşünün: Bir finans uygulaması üzerinde çalışıyorsunuz. Yazılımcı, kendi parçası olan ödeme servisini son derece temiz bir kodla yazıyor. Ama bir kullanıcının belirli bir limit üzerinde işlem yaptığında devreye giren ek bir mevzuat kuralından haberi yok. Çünkü "o iş tarafının konusu." Kod canlıya çıkıyor, müşteri şikayeti geliyor, ekip geri dönüp düzeltiyor. Aslında o riski, business'ı bilen bir geliştirici çoktan önceden konuşmuş olurdu.

Ya da bir testçi düşünün. Yeni bir özelliğin testini koşuyor, analiz dokümanındaki tüm senaryoları geçiyor. Ama o özelliğin başka bir modüldeki rapor ekranını nasıl etkilediğini bilmiyor. Çünkü ürünü uçtan uca tanımıyor. Sonuç olarak fonksiyonel olarak çalışan ama raporları bozan bir feature canlıya çıkıyor.

Her iki örnekte de teknik yetenek değil, sahiplenme eksikliği belirleyici.

Sıkça Sorulanlar

Her yazılımcı domain'e ilgi duymak zorunda mı?

Duymak zorunda değil ama işinin kalitesini önemsiyorsa, domain'i en azından temel düzeyde bilmesi gerekir. Çünkü kod kalitesi ve domain bilgisi düşündüğümüzden çok daha iç içe.

Sahiplenmeyen birini nasıl ikna ederim?

Kuralla değil, somut örneklerle. Domain'i bilmediği için kaçırdığı bir riski ya da neden olduğu bir bug'ı birlikte konuşmak, çoğu zaman uzun motivasyon konuşmalarından daha etkilidir.

Testçinin product owner kadar ürünü bilmesi abartı değil mi?

Değil. Çünkü testçi, ürünün canlıya çıkmadan önceki son güvencesi. Etki analizini yapacak kadar ürünü tanımıyorsa, o güvence çatlamış demektir.

Bu sahiplenme meselesi sadece yazılımcı ve testçi için mi geçerli?

Hayır. Tasarımcı da sadece ekran çizmekle yetinirse, kullanıcı akışındaki domain odaklı incelikleri ıskalar. Aynı dinamik tüm roller için geçerli.

Sahiplenme, Bir Yetenek Değil Bir Tercih

Ürünü sahiplenmek teknik bir beceri değil, bilinçli bir tercih. Bu tercihi yapan insanlar, sadece kendi alanlarında değil, ekibin geri kalanıyla kurdukları ilişkide de daha güçlü hâle geliyor. Yapmayanlar ise zamanla ekibin temposunun dışına düşüyor.

Dolayısıyla "ürün beni ilgilendirmiyor" cümlesini duyduğunuzda, bunu bir tutum problemi gibi değil, bir farkındalık eksikliği gibi ele almak daha sağlıklı. İletişimle, somut örneklerle ve ortak ritüellerle bu farkındalık çoğu zaman oluşuyor. Oluşmadığında da kültür, gerisini kendisi hallediyor.