Ürün Gereksinimleri Dokümanı (PRD) Şablonu (+ Kopyalayabileceğiniz Tam Bir Örnek)

Ürün Gereksinimleri Dokümanı (PRD) Şablonu (+ Kopyalayabileceğiniz Tam Bir Örnek)

Son güncelleme: 28 Temmuz 2026.

Çoğu ürün gereksinimleri dokümanı şablonu sayfası size boş bir form bırakıp gider. Atlassian'ınki, boş bir başarı metrikleri tablosunun etrafına sarılmış dört bölümlük talimattan ibaret. Product School'unki başlığında "(Örnekli)" yazıyor ama içinde hiç örnek yok. Aşağıdaki 12 bölümlük markdown blok şablonun tamamı — ücretsiz, kopyala-yapıştır. 4. Bölüm ise bu 12 bölümün her birini tam bir örnek yapıyla dolduruyor: PDF faturaları bir LLM ile okuyan ve şüpheli olanları bir insana yönlendiren bir müşteri fatura portalı. Boş olanı kopyalayın. Doldurulmuş olanı okuyun. Kendinizinkini yazın.

Önemli Noktalar

• Bir PRD neyin ve neden inşa edileceğini yanıtlar; teknik tasarım dokümanı ise nasıl inşa edileceğini yanıtlar.
• 12 bölüm her proje boyutuna uyar. Tek sayfalık sürüm, aynı şablonun daha az satırla halidir.
• Hedef olmayanlar mutlaka yazılmalıdır. Bir yapay zeka kodlama ajanı, kapsamı eksik bilgiden çıkaramaz.
• Kabul kriterleri makine tarafından kontrol edilebilir olmalıdır: "hızlı" değil, "p95 400ms altında".

Hangi PRD Biçimini Kullanmalısınız?

Şekli, dokümanı kimin okuyacağına göre seçin, ürünün ne kadar büyük hissettirdiğine göre değil. Kendi mühendislerinize giden tek bir özellik, tek sayfalık bir sürüm gerektirir. Dışarıdaki bir ekibe teslim edilen bir yapı, tam 12 bölümlük PRD'yi gerektirir, çünkü kabul kriterleri aynı zamanda onay kapısı görevi görür. Bir yapay zeka kodlama ajanına giden bir spesifikasyon ise aynı on iki bölümün fazlara bölünmüş halini gerektirir.

Herkesin sorduğu tek sayfalık ürün gereksinimleri dokümanı şablonu ayrı bir yapı değildir. Lenny Rachitsky'nin yaygın olarak kopyalanan tek sayfalık sürümü — bültende gerçek örneklerle yayınlanmıştır — töreni çıkarılmış aynı iskelettir. Tek sayfalık sürüm farklı bir doküman değildir. Boş satırları silinmiş aynı on iki bölümdür.

Agile ekipler de bu soruyu sıkça sorar, genelde bir PRD'nin bir backlog ile karşılaştıktan sonra ayakta kalıp kalamayacağı şeklinde. Kalır, tek sayfalık bir sürüm olarak: PRD nedenini ve sınırları taşır, ticketlar ise işi taşır.

PRD Şablonu (Kopyala-Yapıştır Markdown)

İşte tamamı markdown olarak, ücretsiz, e-posta duvarı yok. Notion'a, Confluence'a, Google Docs'a, Linear'a, Word'e yapıştırın ya da PRD.md olarak GitHub'a commit'leyip kodla birlikte versiyonlansın. İnsanlar bu şablonu dokuz farklı formatta istiyor; markdown, hepsine yapıştırıldığında hayatta kalan formattır ve bir yapay zeka kodlama ajanının sorunsuzca okuduğu tek formattır.

# PRD: [Ürün veya özellik adı]

## 1. Başlık
- Sahip (ürün):
- Mühendislik lideri:
- Tasarım lideri:
- Durum: Taslak | İncelemede | Onaylandı | Yayınlandı
- Son güncelleme:
- Değişiklik geçmişi: tarih / yazar / ne değişti

## 2. Problem tanımı
Tek paragraf. Kim acı çekiyor, ne sıklıkla, bugün maliyeti ne. Çözüm dili yok.

## 3. Hedefler ve başarı metrikleri
| Hedef | Metrik | Başlangıç | Hedef | Nasıl ölçülür | Tarih |
|---|---|---|---|---|---|

## 4. Hedef olmayanlar
Olumlu şekilde ifade edin: "Bu faz X'i içermez."

## 5. Kullanıcılar ve personalar
Kim kullanıyor, zaten ne biliyorlar, hangi cihaz, ne sıklıkla.

## 6. Kullanıcı hikayeleri ve kabul kriterleri
Bir [persona] olarak, [eylem] istiyorum, çünkü [sonuç].
- Verilen [bağlam], ne zaman [olay], o zaman [gözlemlenebilir sonuç].

## 7. Fonksiyonel gereksinimler
Numaralandırılmış. Satır başına bir gereksinim. Test edilebilir. "ve" içeren cümle yok.

## 8. Fonksiyonel olmayan gereksinimler
Performans / güvenlik ve çok kiracılılık / veri ikametgahı ve saklama / erişilebilirlik / kullanılabilirlik.

## 9. Bağımlılıklar ve entegrasyonlar
Harici sistemler, API'ler, kimlik bilgileri, erişimi kim sahiplenir, hazırlık süresi.

## 10. Kilometre taşları ve fazlandırma
| Faz | Kapsam | Çıkış kriterleri | Hedef tarih |
|---|---|---|---|

## 11. Açık sorular ve riskler
| Soru veya risk | Sahip | Ne zamana kadar gerekli | Yanıtsız kalırsa etki |
|---|---|---|---|

## 12. Ek ve bağlantılar
Tasarımlar, araştırma, rakip notları, önceki ticketlar, sözleşmeler.

On iki bölüm, sırasıyla: başlık, problem tanımı, hedefler ve başarı metrikleri, hedef olmayanlar, kullanıcılar ve personalar, kabul kriterli kullanıcı hikayeleri, fonksiyonel gereksinimler, fonksiyonel olmayan gereksinimler, bağımlılıklar ve entegrasyonlar, kilometre taşları ve fazlandırma, açık sorular ve riskler, ek.

Bir PRD Neleri İçermeli? 12 Bölüm ve Her Birinin Zayıf Versiyonu

Bir ürün gereksinimleri dokümanı; bir problem tanımı, ölçülebilir hedefler, açık hedef olmayanlar, personalar, kabul kriterli kullanıcı hikayeleri, fonksiyonel ve fonksiyonel olmayan gereksinimler, bağımlılıklar, kilometre taşları, sahipli açık sorular ve bir değişiklik geçmişi içermelidir. Geri kalan her şey ek niteliğindedir. Her satır için test, ISO/IEC/IEEE 29148:2018 standardının gereksinimlere genel olarak uyguladığı testtir: doğrulanabilir, belirsiz olmayan, tekil.

Çoğu PRD bu testi aynı üç noktada geçemez.

İki bölüm, genelde hak ettiğinden fazlasını hak ediyor.

Fonksiyonel olmayan gereksinimler, kapsamın sessizce ikiye katlandığı yerdir. Performans, çok kiracılılık, veri ikametgahı, saklama, erişilebilirlik, kullanılabilirlik: bunların her biri maliyeti olan bir mühendislik kararıdır ve hiçbiri bir kullanıcı hikayesinde görünmez. Güvenlik satırını belirsiz bir cümleye sıkıştırmak yerine buraya koyun ve kontrol edilmesini istediğiniz şekilde yazın; kaynak liste olarak yayın öncesi güvenlik kontrol listemizi kullanın. Yapının bir yapay zeka bileşeni varsa, üretime hazırlık gereksinimleri de burada yer almalı, asla zamanlaması hiç yapılmayan sonraki bir "sağlamlaştırma" fazında değil: PoC'den üretime kontrol listemiz bizim kullandığımız versiyondur.

Açık sorular üç sütun gerektirir, bir değil. Soru, sahip, gereklilik tarihi. Sahibi olmayan bir soru, kimsenin almadığı bir karardır ve altıncı haftada bir değişiklik talebi olarak ortaya çıkar. Söylemekte fayda var: bir PRD, satın almak yerine inşa etmeye karar verdikten sonra yazdığınız şeydir. Problem tanımı hâlâ bir özellik alışveriş listesi gibi okunuyorsa, satın al-inşa et kararı henüz gerçekten verilmemiş demektir.

Örnek Çalışma: Doldurulmuş Bir Fatura Portalı PRD'si

İşte tam bir örnek çalışma, tüm 12 bölüm doldurulmuş. Yapı: orta ölçekli bir lojistik operatörü için bir müşteri fatura portalı. Müşteriler PDF faturalar yüklüyor, bir LLM satır kalemlerini çıkarıyor, sistem sipariş kaydıyla uyuşmazlıkları işaretliyor ve emin olamadığı her şey bir insan inceleme kuyruğuna gidiyor. Teknoloji yığını: Next.js, Supabase/Postgres, tek bir LLM çıkarım adımı. Kopyalayın, yazdırın, PDF'e aktarın, ihtiyacınız olan neyse.

# PRD: Müşteri Fatura Portalı, Faz 1

## 1. Başlık
- Sahip (ürün): Operasyon direktörü, müşteri tarafı
- Mühendislik lideri: Teslimat lideri, Techsy
- Tasarım lideri: Ürün tasarımcısı, Techsy
- Durum: Yapıya onaylandı
- Son güncelleme: 2026-07-28
- Değişiklik geçmişi:
  - 2026-07-14 / ürün / ilk taslak
  - 2026-07-21 / mühendislik / 6.2'ye güven eşiği kuralı eklendi
  - 2026-07-28 / ürün / ERP'ye geri yazma hedef olmayanlara taşındı

## 2. Problem tanımı
Operasyon ekibi, müşteri faturalarını e-postayla gelen PDF'ler olarak alıyor ve
bunları elle sipariş sistemine yeniden giriyor. Hacim haftada 300 faturayı
aşıyor, ortalama işlem süresi fatura başına yaklaşık 6 dakika ve yaklaşık %4'ü
yalnızca ay sonu mutabakatında fark edilen bir giriş hatası taşıyor. Her
düzeltme ikinci bir geçiş ve bir telefon görüşmesi maliyetine yol açıyor.

## 3. Hedefler ve başarı metrikleri
| Hedef | Metrik | Başlangıç | Hedef | Nasıl ölçülür | Tarih |
|---|---|---|---|---|---|
| Manuel işlemi azalt | Ort. işlem süresi | 6 dk | 90 sn altı | Operasyon panosu, haftalık medyan | 2026-11-01 |
| Giriş hatalarını azalt | Mutabakatta düzeltilen fatura | %4 | %1 altı | Finans ay sonu raporu | 2026-12-01 |
| İnceleme yükünü sınırla | İnsan incelemesine yönlenen pay | yok | %25 altı | Portal kuyruk metrikleri | 2026-11-01 |

## 4. Hedef olmayanlar
Bu faz çoklu para birimi faturalarını, ERP'ye geri yazmayı, müşteri
self-servis alacak dekontlarını veya bir mobil uygulamayı desteklemez.
Çıkarım yalnızca PDF'i kapsar. Kağıt faturaların fotoğrafları ve 200 DPI
altındaki taramalar, nedenini açıklayan bir mesajla yüklemede reddedilir.

## 5. Kullanıcılar ve personalar
- Operasyon uzmanı (birincil, 6 kişi): tüm gün istisna kuyruğunda çalışır,
  derin alan bilgisi, yalnızca masaüstü.
- Müşteri AP kontağı (harici, ~140 hesap): faturaları yükler, hesap kurulum
  sürtünmesine düşük tolerans.
- Finans müdürü (ikincil): ay sonu raporunu çeker, fatura başına bir denetim
  izi ister.

## 6. Kullanıcı hikayeleri ve kabul kriterleri
6.1 Bir müşteri AP kontağı olarak, bir fatura PDF'i yüklemek istiyorum, çünkü
e-posta göndermek ve beklemek zorunda kalmak istemiyorum.
- Verilen 20 MB altında ve 200 DPI veya daha iyi bir PDF, ne zaman yüklersem,
  o zaman portal 5 saniye içinde bir referans numarası döndürür ve
  "İşleniyor" gösterir.

6.2 Bir operasyon uzmanı olarak, düşük güvenli çıkarımların tutulmasını
istiyorum, çünkü hiçbir yanlış şey otomatik onaylanmasın.
- Verilen ayrıştırılmış bir fatura, ne zaman herhangi bir satır kaleminin
  çıkarım güveni 0.85'in altına düşerse, o zaman fatura inceleme kuyruğuna
  yönlenir ve asla otomatik onaylanmaz.

6.3 Bir operasyon uzmanı olarak, uyuşmazlığı tek bir yerde görmek istiyorum,
çünkü sipariş sistemini açmadan çözebilmek istiyorum.
- Verilen bir siparişle eşleşen bir fatura, ne zaman herhangi bir satır
  miktarı veya birim fiyatı sipariş kaydından farklı olursa, o zaman portal
  her iki değeri yan yana gösterir ve farkı işaretler.

6.4 Bir finans müdürü olarak, faturaları filtrelemek istiyorum, çünkü ayı
kapatabilmek istiyorum.
- Verilen fatura listesi, ne zaman tedarikçi, tarih aralığı ve duruma göre
  filtrelersem, o zaman sonuçlar p95'te 400ms altında döner ve boş durum
  "Filtreleri temizle" sunar.

## 7. Fonksiyonel gereksinimler
1. Yükleme yalnızca PDF kabul eder, 20 MB maksimum, gönderi başına bir dosya.
2. Çıkarım; tedarikçi, fatura numarası, tarih, para birimi ve miktar, birim
   fiyat ve toplam içeren satır kalemlerini döndürür.
3. Her satır kalemi 0 ile 1 arasında bir güven skoru taşır.
4. Eşleştirme, çıkarılan faturayı açık siparişle PO numarasına göre
   karşılaştırır.
5. İstisnalar en eskiden başlayarak sıralı bir kuyruğa girer, bir uzmana
   atanabilir.
6. Her durum değişikliği; aktör, zaman damgası, önceki değeri içeren bir
   denetim kaydı yazar.
7. Onaylanan faturalar, finans sistemi için bir CSV toplu iş olarak
   dışa aktarılır.

## 8. Fonksiyonel olmayan gereksinimler
- Performans: fatura listesi p95 400ms altında. Çıkarım, yüklemeden itibaren
  p95'te 90 saniye içinde tamamlanır.
- Güvenlik ve çok kiracılılık: kiracı başına izolasyon veritabanı satır
  düzeyinde uygulanır. Bir müşteri asla başka bir müşterinin faturasını
  okuyamaz. Her sürümde otomatik testle doğrulanır.
- Veri ikametgahı ve saklama: belgeler AB'de saklanır. Orijinaller 7 yıl,
  çıkarım verileri 90 gün saklanır.
- Erişilebilirlik: kuyruk tamamen klavyeyle çalıştırılabilir, WCAG 2.2 AA
  kontrastı.
- Kullanılabilirlik: aylık %99.5, mesai saatlerinde destek.

## 9. Bağımlılıklar ve entegrasyonlar
- Sipariş kayıtları: salt okunur Postgres replikası. Erişim müşteri BT'ye ait,
  kimlik bilgileri 2026-08-15'e kadar gerekli.
- LLM çıkarım sağlayıcısı: yapı başlamadan önce sözleşme ve veri işleme
  anlaşması imzalanır.
- E-posta bildirimleri: mevcut işlemsel sağlayıcı, gönderen alan adı müşteri
  tarafından doğrulanır.

## 10. Kilometre taşları ve fazlandırma
| Faz | Kapsam | Çıkış kriterleri | Hedef tarih |
|---|---|---|---|
| P1 | Yükleme, çıkarım, güven yönlendirmesi | 50 gerçek fatura uçtan uca, %25 altı kuyrukta | 2026-09-19 |
| P2 | Sipariş eşleştirme ve uyuşmazlık görünümü | 20 tohum vakada uyuşmazlık doğru işaretlendi | 2026-10-10 |
| P3 | Denetim izi, CSV dışa aktarma, raporlama | Finans portalda bir ayı kapatıyor | 2026-11-01 |

## 11. Açık sorular ve riskler
| Soru veya risk | Sahip | Ne zamana kadar gerekli | Yanıtsız kalırsa etki |
|---|---|---|---|
| Bir faturada iki PO numarası görünüyorsa hangisi geçerli? | Müşteri operasyon direktörü | 2026-08-08 | Eşleştirme mantığı bloke |
| En büyük 12 müşteri taranmış mı yoksa native PDF mi gönderiyor? | Teslimat lideri | 2026-08-08 | Güven eşiği yanlış olabilir |
| 7 yıllık saklama müşteri hukuk müşaviriyle onaylandı mı? | Müşteri finans müdürü | 2026-08-22 | Depolama tasarımı ve maliyeti değişir |
| Haftada 300'de fatura başına çıkarım maliyeti | Teslimat lideri | 2026-09-05 | Birim ekonomi bilinmiyor |

## 12. Ek ve bağlantılar
Anonimleştirilmiş örnek fatura seti (40 dosya), sipariş tablosu şeması,
mevcut işlem süresi çalışması, yükleme ve kuyruk için Figma akışları,
imzalı iş kapsamı bildirimi.

Orada dört seçim öne çıkmayı hak ediyor, çünkü her birinin tembel versiyonu gerçek paraya mal oluyor.

Bölüm 3, başlangıç noktası. "6 dakika" bir süsleme değil. Bir başlangıç noktası olmadan işin işe yarayıp yaramadığını anlayamazsınız ve altı ay sonra biri bunu veri olmadan bir toplantıda tartışır. Tembel versiyon, "verimliliği artır", projeyi çürütülemez hale getirir.

Bölüm 4, hedef olmayan. ERP'ye geri yazma, bir inceleme görüşmesi sırasında varsayılarak var olduktan sonra 2026-07-28'de hedef olmayanlara taşındı. Bunu bir hedef olmayan olarak yazmak bir satıra mal oldu ve bir kapsam tartışmasını önledi.

Bölüm 6.2, güven eşiği. Bu, kendi ilk taslaklarımızın en sık kaçırdığı kural. Bunu dışarıda bırakırsanız sistem, bir insanın görmesi gereken faturaları otomatik onaylar — bu da tam olarak bölüm 3'te vaat ettiğiniz zaman tasarrufunu silen başarısızlıktır.

Bölüm 11, sahipler. Her açık sorunun bir adı ve bir tarihi var. O sütun, bir doküman ile kimsenin sahiplenmediği bir yapılacaklar listesi arasındaki farktır.

PRD size neyi söyler. Ne kadar süreceğini veya ne kadar maliyetli olacağını söylemez, bu ayrı bir çalışmadır: bu yarısı için yapının kapsamını belirleme yazımıza bakın. Ve yazılı olarak belirtmediğiniz bir hedef olmayan, birinin inşa edeceği bir özelliktir.

Bir Yapay Zeka Kodlama Ajanının Gerçekten İnşa Edebileceği Bir PRD Nasıl Yazılır?

Yapay zeka kodlama ajanı için yazılmış bir PRD, kısalığı açıklık uğruna feda eder. Ajanın gayriresmi paylaşılan bir bağlamı yoktur, paylaşılan bir geçmişi yoktur ve açıkça neyi kastetmediğinize dair bir sezgisi yoktur. Dört kural farkın çoğunu kapsıyor ve bunlar kendi yapay zeka destekli yapılarımızda spesifikasyonların başarılı ve başarısız olmasını izlemekten geliyor.

1. Hedef olmayanları olumlu ifade edin. İnsanlar kapsamı eksik bilgiden çıkarır. Ajanlar çıkaramaz. "Bu fazda kimlik doğrulama eklemeyin" dokümanda bir cümle olmalı, yoksa kimlik doğrulama inşa edilir, test edilir ve size geri teslim edilir.

2. İşi fazlara bölün. Tek bir 40 sayfalık monolit, kendinden emin, dağınık, yarı doğru bir pull request üretir. PRD'yi bir ajanın tek bir sınırlı çalıştırmada bitirebileceği geçişlere bölün, her birinin kendi çıkış kriteri olsun.

3. Kabul kriterlerini makine tarafından kontrol edilebilir yapın. "Hızlı" bir gereksinim değil, bir ruh halidir. "Fatura listesi endpoint'inde p95 400ms altında" ajanın özelliği yazmadan önce yazabileceği bir testtir.

4. Dosya yollarını ve teknoloji yığını kısıtlamalarını sohbette değil, dokümanda tutun. Sohbet bağlamı oturumlar arasında buharlaşır. Spesifikasyon buharlaşmaz. Bu aynı zamanda Claude Code'un plan modunun önemli olmasının nedenidir: dosyalarınızı okur ve siz onaylayana kadar hiçbir şeyi düzenlemeden bir plan önerir ve bu onay adımı, plan sizin hafızanızdaki isteğiniz yerine yazılı bir spesifikasyona karşı kontrol edildiğinde çok daha faydalı olur.

İşte fatura portalı, bir ajanın tek geçişte çalıştırabileceği bir faza bölünmüş hali.

# İnşa görevi: Fatura yükleme ve çıkarım (3'ün 1. Fazı)

## Teknoloji yığını kısıtlamaları (değiştirilemez)
Next.js 15 App Router, TypeScript, row-level security'e sahip Supabase Postgres,
Vercel deploy. Önce sormadan yeni bağımlılık yok.

## Oluşturabileceğiniz veya düzenleyebileceğiniz dosyalar
- app/(portal)/invoices/upload/page.tsx
- app/api/invoices/route.ts
- lib/extraction/parse-invoice.ts
- supabase/migrations/0007_invoices.sql

## Dokunmayın
- lib/auth/*  (kimlik doğrulama Faz 2'de gelir; şimdi giriş akışları eklemeyin)
- app/(marketing)/ altındaki her şey
- Mevcut sipariş şeması. Okuyun. Asla migrate etmeyin.

## Kabul kriterleri (bunları önce test olarak yazın)
1. POST /api/invoices, PDF olmayanları 415 ile ve 20 MB üzerindeki dosyaları
   413 ile reddeder.
2. Güveni < 0.85 olan bir satır kalemi invoice.status = 'review' olarak
   ayarlanır, asla 'approved' olmaz.
3. Her insert, actor_id, action, created_at içeren bir denetim satırı yazar.
4. GET /api/invoices?vendor=&from=&to=&status= bir 10,000-row seed üzerinde
   400ms altında döner.

## Bu geçiş için kapsam dışı
Sipariş eşleştirme, uyuşmazlık arayüzü, CSV dışa aktarma, e-posta bildirimleri.

İnsan versiyonuna kıyasla üç şey değişti: dosya yolları ortaya çıktı, bir dokunulmaz liste ortaya çıktı ve kabul kriterleri cümleler yerine assertion'lar haline geldi. Hangi ajana verdiğiniz insanların düşündüğünden daha az önemli, yine de kodlama ajanları karşılaştırması taahhüt etmeden önce okumaya değer. Gereksinimleri ve proje kurallarını ayrı dosyalarda tutun: Cursor rules ve CLAUDE.md kuralları ve araçları taşır, PRD ise neyin inşa edileceğini taşır. Kapsamı üretirken tüketmek yerine yapay zeka yardımı istiyorsanız, bu farklı bir iş akışı. Ve çıkarım adımının kendisi için model seçimi ve değerlendirme döngüsü kendi başına bir yapay zeka entegrasyonu işidir.

PRD Dışarıdaki Bir Ekibe Gittiğinde Neler Değişir

PRD bir ajansa veya yükleniciye gittiğinde, bir uyum dokümanı olmaktan çıkıp sözleşme diline dönüşür. Şirket içi bir ekibin iki dakikalık bir konuşmayla çözdüğü belirsizlik, fiyatlı bir değişiklik talebine dönüşür. PMI'nin Pulse of the Profession araştırması, başarısız projelerin %47'sinin hatalı gereksinim yönetimi yüzünden hedeflerini kaçırdığını buldu. Bu dokümanın var olmasının tüm nedeni bu.

O ortamda üç bölüm orantısız bir ağırlık taşır. Kabul kriterleri onay kapılarına dönüşür, bu yüzden mühendis olmayan biri tarafından gözlemlenebilir olmaları gerekir. Açık sorular, müşteri tarafında isimlendirilmiş bir sahip gerektirir, çünkü yüklenici bunları yanıtlayamaz ve boşluğun etrafında inşa eder. Ve değişiklik geçmişi bürokratik olmaktan çıkar: ne zaman neyin kabul edildiğinin kaydıdır, bu da bir anlaşmazlık sırasında herkesin ilk başvurduğu şeydir.

Birden fazla kez yanlış gittiğini izlediğimiz satır, "kullanıcılar verilerini dışa aktarabilir" ifadesinin bir versiyonudur. Kimse hangi formatı yazmaz. Bunun bize maliyetli olan versiyonu, müşteri kendi markasıyla biçimlendirilmiş bir PDF fatura paketi kastederken bir CSV dışa aktarma olarak gönderildi ve bunu yeniden yapmak, kimsenin kapsamlamadığı yaklaşık bir haftalık mühendisliği yaktı. Dürüst okuma, hatanın teslimatta değil dokümanda olduğudur. Bir kabul kriteri bunu beş dakikada yakalardı: verilen bir dışa aktarma isteği, ne zaman dosya oluşturulursa, o zaman verilen düzene uyan bir PDF'dir. Bir hedef olmayan satırı da bunu diğer yönden yakalardı. Yani artık keşif sürecimizde bir kural bu: "dışa aktarma", "rapor" veya "bildirim" gibi bir isme dayanan herhangi bir gereksinim, bir iş kapsamı bildirimi imzalanmadan önce bir format, bir tetikleyici ve ekli bir örnek çalışma alır.

Bunun büyük kısmı web uygulaması yapılarını nasıl yürüttüğümüzün tam olarak ne olduğudur: kimse kod yazmadan önce bir müşterinin spesifikasyonunun belirsiz yarısını test edilebilir satırlara dönüştürmek.

r/ProductManagement PRD Şablonları Hakkında Gerçekte Ne Diyor

product requirements document template reddit aramasını yapın ve r/ProductManagement'ta tekrar eden aynı şikayeti bulacaksınız: şablon şişkinliği. Kimsenin okumadığı PRD'ler. Şablonda bir başlık olduğu için doldurulan, kimse içeriğe ihtiyaç duyduğu için değil, bölümler. Kickoff'tan bir gün sonra bayatlayan ve sessizce bir Slack thread'iyle değiştirilen dokümanlar. Bu, bu arama için en iyi on sonuçtan birkaçı dahil çoğu şablon için adil bir eleştiri.

Bizim cevabımız: bölümleri hiçbir şeyle doldurmak yerine silin. Kullanıcılar belirginse personalar ilk sırada gider. Ek ikinci sırada gider. Kilometre taşları tracker'da yaşayabilir. Asla silmediğimiz tek bölüm hedef olmayanlar, çünkü ne kadar çok iş yaparsanız o kadar kısalan tek bölüm o ve aksi halde altıncı haftada yaşayacağınız tartışmayı güvenilir şekilde önleyen tek bölüm de o.

Sıkça Sorulan Sorular

Ürün gereksinimleri dokümanı nedir?

Bir ürün gereksinimleri dokümanı (PRD), bir ekibin neyi ve neden inşa ettiğini belirtir: problem, hedefler ve metrikleri, hedef olmayanlar, kimin için olduğu ve "tamamlandı"yı tanımlayan gereksinimler. Kasıtlı olarak, daha sonra mühendislik tarafından yazılan bir teknik tasarım dokümanına ait olan uygulama detaylarını dışarıda bırakır.

Bir ürün gereksinimleri dokümanı nasıl yazılır?

Problem tanımıyla başlayın ve içinde çözüm dili kullanmayı reddedin. Bir başlangıç noktası ve bir hedef tarihle ölçülebilir hedefler ekleyin, ardından hedef olmayanları yazın. Personaları, Verilen/Ne zaman/O zaman kabul kriterli kullanıcı hikayelerini, fonksiyonel ve fonksiyonel olmayan gereksinimleri, bağımlılıkları, kilometre taşlarını ve sahipli açık soruları doldurun.

Bir PRD neleri içermeli?

On iki bölüm: değişiklik geçmişli başlık, problem tanımı, hedefler ve başarı metrikleri, hedef olmayanlar, kullanıcılar ve personalar, kabul kriterli kullanıcı hikayeleri, fonksiyonel gereksinimler, fonksiyonel olmayan gereksinimler, bağımlılıklar ve entegrasyonlar, kilometre taşları ve fazlandırma, açık sorular ve riskler ve bir ek. Bunlardan birine uymayan her şey muhtemelen bir gereksinim değildir.

Bir PRD ne kadar uzun olmalı?

Tek bir özellik için bir ila iki sayfa, bir ürün fazı için üç ila beş, dışarıdaki bir ekip inşa ediyorsa ve kabul kriterleri onay kapısı görevi görüyorsa beş ila sekiz. Uzunluk, kaydedilen karar sayısını takip eder, ürünün boyutunu değil. Boş bölümler doldurulmamalı, silinmelidir.

PRD ile BRD aynı şey mi?

Hayır. Bir iş gereksinimleri dokümanı (BRD), genellikle bir çözüm seçilmeden önce, kuruluşun istediği ticari sonucu ve etrafındaki kısıtlamaları belirtir. Bir PRD, onu sağlayan ürünü tanımlar: kullanıcılar, davranış, kabul kriterleri, hedef olmayanlar. Daha küçük şirketlerde BRD genellikle yalnızca problem tanımı bölümüdür.

Agile ekipler hâlâ PRD yazıyor mu?

Evet, genellikle tek sayfalık bir sürüm olarak. Backlog işi tutar ama ticketlar nedeni, hedef olmayanları ve başarı metriğini tutmakta berbattır. PRD'yi tamamen atlayan ekipler, projeye üç sprint sonra "context" adında bir Confluence sayfası olarak yeniden keşfetme eğilimindedir.

Bir PRD markdown ile yazılabilir mi?

Markdown, bir PRD için en iyi formattır. Notion, Confluence, Google Docs ve Linear'a temiz şekilde yapıştırılır, kodun yanında Git'te PRD.md olarak versiyonlanır, bir pull request'te düzgün şekilde diff'lenir ve yapısını kaybetmeden okuyan tek format bir yapay zeka kodlama ajanıdır. Yukarıdaki şablon tam da bu nedenlerle markdown.

Bir yapay zeka kodlama ajanı için PRD nasıl yazılır?

Normalde kısa olacağınız yerde açık olun. Hedef olmayanları olumlu ifade edin, çünkü bir ajan kapsamı eksik bilgiden çıkaramaz. Dokümanı tek geçişte bitirilebilir fazlara bölün. Kabul kriterlerini sayılarla assertion olarak yazın. Ajanın düzenleyebileceği dosyaları ve dokunamayacağı dosyaları isimlendirin.

PRD ile teknik tasarım dokümanı arasındaki fark nedir?

PRD neyi ve neden sorularını yanıtlar: problem, kullanıcılar, davranış, kabul kriterleri, hedef olmayanlar. Teknik tasarım dokümanı nasıl sorusunu yanıtlar: mimari, veri modeli, API sözleşmeleri, değerlendirilen ödünleşimler. Genellikle ürün birincisine, mühendislik ikincisine sahiptir ve tasarım dokümanı, PRD'ye bir yanıt olarak okunabilir olmalıdır.

PRD'nin sahibi ürün mü, mühendislik mi, yoksa müşteri mi?

Ürün, dokümanın ve içindeki kararların sahibidir. Mühendislik, fizibilite geri bildirimi ve fonksiyonel olmayan gereksinimlerin sahibidir. Ajans yapılarında müşteri, problem tanımının, hedeflerin ve kendi işleriyle ilgili her açık sorunun sahibidir. Tüm dokümanın paylaşılan sahipliği genellikle kimsenin onu sürdürmediği anlamına gelir.

Son Söz

Alınacak üç şey var. Şablon yalnızca doldurulduğunda faydalıdır, bu yüzden boş olanın şeklini değil, doldurulmuş örneğin şeklini kopyalayın. Hedef olmayanlar, dokümandaki kelime başına en değerli bölümdür ve insanların ilk atladığı bölümdür. Ve test edilebilir assertion'lar olarak yazılan kabul kriterleri iki okuyucuya eşit şekilde hizmet eder: bir teslimatı onaylayan bir mühendis ve bir test yazan bir ajan.

Dışarıdaki bir ekibe teslim edeceğiniz bir PRD yazıyorsanız ve sözleşmeye dönüşmeden önce ikinci bir göz istiyorsanız, onu okuyup belirsiz satırları işaretlemekten memnuniyet duyarız. Bu, kendi web uygulaması yapılarımızda yürüttüğümüz aynı geçiş.