PRD'nin Boşluklarını Gözden Geçirenler Görmeden Yakala

PRD'lerin çoğu, onları yazan kişinin tek bir okumasından sonra gider. Bu yazım hatalarını yakalar ama gönderdiğin her belgenin yorumlarında aynı açıklayıcı sorunun sorulmasına yol açan boşluğu nadiren yakalar; çünkü cevabı zaten biliyorsun ve eksik olduğu yeri görmeden okuyup geçiyorsun. Bir özelliğin bağlamını iki hafta kafasında taşımış bir PM, o özellikle ilgili bir PRD'yi, belgeyi ilk kez soğuk soğuk açan bir mühendisten tamamen farklı okur.

Kendi okumandan sağ çıkan PRD, değerlendirmeye en az yetkin olduğun PRD'dir.

Aynı soru neden gözden geçirmede sürekli ortaya çıkar

Belgeyi tüm bağlam zaten kafandayken yazdın; bu yüzden gereksinimlerdeki bir boşluk sana boşluk gibi değil, bariz gibi okunur. Gözden geçirenin bu bağlamı yoktur; bu yüzden aynı türden soru, ele alınmamış bir uç durum, söylenmemiş bir varsayım, belge belge yeniden ortaya çıkar. Son beş PRD'nin üçü, özelliğin belirli bir kullanıcı türü için nasıl davranması gerektiğini soran aynı yorumu aldıysa, bu şanssızlık değil, kapsamı nasıl yazdığındaki bir örüntüdür.

Standart bir kullanıcının 10.000 satıra kadar dışa aktarması durumunda ne olacağını tam olarak belirten bir toplu dışa aktarma özelliği için bir PRD al. 100.000 satırda ya da dışa aktarma sınırı olan ücretsiz katmandaki bir kullanıcı için ne olacağını söylemez; çünkü yazar yazdığı süre boyunca yaygın durumu düşünüyordu. Belgeyi devralan bir mühendisin bu cevapları çıkarsamanın yolu yoktur ve ortaya çıkan yorum dizisi, “satır sınırının üstünde ne olur?”, kontrol etmeyi düşünen olsaydı son üç PRD'de de ortaya çıkacak olan aynı sorudur.

Önce: PRD'yi yazmak, bir kez okumak, net olduğuna karar vermek, incelemeye göndermek.

Sonra: onu özelliğin gerçek bağlamıyla Claude'a vermek, kapsamın net olup olmadığını ve hangi uç durumların eksik olduğunu özellikle sormak ve bir gözden geçiren sormak zorunda kalmadan önce bulduğunu düzeltmek.

Bir PRD'yi incelemeden önce sınamak için bir süreç

Zaten bildiğin belirli bir teknik kısıtı olan bir özellik için, bir hız sınırı, bir veri boyutu üst sınırı, bir izin sınırı, bunu Claude'a doğrudan söylemeye değer; böylece uç durum kontrolü genel tahminlere değil gerçek sisteme dayanır.

Boşluklar hep aynı bölümden geldiğinde

Uç durumlar PRD'lerinin aynı bölümünde sürekli ortaya çıkıyorsa, bunu her seferinde sıfırdan yeniden düzeltmek yerine bir örüntü olarak fark etmeye değer. Örneğin izinler bölümünde tekrarlayan bir boşluk genellikle o bölümün başka bir tek seferlik inceleme değil, kalıcı bir kontrol listesine ihtiyaç duyduğu anlamına gelir. Aynı boşluk kategorisini üç ayrı kez düzeltmek, yalnızca mevcut belgenin değil, altta yatan alışkanlığın değişmesi gerektiğinin işaretidir.

Böyle bir kontrol listesi olduğunda, her yeni PRD'nin ilgili bölümünü ilk incelemeden önce ona karşı çalıştırmaya değer; her seferinde aynı tekrarlayan boşluğu yakalamak için hafızaya güvenmek yerine.

Okumaya devam et

• Tek Satırlık Bir Özellik İsteğinden PRD Yazmak: yapıyı baştan doğru kurmak; bu makalenin ele aldığı inceleme ve düzeltme turundan önce.
• Destek Taleplerini Önceliklendirilmiş Temalara Dönüştürmek: bir PRD'nin kapsaması gereken uç durumların ilk etapta sıkça nereden geldiği.
• Claude ile Başlarken: bu sürecin tamamının üzerine kurulu olduğu temel alışkanlıklar, bağlam, yineleme, belirlilik.