Yazılım Projesi Neden Yarım Kalır?

Bir yazılım projesi genellikle kötü bir fikir olduğu için yarım kalmaz. Hatta yarım kalan projelerin çoğu başlangıçta oldukça heyecan vericidir. Ortada çözülmesi gereken gerçek bir problem, güçlü bir iş modeli ve hevesli bir ekip vardır.

Sonra zaman geçer.

Başlangıçta “birkaç aya çıkar” denilen ürün uzamaya, bütçe büyümeye, toplantılar çoğalmaya başlar. Bir noktadan sonra kimse projenin ne zaman biteceğini söyleyemez. En sonunda da yazılım, kullanılmayan bir yönetim paneli ve yarım çalışan birkaç ekrandan ibaret kalır.

Peki, bu noktaya nasıl gelinir?

Fikir var ama sınırları yok

“Bir mobil uygulama yaptırmak istiyorum” cümlesi bir proje tanımı değildir. Sadece bir başlangıçtır.

Uygulamayı kim kullanacak? Hangi problemi çözecek? Kullanıcı ilk olarak hangi işlemi tamamlayacak? Ürünün çalıştığını kanıtlayan en küçük sürüm nasıl görünecek?

Bu sorular cevaplanmadan yazılıma başlanırsa proje geliştikçe yeni fikirler ortaya çıkar. Her yeni fikir de küçük bir ekleme gibi görünür:

“Buraya mesajlaşma da koyalım.”

“Kullanıcılar birbirini takip etsin.”

“Bir de detaylı raporlama olsun.”

Bu eklemelerin her biri yeni ekranlar, iş kuralları, testler ve teknik bağımlılıklar getirir. Proje büyür ama bitiş çizgisi sürekli uzaklaşır.

İlk sürüm ile hayal edilen son ürün karıştırılır

Bir girişimcinin ürününü büyük düşünmesi yanlış değildir. Yanlış olan, büyük düşüncenin tamamını ilk sürümde geliştirmeye çalışmaktır.

İlk sürümün görevi kusursuz olmak değil, ürünün temel değerini kanıtlamaktır. Bir pazar yeri uygulamasında bu değer, müşterinin talep açması ve hizmet verenin teklif sunabilmesi olabilir. Gelişmiş raporlar, kampanyalar, puan sistemleri ve onlarca yönetim özelliği daha sonra eklenebilir.

Her şey ilk sürüme alınırsa proje aylarca kapalı kapılar ardında geliştirilir. Kullanıcı ürünü görmeden bütçenin büyük kısmı harcanır. Yayına çıkıldığında ise insanların önem verdiği özelliklerin, proje sahibinin tahmin ettiğinden farklı olduğu anlaşılabilir.

Yazılım şirketi sadece söyleneni yapar

İyi bir yazılım ekibi yalnızca kod yazmaz. Gerektiğinde “Bu özelliği şu an yapmayalım” da diyebilmelidir.

Proje sahibinin istediği her şeyi sorgulamadan geliştirmek ilk bakışta iyi hizmet gibi görünebilir. Fakat teknik ekip kapsamı, kullanıcı deneyimini ve iş hedefini değerlendirmiyorsa ortaya büyük ama yönsüz bir ürün çıkar.

Yazılım şirketi müşterisine karşı çıkmak için değil, yatırımı korumak için soru sormalıdır:

• Bu özelliği kim kullanacak?

• İlk yayına gerçekten gerekli mi?

• Daha basit şekilde çözülebilir mi?

• Başarılı olduğunu nasıl ölçeceğiz?

• Başka bir özelliğe veya dış servise bağlı mı?

Bu sorular sorulmuyorsa proje ilerliyor gibi görünür ama aslında yalnızca büyüyordur.

Bütçe yalnızca kodlama için hesaplanır

Yazılım geliştirmek sadece ekranların kodlanması değildir.

Analiz, kullanıcı deneyimi, tasarım, sunucu altyapısı, güvenlik, test, mağaza süreçleri, bakım ve yayın sonrası iyileştirmeler de projenin parçasıdır. Bütçe yalnızca “uygulamanın yapılması” için ayrıldığında, ürün yayına yaklaşırken kaynak tükenmeye başlar.

Özellikle mobil uygulamalarda App Store ve Google Play hazırlıkları, üyelikler, bildirim altyapıları ve üçüncü taraf servisler başlangıçta hesaba katılmadığında sonradan beklenmedik maliyetlere dönüşebilir.

Bu nedenle sağlıklı bir plan sadece “yazılım kaç liraya yapılır?” sorusunu değil, “çalışan ürünün gerçek kullanıcıya ulaşması için neler gerekir?” sorusunu da cevaplamalıdır.

Kararlar kayıt altına alınmaz

Bir toplantıda alınan karar, birkaç hafta sonra bambaşka hatırlanabilir.

Proje sahibi bir ekranın farklı çalışmasını beklerken geliştirici başka bir akış hazırlamış olabilir. Yazılım ilerledikçe bu küçük anlaşmazlıklar birikir ve tamamlanan işler tekrar yapılmaya başlanır.

Projenin yüzlerce sayfalık teknik dokümana ihtiyacı olmayabilir. Ancak özelliklerin, kullanıcı rollerinin, temel iş kurallarının ve teslim ölçütlerinin yazılı olması gerekir.

“Ödeme sistemi tamamlandı” demek yerine şu ifade kullanılabilir:

Kullanıcı kredi kartıyla ödeme yapabilir, başarısız ödeme durumunda bilgilendirilir ve başarılı işlem yönetim panelinde görüntülenir.

İkinci ifade tartışmaya daha az yer bırakır. Çünkü neyin teslim edilmiş sayılacağını açıkça anlatır.

Proje fazlara ayrılır ama hiçbir faz gerçekten bitmez

Projeyi fazlara ayırmak tek başına çözüm değildir. Her fazın sonunda kullanılabilir bir şey ortaya çıkmıyorsa yapılan yalnızca işleri başlıklar altında toplamaktır.

“Birinci faz: altyapı, ikinci faz: geliştirme, üçüncü faz: yayın” gerçek bir ürün planı sayılmaz.

Sağlıklı bir fazın sonunda gösterilebilen, test edilebilen veya canlıya alınabilen somut bir değer bulunmalıdır. Kullanıcı kayıt olabiliyor mu? Sipariş verebiliyor mu? İşletme süreci yönetebiliyor mu?

Bu soruların cevabı hayırsa faz tamamlanmış değildir.

Bazı küçük projelerde ise fazlandırmaya hiç gerek olmayabilir. Böyle durumlarda işi gereksiz yere bölmek yerine analiz, tasarım, geliştirme, test ve yayın adımlarından oluşan tek teslim planı daha doğrudur.

Yayına çıkmak projenin sonu sanılır

Asıl ürün, gerçek kullanıcıyla karşılaştığı gün ortaya çıkar.

Kullanıcıların nerede zorlandığı, hangi özelliği hiç kullanmadığı ve hangi işlemi beklenmedik biçimde gerçekleştirdiği ancak canlı kullanımda görülebilir. Bu nedenle yazılım projesi yayınla bitmez; tahminlerin yerini gerçek verilerin aldığı yeni bir döneme girer.

Yarım kalmayan projelerin ortak noktası kusursuz başlamaları değildir. Neyi önce yapacaklarını, neyi erteleyeceklerini ve hangi noktada “bu sürüm artık canlıya çıkabilir” diyeceklerini bilmeleridir.

Bir yazılım projesine başlamadan önce en değerli çalışma, ekranları çizmek veya teknoloji seçmek olmayabilir. Bazen en değerli şey, fikrin sınırlarını dürüstçe belirlemektir.

Çünkü iyi yazılım daha fazla özellikten değil, doğru sırada alınmış kararlardan doğar.