Yazılım projesi devam ederken yeni bir özellik istendiğinde, önce hangi sorunu çözeceğini ve mevcut işleri nasıl etkileyeceğini açıklığa kavuşturun. İsteği hemen geliştirmeye almak veya doğrudan reddetmek yerine, karar vermeye yetecek bilgiyi toplayın. Böylece yeni ihtiyacı konuşurken daha önce üzerinde anlaşılan işleri de görünür tutabilirsiniz.

Yeni fikirler neden planı belirsizleştirebilir?

İlk örnek ekranlar görüldüğünde kullanıcılar daha önce düşünmedikleri ihtiyaçları fark edebilir. Bu, fikrin baştan yanlış olduğu anlamına gelmez. Ancak her konuşmada küçük bir ek yapılır ve bu ekler ayrı kaydedilmezse, ekipler farklı bir teslim kapsamı beklemeye başlayabilir.

Bir kişi yalnızca yeni bir kutu eklenmesini düşünürken başka biri bu kutuya bağlı filtreleri ve raporları da bekliyor olabilir. Sorun, yeni fikir üretilmesi değil; aynı isteğin farklı anlaşılmasıdır. Başlangıç sınırları net değilse ilk sürümde hangi işlerin gerekli olduğunu yeniden değerlendirmek yararlı olabilir.

Özelliği değil, yaşanan güçlüğü tarif edin

“Bir düğme daha ekleyelim” demek yerine, bugün hangi işin yapılamadığını yazın. İsteğin kimden geldiğini, hangi durumda ortaya çıktığını ve mevcut yöntemle neyin zorlaştığını anlatın. Teknik çözümü baştan belirlemek zorunda değilsiniz.

Örneğin bekleyen kayıtları bulmak zorlaşıyorsa yeni bir ekran tek seçenek olmayabilir. Mevcut listede bir filtre, daha açıklayıcı bir durum bilgisi veya işin farklı sırayla yapılması da değerlendirilebilir. Bunlar hazır çözümler değil, konuşulabilecek seçeneklerdir; uygunlukları mevcut sistem incelenince anlaşılır.

İstek kaydına bir kullanım örneği ekleyin. “Haftanın başında henüz sorumlu atanmamış işleri görmek istiyorum” cümlesi, yalnızca “daha iyi raporlama” demekten daha somut bir başlangıçtır.

Hata, açıklama ihtiyacı ve yeni işi ayırın

Daha önce yapılacağı kararlaştırılmış bir işlemin çalışmamasıyla, sonradan farklı bir davranış istenmesi aynı durum değildir. Bazen de yazılım beklendiği gibi çalışır, ancak iş kuralı yeterince açıklanmamıştır. Önceki kararları ve beklenen sonucu birlikte okuyarak hangi durumun söz konusu olduğunu belirleyin.

Bu ayrımı yalnızca talebin adına bakarak yapmayın. “Küçük düzeltme” denen bir iş yeni bir veri alanı gerektirebilir; “yeni özellik” denen bir istek ise mevcut davranışın açıklanmasıyla çözülebilir. Burada amaç ek işin ücretli olup olmadığına peşinen hükmetmek değil, neyin değişeceğini ortak biçimde tarif etmektir.

Varsayımsal bir işletmede seçenekleri karşılaştıralım

İş taleplerini ortak bir listede izleyen bir işletme düşünelim. İlk sürümde kayıt oluşturma, sorumlu atama ve durum değiştirme üzerinde anlaşılmış olsun. Deneme sırasında bir kullanıcı, kapanan kayıtlar için ayrıca değerlendirme notu istemiş olsun. Bu tamamen varsayımsal bir örnektir.

Önce notun ne amaçla kullanılacağı sorulur. Yalnızca sorumlu kişinin sonraki işini hatırlaması için mi, yoksa kapanış kararını başka bir kişinin incelemesi için mi gereklidir? İkinci durumda kimlerin notu göreceği ve kapanışın ne zaman tamamlanmış sayılacağı da konuşulmalıdır.

Ekip, mevcut açıklama alanının yeterli olup olmadığını inceleyebilir. Ayrı alan gerekiyorsa bunu mevcut sürüme eklemek, sonraki sürüme bırakmak veya henüz başlamamış başka bir işi erteleyerek öne almak seçenekleri değerlendirilebilir. Hiçbiri bütün projeler için doğru cevap değildir; tercih, notun günlük işteki önemine ve diğer işlere etkisine bağlıdır.

Karardan önce hangi sorular cevaplanmalı?

Kısa bir değerlendirme notunda şu soruları yanıtlayın:

  • İhtiyaç nedir? Kullanıcının tamamlayamadığı işi ve beklediği sonucu yazın; yalnızca ekran adını kaydetmeyin.
  • Beklerse ne olur? İş duruyor mu, geçici bir yöntem var mı, yoksa kullanım kolaylığı mı hedefleniyor? Durumu somutlaştırın.
  • Nereler etkilenir? İlgili kayıtları, kullanıcı görevlerini ve mevcut akıştaki değişecek adımları ekiple inceleyin.
  • Neyi yeniden kontrol edeceğiz? Yeni davranışın yanında, etkilenebilecek mevcut işlerden örnekler seçin.
  • Hangi karar verildi? Şimdi yapılacak, sonraya bırakılacak veya ek bilgi beklenecek durumunu ve kararın gerekçesini kaydedin.

İlk inceleme her ayrıntıyı ortaya çıkarmayabilir. Belirsiz kalan noktaları boşluğu tahminle doldurmak yerine açık soru olarak tutun. Süre veya bedel değerlendirmesi için yeterli bilgi yoksa kesin bir rakam yazmak zorunda değilsiniz.

Onaydan sonra aynı beklentiyle ilerleyin

Karar, onu isteyen kişiyle işi uygulayacak ekip tarafından aynı şekilde anlaşılmalıdır. Kabul edilen değişikliği güncel iş listesine ekleyin; ertelenen isteği de kaybolmayacak biçimde tutun. İsteğin konuşulmuş olması, uygulamaya alınmasına onay verildiği anlamına gelmesin.

Tamamlandığında hangi örnekle kontrol edileceğini baştan yazmak yararlıdır. Bunun için kullanıcı kabul testi planlama rehberindeki beklenen ve gözlenen sonucu ayırma yaklaşımından yararlanabilirsiniz.

Yeni özellikleri değerlendirmenin amacı fikirleri azaltmak değildir. Hangi ihtiyacın neden öne alındığını ve diğer işlerin nasıl etkilendiğini anlaşılır tutmaktır. Böylece kararın dayanağı yalnızca en son söylenen istek değil, üzerinde konuşulmuş ihtiyaç ve açıkça kaydedilmiş tercih olur.