Näin kirjoitat tuotevaatimusmäärittelyn tekoälyllä (ilmainen mallipohja)

Tuotevaatimusmäärittely (PRD) on lyhyt, selkeää kieltä käyttävä kuvaus siitä, mitä rakennat, kenelle se on tarkoitettu, mitä sen pitää tehdä ja miten tiedät sen toimivan. Tekoäly nopeuttaa kirjoittamista huomattavasti: annat sille karkeat muistiinpanot, ja se muuttaa ne jäsennellyiksi osioiksi, käyttäjätarinoiksi ja reunatapauksiksi. Sinun tehtäväsi on antaa päätökset, joita tekoäly ei voi tehdä — tavoite, laajuus ja se, mitä jätetään pois — ja tarkistaa, mitä se lisäsi.

Tämä opas kertoo, mitä PRD:hen kuuluu, miten laadit sen askel askeleelta millä tahansa tekoälyavustajalla, kehotteet jokaiselle osiolle ja kopioitavan täytettävän mallipohjan.

Mihin PRD:tä tarvitaan (ja mitä se ei ole)

PRD vastaa neljään kysymykseen:

1. Miksi tätä rakennetaan? Mikä ongelma, kenelle?
2. Mitä sen pitää tehdä ensimmäisessä versiossa?
3. Mitä se ei vielä tee?
4. Miten tiedämme, että se toimii?

Se ei ole tekninen suunnitelma. Se ei kerro, mitä tietokantaa tai kehystä käytetään — se kuuluu erilliseen tekniseen speksiin, jos sellaista edes tarvitaan. Se ei myöskään ole markkinointisuunnitelma tai liiketoimintasuunnitelma. Kun PRD pysyy tuotteen toiminnassa, se on hyödyllinen kaikille lukijoille: suunnittelijalle, kehittäjälle, hyväksyjälle tai tekoälysovelluskehittäjälle, joka muuttaa sen koodiksi.

Kenelle se kuuluu

• Yksinyrittäjille, jotka haluavat estää laajuuden paisumisen jo alussa.
• Pienille tiimeille, joille tarvitaan yksi paikka, jossa sovittu asia lukee.
• Kaikille, jotka palkkaavat freelancerin tai toimiston, koska selkeä PRD saa selkeämmät tarjoukset. Katso palkkaa kehittäjä tai rakenna tekoälyllä.
• Kaikille, jotka rakentavat tekoälyllä, koska PRD:n käyttäjätarinat ja tietolista ovat parempia kehotteita kuin jäsentämätön toivelista.

Missä tekoäly on hyvä — ja missä ei

Yleisin virhe on toisen viimeisen rivin kääntöpuoli: tekoäly täyttää aukkoja varmasti kuulostavilla arvauksilla käyttäjistäsi. Käsittele kaikkea, mitä se kirjoittaa käyttäjistä, markkinakoosta tai käyttäytymisestä, kysymyksenä, jota pitää tarkistaa, ei tosiasiana.

Vaihe 1: Kirjaa se, mitä tiedät

Ennen kuin kysyt tekoälyltä mitään, kirjoita karkeat muistiinpanot. Luettelomerkit riittävät. Kirjaa:

• Ongelma yhdellä tai kahdella lauseella käyttäjän näkökulmasta.
• Kenellä se on. Ole tarkka: „vapaaehtoiset kirjanpitäjät, joilla on 10–40 asiakasta”, ei „pienyritykset”.
• Mitä he tekevät nyt sen sijaan (taulukko, sähköposti, työkalu, josta he eivät pidä).
• Se yksi tulos, joka tekisi ensimmäisestä versiosta onnistuneen.
• Kaikki, mitä tiedät jo jättäväsi tekemättä.
• Kovat rajoitteet: määräaika, budjetti, pitää toimia puhelimella, pitää liittyä työkaluun, jota jo käytät.

Jos et ole puhunut kenellekään, jolla on tämä ongelma, tee se ensin. Näin validoit sovellusidean kertoo käytännön tavan tehdä se. PRD, joka perustuu arvauksiin, on hyvin muotoiltu arvaus.

Vaihe 2: Pyydä tekoälyltä ensimmäinen luonnos

Liitä muistiinpanosi ja pyydä luonnos kiinteässä rakenteessa. Toimiva kehote on esimerkiksi:

Tässä ovat muistiinpanoni tuotteesta. Muuta ne tuotevaatimusmäärittelyksi täsmälleen näillä osioilla: Yhteenveto, Ongelma, Käyttäjät, Tavoitteet ja onnistumismittarit, Laajuus (sisään / ulkopuolella), Käyttäjätarinat hyväksymiskriteereineen, Data, Oikeudet, Reunatapaukset, Avoimet kysymykset. Pidä se alle kahdessa sivussa. Älä keksi faktoja käyttäjistä tai markkinasta — jos muistiinpanoni eivät kerro jotakin, kirjoita kysymys osioon Avoimet kysymykset.

Viimeinen ohje on tärkeä. Kun pyydät tekoälyä siirtämään tuntemattomat asiat osioon „Avoimet kysymykset” sen sijaan, että täyttäisi ne, luonnos on paljon rehellisempi.

Vaihe 3: Tarkenna jokainen osio

Käy luonnos läpi osio kerrallaan. Nämä jatkokehotteet auttavat:

Ongelma ja käyttäjät

Kirjoita ongelmakuvaus uudelleen yhdellä tai kahdella lauseella käyttäjän näkökulmasta. Ei ratkaisusanoja.

Jos ongelmakuvaus mainitsee tuotteesi, se kuvaa ratkaisua, ei ongelmaa.

Tavoitteet ja onnistumismittarit

Ehdota kolmea onnistumismittaria ensimmäiselle versiolle, joita voin mitata ensimmäisen kuukauden aikana pienellä käyttäjämäärällä. Kerro kullekin, miten mittaisin sen.

Valitse yksi tai kaksi. „Kaksikymmentä kirjanpitäjää käyttää sitä viikoittain kuukauden ajan” on mitattavissa. „Tuottavuuden parantaminen” ei ole.

Laajuus

Listaa kaikki tässä PRD:ssä, minkä voisi siirtää myöhempään versioon rikkomatta ydinkulkua.

Tekoälytyökalut yleensä lisäävät ominaisuuksia. Tämä kehote saa ne tekemään päinvastoin. Ole armoton: useimmat ensimmäisen version PRD:t ovat liian isoja. Mikä on MVP selittää, miksi pienet ensimmäiset versiot opettavat enemmän.

Käyttäjätarinat ja hyväksymiskriteerit

Kirjoita jokainen vaatimus käyttäjätarinana („Käyttäjänä haluan [toiminto], jotta [tulos]”) kahden–neljän hyväksymiskriteerin kanssa Annettuna / Kun / Niin -muodossa.

Hyväksymiskriteerit ovat tarkistuslista, jota vasten testaat myöhemmin. „Annettuna varattu aika, kun toinen asiakas katsoo kalenteria, niin aikaa ei näytetä” on testattavissa. „Varaus toimii hyvin” ei ole.

Reunatapaukset ja oikeudet

Listaa jokaiselle käyttäjätarinalle, mitä tapahtuu tyhjällä datalla, virheellisellä syötteellä, hitaalla tai epäonnistuneella verkkopyynnöllä ja käyttäjällä, jolla ei pitäisi olla pääsyä.

Tässä tekoäly tuo lisäarvoa. Se löytää nopeasti tyhjät tilat ja oikeusaukot, jotka ihmiseltä unohtuvat.

Vaihe 4: Tarkista kuin skeptikko

Lue koko teksti vielä kerran ja tarkista:

• Jokainen väite käyttäjistä tuli sinulta tai tutkimuksesta, ei tekoälyltä.
• Laajuuden „ulkopuolella” -osio on vähintään yhtä pitkä kuin „sisällä” -osio.
• Jokaisella käyttäjätarinalla on hyväksymiskriteerit, joita joku voi testata kysymättä sinulta.
• Datan osio listaa jokaisen tietuetyypin, jonka sovellus tallentaa, ja kuka sen näkee.
• Avoimilla kysymyksillä on vastuuhenkilö ja päivämäärä.
• Mikään tekninen asia ei ole hiipinyt mukaan, ellei se ole todellinen rajoite („pitää toimia offline” on vaatimus; „käytä Redisiä” ei ole).

Jaa sitten teksti yhdelle ihmiselle, joka käyttää tai rakentaa tuotteen, ja kysy, mikä on epäselvää. Heidän kysymyksensä ovat aukot.

Täytettävä PRD-mallipohja

Kopioi tämä asiakirjaan ja korvaa hakasulut. Poista osiot, jotka eivät todella koske sinua.

Tuotteen nimi: [nimi] Vastuuhenkilö: [henkilö, joka päättää asioista] Tila: [luonnos / arvioitavana / sovittu] — Viimeksi päivitetty: [päivämäärä]

1. Yhteenveto

[Kaksi tai kolme lausetta: mitä tämä on, kenelle ja pääasiallinen tulos.]

2. Ongelma

[Ongelma käyttäjän näkökulmasta. Mitä he tekevät nyt ja miksi se on kipeää.]

3. Käyttäjät

4. Tavoitteet ja onnistumismittarit

• Tavoite: [tulos, jonka ensimmäisen version pitää saavuttaa]
• Mittari: [miten mittaat sen ja tavoitearvo]
• Ei-tavoite: [jotain, mitä ihmiset voisivat olettaa, mutta mitä tämä versio ei yritä tehdä]

5. Laajuus

Ensimmäisessä versiossa:

• [ominaisuus]
• [ominaisuus]

Ei ensimmäisessä versiossa:

• [ominaisuus, ja miksi se voi odottaa]
• [ominaisuus, ja miksi se voi odottaa]

6. Käyttäjätarinat

Tarina 1: Käyttäjänä haluan [toiminto], jotta [tulos].

• Annettuna [tilanne], kun [toiminto], niin [tulos].
• Annettuna [tilanne], kun [toiminto], niin [tulos].

Tarina 2: Käyttäjänä haluan [toiminto], jotta [tulos].

• Annettuna [tilanne], kun [toiminto], niin [tulos].

7. Data

8. Oikeudet

[Kuka voi kirjautua, mitä rooleja on ja mitä kukin rooli voi nähdä ja muuttaa.]

9. Reunatapaukset

• [Tyhjä tila: mitä näytetään, kun dataa ei vielä ole]
• [Virheellinen syöte: mitä tapahtuu väärällä sähköpostilla tai puuttuvalla kentällä]
• [Pääsy: mitä tapahtuu, kun joku avaa sivun, jota ei pitäisi nähdä]

10. Integraatiot ja rajoitteet

[Maksut, sähköposti, nykyiset työkalut, määräajat, budjetti, laitteet, joilla sen pitää toimia.]

11. Avoimet kysymykset

PRD:stä kehotteisiin

Hyvä PRD muuttuu lähes suoraan kehotteiksi tekoälysovelluskehittäjälle:

• Yhteenveto, käyttäjät ja tietotaulukko muodostavat ensimmäisen kehotteesi.
• Jokainen käyttäjätarina on yksi jatkokehote.
• Jokainen hyväksymiskriteeri on jotakin, minkä testaat esikatselussa.
• „Ei ensimmäisessä versiossa” -lista on se, mitä et vielä pyydä.

Yksi tarina kerrallaan rakentaminen ja hyväksymiskriteerien tarkistaminen ennen seuraavaan siirtymistä on paljon luotettavampaa kuin koko PRD:n liittäminen ja kaiken pyytäminen kerralla. Näin kirjoitat kehotteita tekoälysovelluskehittäjille käsittelee kehotteiden kirjoittamista tarkemmin.

Yleisimmät virheet

• Ratkaisun kirjoittaminen ongelmaksi. „Käyttäjät tarvitsevat kojelaudan” on ratkaisu. „Omistajat eivät näe, mitkä laskut ovat myöhässä, avaamatta jokaista erikseen” on ongelma.
• Ei „laajuuden ulkopuolella” -osiota. Ilman sitä jokainen keskustelu avaa laajuuden uudelleen.
• Tekoälyn keksimät käyttäjät. Tekoälyn luomat persoonat tuntuvat todellisilta, mutta eivät ole.
• Mittarit, joita et voi mitata. Jos sitä ei voi laskea, se ei ole mittari.
• Ei koskaan päivitetä. PRD, joka ei enää vastaa rakennettavaa tuotetta, on huonompi kuin ei mitään. Pidä „viimeksi päivitetty” -päivämäärä ajan tasalla ja muuta sitä, kun päätökset muuttuvat.

PRD:n käyttö Mythexissä

Jos rakennat Mythexissä, voit liittää PRD:n suoraan chattiin. Suunnittelu-tila sopii PRD:lle hyvin: agentti lukee sen, ehdottaa lähestymistavan ja vaiheluettelon, jonka voit tarkistaa suunnitelmavälilehdellä, ja alkaa muuttaa tiedostoja vasta, kun painat Rakenna. Voit myös tallentaa osat, jotka pitää aina ottaa huomioon — yleisön, brändin, säännöt — projektitietona, jotta et toista niitä jokaisessa chatissa. Chat-dokumentaatio selittää Rakenna-, Suunnittelu- ja Kysy-tilat, ja mallipohjat ovat nopea tapa nähdä, miltä ensimmäinen versio voisi näyttää ennen kuin kirjoitat koko asiakirjan.

Kysymykset