Yazılım projelerinin çoğu kod yüzünden değil, en baştaki belirsizlik yüzünden gecikir. Kapsam net değilse süre tahmini de bütçe de tahminden ibaret kalır. Bu yazıda yazılım projesi planlama sürecini iş tarafında nasıl kuracağınızı, hangi kararları kimin vereceğini ve neyi yazıya dökmeniz gerektiğini anlatıyoruz.
Kapsamı yazıya dökmeden başlamayın
Kapsam yalnızca "ne yapılacak" listesi değildir; "ne yapılmayacak" listesi de en az onun kadar önemlidir. Toplantıda konuşulan ama hiçbir yere yazılmayan her madde, ilerleyen haftalarda iki tarafın farklı hatırladığı bir konu haline gelir.
Kapsam belgesinde şunlar net olmalı: sistemin çözdüğü iş problemi, kullanıcı rolleri ve her rolün neleri yapabildiği, ekran listesi, entegre olunacak dış sistemler (muhasebe, ödeme, kargo, CRM), veri göçü olup olmayacağı, dil ve para birimi ihtiyacı, yönetim panelinden hangi alanların düzenlenebileceği. Bir de kapsam dışı bölümü: bu sürümde yapılmayacaklar.
İş tarafında yapmanız gereken en somut şey, mevcut süreci olduğu gibi yazmak. Yazılım yeni bir süreç icat etmez; var olan süreci hızlandırır ya da düzeltir. Süreci siz tarif etmezseniz geliştirici tahmin eder, tahminler de pahalıdır.
Yazılı kapsam aynı zamanda süre ve bütçe tahmininin tek dayanağıdır. Sözlü anlatıma dayanan teklifler her zaman iyimserdir, çünkü kimse konuşulmayan işi fiyatlamaz. Kapsam ne kadar ayrıntılıysa verilen aralık o kadar dar olur; kapsam belirsizse teklif de geniş bir aralık olarak gelir ve bu normaldir.
Karar verici sayısını baştan netleştirin. Kapsamı onaylayacak tek bir isim olsun. Her departmanın ayrı ayrı fikir verdiği ama kimsenin karar vermediği projeler uzar.
Kapsam kayması nasıl oluşur ve nasıl yönetilir
Kapsam kayması genellikle tek bir büyük talep olarak gelmez. "Şuraya küçük bir alan daha ekleyelim", "burada PDF çıktısı da olsun", "bir de şu raporu görelim" gibi tek başına makul görünen isteklerin toplamıdır. Her biri küçüktür; toplamı takvimi ve bütçeyi taşırır.
İkinci kaynak geç gelen bilgidir. Projenin ortasında ortaya çıkan bir muhasebe kuralı ya da yeni fark edilen bir yasal zorunluluk, tamamlanmış işlerin yeniden açılmasına yol açar. Bu yüzden fatura, vergi, sözleşme ve kişisel veri tarafındaki gereklilikleri planlama aşamasında ilgili birimlere sorun.
Kayma kaçınılmazdır ama yönetilebilir. İşleyen yöntem şu: her yeni talep anında değerlendirilmek yerine tek bir listeye yazılır. Liste haftalık veya iki haftalık bir ritimde gözden geçirilir. Her talebin karşısında üç bilgi bulunur: iş etkisi, tahmini süre, hangi sürüme alınacağı. Talep kabul edildiğinde takvimden ya da bütçeden neyin eksileceği aynı toplantıda konuşulur. "Ekleyelim ama tarih değişmesin" cümlesi projeyi bozan cümledir.
Değişiklik bedelsiz değildir; bu, değişiklik yapılmasın demek değil. Amaç değişikliğin bilinçli bir karar olması.
Öncelik sıralaması nasıl yapılır
Her şey aynı anda önemliyse hiçbir şey öncelikli değildir. Basit ve işleyen bir yöntem, maddeleri dört gruba ayırmaktır: olmazsa olmaz, olmalı, olsa iyi olur, sonraki sürüm. Bu ayrımı yaparken tek soru yeterli: bu özellik olmadan sistem canlıya çıkabilir mi? Cevap "evet, zorlanırız ama çıkarız" ise o madde olmazsa olmaz değildir.
Sıralamada iki kriteri birlikte kullanın: iş değeri ve maliyet. Yüksek değerli ve düşük maliyetli işler en başa gider. Yüksek değerli ama maliyetli işler planlanır ve parçalara bölünür. Düşük değerli ve yüksek maliyetli işler çoğunlukla hiç yapılmaz; bu da iyi bir sonuçtur.
Riskli işleri öne alın. Ödeme entegrasyonu, dış servis bağlantısı, veri göçü gibi belirsizliği yüksek kalemleri projenin sonuna bırakmak, en kötü sürprizi en kötü zamanda almak demektir. Bu kalemler erken denendiğinde hâlâ plan değiştirecek vaktiniz olur.
Önceliği yazılı tutun ve tek bir yerde tutun. Sözlü öncelik, iki hafta sonra kimsenin hatırlamadığı öncelik demektir.
MVP ve aşamalı teslim
MVP eksik ürün demek değil; dar ama uçtan uca çalışan ürün demektir. Bir MVP'de kullanıcı en az bir işi baştan sona bitirebilmelidir. Ödeme alan bir sistemde MVP, ürün listesi ve sepetle sınırlı kalamaz; sipariş tamamlanabiliyor olmalıdır.
Aşamalı teslim hem riski hem bütçe baskısını azaltır. Proje üç dört aşamaya bölünür ve her aşamanın sonunda çalışan bir sürüm görürsünüz. Bu sizin için iki anlama gelir: ödemeyi iş göründükçe yaparsınız ve yön değiştirmeniz gerekirse bunu tamamlanmış bir işi çöpe atmadan yaparsınız.
Aşamaları belirlerken her aşamanın sonunda ölçebileceğiniz bir sonuç tanımlayın. "Tasarım bitti" bir sonuç değildir; "sipariş verilebiliyor", "bayi kendi stoğunu görebiliyor" sonuçtur. Böylece ilerlemeyi ekran sayısıyla değil, işin ne kadarının çalıştığıyla takip edersiniz.
Süre tahminlerinde bir nokta genellikle atlanır: verilen aralıklar sizin geri dönüş hızınıza da bağlıdır. Onay bekleyen bir ekran, içerik bekleyen bir sayfa veya gelmeyen bir logo, geliştirme kadar takvim tüketir. Planlama sırasında kendi tarafınızdaki görevlere de sorumlu ve tarih yazın.
Bütçe tarafında da aynı mantık geçerli. Toplam rakam yerine aşama başına rakam konuşmak, hem sizin hem geliştirici tarafın kapsamı gerçekçi tutmasını sağlar. Kesin fiyat her zaman kapsamın netliği kadar kesindir.
Test ve kabul kriterleri
"Bitti" kelimesinin ne anlama geldiği baştan yazılmazsa teslimde tartışma çıkar. Kabul kriteri her madde için ölçülebilir bir cümledir: "Kullanıcı sepetteki ürünü silebilir ve toplam tutar anında güncellenir" gibi. Beğeni değil davranış tarif eder.
Kabul kriterlerini kapsamı yazarken belirleyin, testten bir gün önce değil. Kriter listesi aynı zamanda ekibin ne yapacağını netleştirir; sonradan yazılan kriter, çoğu zaman yapılmış işi tarif etmekten öteye geçmez.
Test tarafında iş biriminin rolü nettir: gerçek veriyle ve gerçek senaryoyla denemek. Geliştirici kendi yazdığını doğru varsayarak bakar; sizin işiniz süreci bilen kişinin gözüyle bakmak. En işe yarar hataları her zaman o işi her gün yapan kişi bulur.
Test için takvimde ayrı bir pencere açın ve o pencerede ilgili kişilerin müsait olmasını sağlayın. Yayın tarihinden iki gün önce başlayan test, test değil temennidir.
Bulunan her konuyu tek bir kanaldan bildirin: ekran görüntüsü, hangi kullanıcıyla, hangi adımlarla. Dağınık kanallardan gelen geri bildirim kaybolur, kaybolan geri bildirim yayından sonra hata olarak geri döner.
Yayın sonrası bakım planı
Yayın bir bitiş değil, işletme aşamasının başlangıcıdır. Planlama sırasında yayın sonrası konuşulmayan projeler canlıya çıktıktan sonra sahipsiz kalır.
Netleştirmeniz gereken başlıklar şunlar: hata bildirimini kim, nereye yapacak; kritik bir arızada beklenen müdahale süresi ne; güncellemeler hangi sıklıkla yapılacak; sunucu, alan adı, sertifika ve üçüncü parti servis ücretleri kimin bütçesinde; yedek ne sıklıkla alınacak ve geri dönüş nasıl test edilecek.
Sahiplik konusunu da baştan konuşun. Alan adı, sunucu hesapları, kod deposu erişimi ve analitik hesapları sizin adınıza açık olmalı. Bunu proje biterken değil, başlarken çözün.
Son olarak bütçenin bir bölümünü yayın sonrasına ayırın. İlk haftalarda gerçek kullanıcı davranışına bakarak yapacağınız düzeltmeler, planda duran birçok özellikten daha değerli çıkabilir. İyi bir yazılım projesi planlama süreci, projenin bittiği günü değil, sistemin çalıştığı ilk yılı hedefler.
