Web Yazılım Projesinde MVP Kapsamı Nasıl Belirlenir? İlk Sürüm Karar Tablosu

Bir web yazılım projesinde MVP kapsamı, listedeki en kolay özellikleri seçerek değil; hedef kullanıcının en önemli işini başlangıçtan sonuca tamamlayabildiği en küçük kullanılabilir sürümü tanımlayarak belirlenir. Kullanıcı bu sürümde giriş yapabiliyor fakat asıl kaydı oluşturamıyorsa ya da kayıt oluşturuyor fakat sonucunu takip edemiyorsa ortada tamamlanmış bir temel akış yoktur.

Bu nedenle ilk sürüm kararı şu dört soruya dayanmalıdır:

1. Hangi kullanıcı, hangi temel işi tamamlayacak?
2. Bu işin gerçekleşmesi için hangi adımlar vazgeçilmez?
3. Hangi teknik ve operasyonel koşullar güvenli, izlenebilir ve kullanılabilir bir sürüm için zorunlu?
4. Sürümün tamamlandığını hangi test edilebilir kabul ölçütleri gösterecek?

Bu makaledeki MVP İlk Sürüm Karar Tablosu, her talebi kullanıcı, iş sonucu, ana akış, veri ve yetki, zorunluluk, bağımlılık, kabul ölçütü ve faz kararı üzerinden değerlendirir. Amaç kapsamı rastgele küçültmek değil; ilk sürümde gerçekten öğrenilebilecek, kullanılabilecek ve yönetilebilecek bir ürün sınırı oluşturmaktır.

MVP, En Az Özellikli Yazılım Değildir

MVP çoğu projede “mümkün olan en az şeyi yapalım” şeklinde yorumlanır. Bu yaklaşım, kullanıcıya değer üretmeyen parçalı bir sürüme yol açabilir. Oysa ilk sürümün küçük olması kadar, temel iş sonucunu eksiksiz üretmesi de gerekir.

Örneğin bir müşteri portalında yalnızca kullanıcı girişi ekranı hazırlamak kullanılabilir bir ürün ortaya çıkarmaz. Kullanıcının kayıt oluşturması, kaydın durumunu görmesi ve yetkisi dâhilindeki verilere erişmesi ana iş akışının parçalarıysa bunların birlikte değerlendirilmesi gerekir. Gelişmiş grafikler veya farklı kanallardan otomatik bildirimler ise ana akış çalıştıktan sonra eklenebilir.

Scrum Guide, Product Goal'u ekip için planlamayı yönlendiren gelecekteki ürün durumu olarak tanımlar; Product Backlog'u da ürünü geliştirmek için gerekenlerin sıralanmış ve gelişen listesi olarak ele alır. Buradaki pratik ders şudur: önce ürünün ulaşacağı sonucu belirleyin, ardından iş listesini bu sonuca katkısına göre sıralayın. Uzun bir özellik listesi, tek başına MVP planı değildir.

Özellik Listesinden Önce Ürün Hedefini Yazın

İlk sürüm kararı vermeden önce herkesin anlayabileceği tek bir ürün hedefi hazırlayın. Hedef, “müşteri portalı geliştirmek” gibi çözüm adından ibaret kalmamalıdır. Kullanıcıyı, yapılacak işi ve beklenen sonucu belirtmelidir.

Örnek:

Kurumsal müşteriler, destek ekibine e-posta göndermeden kendi kayıtlarını oluşturabilsin, güncel durumunu görebilsin ve geçmiş işlemlerini yetkileri dâhilinde takip edebilsin.

Bu hedef üç sınır oluşturur:

• Kullanıcı: Kurumsal müşteri ve onun yetkili çalışanları
• Temel iş: Kayıt oluşturma ve durum takibi
• Beklenen sonuç: Sürecin portal içinde görünür ve izlenebilir ilerlemesi

Bir talebin bu hedefle ilişkisi açıklanamıyorsa ilk sürümde bulunması için güçlü bir gerekçe yoktur. Bununla birlikte güvenlik, yedekleme veya hata takibi gibi kullanıcı ekranında görünmeyen işler doğrudan bir özellik gibi görünmese de ana akışın güvenilir biçimde çalışması için zorunlu olabilir.

Proje hedefi, kullanıcılar, içerik, veri ve entegrasyon ihtiyaçları henüz net değilse önce web sitesi ihtiyaç dokümanı hazırlama rehberindeki sorularla başlangıç girdilerini oluşturabilirsiniz.

MVP Keşif Sürecine Kimler Katılmalı?

MVP kapsamı yalnızca yazılım ekibinin teknik kararı veya müşteri tarafındaki tek bir yöneticinin istek listesi olmamalıdır. Kumsal Ajans sürecinde proje hedefleri, kullanıcı ihtiyaçları, temel iş akışları ve teknik gereksinimler birlikte değerlendirilir.

Görüşmelere proje koşullarına göre şu taraflar katılır:

• Müşteri tarafındaki karar vericiler
• Süreci günlük olarak yürüten ilgili departman temsilcileri
• Kumsal Ajans proje ekibi
• Tasarım ekibi
• Yazılım ekibi

Karar verici iş hedefini ve yatırım sınırını; departman temsilcileri gerçek kullanım adımlarını ve istisnaları; tasarım ile yazılım ekipleri de akışın uygulanabilirliğini, bağımlılıklarını ve teknik risklerini ortaya koyar.

Keşif sonunda en azından şu çıktılar görünür olmalıdır:

• İhtiyaç listesi
• Önceliklendirilmiş özellikler
• Temel kullanıcı akışları
• Kullanıcı rolleri ve veri erişim sınırları
• Bilinen entegrasyon ve teknik bağımlılıklar
• Genel proje yol haritası
• İlk sürüm için taslak kabul ölçütleri

Bu çıktıların biçimi projeye göre değişebilir. Önemli olan kararların yalnızca toplantı notlarında kalmaması ve kapsamın teklif, ihtiyaç dokümanı ya da proje takip sistemi üzerinden izlenebilmesidir.

Önce Uçtan Uca Temel Kullanıcı Akışını Kurun

Özellikleri tek tek puanlamadan önce kullanıcının başlangıçtan sonuca giden akışını yazın. Müşteri portalı örneğinde temel akış şöyle olabilir:

1. Yetkili kullanıcı güvenli biçimde giriş yapar.
2. Kendi rolüne uygun kayıt türünü seçer.
3. Gerekli bilgileri girer ve kaydı oluşturur.
4. Sistem kaydı saklar ve izlenebilir bir durum üretir.
5. Yetkili ekip kaydı görür ve süreç içinde ilerletir.
6. Kullanıcı güncel durumu takip eder.
7. Tamamlanan işlem temel raporlamaya yansır.

Bu zincirin bir halkası yoksa, diğer özelliklerin sayısı yüksek olsa bile temel iş tamamlanamaz. Örneğin gelişmiş raporlama ekranı hazırken rol-yetki yapısı eksikse kullanıcı yanlış verilere erişebilir. Otomatik bildirimler çalışırken durum takibi doğru değilse yanlış bilgi daha hızlı iletilmiş olur.

PMI Disciplined Agile'ın özellikleri kullanıcı hikâyelerine ayırma pratiği, büyük işlevleri ekipçe uygulanabilecek daha küçük parçalara ayırırken “kim kullanacak?” ve “neden kullanacak?” sorularının sorulmasını önerir. Her parçanın kullanıcı hedefi ve kabul ölçütüyle açıklanması, özellik adlarını uygulanabilir işlere dönüştürür.

MVP İlk Sürüm Karar Tablosunun Sekiz Sütunu

Her talebi aynı ölçütlerle değerlendirmek için aşağıdaki sekiz alanı tek satırda doldurun.

1. Hedef kullanıcı

Özelliği kim kullanacak? “Kullanıcılar” gibi genel bir ifade yerine müşteri yöneticisi, saha çalışanı, operasyon uzmanı veya sistem yöneticisi gibi gerçek rolü yazın.

2. Ana problem ve iş sonucu

Bu özellik hangi sorunu çözüyor? Kullanıcı veya işletme için hangi somut sonucu üretiyor? Sonuç açıklanamıyorsa talep, alışkanlık veya kişisel tercih olabilir.

3. Temel kullanıcı akışındaki yeri

Özellik olmadan ana iş başlangıçtan sonuca tamamlanabiliyor mu? Tamamlanamıyorsa ilk sürüm adayı güçlenir. Akış yine tamamlanıyor, yalnızca daha rahat veya zengin hâle geliyorsa sonraki faz düşünülebilir.

4. Veri ve rol-yetki gereksinimi

Hangi veriler okunacak, oluşturulacak veya değiştirilecek? Kim hangi kaydı görebilir? Kişisel, ticari veya operasyonel veriye erişim sınırları daha tasarım aşamasında görünür olmalıdır.

5. Operasyon, güvenlik veya mevzuat zorunluluğu

Talep kullanıcı ekranında görünmese bile iş sürekliliği, güvenlik, denetlenebilirlik veya ilgili mevzuat nedeniyle zorunlu olabilir. Bu değerlendirme projeye ve iş modeline göre yapılmalıdır; her proje için tek bir sabit kontrol listesi yeterli değildir.

6. Teknik ve ticari bağımlılıklar

Özellik başka bir modüle, dış servise, lisansa, veri kaynağına, sözleşmeye veya müşteri kararına bağlı mı? Bağımlılık hazır değilse özellik ilk sürümün tamamını geciktirebilir veya daha küçük bir alternatif gerektirebilir.

7. Test edilebilir kabul ölçütü

“Raporlama yapılacak” gibi yoruma açık bir ifade yerine, özelliğin tamamlandığını gösterecek gözlenebilir sonucu yazın. Örneğin: “Müşteri yöneticisi yalnızca kendi kurumuna ait açık ve tamamlanmış kayıtları tarih aralığına göre listeleyebilir.”

8. Faz kararı

Her satırı üç karardan biriyle sonuçlandırın:

• İlk sürüm: Temel akış, zorunlu kontrol veya ilk öğrenme için gerekli
• Sonraki faz: Değerli fakat ilk kullanım için kritik değil ya da kullanım verisiyle yeniden değerlendirilmesi daha doğru
• Kapsam dışı: Mevcut ürün hedefiyle doğrudan ilişkili değil

Karar Tablosu Örneği

Aşağıdaki örnek, anonim bir müşteri portalı senaryosunun sadeleştirilmiş görünümüdür:

Bu örnekte ikinci faza bırakılan işler değersiz değildir. İlk sürümün ana işi olan güvenli kayıt oluşturma ve durum takibini engellemedikleri, ayrıca gerçek kullanım verisiyle daha doğru biçimde kapsamlandırılabilecekleri için ertelenmiştir.

İlk Sürüm, Sonraki Faz ve Kapsam Dışı Nasıl Ayrılır?

Bir talebi ilk sürüme almadan önce şu soruları sırayla sorun:

1. Ürün hedefiyle doğrudan ilişkili mi?
2. Olmadan temel kullanıcı akışı tamamlanıyor mu?
3. Güvenlik, veri bütünlüğü, operasyon veya mevzuat açısından zorunlu mu?
4. Başka bir ilk sürüm özelliğinin çalışması buna bağlı mı?
5. İlk kullanımdan öğrenmek istediğimiz soruyu ölçmek için gerekli mi?
6. Kabul ölçütü bugün açıkça yazılabiliyor mu?

İlk beş sorudan biri güçlü biçimde “evet” ise talep ilk sürüm adayıdır. Ancak bu otomatik bir puanlama formülü değildir. Geliştirme süresi, bütçe etkisi, teknik risk ve alternatif çözüm birlikte değerlendirilmelidir.

Temel akış onsuz çalışıyor ve gerçek kullanım verisi karar kalitesini artıracaksa sonraki faz daha uygun olabilir. Talep ürün hedefiyle ilişkilendirilemiyor veya başka bir ürünün problemine dönüşüyorsa kapsam dışı tutulmalıdır.

Görünmeyen Teknik İşleri MVP'den Çıkarmayın

MVP yalnızca görünen ekranlardan oluşmaz. Kullanıcı rolleri, erişilecek veriler, işlem yoğunluğu, entegrasyonlar ve proje riskleri analiz edilerek aşağıdaki gereksinimler proje özelinde planlanmalıdır:

• Rol ve yetki yapısı
• Güvenlik kontrolleri
• Yedekleme politikası
• İşlem ve değişiklik logları
• Hata takibi
• Performans gereksinimleri
• Entegrasyon hata senaryoları
• Gerekli geri dönüş ve operasyon adımları

Bu maddelerin hepsi her projede aynı derinlikte uygulanmaz. Örneğin yalnızca kurum içindeki az sayıda kullanıcının eriştiği bir yönetim aracıyla yoğun kişisel veri işleyen müşteri portalının riskleri farklıdır. Doğru soru “Bunu MVP'den çıkarabilir miyiz?” değil, “Temel akışın güvenli ve yönetilebilir çalışması için hangi seviye zorunlu?” olmalıdır.

Hazır bir altyapının bu rol, veri, entegrasyon ve büyüme ihtiyaçlarını karşılayıp karşılamadığından emin değilseniz hazır altyapı ile projeye özel web yazılımı karşılaştırmasını kapsam kararından önce değerlendirebilirsiniz.

Kabul Ölçütü ile Genel Tamamlanma Koşulunu Ayırın

Her özellik için kabul ölçütü, o özelliğin beklenen davranışını tanımlar. “Rol bazlı yetkilendirme tamamlandı” demek yerine hangi rolün hangi veriyi görebileceğini ve hangi işlemi yapamayacağını açıkça yazmak gerekir.

Atlassian'ın kabul ölçütleri rehberi, kabul ölçütlerini bir işin tamamlanmış sayılması için karşılaması gereken açık, kısa ve test edilebilir koşullar olarak açıklar. Kullanıcı hikâyesi amacı ve değeri anlatırken kabul ölçütü, başarılı sonucun nasıl doğrulanacağını gösterir.

Bunun yanında bütün ilk sürüm için geçerli ortak kalite koşulları bulunur. Kumsal Ajansın doğrulanan yaklaşımında ilk sürümün kabulü şu kontroller üzerinden değerlendirilir:

• Onaylanan kullanıcı akışları çalışıyor mu?
• Temel özellikler eksiksiz tamamlandı mı?
• Rol ve yetkiler doğru işliyor mu?
• Kritik hata bulunuyor mu?
• Responsive görünüm ve kullanım kontrol edildi mi?
• Proje kapsamındaki performans ve güvenlik kontrolleri tamamlandı mı?

Scrum Guide'daki Definition of Done, ürün için gerekli kalite ölçülerini karşılayan tamamlanma durumuna ilişkin ortak bir anlayış oluşturur. Projenizde Scrum kullanmasanız bile, özellik bazlı kabul ölçütleriyle bütün sürümün ortak kalite koşullarını ayrı ayrı yazmak belirsizliği azaltır.

Teslim aşamasında erişim, işlev, mobil görünüm ve teknik kontrollerin nasıl ele alınabileceği için kurumsal web sitesi teslim kontrol listesini de kullanabilirsiniz.

Faz Kararlarını ve Yeni Talepleri Yazılı Yönetin

Kapsam tablosu yalnızca proje başında hazırlanıp unutulmamalıdır. Kumsal Ajans sürecinde faz kararları müşteri proje sorumlusu ile proje ekibi tarafından birlikte alınır. Onaylanan kapsam, proje yapısına göre teklif, ihtiyaç dokümanı veya proje takip sistemi üzerinde kayıt altına alınır.

Tasarım ya da geliştirme başladıktan sonra gelen yeni talep için önce etki analizi yapılır:

• Temel akış veya onaylanmış hedef değişiyor mu?
• Mevcut tasarım, veri modeli, rol yapısı ya da entegrasyon etkileniyor mu?
• Yeni test ve kabul ölçütleri gerekiyor mu?
• Takvim ve bütçe üzerindeki etkisi nedir?
• Mevcut faza alınırsa hangi iş ertelenecek?

Sonuçta talep mevcut faza eklenebilir, sonraki faza aktarılabilir veya ayrı kapsam olarak değerlendirilebilir. “Küçük bir ekleme” ifadesi tek başına karar ölçütü değildir; görünürde küçük bir alan değişikliği bile veri, yetki ve entegrasyon zincirini etkileyebilir.

Bir web yazılım firmasını değerlendirirken yalnızca geliştirme yeteneğine değil; kapsamı, testleri, erişimleri ve değişiklik yönetimini nasıl kayıt altına aldığına da bakmak gerekir. Bu konuda web yazılım firması teknik yeterlilik rehberi ek bir kontrol çerçevesi sunar.

Yayın Sonrası Veriler Sonraki Fazı Belirlesin

İlk sürüm yayımlandığında planlama bitmez. MVP'nin temel amacı, gerçek kullanım üzerinden hangi ihtiyacın doğrulandığını ve sıradaki yatırımın nereye yapılması gerektiğini görebilmektir.

Projeye göre şu göstergeler takip edilebilir:

• Toplam ve aktif kullanıcı sayısı
• Tamamlanan işlem sayısı
• İşlem tamamlama oranı ve süresi
• Kullanıcıların akıştan ayrıldığı adımlar
• Hata oranları
• Destek taleplerinin konusu ve sıklığı
• Kullanıcı geri bildirimleri
• Manuel müdahale gerektiren süreçler

Bu göstergelerin tamamı her ürün için aynı öneme sahip değildir. Örneğin az sayıda kurumsal kullanıcısı olan bir portalda toplam kullanıcı sayısından çok tamamlanan işlem, işlem süresi ve destek ihtiyacı anlamlı olabilir.

Ölçüm sonuçlarını ikinci faz tablosuna geri taşıyın. Gelişmiş raporlar gerçekten karar vermeyi zorlaştıran bir eksikliği mi çözüyor? Bildirim eksikliği işlemlerin gecikmesine mi yol açıyor? Dış servis entegrasyonu sürekli manuel işi ortadan kaldıracak mı? Mobil uygulama talebi gerçek kullanım davranışına mı dayanıyor? Sonraki faz, ilk tahminlerin değil, mümkün olduğunca gözlenen ihtiyacın sırasını izlemelidir.

MVP Kapsamlandırmasında Sık Yapılan Hatalar

Her talebi kritik kabul etmek

Paydaşların kendi ihtiyaçlarını önemli görmesi doğaldır. Fakat bütün talepler aynı öncelikteyse gerçekte önceliklendirme yapılmamıştır. Her isteği ürün hedefi ve temel akışla ilişkilendirin.

Yalnızca ekranları saymak

Ekran sayısı; rol-yetki, veri bütünlüğü, loglama, hata yönetimi ve entegrasyon riskini göstermez. Görünmeyen teknik işleri ayrı satırlarda değerlendirin.

Kabul ölçütünü sona bırakmak

Bir özelliğin nasıl test edileceği baştan yazılamıyorsa kapsam yeterince anlaşılmamış olabilir. Kabul ölçütünü geliştirme bittikten sonra değil, karar tablosu hazırlanırken tanımlayın.

İkinci fazı belirsiz bir depoya çevirmek

“Sonra yaparız” denilen taleplere gerekçe, bağımlılık ve yeniden değerlendirme koşulu ekleyin. Aksi hâlde ikinci faz, sahipliği olmayan bir istek listesine dönüşür.

Yeni talebi etkisiz kabul etmek

Her yeni talebi veri, tasarım, teknik bağımlılık, test, bütçe ve takvim açısından inceleyin. Etki analizi yapılmadan verilen hızlı onay, ilk sürümün sınırını görünmez biçimde büyütebilir.

Uygulanabilir MVP Kapsam Kontrol Listesi

İlk sürüm kararını onaylamadan önce aşağıdaki maddeleri kontrol edin:

• Ürün hedefi tek ve anlaşılır bir cümleyle yazıldı.
• Hedef kullanıcılar ve rolleri belirlendi.
• Temel kullanıcı akışı başlangıçtan sonuca tamamlandı.
• Her talep sekiz alanlı karar tablosunda değerlendirildi.
• İlk sürüm, sonraki faz ve kapsam dışı gerekçeleri kaydedildi.
• Veri erişimi ve rol-yetki sınırları tanımlandı.
• Güvenlik, yedek, log, hata ve performans gereksinimleri riske göre planlandı.
• Teknik ve ticari bağımlılıklar görünür hâle getirildi.
• Her temel özellik için test edilebilir kabul ölçütü yazıldı.
• Bütün sürüm için ortak kalite ve kabul koşulları belirlendi.
• Yeni talep ve kapsam değişikliği yöntemi kararlaştırıldı.
• Yayın sonrası izlenecek göstergeler seçildi.
• Sonraki fazın hangi verilerle yeniden sıralanacağı açıklandı.

Sonuç: İlk Sürümü Küçük Değil, Odaklı Kurun

Doğru MVP kapsamı, mümkün olan en az işi yapmak değildir. Hedef kullanıcının temel işi uçtan uca tamamlayabildiği; rol, veri, güvenlik ve operasyon sınırları belirlenmiş; kabul ölçütleri test edilebilir; yayın sonrası öğrenmeye açık en odaklı ilk sürümü kurmaktır.

Önce ürün hedefini yazın, sonra ana kullanıcı akışını çıkarın. Her talebi hedef kullanıcı, iş sonucu, akıştaki yeri, veri ve yetki, zorunluluk, bağımlılık, kabul ölçütü ve faz kararıyla değerlendirin. Görünmeyen teknik ihtiyaçları özellik listesinin dışında bırakmayın. Yeni talepleri etki analiziyle yönetin ve sonraki fazı gerçek kullanım sinyallerine göre yeniden sıralayın.

Projenizin ilk sürüm sınırını, teknik gereksinimlerini ve sonraki geliştirme fazlarını birlikte değerlendirmek isterseniz Kumsal Ajans web yazılım hizmetini inceleyebilirsiniz.

Sık Sorulan Sorular

MVP ile prototip aynı şey midir?

Hayır. Prototip, bir fikri veya kullanıcı akışını denemek için hazırlanabilir ve üretim ortamında gerçek kullanıcıya hizmet etmesi gerekmeyebilir. MVP ise tanımlanan temel iş sonucunu gerçek kullanımda üretebilen, proje için belirlenen güvenlik ve kalite koşullarını karşılayan kullanılabilir ilk sürümdür.

Bir özellik ilk sürüme mi yoksa ikinci faza mı alınmalı?

Özellik olmadan temel kullanıcı akışı tamamlanamıyorsa, güvenlik veya operasyon açısından zorunluysa, başka bir ilk sürüm işinin bağımlılığıysa ya da ilk doğrulama için gerekli veriyi üretiyorsa ilk sürüm adayıdır. Ana akış onsuz çalışıyorsa ve gerçek kullanım verisi kararı iyileştirecekse sonraki faza bırakılabilir.

Güvenlik ve yedekleme MVP'den çıkarılabilir mi?

Güvenlik, erişim, yedekleme ve izlenebilirlik ihtiyacı projenin verisine, kullanıcılarına, işlem yoğunluğuna, entegrasyonlarına ve risklerine göre belirlenir. Bu alanları tamamen yok saymak yerine ilk sürümün güvenli ve yönetilebilir çalışması için gereken seviyeyi proje özelinde tanımlamak gerekir.

MVP kapsamına kim karar vermelidir?

İş hedefini ve bütçe sınırını bilen müşteri proje sorumlusu ile kullanıcı akışını, tasarımı, teknik bağımlılıkları ve riskleri değerlendiren proje ekibi birlikte karar vermelidir. Onaylanan kararlar teklif, ihtiyaç dokümanı veya proje takip sisteminde kayıt altına alınmalıdır.

MVP'nin tamamlandığı nasıl anlaşılır?

Onaylanan temel kullanıcı akışları çalışmalı, zorunlu özellikler tamamlanmalı, rol ve yetkiler doğru işlemeli, kritik hata bulunmamalı ve proje için belirlenen responsive, performans ve güvenlik kontrolleri geçmelidir. Ayrıca her özellik için önceden yazılmış kabul ölçütleri doğrulanmalıdır.

Yayından sonra ikinci faz nasıl önceliklendirilir?

Aktif kullanım, tamamlanan işlemler, işlem süresi, hata oranı, destek talepleri, kullanıcı geri bildirimleri ve manuel iş yükü gibi ürüne uygun göstergeler izlenir. Sonraki faz talepleri, başlangıçtaki varsayımların yanında bu gerçek kullanım sinyallerine göre yeniden sıralanır.