Yazılım Analiz Süreci: Projeler Neden Kod Yazılmadan Kaybedilir?

Bir özel yazılım projesinin nerede ters gittiğini sonradan geriye doğru izlediğinizde, iz çoğu zaman kodun yazıldığı haftalara değil ilk toplantılara çıkar. Ekranlar hazırdır, veritabanı kurulmuştur, program çalışır. Ama işi her gün yapan kişi ekranın başına oturduğunda ilk söylediği şey “Biz bunu böyle yapmıyoruz ki” olur.

Bu cümleyi yıllar içinde farklı sektörlerde, farklı büyüklükteki firmalarda duyduk. Arkasında neredeyse her seferinde aynı hikâye vardı: Analiz ya aceleye getirilmişti ya da yanlış kişilerle yapılmıştı.

Analiz, bir projenin geliştirme aşamaları arasında en kısa tutulmak istenen adımdır. Müşteri bir an önce ekran görmek ister, yazılım firması da bir an önce işe başlamak. Oysa analizde harcanan bir gün, kodlamada ve yayından sonraki düzeltmelerde çok daha fazlasını kurtarır. Yazılımın kalitesi, analizde sorulan soruların kalitesini pek geçemez.

Kâğıttaki süreç ile sahadaki süreç

Analiz toplantısına genellikle firmanın yöneticisi gelir. Süreci en iyi o bilir; daha doğrusu sürecin nasıl işlemesi gerektiğini. İşi her gün yapan kişinin anlatacağı hikâye ise biraz farklıdır.

Sık karşılaştığımız bir örnek: Yönetici, satın alma talebinin önce birim amirine, sonra muhasebeye, en son genel müdüre gittiğini anlatır. Sahaya indiğimizde acil taleplerin telefonla onaylanıp belgenin sonradan tamamlandığını, bazı sabit tedarikçilerde muhasebenin hiç devreye girmediğini, genel müdür izindeyken onayı yardımcısının verdiğini öğreniriz. Yazılımı yalnızca ilk anlatıma göre kurarsanız, ilk haftanın sonunda kullanıcılar sistemin etrafından dolaşmaya başlar.

Bu farkı kimse bilerek saklamıyor. Yönetici kuralı anlatıyor, çalışan pratiği yaşıyor. İkisi de doğru, ikisi de eksik.

Süreci yöneticiden dinleyin, işi yapan kişiyle doğrulayın.

Bu yüzden analizi mümkün olduğunca toplantı odasının dışına taşıyoruz. İşi yapan kişinin yanına oturup gerçek bir iş gününü izlemek, kullandığı Excel dosyalarını, defterleri, e-posta şablonlarını görmek istiyoruz. Monitörün kenarına yapıştırılmış bir not kâğıdı bile bazen kimsenin söylemediği bir iş kuralını ortaya çıkarır.

Kim neyi görecek, kim neyi yapabilecek?

Kullanıcı rolleri, analizde en çok hafife alınan konu. “Yönetici her şeyi görsün, personel kendi işini” demek başlangıç için yeterli görünür. Ardından sorular gelir: Şube sorumlusu diğer şubenin kayıtlarını görebilecek mi? Yeni başlayan bir personel müşterinin telefon numarasını görmeli mi? Kaydı kim silebilir, silinen kaydı kim geri getirebilir?

Bu cevaplar veritabanı tasarımını, ekran sayısını ve ileride yapılacak her değişikliğin maliyetini etkiler. Yazılım kullanıma girdikten sonra yetki yapısını baştan kurmak, en başta doğru kurmaktan her zaman daha pahalıdır. Kişisel veri işleyen sistemlerde iş bir adım daha ileri gider; kimin hangi veriye eriştiğini sonradan açıklayabilmeniz gerekir.

İstisnalar işin kendisidir

Her iş akışının bir de “normal” hâli vardır ve toplantıda anlatılan hep odur. Yazılımın asıl zorlandığı yer ise normal akış değil: İade edilen sipariş, yarıda iptal edilen sözleşme, iki kez açılmış müşteri kartı, ay sonunda düzeltilmesi gereken fatura.

Analizde en çok zaman ayırdığımız soru bu yüzden “Bu olmazsa ne oluyor?” sorusu. Müşteri eksik ödeme yaparsa ne oluyor? Belge imzasız gelirse? Dosyadan sorumlu kişi işten ayrılırsa, üzerindeki açık işler kime geçiyor? Her cevap bir ekran, bir kural ya da en azından bir uyarı mesajı demek.

Bunları analizde yakalamanın maliyeti bir satırlık not. Kodlama sırasında yakalamanın maliyeti birkaç günlük iş. Yayına girdikten sonra yakalamanın maliyeti ise kullanıcının sisteme duyduğu güven.

Raporu en baştan sormak

Birçok projede raporlama sona bırakılır. Sorun şu: Görmek istediğiniz bilgiyi sistem hiç kaydetmiyorsa, raporu sonradan geriye dönük üretemezsiniz.

Basit bir örnek. Yönetim yıl sonunda kaybedilen tekliflerin en çok hangi gerekçeyle kaybedildiğini görmek istiyor. Teklif ekranında “kaybetme gerekçesi” diye bir alan yoksa bu rapor hiçbir zaman alınamaz. Bir yıllık veri elinizdedir ama bu soruya cevap vermez.

Raporda görmek istediğiniz her bilgi, bugün bir ekranda kayda geçmek zorunda.

Bu yüzden ekranları konuşmadan önce, yönetimin ay sonunda ve yıl sonunda hangi sorulara cevap aradığını soruyoruz. Ekranları da bu sorulardan geriye doğru tasarlıyoruz.

İlk sürümde şart olanlar, sonraya kalabilecekler

Analizin sonunda elimizde uzun bir istek listesi olur. Hepsini ilk sürüme sığdırmaya çalışmak, takvimi uzatmanın ve bütçeyi aşmanın en kestirme yoludur.

Listeyi müşteriyle birlikte ikiye ayırıyoruz ve her madde için tek bir soru soruyoruz: Bu olmadan sistem kullanılabilir mi? Otomatik SMS hatırlatması güzel bir özelliktir, ama kayıtların düzgün tutulamadığı bir sistemde hiçbir anlam taşımaz. İlk sürüm günlük iş akışını eksiksiz yürütmeli; geri kalanlar, kullanıcılar sistemi birkaç hafta kullandıktan sonra eklenebilir.

O birkaç haftada istek listesinin ciddi bir kısmının değiştiğini sık görüyoruz. Kâğıt üzerinde önemli görünen bazı özellikler unutuluyor, kimsenin aklına gelmeyen başka bir ihtiyaç öne çıkıyor.

İlk sürümün amacı her şeyi yapmak değil, eski yöntemi bıraktırmaktır.

Analiz toplantısında sorduğumuz sorular

Her proje farklı, ama bazı sorular neredeyse her masada soruluyor. Toplantıya gelmeden önce bunların cevabını düşünmüş olmanız analizi belirgin biçimde kısaltır.

1. Bu işi bugün kim, hangi araçla yapıyor? Son bir haftadan gerçek bir örneği bize gösterebilir misiniz?
2. Sistemi kaç kişi, hangi rollerle kullanacak? Aynı anda en fazla kaç kişi çalışıyor?
3. Kim neyi görmemeli? Silme ve düzeltme yetkisi kimde olacak?
4. Bir kayıt hangi durumlardan geçiyor ve hangi noktada “kapandı” sayılıyor?
5. İş akışının en çok aksadığı, en çok telefonla takip edilen adımı hangisi?
6. Hangi durumlarda kurala uymuyorsunuz? En son ne zaman istisna yaptınız?
7. Ay sonunda ve yıl sonunda yönetim hangi soruların cevabını istiyor?
8. Mevcut veriler nerede duruyor ve ne kadarı yeni sisteme taşınacak?
9. Muhasebe programı, e-posta, SMS ya da başka bir sistemle veri alışverişi gerekiyor mu?
10. Bu sistem hiç yapılmasa, bir yıl sonra en çok neyi kaybetmiş olursunuz?

Son soru ilk bakışta tuhaf görünebilir. Ama cevabı genellikle projenin asıl amacını, saatlerce konuşulan ayrıntılardan daha net ortaya koyar.

Analiz dokümanı size ne kazandırır?

Analizin sonunda yazılı bir doküman çıkar: roller ve yetkiler, iş akışları, ekran listesi, iş kuralları, raporlar ve ilk sürümün sınırları. Bazı müşteriler bunu kırtasiye işi gibi görüyor. Biz tam tersini düşünüyoruz.

Bu doküman her şeyden önce bir mutabakat metnidir. Teklifin neyi kapsadığını ve neyi kapsamadığını gösterir. Proje sırasında yaşanan “Bunun da olacağını sanıyorduk” tartışmalarının neredeyse tamamı, yazılı bir kapsamın yokluğundan doğar.

Doküman, proje bittikten sonra da sizin elinizde kalan bir varlıktır. Yarın başka bir ekiple çalışmaya karar verseniz bile sistemin neden böyle tasarlandığını anlatan belge odur. Yeni işe başlayan bir çalışana sistemi anlatırken de işe yarar.

Bir de pek beklenmeyen bir faydası var. Pek çok firma kendi sürecini ilk kez yazılı hâlde görüyor ve bazen tek satır kod yazılmadan, yalnızca bu belgeyi okurken iki gereksiz onay adımı ortadan kalkıyor.

Özel yazılım geliştirme projelerimizde analizi ayrı bir aşama olarak planlıyor, doküman onaylanmadan kodlamaya geçmemeyi tercih ediyoruz. İster bizimle ister başka bir ekiple çalışın, ilk toplantıdan önce yukarıdaki on sorunun cevabını bir sayfaya yazmanızı öneririz. O tek sayfa, toplantının ilk yarım saatini baştan kazandırır.