Yapay Zekâyla Ürün Gereksinim Dokümanı Nasıl Yazılır (Ücretsiz Şablon)

Ürün gereksinim dokümanı (PRD), ne inşa ettiğinizi, kimin için olduğunu, neleri yapması gerektiğini ve çalıştığını nasıl anlayacağınızı anlatan kısa ve sade bir metindir. Yapay zekâ bunu yazmayı çok hızlandırır: kaba notlarınızı alır, yapılandırılmış bölümlere, kullanıcı hikâyelerine ve uç durumlara dönüştürür. Sizin işiniz ise yapay zekânın veremeyeceği kararları vermek (hedef, kapsam ve neyin dışarıda bırakılacağı) ve yapay zekânın eklediklerini kontrol etmektir.

Bu rehber bir PRD'de neler olması gerektiğini, herhangi bir yapay zekâ asistanıyla adım adım nasıl taslak hazırlayacağınızı, her bölüm için istemleri ve kopyalayabileceğiniz doldurulabilir bir şablonu anlatır.

PRD ne işe yarar (ve ne değildir)

Bir PRD dört soruya cevap verir:

1. Bunu neden inşa ediyoruz? Hangi sorun, kimin için?
2. İlk sürümde ne yapması gerekiyor?
3. Neyi henüz yapmayacak?
4. Çalıştığını nasıl anlayacağız?

Bu bir teknik tasarım değildir. Hangi veritabanının ya da çatının kullanılacağını söylemez; bu, gerekiyorsa ayrı bir teknik spesifikasyonda yer alır. Pazarlama brifi ya da iş planı da değildir. PRD'yi ürünün davranışına odaklı tutmak, onu herkes için kullanışlı kılar: tasarımcı, geliştirici, onaylayan paydaş ya da kodu yazacak bir yapay zekâ uygulama oluşturucu.

Kimin buna ihtiyacı var

• Tek başına çalışan kurucular, kapsamın şişmesini daha başında durdurmak isteyenler.
• Küçük ekipler, “üzerinde anlaştığımız şey” bilgisinin tek bir yerde durması gerektiğinde.
• Serbest çalışan ya da ajans tutanlar, çünkü net bir PRD daha net teklifler getirir. Bir geliştirici tutmak ya da yapay zekâyla inşa etmek konusuna bakın.
• Yapay zekâyla inşa edenler, çünkü PRD'nin kullanıcı hikâyeleri ve veri listesi, yapılandırılmamış bir istek listesinden daha iyi istemler oluşturur.

Yapay zekâ neyi iyi yapar, neyi yapamaz

En yaygın hata, tablonun ikinci satırından önceki satırın tersine dönmüş halidir: yapay zekâ boşlukları kullanıcılarınız hakkında kulağa makul gelen tahminlerle inandırıcı biçimde doldurur. Kullanıcılar, pazar büyüklüğü ya da davranış hakkında yazdığı her şeyi bir olgu değil, doğrulanması gereken bir soru olarak görün.

Adım 1: Bildiklerinizi dökün

Herhangi bir şey istemeden önce kaba notlar yazın. Madde işaretleri yeterlidir. Şunları kapsayın:

• Sorunu, kullanıcının bakış açısından bir ya da iki cümleyle.
• Kimin yaşadığını. Somut olun: “10–40 müşterisi olan serbest muhasebeciler”, “küçük işletmeler” değil.
• Bugün bunun yerine ne yaptıklarını (bir tablo, e-posta, sevmedikleri bir araç).
• İlk sürümü başarılı kılacak tek sonucu.
• Yapmayacağınızı bildiğiniz şeyleri.
• Sert kısıtları: teslim tarihi, bütçe, telefonlarda çalışması gerektiği, zaten kullandığınız bir araçla entegrasyon.

Sorunu yaşayan kimseyle konuşmadıysanız önce bunu yapın. Bir uygulama fikrini nasıl doğrularsınız rehberinde pratik bir yol var. Tahminlere dayanan bir PRD, iyi biçimlendirilmiş bir tahmindir.

Adım 2: Yapay zekâdan ilk taslağı isteyin

Notlarınızı yapıştırın ve sabit bir yapıda taslak isteyin. İyi çalışan bir istem:

Bir ürün hakkındaki notlarım aşağıda. Bunları tam olarak şu bölümlerle bir ürün gereksinim dokümanına dönüştür: Özet, Sorun, Kullanıcılar, Hedefler ve başarı ölçütleri, Kapsam (içinde / dışında), Kabul kriterleriyle kullanıcı hikâyeleri, Veri, Yetkiler, Uç durumlar, Açık sorular. İki sayfanın altında tut. Kullanıcılar ya da pazar hakkında olgu uydurma; notlarım bir konuda bilgi vermiyorsa, soruyu Açık sorular bölümüne yaz.

Son talimat önemlidir. Yapay zekâya bilmediklerini doldurmak yerine “Açık sorular”a yazmasını söylemek çok daha dürüst bir taslak verir.

Adım 3: Her bölümü sıkılaştırın

Taslağı bölüm bölüm gözden geçirin. Şu takip istemleri yardımcı olur:

Sorun ve kullanıcılar

Sorun ifadesini kullanıcının bakış açısından bir ya da iki cümleyle yeniden yaz. Çözüm kelimeleri olmasın.

Sorun ifadesi ürününüzden söz ediyorsa, bir sorun değil bir çözüm tarif ediyordur.

Hedefler ve başarı ölçütleri

Birinci sürüm için, az sayıda kullanıcıyla ilk ayda ölçebileceğim üç başarı ölçütü öner. Her biri için nasıl ölçeceğimi de yaz.

Bir ya da iki tane seçin. “Yirmi muhasebeci bir ay boyunca haftada bir kullanıyor” ölçülebilir. “Verimliliği artırmak” ölçülemez.

Kapsam

Bu PRD'de, temel akışı bozmadan bir sonraki sürüme ertelenebilecek her şeyi listele.

Yapay zekâ araçları özellik eklemeye meyillidir. Bu istem tam tersini yaptırır. Acımasız olun: çoğu birinci sürüm PRD'si fazla büyüktür. MVP nedir rehberi, küçük ilk sürümlerin neden daha çok şey öğrettiğini anlatır.

Kullanıcı hikâyeleri ve kabul kriterleri

Her gereksinimi bir kullanıcı hikâyesi olarak yaz (“[kullanıcı] olarak, [eylem] yapmak istiyorum, böylece [sonuç]”) ve Verilen / Eğer / O zaman biçiminde iki ila dört kabul kriteri ekle.

Kabul kriterleri, daha sonra test edeceğiniz kontrol listesidir. “Verilen bir rezervasyon için, başka bir müşteri takvimi görüntülediğinde, bu saat dilimi gösterilmez” test edilebilir. “Rezervasyon iyi çalışıyor” test edilemez.

Uç durumlar ve yetkiler

Her kullanıcı hikâyesi için; veri boşken, geçersiz girdide, yavaş ya da başarısız bir ağ isteğinde ve erişim hakkı olmayan bir kullanıcıda ne olduğunu listele.

Yapay zekânın öne çıktığı yer burasıdır. İnsanların unuttuğu boş durumları ve yetki boşluklarını hızla yakalar.

Adım 4: Şüpheci bir gözle inceleyin

Taslağın tamamını bir kez daha okuyun ve şunları kontrol edin:

• Kullanıcılarla ilgili her iddia yapay zekâdan değil, sizden ya da araştırmadan gelmeli.
• Kapsam “dışında” bölümü, “içinde” bölümü kadar, en az o kadar uzun olmalı.
• Her kullanıcı hikâyesinin, size sormadan test edilebilecek kabul kriterleri olmalı.
• Veri bölümü, uygulamanın tuttuğu her kayıt türünü ve kimlerin görebildiğini listelemeli.
• Açık sorulara bir sahip ve bir tarih atanmış olmalı.
• Teknik hiçbir şey gerçek bir kısıt değilse girmemeli (“çevrimdışı çalışmalı” bir gereksinimdir; “Redis kullan” değildir).

Sonra ürünü kullanacak ya da inşa edecek bir kişiyle paylaşın ve neyin belirsiz olduğunu sorun. Soruları, boşluklarınızdır.

Doldurulabilir PRD şablonu

Bunu bir dokümana kopyalayın ve köşeli parantezlerin yerine yazın. Gerçekten uygulanmayan bölümleri silin.

Ürün adı: [ad] Sahip: [kararlardan sorumlu kişi] Durum: [taslak / incelemede / üzerinde anlaşıldı] — Son güncelleme: [tarih]

1. Özet

[İki ya da üç cümle: bu nedir, kimin için ve ana sonuç ne.]

2. Sorun

[Sorun, kullanıcının bakış açısından. Bugün ne yaptıkları ve neden zorluk çektikleri.]

3. Kullanıcılar

4. Hedefler ve başarı ölçütleri

• Hedef: [birinci sürümün ulaşması gereken sonuç]
• Ölçüt: [nasıl ölçeceğiniz ve hedef değer]
• Hedef olmayan: [insanların varsayabileceği, bu sürümün yapmaya çalışmadığı bir şey]

5. Kapsam

Birinci sürümde:

• [özellik]
• [özellik]

Birinci sürümde değil:

• [özellik ve neden bekleyebilir]
• [özellik ve neden bekleyebilir]

6. Kullanıcı hikâyeleri

Hikâye 1: [kullanıcı] olarak, [eylem] yapmak istiyorum, böylece [sonuç].

• Verilen [bağlam], eğer [eylem], o zaman [sonuç].
• Verilen [bağlam], eğer [eylem], o zaman [sonuç].

Hikâye 2: [kullanıcı] olarak, [eylem] yapmak istiyorum, böylece [sonuç].

• Verilen [bağlam], eğer [eylem], o zaman [sonuç].

7. Veri

8. Yetkiler

[Kimin giriş yapabileceği, hangi rollerin olduğu ve her rolün neyi görüp değiştirebileceği.]

9. Uç durumlar

• [Boş durum: henüz veri yokken ne gösterilir]
• [Geçersiz girdi: yanlış e-posta ya da eksik alanda ne olur]
• [Erişim: görmemesi gereken bir sayfayı açan birine ne olur]

10. Entegrasyonlar ve kısıtlar

[Ödemeler, e-posta, mevcut araçlar, teslim tarihi, bütçe, çalışması gereken cihazlar.]

11. Açık sorular

PRD'den istemlere

İyi bir PRD, bir yapay zekâ uygulama oluşturucu için neredeyse doğrudan istemlere dönüşür:

• Özet, kullanıcılar ve veri tablosu ilk isteminiz olur.
• Her kullanıcı hikâyesi bir takip isteminiz olur.
• Her kabul kriteri, önizlemede kontrol ettiğiniz bir şey olur.
• “Birinci sürümde değil” listesi, henüz istemeyeceğiniz şeylerdir.

PRD'nin tamamını yapıştırıp her şeyi birden istemek yerine, bir hikâyeyi bir seferde inşa edip ilerlemeden kabul kriterlerini kontrol etmek çok daha güvenilirdir. Yapay zekâ uygulama oluşturucular için istem yazma rehberi istem tarafını daha ayrıntılı anlatır.

Sık yapılan hatalar

• Çözümü sorun gibi yazmak. “Kullanıcıların bir panele ihtiyacı var” bir çözümdür. “Sahipler, her faturayı tek tek açmadan hangilerinin vadesi geçmiş olduğunu göremiyor” bir sorundur.
• “Kapsam dışı” bölümünün olmaması. Bu bölüm olmadan her konuşma kapsamı yeniden açar.
• Yapay zekânın kullanıcı uydurmasına izin vermek. Yapay zekânın uydurduğu kişilikler gerçek gibi görünür ama değildir.
• Ölçemediğiniz ölçütler. Sayamıyorsanız, ölçüt değildir.
• Hiç güncellememek. Inşa ettiğinizle artık uyuşmayan bir PRD, hiç olmamasından daha kötüdür. “Son güncelleme” tarihi tutun ve kararlar değiştiğinde değiştirin.

PRD'yi Mythex ile kullanmak

Mythex ile inşa ediyorsanız, PRD'nizi doğrudan sohbete yapıştırabilirsiniz. Plan modunda başlamak PRD için iyi bir seçimdir: ajan metni okur, bir yaklaşım ve bir adım listesi önerir; bunu bir plan sekmesinde gözden geçirirsiniz ve Build'e basana kadar dosyalarda değişiklik yapmaz. Hedef kitle, marka ve kurallar gibi her zaman geçerli olması gerekenleri proje bilgisi olarak da kaydedebilirsiniz; böylece her sohbette tekrar yazmazsınız. Sohbet dokümanları Build, Plan ve Ask modlarını anlatır. Şablonlar ise tüm dokümanı yazmadan önce ilk sürümün nasıl görünebileceğine hızlıca bakmanın bir yoludur.

Sorular