[{"data":1,"prerenderedAt":43},["ShallowReactive",2],{"blog-mvp-nedir":3},{"html":4,"toc":5,"faq":30},"\u003Cp>MVP (minimum viable product, Türkçede “minimum uygulanabilir ürün”), bir varsayımı gerçek kullanıcıyla test edebilen ya da bir süreci gerçekten devralabilen, canlıda çalışan en dar yazılım sürümüdür. Az şey yapar ama yaptığı şeyi düzgün yapar. Yarım bırakılmış, hatalı bir tam ürün değildir; bilerek dar tutulmuş, sağlam bir ilk adımdır.\u003C\u002Fp>\n\u003Ch2 id=\"mvp-nin-iki-farkli-kullanimi\">MVP'nin iki farklı kullanımı\u003C\u002Fh2>\n\u003Cp>MVP kavramı genelde girişim dünyasıyla, yani yeni bir ürünün pazarda tutup tutmayacağını test etmekle anılır. Ama aynı düşünce, bir şirketin kendi iç süreçleri için yaptırdığı yazılımda da en az o kadar işe yarar. İkisinin amacı biraz farklıdır.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Ürün için MVP\u003C\u002Fstrong>, bir soruya cevap arar: insanlar bunu kullanacak mı, bunun için para ödeyecek mi, sorunu gerçekten çözüyor mu? Burada önemli olan öğrenmektir. İlk sürüm, bu soruyu en az emekle ve en güvenilir biçimde cevaplayacak kadar büyük olmalıdır.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>İç araç için MVP\u003C\u002Fstrong> ise başka bir şey arar: bir süreci, örneğin sipariş takibini ya da satın alma onayını, Excel'den ve e-postadan gerçekten devralabilen en dar sürüm hangisi? Burada kullanıcılar zaten bellidir; soru, onların işini ilk günden kolaylaştıracak en küçük parçanın ne olduğudur.\u003C\u002Fp>\n\u003Cp>İki durumda da ortak ilke aynı: ilk sürüm, bir sonraki kararı vermenizi sağlayacak bilgiyi üretmelidir. Kullanılmayan ya da kullanılamayan bir sürüm bu bilgiyi üretemez.\u003C\u002Fp>\n\u003Ch2 id=\"mvp-ne-degildir\">MVP ne değildir?\u003C\u002Fh2>\n\u003Cp>MVP kelimesi o kadar çok kullanılıyor ki, anlamı sık sık kayıyor. Şunlar MVP değildir:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Hatalı bir tam ürün.\u003C\u002Fstrong> Bütün özellikleri içeren ama hiçbirini düzgün yapmayan bir sürüm, MVP değil yarım iştir. Kullanıcılar dar bir aracı affeder, sürekli bozulan bir aracı affetmez.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Kimsenin kullanmadığı bir demo.\u003C\u002Fstrong> Sunumda gösterilip rafa kalkan bir sürüm hiçbir şey öğretmez.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Güvenliği ve yedeği atlanmış bir sürüm.\u003C\u002Fstrong> Dar kapsam, özensiz altyapı anlamına gelmez. Yetkilendirme, yedekleme ve hata kaydı ilk sürümde de olmalıdır.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sonradan çöpe atılacak bir taslak.\u003C\u002Fstrong> Bazen bilinçli olarak atılacak bir deneme yapılır ve bu meşrudur; ama buna MVP değil, prototip ya da deney demek daha doğrudur.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Bütçe yetmediği için kesilmiş rastgele bir parça.\u003C\u002Fstrong> MVP'nin kapsamı neyin öğrenilmek istendiğine göre belirlenir, kalan paraya göre değil.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Kısacası MVP'de kısılan şey genişliktir, kalite değil.\u003C\u002Fp>\n\u003Cp>Kavramın adındaki iki kelime bu dengeyi iyi anlatır. “Minimum” kapsamı, “uygulanabilir” ise kullanılabilirliği tarif eder. Çoğu ekip birincisine odaklanıp ikincisini unutur: sürüm küçülür ama kimsenin işini görmez hale gelir. Tersi de olur; her şey “uygulanabilir” olsun diye eklenir ve sürüm minimum olmaktan çıkar. İyi bir MVP, ikisinin kesiştiği dar alanda durur: kullanıcının bir işi baştan sona yapabildiği, ama yalnızca o işi yapabildiği bir sürüm.\u003C\u002Fp>\n\u003Ch2 id=\"ilk-surumu-nasil-dilimlersiniz\">İlk sürümü nasıl dilimlersiniz?\u003C\u002Fh2>\n\u003Cp>Dilimleme, MVP'nin en zor ve en değerli kısmıdır. Aşağıdaki sıra hem ürünler hem iç araçlar için işe yarar:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Tek bir cümleyle hedefi yazın.\u003C\u002Fstrong> “Saha ekipleri iş emrini telefondan kapatabilsin ve ofis bunu aynı gün görsün” gibi. Bu cümleye hizmet etmeyen her şey ikinci faza aday olur.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Uçtan uca akışı çıkarın.\u003C\u002Fstrong> Kayıt nerede başlıyor, kimden kime geçiyor, nerede bitiyor? MVP bu akışın tamamını kapsamalı, ama her adımın en basit haliyle.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Her adım için “en basit hali ne?” diye sorun.\u003C\u002Fstrong> Otomatik eşleştirme yerine elle seçim, gelişmiş filtre yerine tek bir arama kutusu, özel rapor yerine dışa aktarma.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Vazgeçilmezleri ayırın.\u003C\u002Fstrong> Rol ve yetkiler, veri doğrulama, yedekleme ve temel hata kaydı kesilmez. Bunlar sonradan eklenmesi en pahalı şeylerdir.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Dışarıda bırakılanları yazın.\u003C\u002Fstrong> “İkinci faz” listesi, kapsamın en az kendisi kadar önemlidir. Yazılmayan istek, proje boyunca geri gelir.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Başarı ölçütünü baştan belirleyin.\u003C\u002Fstrong> Hangi sonucu görürseniz MVP işini yapmış sayılacak? Bu sorunun cevabı yoksa MVP'nin bitip bitmediğini de bilemezsiniz.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Örneğin yirmi kişilik saha ekibiyle çalışan bir teknik servis firması düşünün. İlk istek listesinde iş emri, stok düşümü, müşteri imzası, fotoğraf, faturalama, rota planlama ve yönetici paneli var. Dilimlenmiş bir MVP şöyle görünebilir: ofis iş emrini açar ve teknisyene atar, teknisyen telefondan işi kapatıp fotoğraf ekler, ofis kapanan işleri günlük listede görür ve dışa aktarır. Stok, rota ve faturalama ikinci faza kalır. Bu sürüm küçük, ama ekibin her gün kullandığı Excel listesini ve telefon trafiğini gerçekten devralabilir.\u003C\u002Fp>\n\u003Ch2 id=\"dilimlemede-sik-yapilan-hatalar\">Dilimlemede sık yapılan hatalar\u003C\u002Fh2>\n\u003Cp>Birkaç hata, iyi niyetle başlayan MVP'leri sessizce büyütür. Birincisi, her paydaşın “olmazsa olmaz” listesini birleştirmektir; sonuçta herkesin bir isteği girer, kimsenin işi tam olarak çözülmez. İkincisi, akışı yatay değil dikey kesmektir: bütün ekranları yapıp hiçbirini birbirine bağlamamak yerine, tek bir akışı başından sonuna çalışır hale getirmek gerekir. Üçüncüsü, yönetim panelini ve raporlamayı tamamen unutmaktır. Kullanıcı ekranı hazırdır ama yönetici veriyi göremediği için Excel'e geri dönülür. En basit haliyle bir liste ve dışa aktarma çoğu zaman yeterlidir; hiç olmaması değil.\u003C\u002Fp>\n\u003Cp>Son bir hata da MVP'yi bir kez çıkarıp bırakmaktır. MVP bir başlangıç noktasıdır. Kullanımdan gelen bilgiyle bir sonraki fazın kapsamını belirlemiyorsanız, yaklaşımın asıl faydasını kaçırıyorsunuz.\u003C\u002Fp>\n\u003Ch2 id=\"mvp-yi-nasil-olcersiniz\">MVP'yi nasıl ölçersiniz?\u003C\u002Fh2>\n\u003Cp>Ölçüt, MVP'nin türüne göre değişir. Önemli olan sayıların süs değil, karar verdiren bilgi olması.\u003C\u002Fp>\n\u003Cdiv class=\"table-scroll\">\u003Ctable>\n\u003Cthead>\n\u003Ctr>\n\u003Cth>Soru\u003C\u002Fth>\n\u003Cth>İç araç için\u003C\u002Fth>\n\u003Cth>Ürün için\u003C\u002Fth>\n\u003C\u002Ftr>\n\u003C\u002Fthead>\n\u003Ctbody>\u003Ctr>\n\u003Ctd>Kullanılıyor mu?\u003C\u002Ftd>\n\u003Ctd>Hedef süreçteki kayıtların ne kadarı yeni sistemden geçiyor\u003C\u002Ftd>\n\u003Ctd>Kayıt olan kullanıcıların ne kadarı temel işlemi tamamlıyor\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Eski yöntem bırakıldı mı?\u003C\u002Ftd>\n\u003Ctd>Excel dosyası ve e-posta trafiği azaldı mı\u003C\u002Ftd>\n\u003Ctd>Kullanıcılar ikinci kez geri geliyor mu\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Sorunu çözüyor mu?\u003C\u002Ftd>\n\u003Ctd>Hata, gecikme ve “durum ne?” soruları azaldı mı\u003C\u002Ftd>\n\u003Ctd>Kullanıcılar ödemeye ya da devam etmeye razı mı\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003Ctr>\n\u003Ctd>Ne eksik?\u003C\u002Ftd>\n\u003Ctd>Kullanıcıların hâlâ sistem dışında yaptığı işler\u003C\u002Ftd>\n\u003Ctd>En sık gelen istek ve şikâyetler\u003C\u002Ftd>\n\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\u003C\u002Fdiv>\n\u003Cp>Ölçümün en basit ve en çok ihmal edilen yolu, kullanıcılarla konuşmaktır. İlk haftalarda sistemi kullanan birkaç kişiyle kısa görüşmeler yapmak, çoğu zaman herhangi bir panodan daha fazlasını söyler. Kullanıcıların sistemin dışında hâlâ ne yaptığını sorun; ikinci fazın kapsamı genelde o cevaptan çıkar.\u003C\u002Fp>\n\u003Ch2 id=\"mvp-yaklasiminin-uymadigi-durumlar\">MVP yaklaşımının uymadığı durumlar\u003C\u002Fh2>\n\u003Cp>MVP her iş için doğru çerçeve değildir ve bunu baştan bilmek, yanlış beklentiyi önler. Bazı yazılımların “dar ama çalışan” bir hali yoktur. Mevzuata bağlı bir hesaplamanın yarısını doğru yapmak işe yaramaz; bordro girdisi, vergi hesabı ya da e-Belge üretimi gibi işlerde ilk sürüm de eksiksiz ve doğru olmak zorundadır. Burada kapsamı daraltmanın yolu kuralları eksik bırakmak değil, kapsanan kullanıcı ya da işlem grubunu sınırlamaktır: önce tek şube, tek belge türü ya da tek bir çalışan grubu.\u003C\u002Fp>\n\u003Cp>Benzer biçimde, çalışan ve kritik bir sistemi değiştiriyorsanız, yenisinin eskisinden daha az iş yaptığı bir dönem kabul edilemez olabilir. Bu durumda MVP yerine kademeli bir geçiş planı daha uygundur: yeni sistem önce eski sistemin yanında tek bir işi devralır, sonra bir başkasını. Adı ne olursa olsun ilke aynı kalır: büyük ve geri dönüşü zor bir adım yerine, her biri kendi başına işe yarayan küçük adımlar.\u003C\u002Fp>\n\u003Cp>Bir de şu durum var: kullanıcının ilk temasta yüksek bir kalite beklediği, rakiplerin zaten olgun olduğu bir pazarda çok dar bir ürün, öğrenmek yerine kötü bir ilk izlenim bırakabilir. Burada dar tutulması gereken şey özellik sayısıdır, ilk kullanım deneyiminin özeni değil.\u003C\u002Fp>\n\u003Ch2 id=\"kendi-urunumuzden-ogrendigimiz\">Kendi ürünümüzden öğrendiğimiz\u003C\u002Fh2>\n\u003Cp>Yalnızca müşterilerimiz için yazılım yazmıyoruz; eSIM satıcıları için bir B2B platform olan \u003Ca href=\"\u002Furunler\">Esimbit'i\u003C\u002Fa> kendimiz yazıp işletiyoruz. Bir ürünü işletmek, MVP'ye bakışımızı bir noktada netleştirdi: ilk sürümün kapsamını belirlerken yayından sonraki işi de hesaba katmak gerekiyor. Bağlandığınız her dış servis bir gün hata verir, her kafa karıştıran ekran bir destek mesajına dönüşür. Bu yüzden dar bir MVP'de bile hata durumlarını, tekrar denemeleri ve izlenebilir kaydı kesilecekler listesine koymuyoruz. Kapsamı daraltmak doğru; dayanıklılığı daraltmak değil.\u003C\u002Fp>\n\u003Ch2 id=\"nereden-baslamali\">Nereden başlamalı?\u003C\u002Fh2>\n\u003Cp>İlk adım bir istek listesi değil, tek cümlelik bir hedef ve o hedefe giden uçtan uca akış. Bunu yazdıktan sonra her adımın en basit halini ve ikinci faza kalacakları belirleyin. Bu çalışma, tedarikçilerden alacağınız tekliflerin de aynı şeyi kapsamasını sağlar; teklifleri karşılaştırırken nelere bakacağınızı \u003Ca href=\"\u002Fblog\u002Fyazilim-teklifi-nasil-karsilastirilir\">yazılım teklifi nasıl karşılaştırılır\u003C\u002Fa> yazısında anlattık. Excel'den çıkmak istediğiniz bir süreç için MVP düşünüyorsanız, \u003Ca href=\"\u002Fblog\u002Fexcelden-is-yazilimina-gecis\">Excel'den iş yazılımına geçiş\u003C\u002Fa> yazısı da ilk neyi taşıyacağınıza karar vermenize yardımcı olur.\u003C\u002Fp>\n\u003Cp>\u003Ca href=\"\u002Fhizmetler\u002Fozel-yazilim-gelistirme\">Özel iş yazılımı\u003C\u002Fa> projelerimizde ilk sürümü tam olarak bu mantıkla kuruyoruz: Excel'i gerçekten devre dışı bırakan en dar sürüm, canlıda, veriniz taşınmış ve ekibiniz eğitilmiş halde. İlk sürümünüzü birlikte dilimlemek isterseniz \u003Ca href=\"\u002Filetisim\">iletişim sayfamızdan\u003C\u002Fa> bir görüşme ayarlayabilirsiniz.\u003C\u002Fp>\n",[6,9,12,15,18,21,24,27],{"id":7,"text":8},"mvp-nin-iki-farkli-kullanimi","MVP'nin iki farklı kullanımı",{"id":10,"text":11},"mvp-ne-degildir","MVP ne değildir?",{"id":13,"text":14},"ilk-surumu-nasil-dilimlersiniz","İlk sürümü nasıl dilimlersiniz?",{"id":16,"text":17},"dilimlemede-sik-yapilan-hatalar","Dilimlemede sık yapılan hatalar",{"id":19,"text":20},"mvp-yi-nasil-olcersiniz","MVP'yi nasıl ölçersiniz?",{"id":22,"text":23},"mvp-yaklasiminin-uymadigi-durumlar","MVP yaklaşımının uymadığı durumlar",{"id":25,"text":26},"kendi-urunumuzden-ogrendigimiz","Kendi ürünümüzden öğrendiğimiz",{"id":28,"text":29},"nereden-baslamali","Nereden başlamalı?",[31,34,37,40],{"q":32,"a":33},"MVP ile prototip arasındaki fark nedir?","Prototip, bir akışın nasıl görüneceğini ve çalışacağını tartışmak için yapılır; genelde gerçek veriyle canlıda kullanılmaz. MVP ise gerçek kullanıcıların gerçek işlerini yaptığı, canlıda çalışan ilk sürümdür. Prototip soruları ucuza cevaplar, MVP ise varsayımı gerçek kullanımla test eder.",{"q":35,"a":36},"MVP ne kadar sürede çıkar?","Kapsama, entegrasyon sayısına ve kararların ne kadar hızlı verildiğine bağlı. Kural olarak, ilk sürüm aylarca sürüyorsa büyük ihtimalle MVP olmaktan çıkmıştır. Kapsamı daraltmak, süreyi kısaltmanın en etkili yoludur.",{"q":38,"a":39},"MVP'den sonra yazılım baştan mı yazılır?","İyi kurulmuş bir MVP'de genelde hayır. MVP dar ama sağlam yazılır; sonraki fazlar onun üzerine eklenir. Baştan yazma ihtiyacı çoğu zaman MVP'nin dar değil özensiz yapıldığını gösterir.",{"q":41,"a":42},"Şirket içi bir araç için de MVP yaklaşımı uygun mu?","Evet, belki ürünlerden bile daha uygun. İç araçta MVP, tek bir süreci uçtan uca devralan en dar sürümdür. Ekip onu gerçekten kullanmaya başladığında, sonraki ihtiyaçlar varsayımla değil kullanımla ortaya çıkar.",1793978421139]