10 adımlık hazırlık kontrol listesi
İyi bir proje dosyası onlarca ekran çizimi değil, karar verilebilir bir problem tanımıdır. Aşağıdaki 10 çıktı hazırsa yazılım ekibi ilk görüşmede kapsam, risk ve teslim sırasını konuşabilir.
| Adım | Hazırlanacak çıktı | Neden gerekli? |
|---|---|---|
| 1 | Tek cümlelik problem | Çözüm yerine ihtiyacı sabitler |
| 2 | Birincil kullanıcı | Herkes için tasarım yapılmasını engeller |
| 3 | Tek ana akış | MVP'nin çalışan çekirdeğini belirler |
| 4 | MVP dışı liste | Kapsamın sessizce büyümesini önler |
| 5 | Kullanıcı rolleri | Yetki ve veri modelini belirler |
| 6 | Entegrasyon envanteri | Dış bağımlılıkları görünür yapar |
| 7 | İçerik ve veri kaynağı | Kimin neyi sağlayacağını netleştirir |
| 8 | Başarı ölçütü | Yayının neyi doğrulayacağını söyler |
| 9 | Hesap sahipliği | Mağaza ve altyapıyı müşteride tutar |
| 10 | Kabul ölçütleri | Teslimin tamamlandığı anı tanımlar |
Problemi özellik listesi olmadan tanımlayın
Problem cümlesi kullanıcıyı, mevcut davranışı ve engeli anlatmalıdır. “Bir mobil uygulama istiyoruz” kapsam değildir; “saha ekibi servis kaydını ofise dönmeden tamamlayamıyor” ise tasarım ve teknik karar üretir. Özellikler bu cümleden sonra gelir.
İyi problem tanımı çözümü tarif etmez; hangi kullanıcının hangi işi neden tamamlayamadığını tarif eder.
Tek ana akışı ve MVP dışını birlikte yazın
MVP için ana akış, kullanıcının uygulamayı açmasından doğrulanabilir sonucu görmesine kadar tek zincirdir. DrapeAI örneğinde bu zincir fotoğraf yükle, kıyafet seç ve sonucu gör adımlarından oluştu. Sosyal paylaşım, gelişmiş profil ve ikincil filtreler ilk doğrulama için gerekli değildi.
- Ana akışı en fazla 5-7 kullanıcı adımıyla yazın.
- Her ek özellik için test edilen varsayıma katkısını sorun.
- İlk sürüme girmeyenleri kaybetmeyin; ayrı bir MVP dışı listede tutun.
- Yönetim paneli, çoklu dil ve gelişmiş raporlamayı otomatik olarak zorunlu saymayın.
Roller ve entegrasyonlar maliyeti ekrandan önce belirler
Mobil uygulama kapsamını en hızlı büyüten iki unsur kullanıcı rolü ve dış entegrasyondur. Son kullanıcı, yönetici, saha çalışanı ve işletme sahibi aynı kaydı farklı biçimde görecekse yetki matrisi gerekir. Ödeme, harita, ERP, kimlik doğrulama veya yapay zeka servisi kullanılacaksa hesap, kota ve hata senaryosu baştan yazılmalıdır.
| Entegrasyon sorusu | Beklenen cevap |
|---|---|
| Servisin sahibi kim? | Müşteri hesabı veya açık sorumluluk |
| Test ortamı var mı? | Sandbox erişimi ve örnek veri |
| İstek başarısız olursa ne olur? | Kullanıcıya görünen geri dönüş akışı |
| Kota veya kullanım maliyeti var mı? | Aylık sınır ve uyarı eşiği |
| Hangi veri paylaşılır? | Açık veri alanı ve saklama kararı |
Başarı ve kabul ölçütlerini ayırın
Başarı ölçütü ürün varsayımını, kabul ölçütü ise yazılım teslimini değerlendirir. “Test kullanıcılarının ana akışı yardım almadan tamamlaması” başarı ölçütüdür. “Form çevrimdışıyken veri kaybetmemeli ve yeniden bağlantıda gönderilmeli” ise test edilebilir bir kabul ölçütüdür.
Mağaza ve altyapı hesapları kimin adına açılmalı?
Apple Developer, Google Play, alan adı, analitik ve bulut hesapları müşterinin tüzel veya gerçek kişi hesabı adına açılmalıdır. Yazılım ekibine rol bazlı erişim verilir; şifre ve sahiplik devredilmez. Bu düzen, ekip değişse bile ürünün yayın ve veri kontrolünü müşteride tutar.