Yazılım Projesinde Gereksinim Toplama: Doğru Soruları Sormak

Bir yazılım projesinin kaderi, ilk satır kod yazılmadan çok önce belli olur. QuantKOD olarak firmalara özel yazılım geliştirirken defalarca gördük: teknik olarak kusursuz yazılmış bir özellik, yanlış problemi çözdüğü için çöpe gidebiliyor. Sahadaki gözlemimiz net: projelerin çoğu kötü kod yüzünden değil, yanlış anlaşılmış gereksinimler yüzünden başarısız olur.

Gereksinim toplama, müşterinin söylediklerini bir listeye geçirmek değildir. İşin gerçek mantığını, görünür olmayan kısıtları ve dile getirilmeyen beklentileri ortaya çıkarma işidir. Bu yazıda, bir projenin başında doğru soruları nasıl sorduğumuzu ve hangi alışkanlıkların en pahalı yanlış anlamaları önlediğini anlatıyorum.

İnsanlar İstediklerini Değil, Çözümlerini Anlatır

Gereksinim toplamanın en temel tuzağı şudur: insanlar size ihtiyaçlarını değil, kafalarında kurguladıkları çözümü anlatır. "Bir buton koyalım, basınca rapor maile gitsin" cümlesi bir gereksinim değil, bir çözüm önerisidir. Arkasında yatan gerçek ihtiyaç belki de "yöneticinin her sabah satışları toplantıya girmeden görmesi" olabilir; bunun en iyi cevabı bir buton olmayabilir bile.

Bu yüzden duyduğunuz her çözüm önerisinin altındaki problemi kazımak gerekir. En sevdiğimiz araç, sade ama güçlü bir soru: "Bu sizin için hangi sorunu çözecek?" Bir cevabı birkaç kez "neden" diye eşelediğinizde, çoğu zaman ilk söylenenden tamamen farklı ve çok daha değerli bir ihtiyaca ulaşırsınız.

Müşteri size çözümü anlatır; sizin işiniz, o çözümün altındaki gerçek problemi bulmaktır.

Doğru Soruyu Sormanın Anatomisi

İyi bir gereksinim görüşmesi, sorgu değil keşif konuşmasıdır. Pratikte işimize yarayan birkaç soru tekniği var:

• Açık uçlu sorularla başlayın. "Bu süreci bana baştan sona anlatır mısınız?" gibi sorular, kişinin kendi diliyle iş akışını anlatmasını sağlar. "Şu özelliği istiyor musunuz?" gibi evet/hayır soruları ise sizi kendi varsayımlarınıza hapseder.
• İstisnaları sorun. Herkes mutlu senaryoyu anlatmayı sever. Asıl değerli bilgi istisnalarda saklıdır: "Müşteri ödemeyi yarıda bırakırsa ne oluyor?", "Stok eksiyse süreç nasıl işliyor?" Yazılımın karmaşıklığı ve çoğu hatanın kaynağı bu uç durumlardır.
• Mevcut durumu gözlemleyin. İnsanların işi nasıl yaptığını anlattığı ile gerçekte nasıl yaptığı çoğu zaman farklıdır. Mümkünse mevcut süreci yerinde izleyin; kullandıkları tabloları, defterleri, e-postaları görün. Söylenmeyen kuralların çoğu orada ortaya çıkar.
• Geçmişe bakın. "Son bir ayda bu süreçte yaşadığınız en sinir bozucu an neydi?" Somut bir anıyı hatırlatan sorular, soyut beklenti sorularından çok daha gerçek ve önceliklendirilmiş ihtiyaçlar çıkarır.

Kimi Dinlediğiniz, Ne Sorduğunuz Kadar Önemli

Bir gereksinimi yalnızca tek bir kişiden, çoğu zaman da projeyi başlatan yöneticiden dinlemek, sık karşılaştığımız bir hatadır. Yöneticinin ihtiyacı ile o yazılımı her gün sekiz saat kullanacak operasyon çalışanının ihtiyacı çoğu zaman farklı, bazen çelişkilidir.

Bu yüzden gereksinim toplarken farklı rolleri ayrı ayrı dinlemek gerekir. Yöneticiyi de dinlersiniz, sistemi fiilen kullanacak kişiyi de, sürecin çıktısını tüketen kişiyi de. Roller arasındaki çelişkileri erken görmek, projenin ortasında patlayacak "ama biz bunu böyle istememiştik" sürprizlerini büyük ölçüde önler. Çelişen beklentiler bir sorun değil, tam tersine erken bulunması gereken en değerli bilgilerden biridir.

Çelişki çıktığında işin teknik tarafına çekilmemek de önemlidir. "Hangisini yapalım?" sorusunun cevabı çoğu zaman yazılımda değil, işin önceliklerindedir. Bu durumda doğru tavır, çelişkiyi net biçimde ortaya koyup kararı işi en iyi tanıyan kişilere bırakmaktır. Bizim rolümüz, her iki beklentinin sonucunu somutça anlatıp tarafların bilinçli bir tercih yapmasını sağlamaktır; sessizce birini seçip diğerini görmezden gelmek değil.

Söylenmeyenleri ve Varsayılanları Yakalamak

Gereksinim toplamanın en zor kısmı, kimsenin söyleme ihtiyacı duymadığı şeyleri ortaya çıkarmaktır. Müşteri için o kadar bariz olan kurallar vardır ki, dile getirmeyi akıllarına bile getirmezler. "Tabii ki iptal edilen siparişler raporda görünmez" gibi varsayımlar, yazılı hiçbir yerde geçmediği için çoğu zaman yanlış uygulanır.

Bu örtük bilgiyi yüzeye çıkarmak için kullandığımız birkaç yöntem var:

1. Anladığınızı geri anlatın. "Doğru anladıysam süreç şöyle işliyor..." diyerek duyduğunuzu kendi cümlelerinizle özetleyin. Yanlış anlamalar en çabuk burada, müşteri "hayır, orada şöyle oluyor aslında" dediğinde ortaya çıkar.
2. Somut örnek üzerinden yürüyün. Soyut kural konuşmak yerine gerçek bir örnek isteyin: "Bana dünkü gerçek bir siparişi baştan sona gösterin." Somut vakalar, soyut tariflerde gizlenen istisnaları açığa çıkarır.
3. Erken görselleştirin. Basit bir ekran taslağı ya da akış şeması, sayfalarca metinden daha çok yanlış anlamayı ortaya çıkarır. İnsanlar bir şeyi görünce, sözle ifade edemedikleri itirazları kolayca dile getirir.

Gereksinimi Kayda Geçirmeden İş Bitmez

Sözlü olarak mükemmel anlaşılmış bir gereksinim bile, yazıya dökülmediği sürece kırılgandır. Hafıza zamanla kayar, ekip değişir ve aynı toplantıdan çıkan iki kişi çoğu zaman farklı şeyler hatırlar. Bu yüzden topladığınız gereksinimi, yorumlanmaya açık olmayacak biçimde yazılı hale getirmek gerekir.

İyi yazılmış bir gereksinim, çözümü değil ihtiyacı tanımlar ve test edilebilir olur. "Sistem hızlı olmalı" bir gereksinim değildir çünkü ölçülemez. "Rapor ekranı, bir aylık veride beklenen kullanıcı sayısı altında birkaç saniye içinde açılmalı" denildiğinde ise herkes neyin başarı sayılacağı konusunda hemfikir olur. Pratik bir kontrol sorusu şudur: "Bu cümleye bakarak, işin bitip bitmediğini tartışmasız söyleyebilir miyiz?"

Son olarak, gereksinim toplamayı tek seferlik bir aşama gibi görmemek gerekir. İnsanlar ne istediklerini çoğu zaman çalışan bir şey gördükçe netleştirir. Bu yüzden ilk gereksinimleri olabildiğince iyi anlamaya çalışır, ama planı taş gibi sabit değil, geri bildirimle güncellenecek bir taslak olarak ele alırız.

Kapsamı Konuşmak da Gereksinim Toplamanın Parçasıdır

Gereksinim toplarken sık karşılaştığımız bir yanılgı, her isteği eşit derecede gerekli saymaktır. Oysa uzun bir "olsa güzel olur" listesi, bir gereksinim dokümanı değildir; önceliklendirilmemiş bir dilek listesidir. Doğru soruları sormanın bir parçası da, neyin gerçekten ilk sürüm için zorunlu olduğunu ayıklamaktır.

Burada işimize yarayan soru basittir: "Bu olmadan sistem canlıya çıkabilir mi?" Çoğu istek için cevap aslında "evet"tir; sadece kimse o ayrımı yapmaya zorlanmamıştır. İstekleri "olmazsa olmaz", "önemli ama sonra" ve "gelecekte düşünülebilir" gibi gruplara ayırmak, hem bütçeyi korur hem de en değerli işin önce yapılmasını sağlar.

Bu ayrım aynı zamanda kapsam kaymasına karşı en iyi savunmadır. Yeni bir istek geldiğinde "bu hangi grupta ve neyin önüne geçiyor?" diye sorabildiğinizde, projeye sessizce sızan ve teslim tarihini sürekli geriye iten taleplerin önü kesilir. Gereksinimi toplamak kadar, onun sınırını çizmek de işin parçasıdır.

Sonuç: Önce Doğru Problemi Bulun

Bir özel yazılım projesinde en pahalı hata, yanlış şeyi çok iyi yapmaktır. Bunun önüne geçmenin yolu daha hızlı kod yazmak değil, daha iyi sorular sormaktır. Müşteriyi gerçekten dinlemek, çözümün altındaki problemi kazımak, istisnaları ve farklı rolleri ortaya çıkarmak ve anlaşılanı yazıya dökmek; harcanan zamanın projenin ilerleyen aşamalarında kat kat geri döndüğü adımlardır.

Doğru soruları soran ekip, yarısı yanlış anlaşılmış bir özellik listesiyle değil, gerçek ihtiyacı kavramış bir yol haritasıyla işe başlar. Yazılım geliştirmenin en kritik becerisi çoğu zaman kod değil, doğru soruyu doğru kişiye sorabilmektir.