Yazılım Projelerinde Kapsam ve Vizyona Yönelik Zorluklar
Yazılım projelerinde talebi anlamak, vizyon ve kapsamı belirlemek ve yönetmek en önemli ve zor işlerden biridir. Projenin başlarında ne istenildiğini doğru anlamak proje başarısını ve ürün kalitesini etkileyen kritik bir öneme sahiptir. Analizin bu aşamasında karşılaşılan en yaygın zorluklar olarak şunlarla karşılaşmanız muhtemeldir:
- Kapsam sünmesi (Scope creep)
- Altın kaplama (Gold plating)
- İş ihtiyacının ve beklenen faydanın net olarak belirlenememesi
- Yes men — no men olmak
- Etki analizini iyi yapamamak
- Varsayımlarda bulunmak
- Sen bir şeyler yap sonra gerekirse düzeltiriz
Bu zorluklardan ilk ikisini daha önce incelemiştik. Okumak için buraya tıklayabilirsiniz. Gelin diğer başlıklarıyla sırasıyla ele alalım.
İş ihtiyacının ve beklenen faydanın net olarak belirlenememesi
Yazılımı geliştirme nedenini tam olarak belirleyemeden doğru ürünü nasıl geliştireceksiniz? İşin sonunda ortaya çıkacak yazılımın neyi başarmasını bekliyorsunuz? Eğer bu ikisine cevabınız yoksa, peki, ne yapıyorsunuz? Ne için yapıyorsunuz? Yaptığınız şeyin doğru şey olduğunu nereden bileceksiniz?
Ürünün vizyonunu belirlemek, ürünü niçin yaptığınızı ve ürün ortaya çıktığında nasıl bir değer elde edeceğinizi tanımlamak anlamına gelir. Bunları yapmadan geliştirilecek bir yazılımın eksik, yetersiz hatta gereksiz olması çok muhtemeldir.
Bu tip sorunlar yaşamamak için iki temel noktaya odaklanabilirsiniz.
- İş ihtiyacı bir problemden kaynaklanıyorsa kök sebebi iyi analiz edin. Bunun için “5 Whys” ya da balık kılçığı tekniklerini kullanabilirsiniz.
- İş ihtiyacı bir iş hedefini yerine getirmeye yönelikse, bu durumda hedefin strateji hedefle ilişkisini ve tam olarak neyi başarmak istediğini iyi belirleyin.
Ayrıca her iki durumda da sonuçta neyi görmek istediğinizi tarif etmeye çalışın. Vizyon ifadesi zaten bu fikirden gelmektedir. Yazılımın başarıyla tamamlandığını ve hayata geçerek kullanıldığını hayal edin. Ne olursa bu hayal gerçekleşmiş olur? Daha da iyisi bu başarıyı nasıl ölçebilirsiniz? Metrikleriniz, anahtar performans göstergeleriniz neler olabilir? elbette her projeyi ölçemeyebilirsiniz. Ama ölçülebilen projeler için mutlaka bu konuyu önemseyin.
Yes-men ya da no-men olmak
Kapsam ve değişiklik yönetimiyle ilgili yapılan genel hatalardan biri de “Yes-men” ya da “no-men” olmaktır. Yani ya gelen her türlü değişikliğe evet demek ya da her türlü değişikliğe hayır demektir.
Tanımlanmış yapısal bir değişiklik yönetimi uygulamadığınız durumlarda karşınıza çıkabilecek bu zorulk, “yes-men” de olsanız “no-men” de olsanız sizi sıkıntıya sokar.
Paydaşlardan gelen her türlü talebe evet derseniz, öncelikle proje ekibini gerer, yorar ve mutsuz edersiniz. Hem bu çözüm ekibinin motivasyonsuzluğu hem de yeni gelen işlerin yükü ve riski nedeniyle proje zamanında teslim edilemez, eksik teslim edilir ya da çok sayıda hata içerir. E tabi bunun sonucu olarak da talep sahibi müşterileriniz de mutsuz olur.
Paydaşlardan gelen her türlü talebe hayır demeniz de iyi bir şey değildir. Bu da talep sahipleri ve iş birimi tarafında rahatsızlık yaratır. Mutsuz paydaş ortaya çıkarttığınız üründen memnun olmaz ve proje tesliminde mutlaka sıkıntı yaşarsınız.
Aslında bu durumun çok basit bir çözümü vardır. Paydaşlardan gelecek her türlü değişiklik talebine açık olun. Ancak her türlü değişiklik talebini iyi bir etki analizi çalışmasına tabi tutarak ek maliyeti, riskleri ve teslim tarihi üzerindeki etkilerini paydaşla tartışın. Eğer paydaşlar bu ek maliyeti ve bazı durumlarda teslim tarihi değişimini kabul ediyorsa seve seve değişikliği yerine getirin. Bu sizin işinizin önemli ve kaçınılmaz bir parçası!
Etki Analizini İyi Yapamamak
Bir değişiklik talebinin karşılanmasının ardından önceden çalışan işlevlerin hatalı çalıştığı bir örneğe denk geldiniz mi hiç? Umarım gelmemişsinizdir ama bu durum bizim sektörde pek de istisna değildir.
Yazılım gibi karmaşık bir sistemde belirli bir yeri değiştirdiğinizde bazen bu değiştirdiğiniz yerlerden etkilenen her şeyi göz önünde bulunduramayabilirsiniz. Örneğin yazılımcılarınız ek bir istek nedeniyle birçok raporda kaynak olarak kullanılan bir ilişkisel veritabanı tablosuna yeni birkaç alan eklediğini varsayalım. Bu alanlar kullanılarak yapılacak arama işlevi için de tabloda indeksleme yapmış olsun. Her şey yolunda değil mi? değişikliklerle birlikte ürünü devreye aldınız. Herkes memnun. Birkaç hafta sonra yazılımla ilgili acil kodlu bir hata bildirimi alıyorsunuz. 3 yıldır çalışan karmaşık bir rapor çalışmaz olmuş! Tabi aradan geçen zaman nedeniyle son yaptığınız değişikliğin buna neden olacağı yazılımcınızın aklına gelmiyor ama hatayı bulmak için saatler harcıyor. Neticede görüyor ki son yaptığı indeks değişikliği önceki raporların indeks yapısını etkilediği için raporun oluşturulması çok zaman alıyor ve “time-out” nedeniyle hata veriyor.
Şimdi diyebilirsiniz ki bu konu yazılımla ilgili değil mi? analist olarak sizi neden ilgilendirsin?
İyi bir değişiklik yönetimi ancak İyi bir etki analizi ile mümkün olur. İyi bir etki analizi için de gereksinimlerin, tasarımın, kodun ve testin hem kendi içindeki hem de birbirleriyle ilişkilerini tarif eden kapsamlı bir izlenebilirlik matrisine ihtiyaç duyarsınız. Böylece yapılan değişiklik neleri etkiliyor bu matris üzerinden belirler ve değişiklik yaparken bunu hem analiz hem geliştirme hem de test aşamasında göz önünde bulundurursunuz. Eğer böyle bir izlenebilirlik matrisiniz yoksa işiniz şansa kalmış demektir.
Varsayımlarda Bulunmak
Analizde iş analizi bilgileriyle çalışırken karşılaşacağınız şeylerden birisi de varsayımdır. Varsayım, doğru teyit edilmemiş ifadelere verilen bir isimdir. Örneğin projenizin tek test uzmanının 2 hafta içinde çalıştığı bir projedeki işini tamamlayarak sizin projenize dahil olacağını varsayarsınız. Ya da geliştirdiğiniz yazılımın entegre olması gereken ERP’yi geliştiren şirketin projenin 36. gününde size gerekli Web Services i teslim edeceğini varsayabilirsiniz. Bunlar her zaman karşılaşabileceğiniz durumlardır. Analiz dokümanında varsayımlar diye bir başlık açar bunları yazarsınız. İlgili tüm paydaşların onayını alırsınız. Proje sürecinde gerçekleşmeme ihtimali oluşan bazı varsayımları risk olarak yeniden tanımladığınız da olur. Ama benim burada bahsetmek istediğin varsayımlar bunlar değil. Bir de sizin analist olarak çoğunlukla bilincinde olmadan yaptığınız eksik tamamla davranışıdır. Paydaşın söylemediği bir şeyi “böyle olur” diye varsayar ve analizi bu varsayıma dayandırarak devam ettirirseniz sıkıntı çıkması kaçınılmazdır.
Başkaları adına düşünerek üreteceğiniz her bir bilgi risk demektir. Belki haklısınızdır. Belki o konuda uzman olduğunuz için paydaşların ifade etmediği, atladığı ya da unuttuğu iş kurallarını, süreç adımlarını siz tamamlıyorsunuz. Ama emin misiniz? sizin tamamladığınız bu eksikleri paydaşlar kabul edecek mi? ederse ne ala! Etmezse analiz hatası yüzünden yanlış geliştirilmiş bir yazılımla baş başa kalacaksınız demektir.
Herhangi bir modelleme ya da analiz çalışmasında eksik bazı bilgileri tespit etmeniz ve bunlarla ilgili ön görülerde bulunmanız gayet doğaldır. Ancak bu öngörüleri (varsayım) paydaşlarla ortaya koyulmuş ve kabul edilmiş gereksinimlerden ayırmalısınız. Bu varsayımları bir an önce ilgili paydaşlarla konuşmalı ve onaylatmalı ya da düzeltmelisiniz.
Sen Bir Şeyler Yap Sonra Gerekirse Düzeltiriz
Bir analist olarak karşılaşabileceğiniz bir diğer durum da paydaşların projeyle ilgili net olmamaları ya da vakitsizlikleri nedeniyle yarım yamalak birtakım gereksinimler üzerinden ilerlemenizi istemeleridir. Size birkaç yüksek seviyele gereksinim ve detayda birkaç iş kuralı verip, boşlukları sizin doldurarak yazılımı geliştirmenizi isterler. Ama yaptıklarınızı kabul etmeyerek düzeltme isteğinde bulunma haklarını saklı tutarlar. Böyle durumlarda da süreç doğal olarak kodla ve onar döngüsü içerisinde defalarca turlar.
Elbette bu durum geliştirme ekibinin hiç hoşuna gitmez. Ayrıca proje yönetimi de pek mümkün olmaz. Neyin kabul olacağının, ne yapılacağının belli olmadığı bir projede efor ve takvim tahminlemelerini nasıl yapacaksınız ki?
Bu tip projeler için en ideal çözüm tekrarlı-artırımlı çoğunlukla da çevik yaklaşımlardır. Belirli döngüler içerisinde paydaşın sadece net olduğu kadar gereksinim üzerine çalışılır. Örneğin her hafta ya da iki haftada bir birkaç işleve devreye alınır. Paydaşlar ve kullanıcılar bir yandan ortaya çıkan ürünle ilgili değerlendirmeler de yapar ve hem değişiklik hem de yeni işlev taleplerini iletirler. Ne kadar iş yapılacağı da daha çok belirli bir adam-ay sabitlenmesi üzerinden yürütülür. Çevik kontrat olarak da bilinen bu yaklaşımda kapsam sözü verilmez. Zaten sözü verilebilecek bir kapsam da ortada yoktur. Geliştirme ekibi belirli bir süre içerisinde paydaşın netleştirebildiği gereksinimleri en iyi şekilde geliştirme taahhüdü verir. Geliştirme ekibi ve iş biriminden paydaşlar birlikte çalışılarak kademeli detaylandırma ve adaptif planlamayla ellerinden geleni yapmaya odaklanırlar.
Tabii ki çevik yaklaşımda da paydaşın projeye zaman ayırması kaçınılmazdır. Gerekli vakti ayırmayan bir paydaş için başarılı proje geliştirmeye yönelik herhangi bir metodoloji olduğunu sanmıyorum. Benim tavsiyem böyle bir proje talebi varsa mümkün olan en politik şekilde bu projeyi erteleyin ya da üzerinize almaktan kurtulmaya çalışın.
Yazılım projelerinde analiz çalışmalarında karşılaşılan en yaygın diğer zorluklar için Common Challanges faced by Business Analysts kitabıma göz atmanızı öneririm.
Vizyon ve kapsama yönelik, ya da iş analizine yönelik sizin yaşadığınız zorluklar neler? En sık hangi zorluklarla karşılaşıyorsunuz?
