MVP geliştirmek ne kadar sürer?

MVP nedir, ne değildir?

MVP, İngilizce "minimum viable product" ifadesinin kısaltmasıdır; Türkçesi en küçük uygulanabilir üründür. Tek bir varsayımı gerçek kullanıcıyla sınamaya yetecek kadar ürün demektir.

MVP, yol haritasının tamamının küçültülmüş hâli değildir. Yarım bırakılmış bir ürün de değildir. Güvenliği ya da veri bütünlüğünü atlamak için bir bahane hiç değildir. Az şey yapar, ama yaptığını düzgün yapar.

Bu ayrım süreyi doğrudan etkiler. "Her şeyin biraz olduğu" bir ilk sürüm aylar alır ve hiçbir şeyi sınamaz. Tek bir akışı baştan sona çalıştıran bir ilk sürüm haftalar alır ve net bir yanıt verir.

MVP geliştirmek ne kadar sürer: dört etken

Süre dört şeye bağlıdır. Hiçbiri kod yazma hızıyla ilgili değildir.

• Kapsam: ilk sürümde kaç akış, kaç kullanıcı türü var?
• Belirsizlik: ürünün nasıl çalışacağı ne kadar net? Karar verilmemiş her konu, takvimde bir bekleme demektir.
• Bağımlılıklar: ödeme, harita, mesaj ya da başka bir servise bağlanılacak mı? O servisin belgeleri ve erişimi hazır mı?
• Karar hızı: sorulara kim, ne kadar sürede yanıt veriyor?

Takvimi ne uzatır?

Teknik zorluk kadar, geç verilen kararlar da takvimi uzatır. Gecikmelerin çoğu şu başlıklardan gelir.

Hafta hafta bir MVP

Aşağıdaki sıra, bizim çalışma şeklimizi anlatır. Haftalar projeye göre kayar; sıra değişmez.

• Kapsam: sınanacak varsayımı, ilk kullanıcıyı ve ana akışı yazarız. Neyin girmeyeceğini de yazarız.
• Tasarım ve teknik kararlar: ekranları çizeriz, altyapıyı ve kullanılacak hazır servisleri seçeriz.
• Yapım: haftalık ara teslimlerle çalışan parçalar çıkarırız. Her hafta deneyebileceğiniz bir şey olur.
• Sınama ve yayın: gerçek veriyle deneriz, hataları kapatırız, yayına alırız.
• Ölçüm: ilk kullanıcıların ürünü nasıl kullandığını görmenizi sağlayan temel ölçümü kurarız.

Bir kararı atlamak süreyi kısaltmaz

Takvim sıkıştığında ilk akla gelen, kapsam çalışmasını ya da tasarımı atlamaktır. Bu, maliyeti silmez; yalnızca sonraya taşır ve büyütür.

Yazılmadan önce çözülen bir belirsizlik bir toplantıya mal olur. Yazıldıktan sonra fark edilen aynı belirsizlik, yapılan işin bir kısmının yeniden yapılmasına mal olur. Bu yüzden ilk haftayı konuşmaya ve yazmaya ayırmak, toplam süreyi kısaltır.

Süreyi güvenle nasıl kısaltırsınız?

Süreyi kısaltmanın yolu ekibi büyütmek ya da mesaiyi uzatmak değildir. İşi küçültmektir.

• Sınamak istediğiniz varsayımı tek cümleyle yazın.
• Bu varsayımı etkilemeyen her özelliği sonraya bırakın.
• Üyelik, ödeme ve e-posta gibi standart işlerde hazır servis kullanın.
• Yönetim tarafındaki işleri ilk sürümde elle yürütün.
• Soruları yanıtlayacak tek bir kişi belirleyin ve haftalık bir saat ayırın.
• Entegrasyon erişimlerini ve hesapları iş başlamadan hazırlayın.

Hızlı ama kırılgan olmasın

Kısa süre, özensiz iş demek değildir. Kapsam dışına çıkarmadığımız şeyler vardır: kullanıcı verisinin korunması, yedekleme, temel hata izleme ve kodun başka bir ekibin devralabileceği düzende olması.

MVP işe yararsa üzerine devam edersiniz. İlk sürümü atıp baştan yazmak zorunda kalmamanız için mimariyi sade ama düzenli kurarız. Bu konuyu monolit mi, mikroservis mi ve SaaS mimarisi yazılarımızda ayrıntılı anlatıyoruz.

Tarih değil, varsayım isteyin

Bir ekipten süre isterken yalnızca tarih istemeyin. O tarihin hangi varsayımlara dayandığını da isteyin. Sağlam bir takvim kapsam sınırlarıyla, bağımlılıklarla ve karar tarihleriyle birlikte verilir.

İş akışını ya da varsa mevcut kodu görmeden verilen kesin tarihlere temkinli yaklaşın. "İki haftada biter" demek kolaydır. Zor olan, neyin iki haftada biteceğini yazıya dökmektir.

Süre kadar bütçe de kapsamla belirlenir. Fiyat tarafını yazılım yaptırmak ne kadar rehberimizde anlatıyoruz.

Aynı fikir, iki takvim

Örnek senaryo: Bir kurucu, serbest çalışan eğitmenlerle öğrencileri buluşturan bir platform kurmak istiyor. İlk listesinde eğitmen profilleri, arama, takvim, online ödeme, görüntülü ders, yorumlar, mesajlaşma ve eğitmenler için gelir raporu var.

Bu liste olduğu gibi yapılırsa iki ayrı kullanıcı türü, ödeme ve görüntülü görüşme entegrasyonları ve bir yönetim paneli gerekir. Takvim aylarla ölçülür. Üstelik sonunda hangi varsayımın sınandığı belli değildir.

Kapsam çalışmasında tek bir soru seçilir: öğrenciler bu platformdan ders ayırtır mı? İlk sürüme eğitmen listesi, bir ders saati seçme ve ayırtma adımı girer. Ödeme ilk sürümde havaleyle, ders ise eğitmenin kendi kullandığı görüntülü görüşme aracıyla yapılır. Eğitmenler platforma elle eklenir.

İkinci kapsam, birincinin küçük bir parçasıdır ve soruyu aynı açıklıkla yanıtlar. Bu anlatım kurgusaldır; gerçek bir girişimi tarif etmez.

Web mi, mobil uygulama mı?

Kurucuların çoğu fikrini bir mobil uygulama olarak düşünür. İlk sürüm için bu çoğu zaman gerekmez ve süreyi belirgin biçimde uzatır.

Telefonda da iyi çalışan bir web uygulaması tek seferde yazılır, anında güncellenir ve uygulama mağazası onayı beklemez. Mağazalarda yayınlanan bir uygulama ise ayrı bir arayüz, ayrı bir sınama ve mağaza inceleme süreci ister.

Mobil uygulama şu durumlarda ilk sürümde gerekir: ürünün özü telefonun bir özelliğine dayanıyorsa, örneğin kamera, konum ya da bildirim vazgeçilmezse. Değilse web ile başlayın; kullanıcı ürünü benimsediğinde mobil uygulamayı aynı altyapının üzerine eklersiniz.

Daha kısa sürede olur mu?

Bu soru her görüşmede gelir. Dürüst yanıt: kapsam küçülürse evet, yalnızca tarih öne çekilirse hayır.

Ekibi büyütmek de beklenen etkiyi yapmaz. Küçük bir üründe işi bölmek, anlatmak ve birleştirmek, kazanılan vakti geri alır. Erken aşamada hız, kalabalıktan değil netlikten gelir.

Takvimi gerçekten sıkıştırmanız gerekiyorsa, örneğin bir etkinlik ya da yatırımcı görüşmesi varsa, tarihi sabitleyip kapsamı ona göre küçültürüz. Tarih ve kapsam aynı anda sabit olamaz; birini seçmek gerekir.

Yayından sonra ne olur?

MVP'nin yayına girmesi işin sonu değil, öğrenmenin başıdır. Takvimi planlarken yayından sonraki ilk haftaları da hesaba katın.

İlk kullanıcılar ürünü beklediğinizden farklı kullanır. Bir adımda takılırlar, bir özelliği hiç fark etmezler, sizin önemsiz saydığınız bir şeyi isterler. Bu gözlemler, bir sonraki adımın ne olacağını söyler.

Bu yüzden yayından sonrası için küçük bir bütçe ve vakit ayırın. İlk sürümü yayınlayıp aylarca dokunmamak, sınamak için yaptığınız üründen öğrenme fırsatını kaçırmak demektir.

Kurucunun payına düşen iş

Takvimin bir kısmı yapan ekibe, bir kısmı size bağlıdır. İkinci kısım çoğu zaman hesaba katılmaz ve gecikmelerin sessiz nedeni olur.

• Sorulara yanıt: her hafta küçük kararlar çıkar. Bir günde verilen yanıt ile bir haftada verilen yanıt arasındaki fark, doğrudan takvime yansır.
• İçerik: ürünün içindeki metinler, görseller ve örnek veri sizden gelir.
• Hesaplar: alan adı, ödeme sağlayıcısı ve benzeri hesapların açılması bazen başvuru ve onay gerektirir. Bunları erken başlatın.
• İlk kullanıcılar: ürün hazır olduğunda deneyecek birkaç kişiyi önceden bulun. Yayın günü kullanıcı aramaya başlamak, öğrenmeyi haftalarca geciktirir.
• Ara teslimleri denemek: her hafta gelen parçayı gerçekten kullanıp geri bildirim vermek, sonda çıkacak sürprizleri azaltır.

Süre tahmini neden aralık olarak verilir?

İyi bir tahmin tek bir tarih değil, bir aralıktır. Çünkü yazılımda işin bir kısmı ancak yapılırken ortaya çıkar: bir entegrasyon beklenenden farklı davranır, bir ekran denendiğinde yeniden düşünülmesi gerekir.

Aralığın genişliği belirsizliği gösterir. Kapsam netleştikçe aralık daralır. Bu yüzden kapsam çalışmasından önce verilen tahmin geniş, sonrasında verilen tahmin dar olur. Dar bir aralığı en baştan vaat eden bir ekip, belirsizliği yok saymaktadır.

Özet

MVP süresini kod değil, kapsam ve kararlar belirler. Tek kullanıcı türü, tek ana akış ve hazır servislerle bir ilk sürüm 6–8 hafta içinde yayına alınabilir. Roller, onay adımları, entegrasyonlar ve geç verilen kararlar bu süreyi uzatır.

Fikrinizi hangi kapsamla sınayabileceğinizi konuşmak isterseniz MVP geliştirme sayfamıza bakın; paketin içeriği, fiyatı ve süresi orada yazıyor.