MVP ve Bedrock Çelişkisi: Hangi Fonksiyon Kusursuz Olmalı
MVP ile bedrock aynı cümlede geçiyor ama aynı şeyi söylemiyorlar. MVP en az işi yapan sürümü sahaya çıkarmayı, bedrock ise kullanıcının her gün açtığı fonksiyonun kusursuz çalışmasını ister. Biri eksikliğe izin verir, diğeri hata payını sıfıra çeker. Ürünün hangi parçasında hangisinin geçerli olduğunu baştan ayırmazsanız ikisini de yarım yaparsınız.
İki Kavram Aynı Yöne Bakmıyor
MVP bir yöntemdir: kapsamı daraltıp erken çıkarsınız, geri bildirimle büyütürsünüz. Bedrock ise bir fonksiyondur: kullanıcı onun için uygulamayı açar, o çalışmazsa uygulamayı siler. Yöntem eksikliği kabul eder, fonksiyon etmez.
Bu yüzden “önce MVP çıkaralım, sonra sağlamlaştırırız” cümlesi çoğu ekipte yanlış yere düşer. Sonradan sağlamlaştırılacak yer baştan belliyse, orası zaten minimum değildir.
Bedrock'ta Hata Payı Sıfırdır
Finansal bir uygulamada bakiye görüntüleme basit görünür: bir sorgu, bir ekran. Ama yanlış bakiye gösteren uygulama eksik değil, bozuktur; kullanıcı ikinci kez denemez. Aynı üründe harcama grafiği iki gün geç gelse kimse fark etmez.
Ayrım tam burada. Bir fonksiyonun MVP mantığına uyup uymadığını kapsamının darlığı değil, yanlış çalıştığında kullanıcının ne kaybettiği belirler. Çekirdek fonksiyonu geç çıkarmayı, erken çıkarıp yanlış rakam göstermeye tercih ederim; ikincisinden dönmek ilkinden çok daha pahalıya oturuyor.
Özellik Kalabalığı Kullanıcıdan Gelmez
Ürünlerin şişmesinin sebebi genelde kullanıcı talebi değil, iç talep. Her birim kendi ekranını ister, her toplantıdan bir madde çıkar, altı ay sonra ana ekranda dokuz kutucuk olur. Kullanıcı bunların yedisini hiç açmaz, ama açtığı ikisi de artık daha yavaş yükleniyordur.
Özellik eklemenin faturası eklendiği gün gelmez. Her yeni ekran, çekirdek akışın kontrol edilmesi gereken durum sayısını artırır; o kontrolü yapmayan ekipler farkı üretimde öğrenir.
Kestirmeler Çekirdekte Birikir
İlk sürümü yetiştirmek için atılan kestirmeler ürünün kenarında durmaz. İlk yazılan kod çekirdek koddur, sonraki iki yıl en çok dokunulan yer de orasıdır. Ekipte “burayı elleme, bozuluyor” denen dosya, çoğu zaman lansmana yetişsin diye iki günde yazılmış ödeme akışıdır.
Pratik karşılığı şu: MVP'de kısılacak şey özelliklerin sayısıdır, çekirdek fonksiyonun testi ve hata yönetimi değil. Kapsamı daraltmak ucuz, sonradan temelin altına girmek pahalı.
Hangi Fonksiyon Sizin Çekirdeğiniz
Cevabı ürün toplantısında değil kullanım verisinde bulursunuz. Kullanıcıların büyük çoğunluğunun ilk hafta içinde ve tekrar tekrar açtığı ekran hangisiyse çekirdek odur, ve o ekran için “yeterince iyi” diye bir eşik yoktur. Geri kalan her şey eksik çıkabilir, çıkmalı da.
Kaynaklar