Yazılım projelerinde sık gördüğüm durumlardan biri şudur: Kod temiz, mimari düzgün, performans iyi, testler geçer. Ancak ortaya çıkan ürün gerçek problemi çözmeyebiliyor ya da fırsat yaratmayabiliyor. Üstelik bu tablo, hepimizin yaşadığı kadar tanıdık ve rahatsız edici. Bu noktada refleks genelde yanlış yerde çalışır: Tartışma kod kalitesine, mimariye, teknoloji seçimine ya da performansa kayar. Oysa sorun çoğu zaman kodda değil, en başta yanlış tanımlanan gereksinimde olur.
Yanlış gereksinimler genellikle kötü niyetten değil, aceleden doğar. Yanlış gereksinim, mükemmel yazılmış bir kodu bile değersiz hale getirebilir. Çünkü yazılım, sonuçta ihtiyaca cevap vermek için vardır. Eğer o ihtiyacı doğru tanımlamadıysak, ortaya çıkan şey teknik olarak başarılı olsa bile ihtiyaç açısından etkisiz kalır. Bu tür özellikler “çalışıyor” gibi görünür ama kimse için hayat kolaylaştırmaz.
Analistlik bu noktada anlam kazanır. Analistin görevi çözüm üretmekten önce problemi netleştirmektir. Bu da analisti çoğu zaman “işi yavaşlatan kişi” gibi gösterir. Günümüz dünyasında talep sahipleri çözümle geliyor ve bu çözümde ısrarcı oluyorlar. Analistin “Ne yapacağız?” sorusundan önce “hangi problemi çözmeye çalışıyoruz?” sorusunu masada tutabilmesi gerekir. Bu soru basit görünse bile çoğu zaman atlanır. Bunun en büyük sebeplerinden biri, iş birimlerinin kendi istedikleri çözümde baskıcı olmasıdır. Hız baskısı altında, bazı analistler için çözüm konuşmak problem konuşmaktan daha konforlu hale gelir.
Yanlış gereksinimler varsayımlarla ve gelen çözüm talepleriyle başlar. “Böyle olmasını istiyoruz”, “Süreç böyle ilerlemeli”, “Sistem buna izin vermeli” gibi cümleler sorgulanmadan, doğru kabul edilerek ilerlenebilir. Bu cümleler o kadar sık tekrar ediliyor ki, bir süre sonra kontrol etmeye ihtiyaç duyulmaz. Bu varsayımlar sorgulanmadığında, yazılım ekibi kendisine verilen problemi en iyi şekilde çözer. Ortaya çıkan kod gerçekten iyi olabilir ama çözüldüğü düşünülen problem, baştan yanlış değerlendirilmiş olabilir.
Bu durum yazılımcıların ya da ekiplerin hatası değildir. Tam aksine, verilen işi en iyi şekilde yapmışlardır. Sorun, gereksinimin yeterince düşünülmeden, bağlamından kopuk şekilde tanımlanmasıdır. Analist bakışı bu noktada devreye girer. Kimseyi suçlamadan, problemi kişiden bağımsız ele alarak, “Bu gerçekten çözmek istediğimiz şey mi?” sorusunu gündeme getirir.
İyi yazılım, iyi gereksinimle başlar. İyi gereksinim ise aceleyle değil, doğru sorularla oluşur. Analistliğin değeri de tam olarak burada ortaya çıkar: Mükemmel çözümler üretmekte değil, doğru sorularla yanlış çözümleri daha en baştan engelleyebilmekte.
Aslında talep geldiği ilk andan itibaren şu soruyu daha sık sormamız gerekiyor:
“Neden?” Bu soruyu sormadığımız her projede yalnızca isteneni yapmış oluruz, gereksinimi anlayarak gerçek bir problem ya da fırsata dokunmuş olmayız.