Takvim için önce ilk sürümün sınırını belirleyin
MVP kapsamı, geliştirme süresinin temel girdisidir. Bir uygulamanın adı veya ekran sayısı tek başına takvim kurmaz. Kullanıcı rolünü, tamamlanacak ana görevi ve bu görevin başarılı sayılacağı koşulu yazın. İlk sürüm ile ileride değerlendirilecek özellikleri ayrı listelerde tutun.
Örneğin bir randevu uygulamasında kullanıcı saat seçip talebi gönderebilir; işletme de talebi görüp onaylayabilir. Takvim çakışması, iptal ve hata durumları bu ana akışın parçasıdır. Gelişmiş sadakat sistemi aynı sürüm için zorunlu olmayabilir. Bu örnek, gerçek bir müşteri takvimi veya sabit özellik reçetesi değildir.
Yönetim paneli, backend, bildirim, ödeme ve veri aktarımı gerekip gerekmediğini ayrıca belirleyin. Kapsam değiştiğinde ekip yalnızca bitiş tarihini değil, kabul ölçütünü ve kapasiteyi de yeniden değerlendirmelidir. Aynı geniş işi MVP diye adlandırmak onu otomatik olarak kısaltmaz.
Aktif çalışma ile geçen süreyi ayrı planlayın
Mobil uygulama bütçesi ile takvimi aynı iş paketlerinden kurmak karşılaştırmayı kolaylaştırır. Keşif, tasarım, geliştirme, entegrasyon, test ve yayın hazırlığının her biri çıktıya, sorumluya ve bağımlılığa sahip olmalıdır. Bir geliştiricinin çalışma süresi, projenin toplam takvim süresiyle eşdeğer değildir.
Müşteri onayı, API erişimi, mağaza hesabı doğrulaması veya örnek veri beklenirken ekip bazı işleri ilerletebilir; bazıları tamamen durabilir. Bekleme nedenlerini ve gereken karar tarihini görünür tutun. Tasarım tamamlanmadan hiçbir kod yazılamayacağını varsaymak da, bütün işleri bağımsız saymak da gerçekçi olmayabilir.
Tahmini tek bir kesin sayı yerine dayandığı varsayımlarla değerlendirin. Kapsam olgunlaştıkça belirsizlik azalır ve plan yeniden kurulur. Ekibin ayırdığı kapasite, aynı dönemde başka işlere katılması ve geri bildirim verecek kişinin erişilebilirliği takvimi etkiler; bunları görüşmede açıkça konuşun.
| İş paketi | Tamamlanma kanıtı | Başlamadan gereken |
|---|---|---|
| Keşif | Kapsam ve risk kararları | Ürün sahibi ve mevcut veri |
| Tasarım | Onaylı görev akışı ve durumlar | Kullanıcı/iş kuralı bilgisi |
| Entegrasyon | Gerçek bağlantıyla çalışan akış | Erişim ve test ortamı |
| Kabul | Kritik kontrollerin sonucu | Kararlı yayın adayı |
| Yayın | Gönderim ve izleme hazırlığı | Hesap, içerik ve beyanlar |
OKUMADAN SONRAKİ ADIMA
İlk sürüm takvimini birlikte netleştirelim
Ana görev, mevcut sistemler ve hedef lansmanı paylaşın. İş paketlerini ve belirsiz bağımlılıkları görünür bir plana dönüştürelim.
En zor bağımlılığı erken doğrulayın
Teknik keşif ve liderlik, zor bir entegrasyonun takvime etkisini erkenden değerlendirmeye yardımcı olur. Ödeme, çevrimdışı senkronizasyon, cihaz bağlantısı veya eski sistemin API’si bilinmiyorsa küçük bir deneme seçin. Denemenin sonunda yalnızca kod değil, karar ve açık risk listesi bulunmalıdır.
Örneğin harici sistemden gelen veri eksikse ekranlar hazır olsa da ana görev tamamlanamayabilir. Deneme; kimlik doğrulama, izin, örnek yanıt ve hata davranışını gösterebilir. Tam ürün için ölçek veya bütün uç durumların doğrulandığı sonucunu küçük bir denemeden çıkarmayın.
Risk çözülemiyorsa alternatif akış, daha dar sürüm veya bağımlılığın ertelenmesi değerlendirilir. Bunların kullanıcıya ve operasyona etkisini ürün sahibi onaylamalıdır. Zor işi takvimin sonuna taşımak, belirsizliği ortadan kaldırmaz; karar verme fırsatını geciktirir.
Geliştirmeyi test edilebilir dilimlere ayırın
Ürün teslim planında ilerlemeyi yalnızca tamamlanan ekran sayısıyla izlemeyin. Küçük bir dilim, kullanıcı ve sistem tarafında çalışan bir görevi gösterebilmelidir. Böylece iş kuralı, veri ve tasarım farklılıkları henüz düzeltilebilirken ortaya çıkar.
Her gösterimde onaylanan davranışı, bulunan sorunu ve sonraki kararı kaydedin. Yeni bir talep gelirse mevcut sürüm için gerekli olup olmadığını değerlendirin; ekleniyorsa hangi işi veya tarihi etkilediği açıklansın. Günlük tercih değişikliklerinin sessizce kapsamı genişletmesi planı güvenilmez hale getirir.
Birbirine bağımlı işe daha çok kişi eklemek otomatik hızlanma sağlamaz. Roller, kod inceleme ve koordinasyon da zaman ister. Aynı anda yürütülebilen işlerle bir kararın sonucunu bekleyen işleri ayırmak, yalnızca ekip büyüklüğünü artırmaktan daha yararlı olabilir.
Çalışan dilimi gösterin
Kritik görevin arayüz, veri ve hata davranışını birlikte gözden geçirin.
Kararı kaydedin
Onay, sorun ve kapsam değişikliğini sorumlusu ile görünür tutun.
Planı güncelleyin
Yeni bilgiyle kalan iş ve bağımlılıkları yeniden değerlendirin; eski tahmini koşulsuz sürdürmeyin.
Test ve düzeltme süresini baştan ayırın
Mobil kullanıcı deneyimi testte gerçek görevlerle değerlendirilir. Giriş, yetki, izin reddi, kesilen ağ, boş veri ve yeniden deneme gibi durumları geliştirme boyunca kontrol edin. Emülatör ve otomatik kontroller yararlıdır; hedef cihazlarda kullanım için gerekli değerlendirmeyi tek başlarına karşılamayabilirler.
Yayın adayında kritik akışların tekrar kontrolü, kabul ve bulunan hataların düzeltilmesi için zaman ayrılmalıdır. Sorun sınıflandırması, yayın engelleyen durumlar ve ertelenebilecek eksikler üzerinde anlaşın. Hata bulunacağını kabul edip hiçbir düzeltme kapasitesi bırakmayan takvim kendi içinde çelişir.
Test katılımcıları ve mağaza test kanalları da hazırlık ister. Beta dağıtımı kullanıcı geri bildirimi sağlayabilir; bunun yapılması tüm güvenlik veya işletim gereksinimlerinin karşılandığını göstermez. Bulguların kim tarafından ele alınacağını ve düzeltmelerin nasıl yeniden deneneceğini planlayın.
Mağaza gönderimi ile lansmanı ayrı aşamalar sayın
Mağaza yayın kontrolü kodun yanında açıklama, ekran görüntüsü, veri kullanımı beyanı ve erişim hazırlığını kapsar. Apple başvuruları incelediğini, Google ise inceleme ve yayın zamanının farklı yönetildiğini açıklar. Ekibin gönderim hazırlığını planlaması, dış inceleme sonucunu koşulsuz garanti etmesi anlamına gelmez.
Lansman iletişimini teknik adayın hazır olması, mağaza durumu ve operasyonun hazırlığıyla ilişkilendirin. İlk yayınla güncelleme için mevcut araçlar aynı olmayabilir; ilgili hesabın güncel sağlayıcı koşullarını kontrol edin. Belirli bir mağaza süresini tüm projelere uygulanan garanti gibi kullanmayın.
Yayın sonrası izleme, hata bildirim kanalı ve acil düzeltme sorumlusu belirlensin. Yeni sürüm kullanıcı cihazlarına aynı anda ulaşmayabilir; backend ile sürüm uyumu düşünülmelidir. Takvim, dosya gönderildiğinde değil, kabul edilen teslim ve işletim devri anlaşmaya uygun biçimde tamamlandığında anlamlıdır.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Mobil uygulama kaç ayda biter?
Kapsam, mevcut sistem, ekip kapasitesi ve dış bağımlılıklar bilinmeden güvenilir ortak süre verilemez. İlk sürümü iş paketlerine ayırıp tahminin varsayımlarını görün; belirsizliği keşifle azaltın.
Daha büyük ekip süreyi yarıya indirir mi?
Her zaman değil. Bağımlı işler, ekip alışması ve koordinasyon yükü doğrusal hızlanmayı engelleyebilir. Ek kapasitenin hangi bağımsız işi ilerleteceğini değerlendirin.
MVP daha hızlı biter mi?
Gerçekten daha dar bir kapsam seçilirse süre azalabilir. Ana görevi tamamlayan kalite ve hata davranışı yine gerekir. Aynı kapsamın adını değiştirmek takvimi kısaltmaz.
Tasarım ve geliştirme birlikte ilerleyebilir mi?
Bazı akışlarda evet; kararlı kararları ve açık varsayımları ayırın. Sürekli değişen tasarım üstüne kod yazmak yeniden çalışma yaratabilir. Birlikte ilerleyen işlerin bağımlılıklarını görünür tutun.
Mağaza onayı garanti edilebilir mi?
Dış inceleme sonucu ve süresi ekibin tam kontrolünde değildir. Hazırlık, gönderim ve olası düzeltme sorumluluğu planlanabilir. Teknik teslim ile mağazada erişilebilir olma tarihini ayrı konuşun.
Kapsama yeni özellik eklenirse ne olur?
Gereksinimi, test ve entegrasyon etkisini değerlendirin. Öncelik, kapasite, bütçe veya tarih değişebilir; karar kayıtlı olmalıdır. Yeni özelliği eski plana sessizce eklemeyin.
KAPSAMI BİRLİKTE BELİRLEYELİM
İlk sürüm takvimini birlikte netleştirelim
Ana görev, mevcut sistemler ve hedef lansmanı paylaşın. İş paketlerini ve belirsiz bağımlılıkları görünür bir plana dönüştürelim.
Uygulama takvimini değerlendirin