İş modelini kanıtlayan bir MVP, yalnızca demoyu değil.
İlk atölyeden gerçek kullanıcıların para ödediği bir ürüne. Kapsamı acımasızca daraltılmış, mühendisliği düzgün yapılmış — böylece v2 bir yineleme olur, baştan yazım değil.
- Kapsam atölyesi
- Yapım sprintleri
- Sağlamlaştırma & lansman
- Kanıt döngüsü
Disiplin, yapmayı reddettiğimiz şeydedir.
Minimum uygulanabilir ürün bir bahistir: gerçek kanıt üreten en küçük yapım. Çoğu ilk sürüm, mühendislik zayıf olduğu için değil, kimsenin aslında sormadığı bir soruyu yanıtladığı için başarısız olur — fikrin hoş taraflarını gösterir ve işin bağlı olduğu tek iddiadan sessizce kaçınır. Kapsamı en riskli varsayıma göre belirler, onu sınamayan her şeyi keser ve başarıya dayanabilecek bir altyapı üzerinde yayına alırız; çünkü en sık gördüğümüz başarısızlık biçimi tutmayan bir MVP değildir. Çalışan, ilgi gören ve sonra çöpe atılması gereken bir MVP’dir.
Bu yüzden çıkardığımız sürüm bilinçli olarak dar ve bilinçli olarak gerçektir. Gerçek kullanıcılar, para iddianın parçasıysa gerçek ödemeler, gerçek izleme, sonrasında sorgulayabileceğiniz gerçek veri. Bir prototip size ekranların beğenilip beğenilmediğini söyler; bir MVP davranışın değişip değişmediğini söyler. Fark daha sonra, yönetim kurulu ne öğrendiğinizi sorduğunda ve dürüst yanıtın bir dizi olumlu görüşme değil bir sayı olması gerektiğinde ortaya çıkar.
Ertelenen her özellik, lansman tarihine geri kazandırılmış zamandır — ve kapsam defterimiz her ertelemeyi gerekçesiyle ve onu geri getirecek kanıtla birlikte kaydeder; böylece hiçbir şey sessizce kaybolmaz ve kimse aynı kesintiyi iki kez savunmak zorunda kalmaz.
Bir ilk sürümün yapması gereken dört şey.
Bir MVP’nin tek işi vardır: yanılmayı kaldırılabilir kılacak kadar ucuza kanıt üretmek. Aşağıdaki her şey buna hizmet eder; aşırı mühendislik gibi görünen ama olmayan kısımlar dahil.
En riskli varsayıma göre kapsam
İşinizin bağlı olduğu iddiayı belirler ve bunu gerçek kullanıcılar ve gerçek parayla sınayan en küçük ürünü tasarlarız. Bu genellikle kısmen yapılmış beş akış yerine düzgün yapılmış tek bir akış demektir; ayrıca varsayımı atölyede açıkça adlandırmak demektir, böylece kapsam tartışması iki haftada bir değil, bir kez ve en başta yaşanır. Ortaya çıkan şey, tüm ekibin işaret edebileceği yazılı bir v1 sınırıdır.
Canlı ortam düzeyinde temeller
MVP kırılgan demek değildir. Kimlik doğrulama, ödemeler, izleme ve CI/CD en baştan bağlanır — asla yeniden yapmak istemeyeceğiniz ve v2’nin bir yineleme mi yoksa yeniden başlangıç mı olacağına sessizce karar veren parçalar. Kanıtlanmış, iyi bilinen parçaları kullanırız: uçtan uca TypeScript, önde Next.js, altta PostgreSQL, ilk commit’ten itibaren kod olarak devreye alma.
Düzenli demo ritmi
Sizinle kararlaştırılan düzenli bir ritimde çalışan yazılım. Kapsamı yönlendirmek hâlâ ucuzken, bir sunum yerine canlı bir hazırlık ortamı üzerinde yönlendirirsiniz ve demo, canlıya gidecek olan yapının üzerinde çalıştırılır. O oturumda alınan kararlar aynı gün kapsam defterine işlenir; lansman tarihinin sessizce kaymak yerine dürüst kalmasının nedeni budur.
Lansman & ölçüm
Analitik, huniler ve geri bildirim döngüleri baştan kurulur; böylece MVP yalnızca ekran görüntüsü değil, kanıt üretir. Devam etmenizi, yön değiştirmenizi ya da durmanızı sağlayacak iki ya da üç sayıyı yapım başlamadan önce kararlaştırır ve önce onları ölçmeye başlarız. Lansmandan sonra huni değerlendirmesinde sizinle birlikte otururuz: bu işin amacı bir karardır ve karar, kıyaslanabileceği bir başlangıç çizgisine ihtiyaç duyar.
İş günlük olarak nasıl yürür?
Kapsam defteri, herkese açık tutulur.
Kapsam tartışmaları pahalıdır, çünkü tekrarlanır. Erken bir aşamada biri bir özellik ister, özellik kapsam dışı bırakılır ve daha sonra aynı talep başka bir yönden, daha fazla aciliyetle gelir. Defter buna son verir. Her talep bir kararla, bir gerekçeyle ve — önemli olduğu yerde — onu kapsama geri sokacak kanıtla birlikte yazılır. Hiçbir şey reddedilmez; işler sıraya konur. Ekibinizin çalışmanın herhangi bir gününde okuyabileceği sade bir belgedir ve aynı zamanda v2 iş listesinin dürüst ilk taslağıdır.
- Her talep bir karar, bir gerekçe ve yeniden ele alınma koşuluyla birlikte kaydedilir
- Eşdeğer değişimler yalnızca takas edilir; genişlemeler tarihi, kararlaştırıldıkları gün, görünür biçimde değiştirir
- Lansmanda ertelenenler sütunu, fiyatlanmış ve önceliklendirilmiş haliyle v2 iş listesine dönüşür
Asla yeniden yapmak istemeyeceğiniz parçalar.
Başta yapması ucuz, sonradan eklemesi acı verici olan kısa bir liste vardır: kimlik, ödemeler, ortamlar, devreye alma, hata raporlama ve geçiş yapılacağını varsayan bir veritabanı şeması. Bunların her biri diğer her şeye dokunur; dolayısıyla sonradan eklemek bir görev değil, bir yeniden düzenlemedir. Bu listeyi önce, en basit doğru haliyle kurar, kalan zamanı ürüne ayırırız. Bir Odeontech MVP’sinin lansman günü telaşsız biçimde trafik alabilmesinin nedeni budur.
- İlk özellik dalından önce ortamlar, CI/CD ve önizleme devreye almaları
- Kimlik, roller ve denetim alanları bir kez tasarlanır — sonradan eklemek her tabloya dokunur
- Hata takibi, çalışma süresi kontrolleri ve temel bir nöbet akışı ilk olaydan sonra değil, lansmandan önce devrededir
Heyecan değil, kanıt.
Bir MVP’nin en değerli çıktısı, savunabileceğiniz bir karardır. Bunun için önceden kararlaştırılmış, lansmandan önce ölçülmeye başlanmış ve kararlaştırılmış bir ritimde değerlendirilen sayılar gerekir — yoksa değerlendirme, hangi anekdotun temsil edici olduğu üzerine bir tartışmaya döner. Huniyi kapsam atölyesinde sizinle birlikte kurarız: etkinleşme adımı, değerin hissedildiği an ve para iddianın parçasıysa ücretli dönüşüm. Sonra sizinle kararlaştırılan bir ritimde birlikte izler ve durmayı meşru bir sonuç sayarız. Net bir hayır üreten bir MVP işini yapmıştır.
- Yapımdan önce kararlaştırılan, lansmandan önce ölçülmeye başlanan iki ya da üç başarı metriği
- Sizinle kararlaştırılan bir ritimde, ertelenen iş listesi sayıların yanında açıkken düzenli huni değerlendirmesi
- Niteliksel geri bildirim, metriklerin ölçtüğü akışlarla eşleştirilerek toplanır
Aynı yapım, üç farklı beklenti.
Yatırım turunu üzerine kurabileceğiniz bir tarih.
Yatırım görüşmeleri kanıt ve zamanlama üzerinden yürür. Atölyenin ardından bir kapsam aralığı, ekran kaydı alabileceğiniz düzenli demolar ve siz kapsamı genişletmeyi seçtiğinizde değişen bir lansman tarihi alırsınız. Kapsam defteri aynı zamanda neye, neden karar verdiğinizin kaydıdır; bu da bir inceleme görüşmesinde yol haritası sunumundan daha iyi bir yanıttır.
- Ücretli kapsam atölyesinden sonra kararlaştırılan kapsam aralığı
- Prototip değil, canlı ortam üzerinde düzenli demolar
Yeni bir sorun çıkarmayan yeni bir ürün.
Bir kurumun içinde ilk sürümün zor kısmı nadiren yapımdır — satın alma, kimlik, verinin nerede tutulacağı ve güvenlik incelemesidir. Bunları sonradan keşfetmek yerine en başta planlarız ve güvenlik mühendisliği sayfamızda anlatılan standartlara göre geliştiririz; böylece iç inceleme, sorgulayacak bir şey yerine onaylayacak bir şey bulur.
- Güvenlik ve veri konumu soruları birinci aşamada, yazılı olarak yanıtlanır
- Mevcut sistem envanterinize göre tasarlanmış SSO, günlükleme ve erişim denetimi
- İç ekibe ya da bizimle Dedicated team’e devir yolu
Sizin de yazacağınız bir kod tabanı.
Bunu siz devralacaksınız. Bu yüzden uçtan uca tiplenmiş, riskin olduğu yerde test edilmiş, hat üzerinden devreye alınmış ve bir devir toplantısında değil, depoda belgelenmiştir. Gizli yapım adımı yok, yalnızca tek kişinin çalıştırabildiği bir makine yok, sohbet mesajında sır yok. İsterseniz mühendisleriniz ilk sprintten itibaren pull request’lerimizi inceler ve diledikleri anda kendi değişikliklerini birleştirmeye başlayabilir.
- İstemci ve sunucuda tek dil, şema öncelikli bir API sözleşmesiyle
- Testler kapsama oranı için yayılmak yerine para, kimlik doğrulama ve veri bütünlüğünde yoğunlaşır
- Kod olarak altyapı; böylece ortam biz olmadan yeniden kurulabilir
Neler standarttır, neler ürüne göre şekillenir.
Dört aşama ve erkenden çalışan yazılım.
Kapsam atölyesi
Varsayım haritası, kullanıcı akışları ve kapsam defteri: v1’de ne var, ne bilinçli olarak ertelendi ve neden. Sınanan iş iddiasını, onu kanıtlayacak ya da çürütecek iki üç sayıyı ve varsayılan değil gerçek olan kısıtları — düzenleyici, ticari, teknik — birlikte ele alırız. Atölye ücretli ve bağımsız bir çalışmadır ve çıktısı size teslim edilir: defter, akışlar, bir mimari taslak ve fiyatlanmış bir aralık.
Yapım sprintleri
Düzenli demolar, ilk sprintten itibaren canlı bir hazırlık ortamı ve kanıt geldikçe birlikte alınan kapsam kararları. Her döngü neyin çıktığıyla açılır ve bir sonraki döngünün ne getireceğiyle kapanır; böylece ödünleşimler hâlâ ucuzken yapılır. Önce temeller yerleşir — kimlik, ödemeler, teslimat hattı, geçişler — sonra sınanan akış ekran ekran değil uçtan uca kurulur; böylece gerçek bir kişinin tamamlayabileceği bir şey her zaman vardır.
Sağlamlaştırma & lansman
Güvenlik incelemesi, yük açısından temel kontroller, kapsamda mobil istemci varsa mağaza ya da App Review başvurusu, DNS geçişi ve önemli metrikler için ölçümleme. Hata yollarını bilerek test ederiz: reddedilen bir ödeme, süresi dolmuş bir oturum, yavaş bir üçüncü taraf, mükerrer bir gönderim. Lansmanın kendisinde sürpriz olmaz: yapım boyunca hazırlık ortamına devreye alan hat, canlıya devreye alan hattın aynısıdır.
Kanıt döngüsü
Sizinle kararlaştırılan bir ritimde düzenli huni değerlendirmesi. Hızlanın, yön değiştirin ya da durun — MVP’nin işi bu kararı ucuzlatmaktır ve defter bir sonraki adımın fiyatlanmasını kolaylaştırır. Bazı müşteriler bizimle daha uzun bir yapıma ya da bir Dedicated team’e devam eder; bazıları bir devir dönemiyle kod tabanını kendi bünyesine alır; bazıları durur ki bu, erken alınmış iyi bir sonuçtur. Üçü de en baştan planlanır.
Lansmanda masada ne var.
- Canlı altyapıda, gerçek kullanıcıları olan devreye alınmış bir ürün
- Kapsam defteri — ne çıktı, ne ertelendi ve neden
- Metrik başlangıç çizgisiyle birlikte analitik ve huni ölçümlemesi
- Fiyatlanmış, kanıta göre sıralanmış bir v2 iş listesi
- Önizleme ortamları ve provası yapılmış geri alma ile CI/CD
- Toplantıda değil, depoda yazılmış mimari notlar ve runbook’lar
Bu ne zaman doğru tercih.
Bir tabloyla ya da anketle yanıtlayamayacağınız belirli bir iddia varsa MVP seçin — bir segmentin ödeme yapacağı, bir iş akışının e-postadan çıkarılabileceği, bir kanalın dönüşüm sağladığı, bir operasyonel sürecin gerçek hacimle karşılaştığında ayakta kaldığı. Bir sonraki yatırım turundan önce kanıta ihtiyaç duyan bir kurucuya, hipotezi ve bütçe döngüsü olan bir kurumsal ekibe ve kesinliğe giden en hızlı yolun dar ama çalışan bir sürümü gerçek kullanıcıların önüne koymak olduğu her ürüne uygundur. Hangi iddianın en önemli olduğuna henüz karar vermediyseniz Ürün Keşfi ile başlayın.
Gereksinim kümesi sözleşmeyle ya da mevzuatla zaten biliniyor ve kararlaştırılmışsa başka yere bakın: o bir tam yapımdır ve aksini varsaymak yalnızca projenin adını değiştirir — bkz. Özel Yazılım Geliştirme. Asıl sorun ilerlemesi durmuş mevcut bir sistemse yine başka yere bakın; orada dürüst yanıt modernizasyon ya da legacy yeniden mühendisliği olur. Ve sizin tarafınızda hızlıca kapsam kararı verebilecek kimse yoksa dikkatli olun: bir MVP’yi küçük tutan şey düzenli yönlendirmedir ve o olmadan yapım sessizce yavaş bir v1’e dönüşür.
Sık sorulan sorular
Bunun bağlandığı yerler.
Ürününüzün kanıtlaması gereken tek şey ne?
Varsayımı ve kimin farklı davranması gerektiğini söyleyin. Bir mühendis okur ve bunu netleştirecek en küçük yapıma dair değerlendirmesini yazılı olarak iletir.