Bir yazılım projesi tekliften teslime nasıl ilerler

Yazılım yaptırmak isteyen bir kurumun ilk sorularından biri, sürecin nasıl yürüyeceği. Ne zaman ne görecekler, kendilerinden ne beklenecek, iş nerede bitmiş sayılacak.

Bu yazıda bir projenin ilk görüşmeden bakıma kadar hangi adımlardan geçtiğini anlatıyorum. Adımlar her projede aynı uzunlukta değil. Küçük bir işte birkaçı tek toplantıya sığıyor. Ama hiçbiri atlanmıyor, çünkü atlanan adım projenin sonunda bir sürpriz olarak geri dönüyor.

İlk görüşme

İlk görüşmede fiyat konuşmuyoruz. Ne yapılmak istendiğini, bugün işin nasıl yürüdüğünü ve neyin değişmesi gerektiğini anlamaya çalışıyoruz. Kimler kullanacak, hangi veriyi işleyecek, hangi sistemlerle konuşacak.

Bu görüşmenin sonunda bazen özel yazılıma gerek olmadığını söylüyoruz. Hazır bir ürün işi görüyorsa, bunu baştan söylemek herkesin zamanını koruyor.

Keşif

İhtiyaç netleşmemişse kısa bir keşif aşaması öneriyoruz. Birkaç atölye, mevcut sistemlere ve verilere bakış, iş akışının adım adım çıkarılması. Keşfin çıktısı yazılı bir belge: kapsam, kullanıcı rolleri, entegrasyonlar, veri, bilinen riskler ve bilinmeyenler.

Bu, projenin en ucuz ve en çok para kurtaran aşaması. Yanlış anlaşılmış bir ihtiyacı belgede düzeltmek, kodda düzeltmekten çok daha kolay.

Teklif

Teklif keşif belgesine dayanıyor. Her iş paketi için ne yapılacağı, ne kadar süreceği, kurumdan ne beklendiği ve hangi ölçüte göre kabul edileceği yazılı. Kapsam dışında kalanlar da ayrıca yazılı. Kaynak kodun ve fikri hakların kime kalacağı, bakımın nasıl yürüyeceği burada netleşiyor.

Tasarım

Kod yazmadan önce veri modelini, yetki yapısını ve ana ekranları tasarlıyoruz. Ekran taslaklarını kurumun gerçek kullanıcılarına gösteriyoruz. Bu aşamada çıkan itirazlar, sonradan çıkanlardan çok daha ucuz.

Kişisel veri işlenecekse, hangi verinin neden toplandığı, kimin görebileceği ve ne kadar saklanacağı da bu aşamada kararlaştırılıyor. Bunlar sonradan eklenecek özellikler değil, mimarinin parçası.

Geliştirme

Geliştirmeyi kısa döngülerle yürütüyoruz. Her döngünün sonunda kurum, test ortamında çalışan bir sürüm görüyor. Bir şey yanlış anlaşılmışsa birkaç hafta içinde fark ediliyor.

Her değişiklikte otomatik testler çalışıyor. Bir test kırılırsa o sürüm ilerlemiyor. Bunu kendi sitemizde nasıl yaptığımızı ayrı bir yazıda anlattık.

Test ve kabul

Kabul, teklifte yazan ölçütlere göre yapılıyor. Her özellik için "şu durumda şu sonucu veriyor" türünden somut ölçütler. Kurum bu ölçütleri kendi verisiyle deniyor, uymayan noktalar kayda geçiyor ve düzeltiliyor.

Kabul ölçütü yazılı olmadığında "çalışıyor mu" tartışması kaçınılmaz. Nedenini kabul ölçütü üzerine yazdığımız yazıda anlattık.

Yayına alma

Yayına alma bir gün değil, küçük bir plan. Eski sistemden veri taşınacaksa deneme taşımaları önceden yapılıyor. Bir şey ters giderse nasıl geri dönüleceği yazılı. Kullanıcılara kısa bir eğitim veriliyor ve ilk haftalarda sorulara hızlı cevap veriliyor.

Bakım

Teslimden sonra güvenlik güncellemeleri, altyapı yükseltmeleri ve küçük iyileştirmeler devam ediyor. Bakımın kapsamı ve bir sorunun ne kadar sürede ele alınacağı, teklif aşamasında yazılı hâle getiriliyor.

Kaynak kod, belgeler ve dağıtım adımları kuruma teslim ediliyor. Böylece kurum, bir gün başka bir ekiple devam etmek isterse bunu yapabiliyor.

Kurumun rolü

Bu adımların hepsinde kurum tarafında bir muhatap gerekiyor. İş akışını bilen, sorulara kısa sürede cevap verebilen ve ara sürümleri deneyebilen biri. Projeleri yavaşlatan şey çoğu zaman teknik bir sorun değil, bu muhatabın olmaması.

Kısaca

İlk görüşme, keşif, teklif, tasarım, geliştirme, kabul, yayına alma ve bakım. Adımlar projenin büyüklüğüne göre kısalıp uzuyor ama hiçbiri atlanmıyor. Her adımın sonunda neyin teslim edileceğinin yazılı olması, projenin sonunda sürpriz çıkmamasını sağlıyor.