Backlog’a bakıp “Ne kadar çok iş var, bayağı ilerliyoruz” demek kolay. Filtre ekle, endpoint aç, butonu taşı, export yap... Kutular kapandıkça insana güzel bir düzen hissi geliyor. Ben de bu hissi seviyorum; dağınık şeylerin sıraya girmesi rahatlatıcı. Ama bazen bütün ticket’lar kapanıyor ve kullanıcının derdi olduğu yerde duruyor.
“Feature değil problem yönetmek” derken çözüm üretmeyelim demiyorum. Tam tersine, çözüm bulma hevesimizi beş dakika tutup önce gerçekten neyin bozuk olduğunu anlamaya çalışalım diyorum. O beş dakika bazen haftalarca yanlış iş yapmayı engelliyor.
Feature talebi nereden gelir?
Bir paydaş “Remote Start butonu ekleyelim” dediğinde bu cümle genellikle çözüm biçiminde paketlenmiş bir sinyaldir. Altındaki problem farklı olabilir: kullanıcı mevcut aksiyonu bulamıyordur, cihaz state’i geç güncelleniyordur, authorization başarısızdır veya operasyon ekibi belirli işlemi uzaktan yönetemiyordur.
Butonu doğrudan backlog’a koyarsak bu olasılıkların hepsini aynı çözümle kapatmaya çalışırız. İlk refleks “hayır, buton yapmayalım” olmamalı. Benim yapmaya çalıştığım şey, butonu bir kenara not edip biraz meraklı davranmak: Neden istiyoruz, kim takılıyor, bugün ne oluyor?
Ben iyi bir problem tanımında şu bileşenleri arıyorum:
- Problemi kim yaşıyor?
- Hangi journey adımında ortaya çıkıyor?
- Ne sıklıkta ve ne büyüklükte?
- Kullanıcı veya operasyon etkisi nedir?
- Hangi log, SQL sorgusu, görüşme veya ticket bunu kanıtlıyor?
- Problem çözülürse hangi metrik değişmeli?
Bu sorular cevaplanmıyorsa elimizde problem değil, hipotez vardır. Hipotez de değerlidir; yalnızca kesin gerçek gibi planlanmamalıdır.
Jira nasıl feature fabrikasına dönüşür?
Feature başlığı kolay estimate edilir ve kolay raporlanır. “Buton tamamlandı” net bir durumdur. “Başlatma başarısızlıklarını azalt” ise birden çok ekip ve bilinmeyen içerir. Organizasyonlar bu belirsizlikten kaçmak için sonucu değil çıktıyı planlamaya eğilimlidir.
Sonra roadmap bir alışveriş listesine, sprint raporu da kapanan ticket sayısına dönüşüyor. Herkes yoruluyor, sistem büyüyor, kullanıcı metriği kıpırdamayınca listeye yeni bir feature daha ekliyoruz. Çok çalışıp aynı yerde kalmanın en düzenli yolu bu olabilir.
Bir problemin birden fazla çözüm sınıfı vardır
Gerçek problem netleştiğinde çözüm her zaman yeni yazılım olmayabilir:
- Mevcut UI metni veya sıralaması değişebilir.
- Veri kalitesi düzeltilebilir.
- Operasyon süreci sadeleştirilebilir.
- Kullanılmayan özellik kaldırılabilir.
- Alarm veya destek akışı geliştirilebilir.
- Bazen hiçbir şey yapılmayabilir.
Bu seçeneklerin her birini maliyet, risk, geri döndürülebilirlik ve beklenen etkiyle karşılaştırmak gerekir. Küçük ve reversible bir deney, büyük feature’dan daha fazla öğrenme sağlayabilir.
Acceptance criteria çözümü değil sonucu korumalı
Kabul kriterleri yalnızca UI veya API davranışını tarif ederse ekip tam olarak isteneni yapıp problemi çözemeyebilir. İyi kriter iki katmanlıdır:
- Ürün sonucu: Hangi kullanıcı veya operasyon davranışı iyileşecek?
- Teslimat güvenliği: Hangi edge case, yetki, gözlemleme ve rollback koşulu korunacak?
Örneğin “buton görünür” teslimat kriteridir. “Uygun state’teki kullanıcı işlemi tamamlayabilir, uygun olmayan state’te açıklayıcı sonuç alır ve başarısızlık ölçülür” ise problem alanını daha iyi korur.
Release sonrası öğrenme
Feature yayınlandığında task kapanabilir; problem henüz kapanmamıştır. Önceden seçilen metriğe, segmentlere ve yan etkilere bakılmalıdır. Başarı gelmediyse iki olasılık vardır: çözüm zayıftır veya problem tanımı yanlıştır. İkisi de yeni bilgi üretir.
Problem yönetmek roadmap’i belirsiz bırakmak değildir. Belirsizliği görünür hale getirip çözüm yatırımını kanıtla büyütmektir. Ekibin başarısını “ne kadar feature çıkardık?” yerine “hangi problemi ne ölçüde azalttık?” sorusuyla değerlendirmektir.
Benim için mesele kusursuz bir discovery süreci kurmak değil. Bazen yalnızca ticket başlığını “şu ekranı yap” yerine “şu kullanıcı neden burada kalıyor?” diye değiştirmek bile konuşmayı değiştiriyor. Küçük bir dil farkı gibi görünüyor ama ekip hangi cevabı aradığını hatırlıyor. Ben de PM olarak yapılacaklar listesini değil, merakımı yönetmeye geri dönüyorum.