MVP Geliştirme

MVP, ürünün ucuzlatılmış sürümü değildir. Tek bir soruya cevap vermek için kurulan en küçük çalışan üründür ve o soru yazılı değilse ortaya çıkan şey MVP değil, yarım bırakılmış bir üründür. Yarım ürün de hiçbir şey öğretmez. Bu yüzden işe özellik listesiyle değil tek cümleyle başlıyoruz: yanlış çıkarsa geri kalan her şeyi anlamsız kılacak varsayım hangisi? Cevap yazıldıktan sonra iki liste çıkıyor, biri yapılacaklar biri yapılmayacaklar. Detartech'in MVP işi asıl olarak ikinci listeyi savunmaktır; kod yazmak kısmı en öngörülebilir olanıdır.

MVP'yi nasıl tanımlıyoruz

MVP prototip değildir. Prototip iç ekibe "bu teknik olarak çalışıyor mu" sorusunu cevaplar ve test koşullarında yaşar. MVP ise dışarı çıkar ve gerçek kullanıcıya ulaşır; kapsamı dar olsa da uçtan uca çalışır, yani kayıt olunabilir, ödeme alınabilir ve hata ekranı görülebilir. Bir de v1 vardır: özellik listesi baştan kapatılmış, hipotezi olmayan ilk sürüm. V1 meşru bir iştir ama süresi, fiyatı ve riski MVP'den farklıdır, o yüzden gelen talebi hangi kutuya koyduğumuzu ilk görüşmede söylüyoruz. Üstlenmediğimiz işler de var: başarısı tanımlanmamış projeler, "önce çıkaralım sonra bakarız" tipi talepler ve sonucu kimsenin karar için kullanmayacağı ölçümler. MVP'nin tarihçesi, türleri ve bugünkü hali için MVP geliştirme rehberimize bakabilirsiniz.

Bir MVP'yi nasıl kuruyoruz

Aşağıdaki altı başlık bir MVP projesinde verilen kararların tamamını kapsıyor. İlk üçü işin nasıl kurulduğu: kapsamın kesilmesi, doğrulamanın tasarlanması ve teslim ritmi. Sonraki ikisi çıkıştan sonrası: demonun gerçek kullanımdan farkı ve üretime geçerken teknik borçla ne yapıldığı. Altıncısı diğerlerinin tersi, yani MVP'nin yanlış cevap olduğu ve bunu baştan söylediğimiz durumlar.

Kapsam kesme: ne yapılmayacağına karar vermek

Kapsam kesmek özellik silmek değil, her özelliği tek bir soruya bağlamaktır: bu hangi varsayımı test ediyor? Cevabı olmayan özellik çöpe gitmez, MVP sonrası listesine yazılır ve o liste proje sonunda size teslim edilir. Kesme kararının somut örneği BiTalih: ekiplerin ihtiyacı sosyal medya içeriği üretmekti, ama bir tasarım aracı yapılmadı. Sabit şablonlar tanımlandı, kullanıcıya yalnızca yer, zaman ve tutar gibi değişken alanları güncelleme yetkisi verildi. Bu bir eksiklik değil karardı; tasarım bütünlüğü korunduğu için içerik üretimi saatlerden dakikalara indi.

Doğrulama tasarımı: hangi soru, hangi ölçüm

Kod yazılmadan önce üç satır yazılır: test edilecek varsayım, onu ölçecek metrik ve "oldu" saymak için gereken eşik. Eşik önceden konmazsa her sonuç sonradan iyi tarafından anlatılabilir, bu yüzden metrik ikili olur: tuttu veya tutmadı. Aynı belgeye ölçümün kime yapılacağı ve o kullanıcılara nasıl ulaşılacağı da yazılır, çünkü trafiği olmayan bir MVP ölçüm değil tahmin üretir. Olay kayıtları ilk sürümle birlikte devreye alınır; sonradan eklenen ölçüm ilk haftaların verisini geri getirmez.

Sürekli temas ve pre-prod üzerinden şeffaflık

Süreç boyunca müşteriyle sürekli temas halindeyiz ve mümkün olan her gün ilerleme paylaşılır. Bunun için proje başında, canlı sisteme çok benzeyen ama henüz gerçek kullanıcıya açılmamış bir test ortamı kuruyoruz; buna pre-prod diyoruz ve yapılan her değişiklik genellikle bu ortamda anlık olarak izlenebiliyor. İlerlemenin kanıtı böylece bir ekran görüntüsü değil, gerçek bir adreste çalışan yazılım oluyor; bunu mümkün kılan şey de en baştan kurulan yayın hattı. Lextum AI, Biletico, Anneekspres ve World Summer Schools projelerinin hepsinde CI/CD otomasyonu Jenkins ile kuruldu. Yayına almanın bir olay olmaktan çıkması, bu şeffaflığın sürdürülebilir olmasının ön koşulu.

Yatırımcı demosu ile gerçek kullanıcı testinin farkı

Yatırımcı demosu on dakikalık bir anlatı için kurulur ve mutlu yoldan gider. Gerçek kullanıcı testi mutsuz yolları gerektirir: boş ekran, hatalı giriş, yarıda kalan ödeme, zayıf bağlantı, küçük telefon. İkisi aynı üründen çıkar ama sıra önemlidir; önce gerçek akış kurulur, demo o akışın içinden geçen yazılı bir güzergâh olur. Biletico'yu devraldığımızda platformun temeli atılmıştı ama ödeme akışı yarım bırakılmıştı. Ödeme çalışmadığında geri kalan her ölçüm anlamını yitirir, çünkü kullanıcı satın alma adımına varmadan ayrılır. Bu yüzden ilk önceliği ödeme aldı; ödeme, arama, profil ve bilet yönetimi canlıya çıkmadan önce çalışır hale getirildi.

MVP'den üretime geçiş ve teknik borç kararı

Her teknik borç ödenmez; ödenecek olanların sırası belirlenir. MVP sonunda genellikle büyümeden önce değişmesi gereken kalemlerle uzun süre olduğu gibi yaşayabilecek kalemleri ayıran yazılı bir değerlendirme paylaşırız; bu ayrım projeye göre değişir ve her seferinde aynı kesinlikte kategorilere bölünmez. Amaç, kararın teknik değil ticari olarak verilebilmesidir. Lextum AI üretim tarafına düşen maddelerin somut örneği: sistem mikro servis mimarisi ve RabbitMQ ile asenkron işlem yapısı üzerine kurulu, rol bazlı erişim ve tam denetim izi de aynı yapının parçası. Yüksek trafikli kurumsal kullanım bu maddeleri pazarlık dışı yapıyor. Sorun talep değil yükse iş MVP'den çıkar, Backend Ölçekleme tarafına geçer.

MVP'nin yanlış cevap olduğu durumlar

Dört durumda MVP önermiyoruz. Birincisi cevabı zaten bilinen sorular: süreç şirketin içinde yıllardır işliyorsa yapılacak iş talebi test etmek değil, kapsamı yazılı bir sistem kurmaktır. İkincisi sonucu kimsenin karar için kullanmayacağı işler; ölçüm çıktığında yön değiştirmeye yetkisi olan biri yoksa ölçüm masraftan ibarettir. Üçüncüsü en küçük çalışan sürümün gerçekten küçük olmadığı akışlar: ödeme, kimlik doğrulama ve mevzuat gerektiren adımlar yarım bırakılamaz. Dördüncüsü ürünün zaten var olduğu ve sorunun talep değil görünürlük ya da dayanıklılık olduğu durumlar; orada doğru cevap yeni bir MVP değildir.

Proje teslim paketi

MVP bittiğinde elinizde dört şey kalıyor. Birincisi kod: tüm geçmişiyle birlikte sizin hesabınızdaki depoda durur, sıkıştırılmış bir klasör olarak değil, kimin neyi ne zaman değiştirdiği okunabilir halde. İkincisi çalışan altyapı: sunucu, veritabanı ve yayın hattı sizin adınıza açılmış hesaplar üzerinde kurulur, böylece devir ayrı bir taşıma projesine dönüşmez. Üçüncüsü veri ve ölçüm: veritabanı şeması, olay kayıtları ve baştaki sorunun cevabını içeren ölçüm raporu. Dördüncüsü devir belgesi: sistemin yerelde nasıl ayağa kalktığı, nasıl yayına alındığı, hangi kararın bilinçli verildiği ve MVP sonrası listesinde ne biriktiği. Bu dördü, projeyi bizimle sürdürmeseniz de teslim ediliyor.

Bütçe ve kapsam nasıl korunuyor

Bütçeyi koruyan şey rakamı sabitlemek değil, kapsamı yazılı tutmaktır. Süre baştan tahmini olarak verilir; pre-prod ortamı üzerinden ilerleme sürekli görülebildiği için tarih sürpriz olmaz, esneyen şey her zaman kapsamdır. Süreç sırasında gelen her yeni istek tek soruyla fiyatlanır: bu girecekse hangi madde çıkacak, yoksa ayrı bir kalem mi açılacak? Karar sizin, kayıt yazılı; böylece proje sonunda kapsamın nerede ve neden büyüdüğü tartışma konusu olmaz. İstediğiniz an durma hakkınız var ve o ana kadar üretilen her şey elinizde kaldığı için durmak kayıp değil karardır. Üçüncü taraf maliyetleri, yani ödeme sağlayıcı komisyonu, bulut faturası ve uygulama mağazası ücretleri, baştan ayrı kalem olarak yazılır ve sizin hesabınızdan işler; geliştirme bedelinin içinde saklanmaz.

Ölçüm kapsamımız

Ölçtüğümüz şey çekirdek akışın tamamlanmasıdır: kullanıcı ürünün var olma sebebi olan eylemi yapabildi mi, kaç adımda yapabildi, nerede düştü, geri geldi mi. Para alan bir üründe ödeme adımı ayrı izlenir, çünkü niyet ile ödeme arasındaki fark en pahalı bilgidir. Ölçmediğimiz şeyler de var: sayfa görüntülenmesi, tek başına kayıt sayısı, süre bazlı etkileşim ortalamaları ve küçük örneklemde memnuniyet puanı. Bunlar yükselirken ürün başarısız olabilir, o yüzden karar verdirmezler. Bizim hızımız da başarı metriği değildir; kaç iş kalemi bitirdiğimiz iç takip verisidir. Ölçüm için gereken pencere ve örneklem projeye göre değişir; veri henüz karar verdirecek kadar olgunlaşmadıysa bunu açıkça söyleriz, sonucu olduğundan kesin göstermeyiz.

Teknoloji seçim kriterlerimiz

MVP, yeni bir teknoloji öğrenmek için kötü bir yerdir. Seçim bu yüzden dar bir kümeden yapılıyor: üretimde çalıştırdığımız ve devrettiğimizde başkasının sürdürebileceği araçlar. İşlem karmaşıklığı, rol yapısı ve kurumsal entegrasyon ağır bastığında backend .NET oluyor; Lextum AI, World Summer Schools ve Welldone bu tarafta. İşin ağırlığı veri modeli ve yönetim ekranlarındaysa Python ve Django daha hızlı sonuç veriyor; Anneekspres pazar yeri böyle kuruldu. Arayüzde React ve Next.js, tek kod tabanının hem iOS hem Android tarafında saha kullanımına çıkması gerektiğinde Flutter veya React Native kullanıyoruz. Seçimi belirleyen üç ölçüt: devirden sonra bakımı kimin yapacağı, o teknolojide eleman bulunup bulunmadığı ve barındırmanın sizin hesabınızda kalabilmesi.

Sahadaki karşılığı

Aşağıdaki işler yayında veya tamamlanmış durumda. Her birinin ayrıntısı Başarı Hikayeleri bölümündeki kendi sayfasında duruyor.

• Lextum AI: Hukuk ekipleri için belge üretimi, sözleşme incelemesi, eş zamanlı düzenleme ve versiyonlama. Mikro servis mimarisi, RabbitMQ, rol bazlı erişim ve denetim iziyle üretime taşındı.
• Biletico: Temeli atılmış ama neredeyse hiçbir özelliği çalışmayan bir platform devralındı; ödeme, arama, profil ve bilet yönetimi çalışır hale getirildi, canvas tabanlı oturma planı eklendi.
• World Summer Schools: Yüzlerce yaz okulu programı tek bir aranabilir katalogda toplandı; içerik girişi OpenAI entegrasyonuyla hızlandırıldı, rol bazlı yetkilendirme kuruldu.
• Anneekspres: Anne ve çocuk ürünleri pazar yeri sıfırdan kuruldu: satıcı paneli, ödeme ve sipariş akışı, PostgreSQL ve RabbitMQ tabanlı altyapı.
• BiTalih: Sabit şablon ve değişken alan mantığıyla kurulan içerik üretim platformu; rol bazlı erişimle içerik üretimi saatlerden dakikalara indi.
• Welldone: Endüstriyel çamaşırhane operasyonu için Flutter mobil uygulama, React yönetim paneli ve .NET servisleri; sahada QR kod ile paketleme, yöneticide gerçek zamanlı raporlama.
• Terazzi: Var olan bir platformda tasarım ve müşteri paneli geliştirmeleri, arama motoru görünürlüğü ve backend performansı üzerinde çalışıldı.