MVP Nedir? Fikirden İlk Canlı Sürüme Nasıl Gidilir?

Aklınızda bir yazılım fikri var: bir SaaS, bir müşteri paneli ya da Excel'de dönen bir işi kurtaracak bir sistem. İlk içgüdü çoğu zaman her şeyi düşünüp hepsini birden yapmaktır. Aylar geçer, ürün "neredeyse hazır" hâlde bekler ve henüz kimse onu kullanmamıştır. MVP tam olarak bu tuzağa karşı geliştirilmiş bir yöntem. Bu yazıda MVP'nin gerçekte ne olduğunu, neyin içeri girip neyin dışarıda kalacağına nasıl karar verildiğini ve kendi ürünlerimizi fazlara bölerek canlıya çıkarırken öğrendiklerimi anlatıyorum.

MVP nedir? Sade bir tanım

MVP, İngilizce Minimum Viable Product ifadesinin kısaltması; Türkçede "minimum uygulanabilir ürün" ya da "en küçük işe yarar ürün" diye çevriliyor. Tanımın kilit kelimesi "minimum" değil, "uygulanabilir": gerçek bir kullanıcının gerçek bir sorununu uçtan uca çözen, ama bunu olabilecek en dar kapsamla yapan ilk sürüm.

MVP bir demo, bir tasarım taslağı ya da yarım bırakılmış bir ürün değildir. Kullanıcı ona girer, bir işi başlatır ve bitirir. Eksik olan şey özellik sayısıdır, kalite değil.

Amacı da tek cümleyle söylenebilir: en pahalı varsayımı en ucuz yoldan sınamak. "İnsanlar bu işi bu şekilde çözmek istiyor mu?" sorusunun cevabını aylarca geliştirme yaptıktan sonra değil, mümkün olan en erken noktada almak.

MVP, prototip ve tam ürün: fark ne?

Üç kavram sık karıştırılır. Karışınca da ya erken yayına çıkılıp güven kaybedilir ya da hiç yayına çıkılamaz.

Prototip "anlaşılıyor mu" sorusuna, MVP "kullanılıyor mu" sorusuna cevap verir. İkinci sorunun cevabı yalnızca canlıda alınır.

Neden küçük başlamak gerekiyor?

Büyük başlamanın maliyeti yalnızca para değildir. Asıl kayıp, yanlış bir varsayımın üzerine inşa edilen her haftadır. Küçük başlamanın getirdikleri:

• Erken geri bildirim: Kullanıcı ilk haftada hangi ekranı hiç açmadığını, hangi adımda takıldığını gösterir. Bu bilgi toplantı odasında üretilemez.
• Daha az çöpe giden iş: Kimsenin kullanmayacağı bir modül hiç yazılmamış olur.
• Karar hızı: Kapsam dar olduğunda "bunu şimdi mi, sonra mı yapalım" tartışması kısalır.
• Sağlam zeminde genişleme: Çekirdek çalıştıktan sonra eklenen her modül, test edilmiş bir yapının üstüne oturur.

Bu yaklaşım yalnızca SaaS için değil; bir iç süreç otomasyonu ya da müşteri paneli için de aynen geçerli. Otomasyonda hangi süreçten başlanacağını işletmeler için iş otomasyonu rehberinde ayrıca ele aldım.

MVP kapsamı nasıl belirlenir? Beş adım

Kapsam kesmek MVP'nin en zor kısmıdır, çünkü her özellik birilerine "olmazsa olmaz" görünür. Kullandığım sıra şu:

1. Sorunu tek cümleye indirin. "Güvenlik şirketlerinde nöbet çizelgesi Excel'de tutuluyor, fazla mesai elle hesaplanıyor" gibi. Cümle iki ayrı soruna bölünüyorsa, aslında iki ayrı ürün düşünüyorsunuz demektir.
2. Tek bir ana akış seçin. Kullanıcının baştan sona tamamladığı en değerli iş hangisi? MVP o akışı uçtan uca çalıştırır, geri kalan her şey sırasını bekler.
3. Her özelliğe "bu olmadan akış tamamlanır mı?" diye sorun. Tamamlanıyorsa özellik ikinci faza gider. Detaylı raporlar, gelişmiş filtreler ve rol çeşitliliği çoğu zaman buraya düşer.
4. Elle yapılabilecekleri elle yapın. İlk kullanıcıların hesabını elle açmak ya da bir bildirimi e-postayla göndermek MVP için kabul edilebilir. Otomasyon, talep kanıtlandıktan sonra gelir.
5. Başarı ölçütünü baştan yazın. "Canlıya çıktık" bir başarı ölçütü değildir. Neyin gerçekleşmesi fikrin doğru olduğunu gösterecek? Bunu yayından önce yazmazsanız, sonradan her sonuç başarı gibi okunur.

Olmazsa olmaz ile sonraya kalabilir arasındaki çizgi

Kapsam dar olabilir ama bazı kalemler pazarlık konusu değildir. Bunları kesmek MVP'yi "küçük" değil "bozuk" yapar.

Entegrasyonlar ayrıca dikkat ister: MVP'de her sistemle konuşmaya çalışmak, takvimi en çok kaydıran kalemdir. Hangi bağlantının gerçekten gerekli olduğunu ayırt etmek için API entegrasyonu yazısındaki "entegrasyon ne zaman gerekir" belirtileri iyi bir başlangıç noktası.

Kendi ürünlerimizden: fazlara bölerek canlıya çıkmak

Bu yazıdaki sıra teoriden değil, vitrinimizdeki SaaS ürünlerini kurarken tekrar tekrar uyguladığımız yöntemden geliyor. Birkaç somut örnek:

• FocusNöbet'te nöbet çizelgesi, bordro ve mevzuat uyumu tek pakette değil, fazlar hâlinde (Faz 1-4) kuruldu; her faz bir öncekinin üstüne oturdu. Ayrıntılar FocusNöbet vaka sayfasında.
• FocusKarbon tek seferde tam platform olarak değil, önce Faz 0 olarak canlıya alındı. Ürün hâlâ yapım aşamasında; ama konumlandırma, rakip analizi ve arama görünürlüğü şimdiden canlıda sınanıyor.
• Periyon'da OEE ayrı bir ürün olarak başlamadı; mevcut bakım modülünün içine gömüldü ve Faz 1 olarak canlıya çıktı.
• Focushavza için sıfırdan yazmak yerine FocusKarbon'un çekirdeği paylaşımlı bir katmana çıkarıldı ve su ürünü onun üstüne kuruldu. İkinci ürün baştan yazılmadı; nasıl yapıldığı Focushavza vaka sayfasında.
• FocusISG ise tersinden bir örnek: Periyon'un içinde bir alt modül olarak doğdu, kendi başına satılabilir hâle gelmesi gerekince bağımsız ürüne ayrıştırıldı.

Ortak ders şu: ilk sürüm "her şey" olmak zorunda değil, ama çalışan bir çekirdek olmak zorunda. Çekirdek sağlamsa üstüne modül eklemek, bir modülü ayrı ürüne çevirmek ya da aynı temel üzerinde ikinci bir ürün kurmak mümkün oluyor.

MVP canlıya çıktıktan sonra neye bakmalı?

Yayın günü MVP'nin bitişi değil, başlangıcıdır. İlk haftalarda ölçülecekler, baştan yazdığınız başarı ölçütünün etrafında döner:

• Talep: İnsanlar denemek için adım atıyor mu? Bir tanıtım sayfası ve demo formu bunu ölçmenin en ucuz yoludur; sayfanın kurgusu için landing page ve dönüşüm rehberine bakabilirsiniz.
• Aktivasyon: Kaydolanlar ana akışı en az bir kez tamamlıyor mu?
• Geri dönüş: Ertesi hafta tekrar geliyorlar mı? Tek seferlik merak ile gerçek ihtiyaç burada ayrışır.
• Takıldıkları yer: Destek mesajları ve yarım kalan işlemler, bir sonraki fazın yapılacaklar listesidir.

Periyon'da demo talep formunun ilk günden bir yönetim paneline ve e-postaya bağlanmasının sebebi de buydu: talep ölçülemiyorsa, MVP'nin cevap vermesi beklenen soru da cevapsız kalır.

En sık yapılan MVP hataları

1. MVP'yi bahane edip kaliteyi düşürmek. Dar kapsam ile özensiz iş aynı şey değildir. Çalışmayan bir ürün size fikrin mi yoksa uygulamanın mı başarısız olduğunu söylemez; ikisini ayırt edemezsiniz.
2. "Bir özellik daha" döngüsü. Yayın tarihi her yeni fikirle ileri atılır. Sabit bir kapsam listesi ve tarih konmadan bu döngü kırılmaz.
3. Ölçüm koymadan yayına çıkmak. Kaç kişinin ana akışı tamamladığını bilmiyorsanız, geri bildirim yalnızca en yüksek sesle konuşan kullanıcıdan gelir.
4. İlk altyapıyı sonsuza kadar sanmak. MVP için seçilen altyapı, ürün büyüdükçe değişebilir. Kariyernova'da platform maliyeti içeriğe göre orantısız kalınca site Shopify'dan statik bir yapıya taşındı. Böyle bir geçişin mümkün olması için içeriği ve veriyi baştan tek bir platformun içine kilitlememek gerekir.
5. Brifi netleştirmeden geliştirmeye başlamak. Kim kullanacak, hangi işi bitirecek, başarı neye benziyor? Bu üç sorunun cevabı yazılı değilse teklif de takvim de havada kalır. Web sitesi yaptırma rehberindeki "teklif almadan önce netleştirilecek maddeler" listesi, yazılım projeleri için de işe yarar.

MVP'yi kodsuz araçlarla mı, yazılımla mı kurmalı?

Kodsuz (no-code) araçlar, bir akışın talep görüp görmediğini sınamak için yeterli olabilir; özellikle ana akış bir form, bir tablo ve bir bildirimden ibaretse. Ürün kendine özgü bir iş kuralı taşıyorsa — bir mevzuat hesabı, bir çizelge motoru, çok kullanıcılı bir yetki yapısı — kodla kurulan bir çekirdek genellikle daha az yeniden yazım gerektirir.

Hangi yolu seçerseniz seçin, dışarıdan bir ekiple çalışacaksanız üç şeyi baştan konuşun: kapsamın yazılı listesi, her fazın "bitti" tanımı ve kaynak kod ile verinin kime ait olduğu. Bu üçü netse, MVP'nin sonunda elinizde hem çalışan bir ürün hem de bir sonraki adımı planlamaya yetecek gerçek veri olur.