Geliştiriciye Fikir Anlatma Sanatı: İyi Brief Nasıl Yazılır?

Ben her sistemi baştan sona kodlayan bir yazılım mühendisi değilim. Bunu uzun süre bir eksiklik gibi taşıdım.

Sonra şunu fark ettim: kod yazmayan ürün insanının da bir aleti var ve o alet iyi bilendiğinde en az kod kadar keskin.

O alet: brief.

İlk hatam: teknik görünmeye çalışmak

İlk brieflerimde geliştiriciye "teknik konuşmaya" çalışıyordum. Veritabanı tablosu öneriyor, mimari tarif ediyor, hangi kütüphanenin kullanılacağını yazıyordum.

Sonuç iki türlü kötüydü: ya yarım teknik bilgim yanlış yönlendiriyordu ya da geliştirici "sen karışma, ben hallederim" moduna geçiyordu. Haklıydı da.

Zamanla öğrendiğim şey şu: geliştiriciye nasıl yapacağını değil, neyi neden yaptığımızı anlatmak gerekiyor. Teknik kararlar onun uzmanlık alanı; benim işim, o kararları doğru vermesi için gereken bağlamı eksiksiz taşımak.

İyi briefin beş sorusu

Artık her briefi aynı beş sorunun cevabı olarak kuruyorum:

1. Problem ne? Bir cümle. "Kullanıcı, yüklediği fotoğrafın işlenip işlenmediğini anlamıyor ve uygulamayı kapatıyor."

2. Kim yaşıyor? Kullanıcı tipi ve senaryo. Persona romanı değil; iki cümlelik gerçek bir durum.

3. Başarı neye benziyor? Özellik bittiğinde neyin değiştiğini nereden anlayacağız? "İşlem ekranında kalma oranı artar", "destek mesajları azalır". Ölçülebilir olsun.

4. Kapsam ne ve ne DEĞİL? En kıymetli bölüm bu. "Bu sürümde bildirim yok, yalnızca ekran içi durum göstergesi var" cümlesi, üç günlük gereksiz işi baştan iptal eder.

5. Serbest alan nerede? Hangi kararlar geliştiricinin? Bunu açıkça yazmak güven verir: "Yükleme animasyonunun biçimi tamamen sende."

Beş cevap bir sayfayı geçmiyorsa, brief hazırdır. Geçiyorsa, muhtemelen tek brief değil iki brieftir.

Briefin gizli işlevi: kendinle yüzleşme

İşin sırrı şurada: brief aslında geliştiriciden önce yazana hizmet eder.

"Başarı neye benziyor?" sorusuna net cevap veremiyorsam, özellik daha fikir aşamasındadır, geliştirmeye hazır değildir. Kapsam dışını yazamıyorsam, kapsamı ben de bilmiyorumdur.

Kötü brief, belirsizliği geliştiriciye havale eder. İyi brief, belirsizliği yazım aşamasında öldürür. Aradaki fark, sprint ortasında "aslında ben şöyle demek istemiştim" konuşmasının olup olmamasıdır; o konuşmanın maliyetini bilen bilir.

---

Geliştiriciyseniz merak ediyorum: bugüne kadar aldığınız en iyi brief neye benziyordu? Ya da en kötüsü, o da öğretici.