PRD Yazımı: Eksiksiz 10 Adımlı Kılavuz + Yapay Zekâ Yazma İstemleri

Ürün gereksinimleri belgeleri (veya PRD'ler) ürün ekipleri için neden bu kadar önemli araçlardır? Çünkü ürününüzün gelecekteki durumunu ne kadar net hayal edebiliyor olursanız olun, hiçbir iki paydaş bunu aynı şekilde anlamayacaktır.

Yeni bir ürünün veya özelliğin kritik unsurlarını ne kadar etkisiz bir şekilde ilettiklerini çok geç olana kadar fark etmeyen ürün yöneticilerinin anlattığı milyonlarca korku hikâyesi olduğuna eminim. 

Ürün Gereksinimleri Belgesinin (PRD) bu kadar önemli olmasının nedeni budur. Başarının nasıl görünmesi gerektiği konusunda herkesin aynı noktada buluşmasını sağlamak için ayrıntılı ve sistematik bir yaklaşım kullanır.

Bu kılavuzda, net hedefler, gereksinimler ve iyi düşünülmüş bir eylem planıyla harika bir PRD oluşturmanıza yardımcı olacağız. Ayrıca, değerli zamanınızdan tasarruf etmenize yardımcı olmak için PRD'nin çoğunu sizin için oluşturacak (veya en azından size güçlü bir ilk taslak sunacak!) bir dizi LLM istemimiz de var.

Ürün Gereksinimleri Belgesi (PRD) Nedir?

Basitçe ifade etmek gerekirse, bir ürün gereksinimleri belgesi belirli bir ürün sürümünde bulunması gereken özellikleri ve işlevleri ayrıntılı olarak açıklar. Belirli bir ürünün tasarlanması ve geliştirilmesiyle ilgilenen tüm ekipler için temel bir başvuru noktasıdır. Ayrıca ürün yol haritasının oluşturulması için de gereklidir.

Geleneksel olarak, ürün geliştirme sürecinin ardışık olduğu Şelale metodolojisi proje ortamında kullanılsa da Çevik ürün yönetiminde de kullanılabilir.

PRD'de yakalanan bilgilerden başka çeşitli belgeler de oluşturulabilir. Mühendislik ekibi, ürün özelliklerini ve sistem gereksinimlerini ayrıntılı olarak açıklayan bir Teknik Gereksinimler Belgesi oluşturabilir.

İş analistleri, bir kullanıcının sistemle etkileşime girdiğinde neler olduğunu ayrıntılı olarak açıklayan ve ürün tasarımını göstermek için tel kafesler içeren bir İşlevsel Gereksinimler Belgesi oluşturabilir. 

Kullanıcı deneyimi (UX) tasarımcıları, ürünün nasıl görünmesi ve hissettirmesi gerektiğini açıklayan bir Kullanıcı Arayüzü Gereksinimleri Belgesi oluşturabilir.

PRD Yazmanın Faydaları Nelerdir ve PRD Neleri İçerir?

Kapsamlı bir PRD yazmaya zaman ayırmanın çeşitli faydaları vardır. Bunlardan birkaçına göz atalım:

1. Tüm paydaşların aynı noktada buluşmasını sağlar.
2. Kapsam dışında kalanları netleştirir
3. Ekipler arasındaki iş birliğini teşvik eder
4. Müşteri bakış açısını ürünün merkezine yerleştirir

Yapı açısından tipik bir PRD aşağıdakileri içermelidir:

• Düzenleme tarihi, sürüm geçmişi vb. belge meta verileri.
• Gerçekleştirmek istediğiniz ürün hedefleri.
• Hedef personalar gibi müşteri araştırması verileri.
• Geliştirmek istediğiniz özelliklerin önceliklendirilmiş listesi.
• Geliştirmeyeceğiniz özelliklerin negatif kapsamı.
• Bu hipotezleri test etmek için temel metrikler.
• Özelliklerinizin test ettiği temel hipotezler.
• Özelliğin ne zaman ve nasıl kullanıma sunulacağını gösteren yayınlama stratejisi.

Çoğu PRD bu unsurları içerse de ihtiyaçlarınıza ve ürününüzün gerçek durumuna göre unsurlar eklemeniz veya çıkarmanız tamamen uygundur.

Ürün Gereksinimleri Belgesine Örnek Nedir?

Bazen bir belgeye nelerin dahil edilmesi gerektiğini görsel kullanarak anlamak daha kolaydır; bu nedenle aşağıda tamamlanmış bir PRD örneği yer alıyor.

Ürün Gereksinimleri Belgesi Nasıl Yazılır? (LLM'lerden Biraz Yardım Alarak)

Paylaştığımız tüm bilgilere rağmen ilk PRD'nizi hazırlamak gözünüzü korkutabilir. Endişelenmeyin; size yardımcı oluyoruz! İşte gereksinim toplamada yapay zekâ kullanmak ve sağlam bir PRD oluşturmak için 10 adımlık kontrol listemiz. Ayrıca doğru bilgilerin tamamını toplamanıza yardımcı olacak bir şablon da ekledik.

1. Adım: Problemi netleştirin

Başka herhangi bir şey yapmadan önce çözmeye çalıştığınız problemi ve bunu çözmeye çalıştığınız kullanıcı personalarını netleştirmeniz çok önemlidir. Bu, ürüne tam olarak hangi işlevleri dahil edeceğinizi ve sürüm için hangi özelliklere öncelik vereceğinizi etkiler. 

İş Gereksinimleri Belgesi, karşılaşılan problemi ve ürünün bu problemi çözmek için nasıl davranması gerektiğini ayrıntılandıran bir ihtiyaç beyanı içermelidir. PRD'yi hazırlamadan önce İGB'yi gözden geçirmek ve işletmenin üründen tam olarak neye ihtiyaç duyduğunu netleştirmek önemlidir.

2. Adım: Pazar ve kullanıcı araştırmasını gözden geçirin

PRD'yi yazdığınız sırada pazar araştırmanızın ve personalarınızın hazır olması gerekir. Ancak bazen belirli bir özelliğe yönelik persona, sahip olduğunuz genel personadan farklı olabilir. Durum sizin için de böyleyse bu LLM istemini kullanarak bir persona açıklaması oluşturalım:

Kullanıcılarımla gerçekleştirdiğim çeşitli ürün keşfi görüşmelerinin dökümlerini burada bulabilirsiniz.

{dökümlerinizi bu mesaja txt dosyaları olarak yükleyin}

Lütfen bu dökümleri inceleyin, aralarındaki ortak özellikleri analiz edin ve aşağıdaki yapıyı izleyerek bir persona açıklaması oluşturun (XML etiketleriyle sınırlandırılmıştır):


<USER_PERSONA_STRUCTURE>

1. Adı:

(Gerçekçi ancak kurgusal, örneğin: Yoğun Muhasebeci Anna)

2. Demografik Bilgiler:

t•tYaş
t•tCinsiyet (isteğe bağlı)
t•tKonum
t•tMeslek

3. Hedefler:
t•tUlaşmak istedikleri birincil hedef(ler)
t•tİkincil veya ilişkili hedefler

4. Zorluklar/Sorunlar:
t•tKarşılaştıkları başlıca engeller
t•tHayal kırıklıkları veya ihtiyaçlar

5. Davranışlar:
t•tİlgili alışkanlıklar, tercihler ve kullanım biçimleri

6. Tercih Edilen Araçlar/Platformlar:
t•tSıklıkla kullandıkları uygulamalar, web siteleri ve cihazlar

7. Kısa Bir Alıntı (İsteğe Bağlı Ancak Etkili):

İhtiyaçları hakkında nasıl hissettiklerini yansıtan tek bir cümle.

(Örnek: “Yalnızca manuel işlem gerektirmeden bana zaman kazandıran bir sistem istiyorum.”)

</USER_PERSONA_STRUCTURE>


Örnek:

Adı: Yoğun Muhasebeci Anna

Demografik Bilgiler: 34 yaşında, Chicago'da yaşıyor, küçük bir firmada mali müşavir

Hedefler: Müşteri işlerini daha hızlı tamamlamak, manuel idari görevleri en aza indirmek

Zorluklar: Çok fazla evrak işi, kullanışsız yazılım, zaman baskısı

Davranışlar: Vergi döneminde geç saatlere kadar çalışıyor, basit ve mobil erişilebilir uygulamaları tercih ediyor

Tercih Edilen Araçlar: QuickBooks, Slack, Google Drive

Alıntı: “Basit değilse, bunun için zamanım yok.”


Persona oluşturma gereksinimleri:

- Lütfen yalnızca dökümlerde sağlanan bilgileri kullanın ve orada bulunmayan bilgileri uydurmayın.

- Yalnızca sizinle paylaştığım dökümlerin en az %80'inde bulunan özellikleri kullanın.

- Belirli bir persona veri unsuru için yeterli bilgi bulamazsanız bu alanı boş bırakın.

Sonuç olarak, ürün gereksinimleri dokümanınıza ekleyebileceğiniz bir persona açıklaması elde edeceksiniz. Ancak LLM tarafından oluşturulan içerikte hatalar olabileceğinden lütfen içeriği tekrar kontrol edin.

3. Adım: İşlevsel paydaşları sürece dahil edin

Daha önce de belirttiğimiz gibi, en iyi PRD'ler iş birliği içinde hazırlanır. Gereksinimler dokümanınıza katkı sağlamak amacıyla işletmenin farklı alanlarından görüş almak için işlevler arası bir toplantı düzenleyin. 

Bu, paydaşların varsayımları belirtmesi, riskler veya kısıtlarla ilgili endişelerini dile getirmesi ve ürün geliştirme sürecini etkileyebilecek bağımlılıkları not etmesi için harika bir fırsattır. 

4. Adım: Temel hipotezinizi ve ürün metriklerinizi tanımlayın

Geliştirdiğiniz özellik ne olursa olsun, bunun kullanıcılarınız veya şirketiniz üzerinde bir tür etkisi olmasını beklersiniz. Bu etkiyi ölçebilmek ve özelliğinizin başarılı olup olmadığını görebilmek için öncelikle test edilebilir bir hipotez tanımlamanız gerekir.

En sevdiğim hipotez formatına Eğer-o zaman-çünkü adı verilir. Şu şekilde görünür:

[A özelliğini geliştirirsek], [B temel metriğinin], [nedenini açıklayın] nedeniyle [C miktarı kadar artacağı/azalacağına] inanıyoruz.

Örneğin, Spotify üzerinde çalışıyor olsaydım, bu şu şekilde görünebilirdi.

Sabah rutinlerine yönelik çalma listeleri geliştirirsek günlük kullanıcı tutma oranının %5 artacağına inanıyoruz; çünkü daha fazla kişi Spotify'ı her gün sabahları kullanacak.

Bu süreci yapay zekâ ile otomatikleştirmek için özelliğin neyi başarmasını beklediğinizi kendi kelimelerinizle açıklayın ve yapay zekâdan bunu Eğer-o zaman-çünkü formatında oluşturmasını isteyin. Kullanabileceğiniz istem aşağıdadır:

{özellik açıklamanızı buraya ekleyin}

Lütfen eğer-o zaman-çünkü formatını kullanarak bir hipotez oluşturun.

Gereksinimler:

- Hipotez 100 kelimeden uzun olmamalıdır.

- Lütfen yalnızca sağladığım bağlamı kullanın.

Hipotez hazır olduğunda, bu özellik için ölçmek istediğiniz ürün metriklerini de tanımlamanız gerekir.

Açıkça, hipotezinizin hedeflediği metriği ölçmek istersiniz (Spotify örneğinde kullanıcı tutma oranı). Ancak her özellik için ihtiyaç duyduğunuz 3 temel metrik daha vardır:

• Benimseme
• Kullanıcı tutma
• Etkileşim

Bu metrikleri ölçmek için analiz aracınızın tetiklemesi gereken olaylarla birlikte doğru metriği seçme konusunda yapay zekâdan yardım isteyebilirsiniz. Bunun için kullanabileceğiniz bir istem aşağıdadır.

{özellik açıklamanızı buraya ekleyin}

Hipotez aşağıdadır:

{önceki istemden elde ettiğiniz hipotezi buraya ekleyin}

Lütfen izlenecek metrikleri ve bunlarla birlikte olay tetikleyicilerini önerin. Lütfen şu kategorilerde metrikler önerin:

- Benimseme

- Kullanıcı tutma

- Etkileşim

Bu metrikleri, açıkladığım özellik için Ürün Gereksinimleri Dokümanına ekleyeceğimi lütfen göz önünde bulundurun.

Spotify örneğimizde metrikler aşağıdaki gibi olurdu:

Benimseme: Sabah çalma listesini başlatan kullanıcıların yüzdesi. Olay tetikleyicisi, kullanıcının çalma listesini başlattığı andır.

Kullanıcı tutma: Sabah çalma listesini 7, 14 ve 30 gün boyunca kullanmaya devam eden kullanıcıların yüzdesi. Olay tetikleyicisi, kullanıcının çalma listesini başlattığı andır.

Etkileşim: Kullanıcıların çalma listesini dinlediği ortalama dakika sayısı. Olay tetikleyicileri, çalma listesini başlatmak ve durdurmaktır.

5. Adım: Tasarımlarınızı hazırlayın

Özellik gerektiriyorsa tasarım olmadan hiçbir PRD tamamlanmış sayılmaz. Bazı ekipler son tasarımları ekler; bazıları ise yalnızca üst düzey kavramları veya bir prototipi dahil etmeyi, ayrıntıları daha sonra ekiple birlikte netleştirmeyi tercih eder.

Her iki yaklaşımın da avantajları ve dezavantajları vardır. Son tasarımlar netlik sağlar ancak PRD'nin teslimini yavaşlatır. Erken aşamadaki kavramlar devir sürecini hızlandırır ancak yanlış yorumlama ve yeniden çalışma riski taşır.

En uygun nokta nedir? Boş veya hata durumları gibi ikincil unsurları atlayarak temel kullanıcı yolculuğunu ve önemli durumları kapsayan tasarımları paylaşmak. Neyse ki modern UX tasarım araçları aynı anda hem prototip hem de tasarım oluşturmanıza olanak tanır.

Böylece belirsizlik riskini en aza indirirken tasarımınızı ve PRD'nizi ekibinize daha erken ulaştırabilirsiniz.

6. Adım: Fikrinizi Bağımsız Özelliklere Ayırın

Deneyimli PM'lere büyük bir özelliği daha küçük, yönetilebilir kullanıcı hikâyelerine ayırmanın faydalarını anlatmam gerektiğini düşünmüyorum. Ürün yönetiminde yeniyseniz, işte bunlardan birkaçı:

• Küçük hikâyeleri ekibiniz için tahmin etmek daha kolaydır.
• Ekip aynı anda tek bir hikâyeye odaklanıp bunları zahmetsizce tamamlayabildiği için teslim edilmeleri daha kolaydır.
• Ekibiniz bir sonraki hikâyeyi geliştirirken QA'larınız tek bir hikâyeyi test edebileceğinden test edilmeleri daha hızlıdır; böylece test uzmanlarının ve geliştiricilerin çalışmaları paralel yürütülür.
• Teslimatı hızlandırmak için daha az önemli olanları kapsamdan çıkarma esnekliği sağlarlar.

Özelliği parçalara ayırmak harikadır, ancak bu savaşın yalnızca yarısıdır. İkinci yarı ise bunlara öncelik vermektir. Tüm hikâyeler eşit yaratılmamıştır. Özelliğinizin bazı bölümleri temel yolculuğu oluştururken diğerleri olmazsa olmaz olmayan eklemelerdir. Spotify örneğimizde, MoSCoW önceliklendirme yöntemini kullanarak önemli ve önemli olmayan hikâyelerin listesi şöyle görünecektir.

Buradaki listeye baktığınızda, kullanıcıların sabah çalma listesini görmesi ve tek dokunuşla erişebilmesi özelliğinin, çalma listesini düzenleyebilme özelliğinden çok daha önemli olduğu açıkça görülür.

Dolayısıyla zaman kısıtlamasıyla karşılaşırsanız ve hızlıca yayın yapmanız gerekirse düzenleme kullanıcı hikâyesini sürümünüzden çıkarıp gelecekteki sürümlere taşıyabilirsiniz.

Bazı kişiler bu listeyi bir elektronik tabloda oluşturur. Ancak yerleşik önceliklendirme ve entegrasyon özellikleriyle birlikte geldiği için özel bir ürün yol haritası aracı kullanmanızı öneririm.

7. Adım: Sürüm Stratejisini Tanımlayın

Gerçek hayattaki sürümler nadiren basittir; tüm özelliği tamamlayıp üretim ortamına göndermekten ibaret değildir. Çoğu zaman, kendi PRD'sine sahip olacak kadar büyük bir özelliğin sürümü, potansiyel olarak aşağıdakileri içerebilen çok aşamalı bir süreçtir:

• Yalnızca mutlaka olması gereken hikâyeleri içeren MVP sürümünü geliştirmek ve beta sürümü yayınlamak.
• Geri bildirim toplamak, sorunları düzeltmek, olması gereken hikâyeleri eklemek ve üretim sürümüne hazırlanmak.
• Üretim ortamına birden fazla aşamada kademeli olarak sürüm çıkarmak.
• Bunlara ihtiyaç olduğunu görürseniz olabilecek özellikleri eklemek.

Sürüm stratejisi oluşturma sürecini hızlandırmak için bu istemi kullanarak LLM'nizden yardım isteyebilirsiniz.

{özellik açıklamanızı buraya ekleyin} oluşturmak istiyorum.

İşte bu özellik için MoSCoW kullanılarak önceliklendirilmiş kullanıcı hikâyelerinin listesi:

{önceki adımdaki özellik listesini buraya ekleyin}

Lütfen bunun için bir sürüm stratejisi oluşturun. Strateji şunları içermelidir:

- Yukarıdaki listedeki özellikleri, MVP sürümü de dâhil olmak üzere birden fazla sürümde gruplandırın.

- Gerekli olduğunu düşünüyorsanız bir beta sürümü aşaması ekleyin

- Gerekli olduğunu düşünüyorsanız, zaman çizelgelerini, aşamalarda kullanıma sunulacak kullanıcı yüzdelerini ve her kullanıma sunma aşamasına dâhil edilecek kullanıcı türlerinin açıklamasını da içeren, 2 veya daha fazla aşamalı kademeli bir kullanıma sunma planı oluşturun.

Beta Sürümünün gerekli olup olmadığına karar verme kriterleri (XML etiketleriyle sınırlandırılmış CSV biçiminde):

<BETA_RELEASE_CRITERIA>

Kriter,Beta Sürümü,Doğrudan Üretim Sürümü

Kullanıcı Riski,Orta ila yüksek – belirsiz kullanıcı etkisi veya olası gerilemeler,Düşük – özellik iyi test edilmiş ve kullanıcılar için düşük riskli

Özellik Olgunluğu,MVP veya deneysel; yeterince iyileştirilmemiş ya da eksiksiz olmayan kullanıcı deneyimine sahip olabilir,Tamamen geliştirilmiş ve kararlı

Geri Bildirim İhtiyacı,Yüksek – yönü veya kullanıcı deneyimi seçimlerini doğrulamak için erken kullanıcı geri bildirimi kritik öneme sahip,Düşük – özelliğin değeri ve kullanılabilirliği konusunda güven mevcut

Kalite Güvencesi Güveni,Orta – kurum içi kalite güvencesini tamamlamak için gerçek dünya testlerine ihtiyaç var,Yüksek – kurum içinde kapsamlı olarak test edilmiş

İş Etkisi Belirsizliği,Temel performans göstergelerini (elde tutma, dönüşüm vb.) etkileyip etkilemeyeceği belirsiz,Önceki doğrulamalarla desteklenen olumlu veya nötr bir etki bekleniyor

</BETA_RELEASE_CRITERIA>

Kademeli Sürümün gerekli olup olmadığına karar verme kriterleri (XML etiketleriyle sınırlandırılmış CSV biçiminde):

<GRADUAL_RELEASE_CRITERIA>

Kriter,Kademeli Sürüm,Tam ve Anında Sürüm

Kullanıcı Riski,Yüksek – özellik geniş ölçekte kullanıma sunulursa gerilemelere, hatalara veya kafa karışıklığına neden olabilir,Düşük – beklenmeyen sorunlar oluşsa bile kullanıcıların yaşayacağı kesinti en düşük düzeyde

Sistem Yükü Riski,Yüksek – özellik sunucu veya arka uç yükünü artırabilir; ölçeklenme davranışı bilinmiyor,Düşük – performans beklenen en yüksek yük koşullarında doğrulanmış

Değişiklik Kapsamı,Büyük – kritik yollara, temel kullanıcı deneyimi akışlarına veya arka uç mantığına dokunuyor,Küçük – kendi içinde sınırlı, isteğe bağlı veya kapsamı dar

İzleme Hazırlığı,Küçük kullanıcı gruplarındaki sorunları tespit etmek için ölçümler, uyarılar ve günlükler hazır,Temel değil – sessiz hatalar veya tespit edilmesi zor gerilemeler riski düşük

Geri Alma Karmaşıklığı,Yüksek – tamamen yayımlandıktan sonra geri alınması zor (ör. şema geçişleri, veri değişiklikleri),Düşük – bir şeyler bozulursa devre dışı bırakılması veya düzeltilmesi kolay

</GRADUAL_RELEASE_CRITERIA>

Büyük olasılıkla, LLM'nin size verdiği zaman çizelgeleri gerçekçi olmayacaktır. Bu nedenle bunları ekibinizin kapasitesine ve ürün hedeflerinize göre değiştirmekten çekinmeyin.

8. Adım: Ürün Gereksinimleri Belgesini (PRD) taslağa dökün

Önceki adımda toplanan bilgileri kullanarak artık PRD'yi taslak hâline getirebilirsiniz.

Yine zamandan kazanmak için seçtiğimiz LLM'den bunu bizim için şu istemi kullanarak yapmasını isteyeceğiz.

Lütfen bu yapıyı kullanarak bir Ürün Gereksinimleri Belgesi oluşturun (XML etiketleriyle sınırlandırılmıştır):


<PRD_STRUCTURE>

1. Amaç

    - Vizyon
    - Hedefler
    - Persona(lar)

2. Özellikler (aşağıdaki sütunlara sahip tablo)

    - Kullanıcı hikâyesi kısa adı
    - Kullanıcı hikâyesi kısa açıklaması
    - Kullanıcı hikâyesi önceliği

3. Kullanıcı Akışı ve Tasarım

    - Buraya "lütfen kullanıcı yolculuğunuzu ve tasarım bağlantılarınızı buraya ekleyin" yer tutucu metnini bırakın

4. Sürüm Stratejisi

    - Kapsamlarıyla birlikte sürüm aşamaları. Aşağıdaki sürüm bağlamında bir beta sürümü sağladıysam beta sürümünü dâhil edin
    - Aşağıdaki sürüm bağlamında bir kademeli kullanıma sunma stratejisi sağladıysam bunu dâhil edin. Kademeli kullanıma sunma uygunsa aşamalarda kullanıma sunulacak kullanıcı yüzdelerini ve her kullanıma sunma aşamasına dâhil edilecek kullanıcı türlerinin açıklamasını da ekleyin.

5. Analiz

    - Temel hipotezler
(aşağıdaki sütunları içeren tablo)
    - Ölçüm
    - Hedef değişim
    - Olay tetikleyicisi

</PRD_STRUCTURE>


PRD'yi oluşturmak için şu bağlam parçalarını kullanın (XML etiketleriyle sınırlandırılmıştır):

<USER_PERSONAS>

{persona açıklamasını buraya ekleyin}

</USER_PERSONAS>


<CORE_HYPOTHESIS>

{önceki adımlardaki temel hipotezi kopyalayıp buraya yapıştırın}

</CORE_HYPOTHESIS>


<KEY_METRICS>

{önceki adımlardaki temel ölçüm listesini kopyalayıp buraya yapıştırın}

</KEY_METRICS>


<USER_STORIES>

{önceki adımlardaki kullanıcı hikâyesi listesini kopyalayıp buraya yapıştırın}

</USER_STORIES>


<RELEASE_STRATEGY>

{önceki adımlardaki sürüm stratejisini kopyalayıp buraya yapıştırın}

</RELEASE_STRATEGY>

Geriye kalan tek şey PRD içeriğini hızlıca gözden geçirmek. Özellikle vizyona ve hedeflere dikkat edin; çünkü LLM bunları özellik açıklamalarınıza dayanarak oluşturmaya çalışacaktır. Beğenmezseniz düzenlemekten çekinmeyin.

9. Adım: Onay alın

PRD tamamlandığında müşteri tarafından onaylandığından emin olun. Bu bir iç projeyse proje sponsoru veya üst düzey yönetim ekibi onay verebilir. Bu, iş hedefleriyle uyumu ve ürün geliştirme sürecine verilen desteği güvence altına almaya yardımcı olur. 

Sürüm kriterlerinin kabul edilmesi büyük önem taşır; böylece geliştirme sürecinin sonunda ürünün işlevsellik, kullanılabilirlik ve performans açısından tam olarak neler yapabileceği konusunda yanlış anlaşılmalar yaşanmaz.

10. Adım: Paylaşın ve iletişim kurun

PRD onaylandıktan sonra PRD'nin nerede saklanacağını paylaşın ve ürün geliştirme süreci boyunca PRD'ye erişme, PRD'yi görüntüleme ve değiştirme sürecini açıklayın. 

Son hâline getirilmiş PRD proje boyunca başvuru noktası olarak kullanılmalı ve gereksinimler değişirse gerçek zamanlı olarak güncellenebilmelidir. Bununla birlikte, başlangıçta ne üzerinde anlaşmaya varıldığını belirlemenin her zaman bir yolu olmalı; yapılan tüm değişiklikler iyi belgelenmeli ve değişiklik gerekçesiyle birlikte sunulmalıdır.

Ürün gereksinimleri belgeleri için en iyi uygulamalar

Umarız bir PRD'nin neleri içermesi gerektiğini netleştirmişizdir; şimdi gelin, onu oluşturmak için bazı en iyi uygulamaları inceleyelim.

• Paydaşlardan görüş alın. En iyi PRD'ler, tüm kilit paydaşların katkısıyla oluşturulur. Mühendislerin daha sonra kritik işlevlerden oluşan uzun bir listenin desteklenebilir olmadığını açıklaması için böyle bir liste oluşturmanın anlamı yoktur. Diğer ekipleri sürece erken dâhil etmek netlik sağlar ve varsayımların, kısıtlamaların ve bağımlılıkların belirlenmesine olanak tanır.
• Modern araçlardan yararlanın. Şanslıyız ki PRD oluşturma ve yönetimi konusunda bize yardımcı olan, yazılım odaklı birçok dokümantasyon aracı var. Örneğin Notion, varsayımlarınızı veya özelliklerinizi listeleyebileceğiniz zengin biçimlendirme seçeneklerine sahip tablolarla birlikte kullanabileceğiniz hazır PRD şablonları içerir. Öte yandan Confluence, yerel Jira ve BitBucket entegrasyonuyla birlikte gelir; bu sayede görevleri ve sürümleri belgeye gömebilirsiniz.

• Gerektikçe yineleyin. PRD, sürekli güncellenen bir belge olarak tasarlanmıştır. Değişen müşteri veya pazar gereksinimleri, ürün yeteneklerinin artırılmasını, önceliklerinin yeniden belirlenmesini veya tamamen kaldırılmasını gerektirebilir. Pazara ilk giren konumunu güvence altına almak için zaman çizelgesinin kısaltılması ya da bir varsayım gerçekleşmediğinde uzatılması gerekebilir.

• Sürüm denetimi kullanın. PRD'nin gerektiğinde gözden geçirilmesi ve değiştirilmesi önemli olsa da ürün yöneticisinin başlangıçta üzerinde anlaşmaya varılanları her zaman görebilmesi kritik önem taşır. Sürüm denetimi kullanmak ve uygun erişim düzeylerini sağlamak; geçmişte üzerinde anlaşmaya varılanların, yapılan değişikliklerin ve bunların nedenlerinin her zaman kayıtlı olmasını sağlar.

• Görünür tutun. PRD, proje planlama toplantısından sonra masa çekmecesine atılan, bir kez hazırlanıp tamamlanan bir belge değildir; proje yönetimi için kritik bir varlıktır. Daha önce ele aldığımız gibi PRD'niz, ürün üzerinde çalışan tüm ekip üyeleri için bir başvuru noktası görevi görür; bu nedenle görünür tutulması hayati önem taşır. 

Ürün Gereksinimleri Belgesi Şablonu

Bu bölümü tamamlamak için, bugün ilk ürün gereksinimleri belgenizi hazırlamaya başlarken kullanabileceğiniz bir PRD şablonunu burada bulabilirsiniz. 

Netlik sağlamak için gerektiğinde bölümler ekleyip çıkararak şablonu projenizin ihtiyaçlarına uyacak şekilde özelleştirdiğinizden emin olun.

Ürün Gereksinimleri Belgesi Şablonu

Ürün Gereksinimleriniz Hakkında Bugün Netlik Kazanın

Yukarıdaki bilgileri dikkatle incelediyseniz, etkili bir Ürün Gereksinimleri Belgesi oluşturma yolunda oldukça ilerlemişsiniz demektir.

Başlangıçta biraz zaman alabilse de sağladığı faydalar gösterdiğiniz çabaya değer ve örnek şablonumuz bir sonraki harika ürününüzü planlayıp geliştirmenize yardımcı olabilir.

Biz de sizin gibi ürün alanında çalışan kişilerden oluşan bir topluluğuz! Bu bilgileri faydalı bulduysanız bültenimize abone olun. Sizi faydalı makaleler, nasıl yapılır rehberleri, araç incelemeleri ve daha fazlasıyla güncel tutacağız.