Modern ürün ekipleri hızlı hareket eder - ve buna uygun PRD’lere ihtiyaç duyar. Trupeer ile ücretsiz bir lean PRD şablonuyla başlayarak ürün spesifikasyonu yazma sürecinde saatler kazanabilir, bunu marka yönergeleriniz ile özelleştirebilir ve lean PRD’leri, çapraz fonksiyonlu ekipleri hızla aynı hizaya getiren video anlatımlara dönüştürebilirsiniz.

Lean PRD nedir ve bir PRD’den farkı nedir?

Ürün gereksinimleri dokümanı; neyin, kimin için inşa edildiğini ve “tamamlandı” sayılması için neyin doğru olması gerektiğini ortaya koyar. Lean PRD de aynı işi, on sayfa yerine bir veya iki sayfada yapar; çünkü ekip, detaylara güvenle girilebilecek kadar sorunun içindedir.

Genellikle yapılan açıklama, lean PRD’nin daha kısa olduğudur. Bu tanımın kendisi değil, belirtisidir; peşinden koşmak ise kötü bir doküman üretir. Çünkü bir PRD’yi, önemli olan parçaları keserek kısaltabileceğiniz gibi önemli olmayan parçaları keserek de kısaltabilirsiniz.

İşlevsel tanım ise yetkiyle ilgilidir. PRD, bir ekibe getirilen kısıtlar bütünüdür. Lean PRD ise doğru sonucu hâlâ veren en küçük kısıt sayısını koyar ve ekibin nerede karar verdiğini açıkça belirtir. Kısadır; çünkü geleneksel bir PRD’yi dolduran çoğu şey, kimsenin fikrinin olmadığı bir spesifikasyon olarak ortaya çıkar.

Bir PRD, ekipten aldığınız kararların listesidir

Bir PRD’deki herhangi bir gereksinimi okuyun ve bunun ne yaptığını sorun. Her biri, inşa ederken aksi halde o kararı verecek kişiden bir seçeneği kaldırır.

Bazı kaldırmalar gereklidir. Dosyalar işlenmek için yirmi dakika sürüyorsa ve kapalı bir dizüstü bilgisayarda bile ithalatın hayatta kalması gerekiyorsa, ekip bunu bilmelidir ve bu onların kararı değildir.

Çoğu ise değildir. Haritalama ekranında sütun sırası, bir hata mesajının ifadesi, doğrulamanın yüklemeden önce mi sonra mı çalışacağı: PRD’lerde bunlar yer alır; çünkü şablonda bunlar için bir bölüm vardır ve boş bir bölüm “özensizlik” gibi görünür. Her biri ya ekibin sorgusuz sualsiz uyacağı bir kısıttır; bu durumda ürünü daha da kötüleştirmiş olabilirsiniz, ya da ekibin pazarlık ederek içinden çıkacağı bir kısıttır; bu da günler sürer.

Bu yüzden bir lean PRD, içine girmeden önce her satırdan tek bir soru sorar. Ekip bu iki seçenekten hangisini seçse, ben de aynı derecede memnun olur muydum? Evetse, yazmayın. Bunun onların kararı olduğunu yazın. Bu soru dokümanı kısaltan şeydir; kısalık ise hedef değil, yan üründür.

Bu şablon Trupeer’da nasıl özelleştirilir

Adım 1: Şablonlar bölümünü açın

Ana navigasyondan Şablonlar bölümüne gidin.

Adım 2: Bir şablon seçin ve açın

Açmak istediğiniz herhangi bir şablonun üzerine tıklayın.

Adım 3: Şablon görünümünü genişletin

Gerekirse, tam düzeni ve ayrıntıları net görmek için şablon görünümünü genişletin.

Adım 4: Şablonu düzenleyin

Seçili şablonda değişiklik yapmaya başlamak için Düzenle’ye tıklayın.

Düzenleyici içinde şunları yapabilirsiniz:

• Yeni bölümler ekleyin

• Biçimlendirme kurallarını tanımlayın veya güncelleyin

• Bir logo ekleyin ve konumunu ile ilgili ayarları düzenleyin

Adım 5: Özelleştirilmiş şablonunuzu kaydedin

Gerekli tüm değişiklikleri yaptıktan sonra, güncellenmiş şablonu kendi şablonunuz olarak saklamak için Kaydet’e tıklayın.

Adım 6: Önizleyin ve şablonu ince ayar yapın

Özelleştirilmiş şablonunuzun nasıl göründüğünü görmek istediğinizde Önizleme’yi açın.

Önizleme ekranından, gerekirse doğrudan ayarlamaya devam edebilir; böylece şablonun tam olarak istediğiniz gibi göründüğünden emin olursunuz.

Lean PRD şablonuyla şunları yapabilirsiniz:

• Yazmaya saatler kazanın: Odaklı tek sayfalık lean bir yapı ile 20 sayfalık formatı atlayın.

• Ekipleri daha hızlı hizalayın: Dahili problem ve hipotez bölümleri ürün netliğini zorunlu kılar.

• Markanızla uyumlu kalın: Trupeer’ın marka kitini kullanarak logonuzu, yazı tiplerinizi ve renklerinizi uygulayın.

• Hızlı iterasyon yapın: Spesifikasyon geliştikçe PRD’yi güncelleyin ve videoyu yeniden oluşturun.

• Ekipler arasında standardize edin: Her ürün girişimi için aynı şablonu kullanın.

• Küresel ürün ekiplerine ulaşın: Lean PRD’leri tek tıklamayla 65+ dile çevirin.

Her gereksinimi “kısıtlı” ya da “ekip kararı” olarak etiketleme nasıl yapılır

Her satırda iki etiket, istisna yok.

Kısıtlı. Böyle olmak zorunda ve bunun nedeni şu. Neden isteğe bağlı değildir ve kısıtın ayakta kalmasını sağlayan kısım da burasıdır. Nedeni olan bir kısıt, koşullar değiştiğinde akıllıca sorgulanabilir. Nedensiz bir kısıt ise üç yıl sonra kimsenin dokunmaya cesaret edemediği bir “efsane”ye dönüşür.

Ekip kararı. Sonucu anlattım. Oraya nasıl gideceğiniz sizin. Benim fikrimi istiyorsanız sorun ve bunu bir görüş olarak değerlendirin.

Oran size bir şey söyler. İlk taslaklar ağır biçimde kısıtlı gelir ve her satıra bir neden eklemek, çoğunun çöktüğü yerdir; çünkü dürüst neden çoğu zaman şablonda zaten var olmasıdır.

İki kural etiketleri dürüst tutar. “Ürünün geri kalanıyla tutarlılık” ile gerekçelendirilen bir kısıt, tutarlı olduğu spesifik şeyi adlandırmalıdır. Ve “ekip kararı” satırı bir vaattir: İnşa sırasında birini geçersiz kılarsanız dokümanı bozmuş olursunuz; bu yüzden bir sonraki inanılmaz.

Delege etmeyi güvenli kılan kabul satırı

Ancak “nasıl”ı devredebilirsiniz; “ne” konusunda tam olarak net olduysanız. Bu bir takas ve kabul satırı bunun bedelini ödediğiniz yerdir.

Tek bir cümle: Bu yayınlandığında doğru olacak şeyi, şu an doğru olmayan şekilde tanımlayın. Öyle yazın ki siz de bir mühendis de, bunun gerçekleşip gerçekleşmediği konusunda bağımsız olarak aynı fikirde olabilsin. İş hedefi olan bir metrik hedef değil; başka yerde olması gereken bir iş sonucu. Yazmaya çalışmadığınız şey olan bir özellik listesi de değil.

İyi: Bir müşteri, en fazla elli bin satırlık bir dosyayı yükleyebilir, tarayıcısını kapatabilir ve döndüğünde ithalatın doğru şekilde tamamlandığını görebilir.

Kötü: Toplu ithalat deneyimini iyileştirin.

Kabul satırı en üste, bağlamın ve gereksinimlerin önüne gider. Eğer bunu yazamıyorsanız dokümanı yazmaya hazır değilsiniz; dürüst bir sonraki adım taslak değil, bir görüşmedir.

Ücretsiz lean PRD şablonu: kopyalanacak bir buçuk sayfa

Buradan kopyalayın.

Kabul satırı. Yukarıdaki gibi tek bir cümle.

Şimdi neden. İki veya üç cümle. Bu çeyrekte bunu yapmaya değer kılan şey nedir; gelecek yıl değil. Bu bölüm kesilir ve kesilmemelidir; çünkü ekip, yüzlerce küçük takası hiç görmeyeceğiniz şekilde yapmak için bunu kullanır.

Bu kime yönelik. Kullanıcının en dar gerçek tanımı ve kabaca kaç kişi olduğu. Buradaki bir sayı, aşırı mühendislik yapılmasının önüne ciddi ölçüde geçer.

Kısıtlı gereksinimler. Numaralı. Her biri tek bir cümle ve bir neden. On beşin altında tutmayı hedefleyin. Otuzunuz varsa, çoğu gizlice ekip kararıdır.

Ekip kararı. Bilerek belirtmediğiniz alanları adlandıran kısa bir liste. Bunları adlandırmak önemlidir; çünkü belirtilmeyen bir alan, delege edilmiş bir karar gibi değil, bir gözden kaçma gibi okunur.

İnşa etmiyoruz. Kapsam dışı olduğu için istenmiş olan, tartışmalı olacak kadar net şekilde adlandırılmış şeyler. Kimsenin itiraz etmediği bir “inşa etmiyoruz” listesi hiçbir iş yapmıyor demektir.

Açık sorular. Her birinin yanında bir isim ve bir tarih. Sahibi olmayan sorular yanıtsız kalır; ta ki engelleyici hale gelene kadar.

Nasıl bileceğiz. Yayından sonra ve ne zaman bakacağınız ölçüm. Bir veya iki tane; bir gösterge paneli değil.

Buraya kopyalayın. Doldurulmuş sürüm iki sayfayı aşarsa önce kısıtlı listeye bakın. Dolgu her zaman oradadır.

Toplu ithalat özelliği için doldurulmuş bir lean PRD örneği

Kabul satırı. Bir müşteri yöneticisi, bir CSV’den en fazla elli bin müşteri kaydını içe aktarabilir; ithalat sırasında tarayıcısını kapatabilir ve döndüğünde bunun doğru şekilde tamamlandığını görebilir.

Şimdi neden. Beş en büyük hesabımızın üçü bu çeyrekte bir rakipten geçiş yapıyor ve her birinin on iki ile kırk bin arasında kaydı var. Bugün ya beş yüzlük gruplar halinde yapıştırıyorlar ya da bize bir dosya gönderiyorlar ve biz bunu manuel olarak yapıyoruz; bu da geçen ay destek ekibimizin on bir gün sürmesine neden oldu.

Bu kime yönelik. Onboarding sırasında hesap yöneticileri; çeyrekte yaklaşık kırk tanesi ve çoğu bunu tam olarak bir kez yapacak.

Kısıtlı gereksinimler.

1. İthalat, tarayıcı kapanmasına rağmen hayatta kalmalı; çünkü bu boyuttaki dosyalar yirmi dakika veya daha uzun sürer ve dizüstü bilgisayarlar uykuya geçer.

2. Doğrulama başarısız olan satırlar, doğrulaması geçen satırları engellememeli; çünkü tek bir hatalı satır şu anda bir müşterinin tüm çalışmasını boşa çıkarıyor.

3. Müşteri, başarısız satırlardan oluşan bir dosyayı, neden eklenmiş şekilde indirebilmelidir; çünkü onları bizim yardımımız olmadan nasıl düzeltecekleri budur.

4. Çift kayıt tespiti e-posta adresi üzerinden çalışmalı; ürünün geri kalanının bir müşteriyi nasıl tanımladığıyla aynı şekilde.

5. Eşlemesi yapılmış ilk on satırın ekranda önizlemesi olmadan hiçbir ithalat başlamamalıdır; çünkü en yaygın destek talebi, sonradan fark edilen yanlış eşleştirilmiş bir sütundur.

Ekip kararı. Haritalama ekranı düzeni, hata mesajı ifadeleri, ilerleme göstergesi, doğrulamanın nerede çalıştığı, elli bin satırın üzerindeki dosya boyutu üst sınırı, ithalatlar arasında eşlemelerin hatırlanıp hatırlanmadığı.

İnşa etmiyoruz. Planlı veya tekrarlayan ithalatlar. Salesforce veya HubSpot’tan doğrudan içe aktarma. İthalat sırasında kayıtları düzenleme. Üçü de istenmiş ve üçü de ayrı iş parçaları.

Açık sorular. Müşterinin oturumu sona erdiğinde devam eden bir ithalata ne olur, sahip Priya, 14 Mart’a kadar.

Nasıl bileceğiz. Destek tarafından yönetilen manuel ithalatlar, çeyreğin sonunda ayda birin altına düşer.

Beş kısıtlı gereksinim, altı alan açıkça delege edildi. Bu bir sayfa eder.

Üç yerine beş sprint süren PRD

Halbrook, yaklaşık doksan kişilik bir B2B yazılım şirketi, yukarıdaki özelliği geliştirdi. İlk deneme standart şablonlarını kullandı ve kırk bir numaralı gereksinimle dokuz sayfaya ulaştı.

Haritalama ekranındaki sütun sırasını, altı hata mesajının ifadesini, on megabayt dosya tavanını, doğrulamanın istemci tarafında çalışması gerektiğini, modal düzenini ve ilerleme çubuğunun bir yüzde göstermesi gerektiğini belirtiyordu.

Üç sprint olarak tahmin edildi. Beş sürdü.

Retrospektif farkı izledi. Kırk bir gereksinimin altısı, inşa sırasında yeniden müzakere edildi; her biri, ekip farklı şekilde uygulamak için iyi bir gerekçeye sahip olduğu için, arada gidip gelmelerde yarım gün ile üç gün arasında maliyet çıkardı.

İstemci tarafı doğrulama, bunların en kötüsüydü. Ekip, birkaç bin satırın üzeri için sunucu tarafı işlemenin gerekli olduğunu biliyordu ve bunu ilk sprintte gündeme getirdi. Dokümanın değişmesi dokuz gün sürdü; çünkü PM izindeydi ve imzalı bir PRD’de numaralı bir gereksinimi geçersiz kılacak kimse kendini yetkin hissetmedi.

Sonrasında sorulduğunda PM, bu altı gereksinimden beşinde hiçbir fikri olmadığını söyledi. Oradaydılar; çünkü şablon bir kullanıcı arayüzü bölümü içeriyordu ve boş bırakmak özensiz gibi gelmişti.

Önem verdiği gereksinim, yani ithalatın tarayıcı kapanmasına rağmen hayatta kalması, listenin otuz dördüncü sırasında yer alıyordu ve “olsa iyi olur” olarak okunmuştu. Bunun olmadan yayınlandı; iki ay sonra, yaklaşık bir sprintlik ek maliyetle eklendi.

Sonraki özellik bu sayfadaki formatı kullandı. Bir buçuk sayfa; her biri bir neden içeren on bir kısıtlı gereksinim, ekip kararı olarak işaretlenmiş altı alan, bir kabul satırı. Üç sprint olarak tahmin edildi ve üçte teslim edildi; hiçbir gereksinim yeniden müzakere edilmedi.

Yine de bir tasarım kararı ona geri döndü: Ekip tarafından ekip kararı olarak işaretlenmiş bir şey olduğu ortaya çıktı ve bu, kabul satırını etkiliyordu. Formatın üretmeye çalıştığı görüşme tam olarak bu.

Bir saatten kısa sürede lean PRD nasıl yazılır

Önce kabul satırını yazın ve saatinizin orantısız bir kısmını ona ayırın. Aşağısı, var olduğunda çok daha kolay olur ve gelmeyecekse bu bir bilgidir.

Ardından “inşa etmiyoruz” listesini ikinci sırada yazın; insanlar ne istiyor hâlâ aklınızdayken. Şeyin şeklini benimsedikten sonra sonradan yazmak çok daha zordur.

Sonra on dakika boyunca, etiketlemeden aklınıza gelen her gereksinimi listeleyin. Giderken filtrelemeyin.

Şimdi onları etiketleyin. Her biri için, neden böyle olması gerektiğini yazın. Nedeni “genelde böyle yaparız” çıkarsa veya hiç gelmezse, ekip kararı tarafına geçer. Bu adım genellikle listeyi ikiye böler.

Şimdi neden ve bu kime yönelik kısmını, zaten bildiklerinizden yola çıkarak yazın. Her biri iki dakika.

Son olarak kısıtlı listeyi bir mühendis gibi okuyun. “Neden?” diye soracağınız ama dokümanın yanıt vermediği her yerde ya nedeni ekleyin ya da satırı kaldırın.

Lean PRD şablonu kullanırken yapılan yaygın hatalar

Son iki tanesinin açılması değerlidir. İşin bir düzenleyici tarafından yönetildiği, bir güvenlik gerekçesi (safety case), teslimatları belirtilmiş bir müşteri sözleşmesi ya da erişilebilirlik veya veri koruma yükümlülüğü söz konusu olduğunda, lean PRD yanlış araçtır. Bunların tam bir spesifikasyona, yükümlülüğe izlenebilirliğe ve bunun için hesap verecek olan herkesin incelemesine ihtiyacı vardır. “Nasıl”ı devretmek, “nasıl”ın denetime konu olan şey olduğu durumda tam olarak yapamayacağınız şeydir.

PRD, BRD, spesifikasyon ve kullanıcı hikâyesinden nasıl farklıdır?

İş gereksinimleri dokümanı PRD’nin üstündedir. Bir iş problemini ve bir çözümün ticari olarak neyi başarması gerektiğini açıklar; genellikle kimse ne inşa edileceğine karar vermeden önce. Bir iş gereksinimleri dokümanı örneği arıyorsanız, bu farklı bir çıktıdır ve farklı bir aşamaya aittir.

Teknik spesifikasyon ise bunun altındadır. Neyin nasıl inşa edileceğini anlatır ve mühendislik tarafından, onlar için değil onlardan bağımsız olarak yazılır. Lean PRD, bu alanın çoğunu bilerek boş bırakır; ekip kararı etiketi de tam olarak bunu yapar.

Kullanıcı hikâyesi ise hepsinden küçüktür. Tek bir hikâye, bir iş dilimidir. PRD ise birçok hikâyeyi içerecek bir iş gövdesini kapsar ve kabul satırı, bu hikâyelerin toplu olarak neye ulaşması gerektiğini özetler.

Kuruluşların elinde tuttuğu bir ürün spesifikasyonu dokümanı, neyin inşa edilmesi gerektiğinden çok, neyin inşa edildiğine dair bir açıklamaya daha yakındır. Yayından sonra da sürdürülür; PRD ise sürdürülmez.

Confluence, Notion ve Google Docs’ta lean PRD şablonları

Confluence en yaygın yerdir ve standart PRD şablonu; hedefler, arka plan, varsayımlar, kullanıcı hikâyeleri, gereksinimler ve açık sorular için bölümler içerir. Bunu yukarıdaki yapı ile değiştirmek gayet iyi çalışır ve durum ile sahip için sayfa özelliklerini korumaya değer.

Notion, kısıtlı gereksinimleri bir veritabanı olarak istiyorsanız daha uygundur; çünkü etiket bir özellik haline gelir ve çeyrek genelindeki oran, saymadan görülebilir.

Google Docs, tartışılacak bir doküman için en hızlısıdır; çünkü tartışma yorumlarda gerçekleşir. Zayıf tarafı şudur: Tartışma daha sonra kimsenin okumadığı çözümlenmiş yorumlarda yaşar. Bu yüzden, bir yorum dizisinde değişen herhangi bir kararı, o diziyi çözmeden önce gereksinimin nedenine yazın.

Hangisini kullanırsanız kullanın, formatın önemi, etiketlerin bir inceleme toplantısından sağ çıkıp çıkmamasından çok daha azdır.

Word, Excel veya PDF’de lean PRD şablonu alabilir miyim?

Word veya Google Docs, dokümanın kendisi için uygundur ve yukarıdaki yapı herhangi bir ayar gerektirmeden doğrudan yapıştırılır. PRD’nin içinde bir liste bulunan bir metin (prose) olduğu için, bunun yaşaması gereken yer burasıdır.

Excel, tek bir PRD’den ziyade özellikler genelindeki gereksinimler kaydı için uygundur. Özellik, gereksinim, kısıtlı veya ekip kararı, neden ve inşa sırasında yeniden müzakere edilip edilmediği. Son sütun, gördüğüm tek PRD metriğidir; insanların davranışını değiştiren de odur.

PDF, bir karara eklenen veya şirket dışıyla paylaşılan sürüm için uygundur. Açık sorular bölümü yerinde yanıtlanmak üzere tasarlandığı için, çalışma sürümünü düzenlenebilir tutun.

Lean PRD için AI PRD oluşturucular kullanmaya değer mi?

Yargıdan ziyade hatırlama gerektiren kısımlar için gerçekten faydalıdır. İyi bir tanesini, özelliğin açıklamasıyla besleyin; unutmuş olabileceğiniz bölümlerle birlikte yapılandırılmış bir taslak üretir ve bu makul bir başlangıç noktasıdır.

Yapamadıkları şey etiketlemedir; çünkü soru şudur: iki tarafta da aynı derecede memnun olur muydunuz ve bunu yalnızca siz bilirsiniz. Tek başına bırakılırsa bir oluşturucu, eğitim verisinin gördüğü şey bu olduğu için kendinden emin şekilde belirtilmiş bir doküman üretir; bu sayfanın tam olarak anlattığı hatanın ta kendisidir.

Pratik kullanım, uzun sürümü üretip ardından etiket sorusuyla kesmektir. Boşluktan yazmaktan daha hızlıdır ve yargıyı ait olduğu yerde tutar.

PRD’nin, teslim edilenle bağlantılı kalması nasıl sağlanır

PRD, iş başladığı gün okunmayı bırakır ve sonrasında asla güncellenmez; bu sorun değil. Sorun olan, kabul satırının ekip dışındaki kimseye ulaşmamasıdır.

Buna ihtiyaç duyanlar destek ekibidir; biletleri onlar alır. Değişenleri bilmesi gerekenler ise müşterilerdir. İkisi de genellikle tek satırlık bir değişiklik kaydı alır; ama sprint maliyeti olan “yeniden başlatılabilir ithalat” detayını ikisi de almaz.

Trupeer AI bu boşluğu düşük maliyetle kapatır. Bunu kim yaptıysa bitmiş özelliği bir kez kaydeder; siz de yazılı bir anlatım, sürüm notu için bir video ve kendi markanızla bilgi tabanınız için bir doküman elde edersiniz. Müşteriye dönük sürüm için yapılandırmalar, bilgi tabanı makalesi şablonlarımız içinde yer alır.

Kaydedin. Markalayın. Çevirin. Trupeer’layın.

Gerçekte neyin inşa edildiğine dair dahili kayıt için teknik dokümantasyon bunu kapsar ve kurulum talimatları doküman şablonu kurulum kılavuzunda bulunur.

Sık Sorulan Sorular

Word’de ücretsiz bir lean PRD şablonu var mı?

Yukarıdaki yapı doğrudan Word veya Google Docs’a yapıştırılır ve yeniden biçimlendirme gerektirmez. Şablonla aranızda bir form olmadığı için “erişim kapılı” bir indirme de yoktur. Doldurulmuş sürümü ekip ev formatınız olarak saklayın; çünkü değer, bölümlerin kendisinden değil, her PRD’nin aynı görünmesinden gelir.

PDF’de ücretsiz bir lean PRD şablonu var mı?

Doküman ekip dışına paylaşılıyorsa veya bir karar kaydına ekleniyorsa, kendi dışa aktarımınızı alın. Açık sorular hâlâ açıkken düzenlenebilir tutun; çünkü sorular yanıtlanmadan dondurulan bir PRD, izlenmekten çok görmezden gelme eğilimindedir.

Excel’de ücretsiz bir lean PRD şablonu var mı?

Excel, tek bir PRD’den ziyade özellikler genelindeki gereksinimler kaydı içindir. Özellik, gereksinim, kısıtlı veya ekip kararı, neden ve inşa sırasında yeniden müzakere edilip edilmediği. Son sütunu çeyreklik olarak gözden geçirmek, hangi PM’lerin fazla spesifikasyon yazdığını bulmanın en hızlı yoludur.

Google Docs için bir PRD şablonu var mı?

Yukarıdaki yapıyı bir Google Doc’a kopyalayın ve ekip sürücünüzde şablon olarak kaydedin. Bu doküman özelinde Google Docs iyi bir seçimdir; çünkü tartışma yorumlarda olur. Ancak bir yorum dizisinde alınan kararlar, o dizisi çözülmeden önce gereksinimin nedenine yazılmalıdır.

En iyi PRD şablonu hangisi?

Retrospektif sırasında değil, mühendisleriniz başlamadan önce okuyan şablon. Yapı, gereksinimlerin neden taşıyıp taşımadığı ve dokümanın ekibin nerede karar verdiğini söyleyip söylemediğinden çok daha az önemlidir. Neden gerekçesi olmayan on bölümlü bir şablon, ne kadar eksiksiz görünürse görünsün, kimsenin güvenmediği dokümanlar üretir.

PDF’de bir iş gereksinimleri dokümanı örneğini nerede bulabilirim?

BRD, daha erken bir aşamada farklı bir dokümandır; bir iş problemini ve bir çözümün neyi başarması gerektiğini anlatır ve genellikle ürün kararı verilmeden önce. BRD’ye ihtiyacınız varken PRD aramak yaygındır ve PRD, inşa kararının zaten alındığını varsaydığı için hayal kırıklığı üretir.

Lean PRD ne kadar uzun olmalı?

On beşten az kısıtlı gereksinimle bir ila iki sayfa. Daha uzun olması genellikle spesifikasyonun geri sızdığı anlamına gelir ve test, her kısıtlı satıra bir neden eklemektir. Bunun içinden kalan gerçek dokümandır.

Lean PRD’yi kim yazmalı?

Kabul satırı, sonuçtan hesap verecek kişiyle mutabık kalınarak; kısıtlı liste ise dolaşıma çıkmadan önce kıdemli bir mühendis tarafından gözden geçirilerek, ürün yöneticisi tarafından yazılmalıdır. Bu inceleme, gereksiz kısıtların çoğunun yakalandığı yerdir ve yaklaşık yirmi dakika sürer.