Kapsamı Daraltmak: Yayınlanmayan Özelliklerden Öğrendiklerim

Bir uygulamanın maliyetini konuşurken hep yazılan koddan bahsediyoruz. Oysa gerçek maliyet çoğu zaman başka bir yerde: yazılıp da yayına girmemiş, ya da yayına girip kimsenin dokunmadığı özelliklerde.

Kendi projelerimde bunun somut örneklerini yaşadım. Haftalarca uğraştığım, teknik olarak gurur duyduğum bir akışın, ürünün geri kalanı hazır olmadığı için ilk sürüme hiç girmemesi. Ya da giren ama kullanıcının hiç fark etmediği bir özelliğin, her sürümde bakım maliyeti üretmeye devam etmesi.

Kapsamı daraltmayı uzun süre bir kayıp olarak gördüm — “yapamadığım şeyler” listesi gibi. Şimdi tam tersini düşünüyorum: daraltmak, üründe verilen en değerli karar.

Kapsam neden kendiliğinden büyür

Kapsam genişlemesi kötü niyetten ya da disiplinsizlikten çıkmıyor. Genelde çok makul görünen adımlardan oluşuyor:

• “Zaten oradayken.” Bir ekranı yazarken benzer bir ekranı da yazmak ucuz görünüyor. Ama ikinci ekran da test edilecek, sürdürülecek, çevrilecek, hataları giderilecek.
• “Kullanıcı isteyecek.” Henüz kullanıcı yokken, olası bir isteği önceden karşılamaya çalışmak. Bu tahminlerin çoğu tutmuyor.
• “Rakipte var.” Rakibin özelliği, onun kullanıcı kitlesi ve geçmişi bağlamında anlamlı olabilir. Sizinkinde olmayabilir.
• “Teknik olarak ilginç.” Bu bende en sık işleyen sebep. Çözmesi zevkli bir problem, çözülmesi gereken bir problem değildir.

Kullandığım üç soru

Bir özelliği ilk sürüme alıp almamaya karar verirken sırayla üç soru soruyorum:

1. Bu olmadan ürün ne işe yaramaz hale gelir mi? Cevap “hayır, sadece daha zayıf olur” ise özellik ilk sürümde değil. Vakti Geçmeden’de ürünün özü “yakınındaki işletmenin gün sonu ürününü görüp almak”. Bu akış olmadan uygulama yok. Geri kalan her şey — favoriler, geçmiş, filtreler, bildirim tercihleri — sonraya kalabilir.

2. Bunu manuel yapabilir miyim? Bir sürecin otomatik olması, o sürecin var olmasından farklı bir şey. İlk aşamada işletme başvurularını elle onaylamak, tam bir yönetim paneli yazmaktan kat kat ucuz — ve gerçek başvuruları görmeden panelin nasıl olması gerektiğini zaten bilemezsiniz.

3. Bunu ertelersem geri dönüşü zorlaşır mı? Bu, kesme kararını sınırlayan soru. Veri modeli, kimlik doğrulama yapısı, çok dillilik altyapısı gibi şeyler sonradan eklenmesi pahalı olan kararlar. Bunları ertelemiyorum — özelliği değil, altyapıyı baştan doğru kurup üstündeki özellikleri kesiyorum.

Kesmek ile ertelemek arasındaki fark

Bu ayrımı geç öğrendim. Bir özelliği kapsam dışı bırakmanın iki farklı biçimi var ve karıştırıldığında ürün bozuluyor.

En çok zarar veren şey, ertelenen özelliğin arayüzde izini bırakmak: çalışmayan bir sekme, “yakında” yazan bir ekran, basıldığında hiçbir şey yapmayan bir düğme. Kullanıcı bunu eksik bir özellik olarak değil, bozuk bir uygulama olarak okuyor. Yayında olmayan bir şeyin arayüzde de olmaması gerekiyor.

Yanlış şeyi kesmemek için

Daraltmanın riski, ürünü anlamsız hale getirecek kadar kesmek. Bunu engellemek için kullandığım yöntem, özellikleri tek tek değil akış olarak düşünmek.

Kullanıcının uygulamada tamamlaması gereken bir yolculuk var: girer, arar, bulur, işlem yapar, sonucu görür. Bu yolculuğun her adımı bir zincir halkası. Bir halkayı kesince zincir kopuyor — geriye kalan diğer halkaların hiçbir değeri kalmıyor.

Dolayısıyla kesme kararını şöyle veriyorum: zincirin dışındaki her şey kesilebilir, zincirin üstündeki hiçbir şey kesilemez. Ama zincirin üstündeki adımlar basitleştirilebilir. Arama adımı kalmak zorunda; ama gelişmiş filtreler, sıralama seçenekleri ve kayıtlı aramalar olmadan da arama vardır.

Kesilen şeyleri kaydediyorum

Kapsam dışı bıraktığım her şeyi tek bir yerde tutuyorum — özelliğin adı, neden ertelendiği ve hangi koşulda geri gelmesi gerektiği. Üç faydası oldu:

• Aynı tartışmayı iki ay sonra baştan yapmıyorum; karar ve gerekçesi yazılı.
• Kullanıcıdan bir istek geldiğinde, o listede zaten olup olmadığına bakabiliyorum. Aynı isteğin tekrar gelmesi, önceliği değiştiren gerçek bir sinyal.
• Yayın sonrası ne yapacağımı düşünmek zorunda kalmıyorum; liste zaten orada duruyor.

Bu listenin yan etkisi psikolojik: bir şeyi kesmek, onu kaybetmek gibi hissettirmiyor. Sadece sırasını değiştiriyorsunuz.

Yayından sonra ne oldu

Kapsamı daralttığım projelerde tekrarlanan bir şey gördüm: yayına aldıktan sonra, listedeki özelliklerin bir kısmını hiç yapmadım. Sebep unutmak değil — gerçek kullanıcıyı gördükten sonra o özelliklerin gereksiz olduğunu anlamak.

Buradaki asıl kazanç şu: eğer o özellikleri ilk sürüme koymuş olsaydım, gereksiz olduklarını asla öğrenemeyecektim. Yazılmış, yayınlanmış ve bakımı yapılan bir özelliğin gereksiz olduğunu kabul etmek, hiç yazmamış olmaktan çok daha zor.

Kapsamı daraltmak, daha az iş yapmak değil. Hangi işin yapılmaya değer olduğunu, tahmin yerine gerçeğe bakarak öğrenmek.

• Ürün
• Kariyer
• Mobil Geliştirme
• Planlama