Ինչպես գրել օգտատիրոջ պատմություններ (օրինակներով և ընդունման չափանիշներով)

Օգտատիրոջ պատմությունը գործառույթի կարճ նկարագրություն է օգտատիրոջ տեսանկյունից. «Որպես [օգտատիրոջ տեսակ], ես ուզում եմ [նպատակ], որպեսզի [պատճառ]»։ Դրա տակ գրում եք ընդունման չափանիշներ՝ մի քանի հատուկ պայման, որոնք պետք է ճիշտ լինեն, որպեսզի պատմությունը համարվի ավարտված։ Յուրաքանչյուր պատմություն պահեք բավականաչափ փոքր, որ մեկ անգամում կառուցվի և թեստավորվի, իսկ չափանիշները գրեք այնպես, որ ցանկացած մարդ կարողանա ստուգել դրանք։

Օգտատիրոջ պատմությունները տարածված են դարձել agile ծրագրային թիմերի շրջանում, բայց դրանք հավասարապես օգտակար են, երբ մենակ եք կառուցում AI հավելվածների կառուցողով։ Լավ պատմությունը լավ հուշում է։

Ձևաչափը

Օգտատիրոջ պատմությունն ունի երեք մաս.

Որպես [ով], ես ուզում եմ [ինչ] որպեսզի [ինչու]։

• Ով-ը օգտատիրոջ կոնկրետ տեսակն է. առաջին անգամ այցելուն, վճարող անդամը, կլինիկայի ադմինիստրատորը, ադմինը։ Ոչ թե «օգտատերը»։
• Ինչ-ը այն է, ինչ նրանք ուզում են անել՝ իրենց բառերով։ Ոչ թե թե ինչպես է աշխատում էկրանը։
• Ինչու-ն այն արդյունքն է, որ նրանց հետաքրքրում է։ Սա այն մասն է, որ մարդիկ բաց են թողնում, և որը կանգնեցնում է սխալ բան կառուցելուց։

Օրինակ.

Որպես մարզասրահի անդամ, ես ուզում եմ հեռախոսից չեղարկել դասի ամրագրումը, որպեսզի սպասման ցուցակի որևէ մեկը կարողանա զբաղեցնել իմ տեղը, և ես չվճարեմ բացակայության տույժ։

«Ինչու»-ն երկու բան է ասում, որ «ինչը»-ն չէր ասում. այն պետք է աշխատի հեռախոսում, և ներգրավված են սպասման ցուցակը և տույժերի կանոնները։

Ընդունման չափանիշներ

Պատմությունն ասում է, թե ինչ է ուզվում։ Ընդունման չափանիշները ասում են, թե երբ է այն ավարտված։ Դրանք պետք է բավականաչափ հատուկ լինեն, որպեսզի երկու մարդ համաձայնվեն, թե յուրաքանչյուրն անցնում է, թե ոչ։

Դրանք գրելու տարածված եղանակը Given / When / Then-ն է.

• Given մեկնարկային իրավիճակ
• When օգտատերը ինչ-որ բան է անում
• Then սա արդյունքն է

Մարզասրահի ամրագրման պատմության համար.

1. Given ունեմ ամրագրում, որը 12 ժամից ավելի հեռու է, when սեղմում եմ Cancel և հաստատում, then ամրագրումը հեռացվում է և տեսնում եմ «Booking cancelled»։
2. Given չեղարկում եմ ամրագրումը, և դասը ունի սպասման ցուցակ, when չեղարկումը պահպանվում է, then սպասման ցուցակի առաջին անձը ստանում է տեղը և էլ. նամակ։
3. Given ամրագրումը 12 ժամից պակաս հեռու է, when սեղմում եմ Cancel, then հաստատելուց առաջ տեսնում եմ, որ կիրառվում է ուշ չեղարկման տույժ։
4. Given գտնվում եմ հեռախոսի լայնության էկրանին, then Cancel կոճակը տեսանելի է առանց կողքին ոլորելու։

Պարզ ստուգացանկը նույնպես աշխատում է, քանի դեռ յուրաքանչյուր կետ թեստավորելի է։ «Չեղարկելը հեշտ է» թեստավորելի չէ։ «Չեղարկումը ամրագրումների ցուցակից պահանջում է առավելագույնը երկու հպում» թեստավորելի է։

Քայլ առ քայլ. լավ պատմություն գրելը

Քայլ 1. Սկսեք իրական օգտատիրոջից և իրական խնդրից

Ընտրեք մեկ տեսակի օգտատեր և բան, որի հետ նրանք այսօր դժվարանում են։ Եթե արել եք հաճախորդների հարցազրույցներ, օգտագործեք նրանց բառերը։ «Ես միշտ մոռանում եմ չեղարկել և վճարում եմ» ավելի լավ մեկնակետ է, քան «ավելացրու չեղարկման գործառույթ»։

Քայլ 2. Գրեք մեկ տողով պատմությունը

Լրացրեք ձևանմուշը։ Եթե չեք կարող գրել համոզիչ «որպեսզի»-ն, հարցրեք, արդյոք գործառույթն ընդհանրապես անհրաժեշտ է։

Քայլ 3. Ավելացրեք երեքից վեց ընդունման չափանիշ

Նախ ընդգրկեք հիմնական հաջող դեպքը, ապա կարևոր տարբերակները. այլ դեր, դատարկ վիճակ, սահման, սխալ։ Եթե գրում եք ավելի քան վեց, պատմությունը հավանաբար չափազանց մեծ է։

Քայլ 4. Նշեք, թե ինչն է շրջանակից դուրս

Մեկ տողը շատ հետընթաց խնդիրներ է խնայում. «Շրջանակից դուրս. վճարովի դասերի վերադարձներ. ադմինները անդամների փոխարեն չեղարկումներ» Այն կանգնեցնում է պատմությունը աճելուց, մինչ կառուցում եք։

Քայլ 5. Ստուգեք INVEST-ով

INVEST-ը լավ պատմությունների համար տարածված ստուգացանկ է. պատմությունը պետք է լինի.

Յուրաքանչյուր պատմություն գնահատելու կարիք չկա։ Այն ամենաօգտակարն է, երբ պատմությունը սխալ է թվում, և ուզում եք իմանալ, թե ինչու։

Լավ և վատ օրինակներ

Ինչպես բաժանել չափազանց մեծ պատմությունը

Մեծ պատմությունների պատճառով են նախագծերը կանգնում։ Բաժանելու տարածված եղանակներ.

• Օգտատիրոջ դերով. Անդամները չեղարկում են իրենց ամրագրումները, աշխատակիցները՝ ցանկացածի։
• Հոսքի քայլով. Դիտել դասերը. ամրագրել դաս. ստանալ հիշեցում։
• Նախ պարզ դեպքը. Չեղարկել անվճար դաս հիմա. վճարների և վերադարձների վերաբերյալ՝ հետագա պատմությունում։
• Տվյալների տարբերակով. Նախ աջակցել մեկ վայր, հետո մի քանիսը։
• Հաջող ճանապարհ, հետո սխալներ. Նախ կառուցեք աշխատող տարբերակը, հետո ավելացրեք լրացված դասերի, ժամկետանց անցաթղթերի և այլնի մշակումը։

Կտորներից յուրաքանչյուրը դեռ պետք է լինի մի բան, որը օգտատերը կարող էր օգտագործել և նկատել։

Օգտատիրոջ պատմությունները որպես հուշումներ

Չափանիշներով օգտատիրոջ պատմությունը շատ մոտ է AI հավելվածների կառուցողի լավ հուշմանը. այն AI-ին տալիս է ով-ը, ինչը, ինչուն և «ավարտված»-ի սահմանումը։ Յուրաքանչյուր հաղորդագրությամբ ուղարկեք մեկ պատմություն.

Որպես մարզասրահի անդամ, ես ուզում եմ հեռախոսից չեղարկել դասի ամրագրումը, որպեսզի սպասման ցուցակի որևէ մեկը կարողանա զբաղեցնել իմ տեղը։ Ընդունման չափանիշներ՝

1. Cancel-ը յուրաքանչյուր ամրագրման վրա է My Bookings-ում, հաստատման քայլով։
2. 12 ժամից ավելի առաջ չեղարկելը պարզապես հեռացնում է ամրագրումը։
3. 12 ժամից պակաս առաջ՝ հաստատելուց առաջ ցույց տվեք «Կիրառվում է ուշ չեղարկման 5 դոլար տույժ» և գրանցեք տույժը ամրագրման վրա։
4. Եթե դասն ունի սպասման ցուցակ, առաջին անձը ստանում է տեղը և էլ. նամակ։
5. Աշխատում է հեռախոսի լայնության էկրանին։ Շրջանակից դուրս. վերադարձներ, աշխատակիցները անդամների փոխարեն չեղարկում են։ Կառուցիր սա, ապա ստուգիր յուրաքանչյուր չափանիշ նախադիտման մեջ և ասա, թե որոնք են անցնում։

Կարող եք նաև խնդրել AI-ին պատմություններ նախագծել կոպիտ գաղափարից, ապա խմբագրել դրանք ինքներդ.

Ահա իմ հավելվածի գաղափարը. [երկու-երեք նախադասություն]։ Գրիր առաջին տարբերակի օգտատիրոջ պատմությունները, խմբավորած ըստ օգտատիրոջ տեսակի, յուրաքանչյուրը 3-ից 5 Given/When/Then ընդունման չափանիշով։ Նշիր, որոնք են անհրաժեշտ գործարկման համար, և որոնք կարող են սպասել։

Միշտ կարդացեք և խմբագրեք արդյունքը. AI-ն չգիտի ձեր օգտատերերին. դուք գիտեք։

Նաև ընդունման չափանիշները ծառայում են որպես ձեր թեստային պլան։ Երբ պատմությունը կառուցված է, ինքներդ անցեք յուրաքանչյուր չափանիշով։ Մեր ուղեցույցը՝ ինչպես թեստավորել ձեր հավելվածը գործարկումից առաջ, հենվում է սրա վրա։

Որտեղ են օգտատիրոջ պատմությունները մյուս փաստաթղթերի հետ

• Արտադրանքի պահանջների փաստաթուղթը նկարագրում է ամբողջ արտադրանքը. խնդիրը, օգտատերերը, շրջանակը։ Օգտատիրոջ պատմությունները դրա ներսի մանրամասն մասերն են։ Տես ինչպես գրել PRD AI-ով։
• Սխալի հաշվետվությունը նկարագրում է մի բան, որ կոտրված է արդեն կառուցված պատմության նկատմամբ։ Տես ինչպես գրել լավ սխալի հաշվետվություն։
• MVP-ն օգտատիրոջ պատմությունների ամենափոքր հավաքածուն է, որ տալիս է հիմնական արժեքը։ Տես ինչ է MVP-ն։

Սովորական սխալներ

• «Որպես օգտատեր…» Չափազանց անորոշ է։ Նշեք օգտատիրոջ իրական տեսակը։
• «Որպեսզի»-ն բաց թողնելը։ Առանց պատճառի չեք կարող խելամիտ փոխզիջումներ անել։
• Լուծումը գրելը կարիքի փոխարեն։ «Ուզում եմ բացվող ցուցակ» դիզայնը ֆիքսում է, նախքան որ որևէ մեկը մտածի դրա մասին։
• Չափանիշներ, որոնք չեն կարող թեստավորվել։ «Հեշտ», «արագ» և «ինտուիտիվ»-ը ցանկություններ են, ոչ թե չափանիշներ։
• Պատմություններ, որոնք իրականում էպիկեր են։ «Կառավարել իմ հաշիվը»-ը տասը պատմություն է։
• Բոլոր պատմությունները նախապես գրելը։ Մանրամասն գրեք հաջորդ մի քանիսը. մնացածը պահեք որպես մեկ տողեր, մինչև հասնեք դրանց։

Պատմությունները Mythex-ում

Mythex-ում Plan ռեժիմը լավ տեղ է գաղափարը պատմությունների վերածելու համար. գործակալը քննարկում է մոտեցումը, նախքան որևէ բան խմբագրելը։ Երբ պատմությունը պատրաստ է, անցեք Build-ի և տեղադրեք այն, մեկ հաղորդագրությամբ մեկ պատմություն։ Յուրաքանչյուրից հետո /test-ը կարող է սեղմել նախադիտման միջով և ստուգել հոսքը, իսկ ցանկացած պատասխան կարող եք հետ գլորել Revert to this point-ով, եթե սխալ գնաց։ Տես փաստաթղթերում արդյունավետ հուշումները և մեր ուղեցույցը՝ հուշումներ գրելու մասին AI հավելվածների կառուցողների համար։

Օգտատիրոջ պատմության ստուգացանկ

• Նշում է օգտատիրոջ կոնկրետ տեսակ
• Նկարագրում է կարիք, ոչ թե դիզայն
• Ներառում է իրական «որպեսզի» պատճառ
• Ունի երեքից վեց թեստավորելի ընդունման չափանիշ
• Ընդգրկում է առնվազն մեկ եզրային դեպք կամ սխալ
• Նշում է, թե ինչն է շրջանակից դուրս
• Բավականաչափ փոքր է, որ մեկ անգամում կառուցվի և թեստավորվի
• Չափանիշները ստուգված են կառուցելուց հետո, մեկ առ մեկ

Հարցեր