Tek bir müşteri için özellik geliştirmek her zaman yanlış değildir. Bazen yeni ve değerli bir kullanım alanını gösterir; bazen de ürünün yönünü tek hesaba bağımlı hale getirir. Kararı yalnız müşterinin gelir büyüklüğüyle vermek, bakım ve fırsat maliyetini görünmez bırakabilir.
Bu yazı özellik değerlendirmesi için önerdiğim bir karar kartıdır. Herhangi bir müşterinin talebini veya projede verilmiş ticari taahhüdü açıklamaz. Örnekler genel ürün yönetimi bağlamındadır.
İsteğin arkasındaki işi anlamak
Önce talep edilen ekran veya düğme yerine müşterinin yapmaya çalıştığı işi yazarım. Bu iş mevcut hedef kullanıcı grubunun temel ihtiyacı mı, yoksa müşteriye özgü bir süreç mi? Aynı problem başka hesaplarda farklı biçimde görülüyor mu?
Özellik talebinin arkasındaki problem bu görüşmeyi ayrıntılandırıyor. Bir müşterinin ayrıntılı çözüm önermesi, sorunun tüm kullanıcılar için aynı çözümü gerektirdiğini göstermez.
Kapsamı üç seçenekle değerlendirmek
| Seçenek | Ne zaman anlamlı olabilir? | Taşıdığı yük |
|---|---|---|
| Ortak ürün özelliği | Temel kullanıcı grubunda tekrar eden ihtiyaç | Genel tasarım ve sürekli bakım |
| Yapılandırılabilir seçenek | Ortak işin sınırlı bir varyasyonu | Ayar, test ve dokümantasyon |
| Özel hizmet veya entegrasyon | Müşteriye özgü ama sınırlandırılabilir iş | Ayrı teslim ve destek sorumluluğu |
Dördüncü seçenek geliştirmemektir. Talep stratejiye uymuyor, maliyeti karşılanmıyor veya güvenilir biçimde sürdürülemiyorsa açık bir ret, belirsiz bir vaat vermekten daha sağlıklıdır.
İlk geliştirme süresinden fazlasını hesaplamak
Yeni özellik test, dokümantasyon, destek, veri geçişi ve gelecekteki değişikliklerle birlikte değerlendirilir. Özellikle müşteriye özel koşullar ortak kodun birçok yerine dağılıyorsa bakım maliyeti büyüyebilir. Bir kez teslim edilmesi işin bittiği anlamına gelmez.
Fırsat maliyeti de görünür olmalıdır. Bu iş yapılırsa hangi kullanıcı problemi ertelenecek? Ekibin mevcut güvenilirlik veya destek yükü bunu kaldırıyor mu? “Müşteri öderse yapılır” yaklaşımı, uzun vadeli sahipliği tek başına çözmez.
Ticari taahhüdü ürün varsayımından ayırmak
Müşterinin talep etmesiyle gerçekten kullanması veya ödeme yapması farklı sinyallerdir. Kapsam, kabul koşulu, teslim beklentisi ve bakım sorumluluğu açık konuşulmalıdır. Henüz araştırılan bir özellik satış görüşmesinde kesin tarihli söz haline gelmemelidir.
Bir pilot seçilecekse hangi belirsizliğin sınanacağı belirtilir. Kullanım sıklığı, görevin tamamlanması ve diğer kullanıcı gruplarına uygunluk gözlenebilir. Sonucun yalnız talep eden kişinin memnuniyetiyle değerlendirilmesi, ürün düzeyindeki etkileri eksik bırakabilir.
Geri dönüş ve sonlandırma yolunu düşünmek
Özellik beklenen faydayı sağlamazsa ne olacak? Bir yapılandırma kapatılabilir mi, veri taşınabilir mi, kullanıcıya açık bir alternatif sunulabilir mi? Bu sorular geliştirmeden önce sorulursa geçici deneme kalıcı karmaşıklığa daha az dönüşür.
Karar kaydında seçilen seçenek, gerekçe, reddedilen alternatifler ve yeniden değerlendirme koşulu bulunur. MVP kapsamı ilk denemeyi daraltmayı; backlog sadeleştirme tek talebin bütün ürün sırasını nasıl etkilediğini görmeyi tamamlıyor. İyi karar, müşteriyi önemsemekle ürünün sürdürülebilir sınırını korumayı birlikte ele alır.