როგორ დავწეროთ მომხმარებლის ისტორიები (მაგალითები და მიღების კრიტერიუმები)

მომხმარებლის ისტორია არის ფუნქციის მოკლე აღწერა მომხმარებლის თვალთახედვით: «როგორც [მომხმარებლის ტიპი], მინდა [მიზანი], რათა [მიზეზი]». მის ქვეშ წერ მიღების კრიტერიუმებს — რამდენიმე კონკრეტულ პირობას, რომლებიც უნდა სრულდებოდეს, რათა ისტორია შესრულებულად ჩაითვალოს. ყოველი ისტორია საკმარისად პატარა უნდა იყოს, რომ ერთ ჯერზე აშენდეს და შემოწმდეს, ხოლო კრიტერიუმები ისე უნდა იყოს დაწერილი, რომ ნებისმიერმა შეძლოს მათი შემოწმება.

მომხმარებლის ისტორიები პოპულარული გახდა ეჯაილ (agile) პროგრამული უზრუნველყოფის გუნდებში, მაგრამ ისინი თანაბრად სასარგებლოა, როცა საკუთარ თავზე აშენებ AI აპის ბილდერით. კარგი ისტორია კარგი მოთხოვნაა.

ფორმატი

მომხმარებლის ისტორიას სამი ნაწილი აქვს:

როგორც [ვინ], მინდა [რა] რათა [რატომ].

• ვინ არის კონკრეტული ტიპის მომხმარებელი: პირველად შემოსული სტუმარი, ფასიანი წევრი, კლინიკის რეგისტრატორი, ადმინისტრატორი. არა «მომხმარებელი».
• რა არის ის, რის გაკეთებაც მას სურს, მის სიტყვებში. არა როგორ მუშაობს ეკრანი.
• რატომ არის შედეგი, რომელიც მას აინტერესებს. ეს არის ნაწილი, რომელსაც ხალხი ხშირად გამოტოვებს, და სწორედ ის აჩერებს არასწორი რამის აშენებას.

მაგალითი:

როგორც სპორტდარბაზის წევრი, მინდა ვარჯიშის ჯავშნის გაუქმება ჩემი ტელეფონიდან რათა ლოდინის სიაში მყოფმა ვინმემ ჩემი ადგილი დაიკავოს და მე არ დამერიცხოს გამოუცხადებლობის საფასური.

«რატომ»-ი ორ რამეს გეუბნება, რაც «რა»-მ არ თქვა: ის უნდა მუშაობდეს ტელეფონზე, და ჩართულია ლოდინის სია და საფასურის წესები.

მიღების კრიტერიუმები

ისტორია გეუბნება, რა გინდა. მიღების კრიტერიუმები გეუბნება, როდის არის ის დასრულებული. ისინი საკმარისად კონკრეტული უნდა იყოს, რომ ორმა ადამიანმა შეთანხმდეს, თითოეული გადის თუ არა.

ხშირად იწერება როგორც მოცემულია / როცა / მაშინ:

• მოცემულია საწყისი სიტუაცია
• როცა მომხმარებელი რამეს აკეთებს
• მაშინ ეს არის შედეგი

სპორტდარბაზის ჯავშნის მაგალითისთვის:

1. მოცემულია მაქვს ჯავშანი 12 საათზე მეტით დაშორებულ დროზე, როცა ვაჭერ გაუქმებას და ვადასტურებ, მაშინ ჯავშანი წაიშლება და ვხედავ «ჯავშანი გაუქმებულია».
2. მოცემულია ვაუქმებ ჯავშანს და კლასს აქვს ლოდინის სია, როცა გაუქმება შეინახება, მაშინ ლოდინის სიაში პირველი ადამიანი იღებს ადგილს და ელფოსტას.
3. მოცემულია ჯავშანი 12 საათზე ნაკლები დროით დაშორებულია, როცა ვაჭერ გაუქმებას, მაშინ დადასტურებამდე ვხედავ, რომ გამოუცხადებლობის საფასური გამოიყენება.
4. მოცემულია ვარ ტელეფონის სიგანის ეკრანზე, მაშინ გაუქმების ღილაკი ჩანს გვერდზე გადაადგილების გარეშე.

ჩვეულებრივი ჩამონათვალიც მუშაობს, თუ თითოეული პუნქტი შემოწმებადია. «გაუქმება ადვილია» შემოწმებადი არაა. «გაუქმება მაქსიმუმ ორი დაჭერით ჯავშნების სიიდან» — შემოწმებადია.

ნაბიჯ-ნაბიჯ: კარგი ისტორიის წერა

ნაბიჯი 1: დაიწყე რეალური მომხმარებლით და რეალური პრობლემით

აირჩიე ერთი ტიპის მომხმარებელი და რამე, რაც დღეს უჭირთ. თუ მომხმარებლებთან ინტერვიუ გაქვს ჩატარებული, გამოიყენე მათი სიტყვები. «ყოველთვის მავიწყდება გაუქმება და მრიცხავენ» უკეთესი საწყისი წერტილია, ვიდრე «დაამატე გაუქმების ფუნქცია».

ნაბიჯი 2: დაწერე ერთსტრიქონიანი ისტორია

შეავსე შაბლონი. თუ ვერ დაწერ დამაჯერებელ «რათა»-ს, იკითხე, საჭიროა თუ არა ფუნქცია საერთოდ.

ნაბიჯი 3: დაამატე სამი-ექვსი მიღების კრიტერიუმი

ფარე ძირითადი წარმატებული შემთხვევა ჯერ, შემდეგ მნიშვნელოვანი ვარიაციები: სხვა როლი, ცარიელი მდგომარეობა, ლიმიტი, შეცდომა. თუ ექვსზე მეტს წერ, ისტორია ალბათ ძალიან დიდია.

ნაბიჯი 4: ჩაწერე, რა არ შედის

ერთი სტრიქონი ბევრ უკუკავშირს ზოგავს: «არ შედის: დაბრუნებები ფასიანი ვარჯიშებისთვის; ადმინისტრატორების მიერ წევრების ნაცვლად გაუქმება.» ეს ხელს უშლის, რომ ისტორია აშენების დროს გაიზარდოს.

ნაბიჯი 5: შეამოწმე INVEST-ით

INVEST კარგი ისტორიების გავრცელებული ჩამონათვალია. ისტორია უნდა იყოს:

ყველა ისტორიას არ უნდა შეუფასო ქულები. ყველაზე სასარგებლოა, როცა ისტორია არასწორად გეჩვენება და გინდა გაიგო, რატომ.

კარგი და ცუდი მაგალითები

როგორ დავყოთ ძალიან დიდი ისტორია

დიდი ისტორიები სწორედ იქ ჩერდება ხოლმე პროექტები. გავრცელებული გზები დაყოფისთვის:

• მომხმარებლის როლით. წევრები აუქმებენ საკუთარ ჯავშნებს; პერსონალი აუქმებს ნებისმიერისას.
• ნაკადის ნაბიჯით. დაათვალიერე ვარჯიშები; დაჯავშნე ვარჯიში; მიიღე შეხსენება.
• მარტივი შემთხვევა ჯერ. გააუქმე უფასო ვარჯიში ახლა; საფასურები და დაბრუნებები მოგვიანებით ისტორიაში.
• მონაცემების ვარიაციით. მხარი დაუჭირე ერთ ლოკაციას ჯერ, რამდენიმეს მოგვიანებით.
• ძირითადი გზა, შემდეგ შეცდომები. ააშენე ის, რომ მუშაობდეს, შემდეგ დაამატე დამუშავება გავსებული ვარჯიშებისთვის, ვადაგასული აბონემებისთვის და ა.შ.

თითოეული ნაწილი მაინც უნდა იყოს ის, რაც მომხმარებელს შეეძლოს გამოიყენოს და შეამჩნიოს.

მომხმარებლის ისტორიები როგორც მოთხოვნები

მომხმარებლის ისტორია მიღების კრიტერიუმებით ძალიან ახლოსაა კარგ მოთხოვნასთან AI აპის ბილდერისთვის. ის AI-ს აძლევს ვისი, რას, რატომ და შესრულების განმარტებას. გაგზავნე თითო ისტორია ერთ შეტყობინებაში:

როგორც სპორტდარბაზის წევრი, მინდა ჩემი ტელეფონიდან გავაუქმო ვარჯიშის ჯავშანი, რათა ლოდინის სიაში მყოფმა ვინმემ ჩემი ადგილი დაიკავოს. მიღების კრიტერიუმები:

1. გაუქმება ჩანს თითოეულ ჯავშანზე ჩემს ჯავშნებში, დადასტურების ნაბიჯით.
2. 12 საათზე მეტით ადრე გაუქმება უბრალოდ შლის ჯავშანს.
3. 12 საათზე ნაკლებით ადრე აჩვენე «გვიანი გაუქმების საფასური $5 გამოიყენება» დადასტურებამდე და ჩაწერე საფასური ჯავშანზე.
4. თუ ვარჯიშს ლოდინის სია აქვს, პირველი ადამიანი იღებს ადგილს და ელფოსტას.
5. მუშაობს ტელეფონის სიგანის ეკრანზე. არ შედის: დაბრუნებები, პერსონალის მიერ წევრების გაუქმება. ააშენე ეს, შემდეგ შეამოწმე თითოეული კრიტერიუმი preview-ში და მითხარი, რომელი გადის.

ასევე შეგიძლია სთხოვო AI-ს, მოკლე იდეიდან ისტორიების შედგენა, შემდეგ კი თავად დაარედაქტირო:

ჩემი აპის იდეა: [ორი-სამი წინადადება]. დაწერე პირველი ვერსიის მომხმარებლის ისტორიები, დაჯგუფებული მომხმარებლის ტიპის მიხედვით, თითოეულს 3-დან 5 მოცემულია/როცა/მაშინ მიღების კრიტერიუმით. აღნიშნე, რომელი აუცილებელია გაშვებისთვის და რომელი შეიძლება მოგვიანებით.

ყოველთვის წაიკითხე და დაარედაქტირე შედეგი. AI არ იცნობს შენს მომხმარებლებს; შენ იცნობ.

მიღების კრიტერიუმები ასევე შენი სატესტო გეგმაც არის. როცა ისტორია აშენდება, თითოეული კრიტერიუმი თავად გაიარე. ჩვენი გზამკვლევი აპის გაშვებამდე ტესტირების შესახებ ამას ეფუძნება.

სად ერგება მომხმარებლის ისტორიები სხვა დოკუმენტებს

• პროდუქტის მოთხოვნების დოკუმენტი აღწერს მთლიან პროდუქტს: პრობლემას, მომხმარებლებს, ფარგლებს. მომხმარებლის ისტორიები მასში დეტალური ნაწილებია. იხილე როგორ დავწეროთ PRD AI-ით.
• ბაგის რეპორტი აღწერს რაღაცას, რაც გატყდა უკვე აშენებულ ისტორიასთან მიმართებით. იხილე როგორ დავწეროთ კარგი ბაგის რეპორტი.
• MVP არის უმცირესი ისტორიების ნაკრები, რომელიც ძირითად ღირებულებას აძლევს. იხილე რა არის MVP.

გავრცელებული შეცდომები

• «როგორც მომხმარებელი…» ძალიან ბუნდოვანია. დაასახელე მომხმარებლის კონკრეტული ტიპი.
• «რათა»-ს გამოტოვება. მიზეზის გარეშე ვერ გააკეთებ გონივრულ კომპრომისებს.
• გადაწყვეტის წერა საჭიროების ნაცვლად. «მინდა ჩამოსაშლელი» დიზაინს ადრევე ამაგრებს, სანამ ვინმე იფიქრებს.
• კრიტერიუმები, რომელთა შემოწმებაც შეუძლებელია. «მარტივი», «სწრაფი» და «ინტუიციური» სურვილებია, არა კრიტერიუმები.
• ისტორიები, რომლებიც სინამდვილეში ეპიკებია. «ჩემი ანგარიშის მართვა» ათი ისტორიაა.
• ყველა ისტორიის წინასწარ წერა. შემდეგი რამდენიმე დეტალურად დაწერე; დანარჩენი ერთსტრიქონიანი დატოვე, სანამ მათ მიაღწევ.

ისტორიები Mythex-ში

Mythex-ში Plan რეჟიმი კარგი ადგილია იდეის ისტორიებად გადასაქცევად: აგენტი ამუშავებს მიდგომას მანამდე, სანამ რამეს შეცვლის. როცა ისტორია მზადაა, გადადი Build-ზე და ჩასვი, თითო ისტორია ერთ შეტყობინებაში. ყოველი მათგანის შემდეგ /test შეუძლია preview-ში ნაკადი გაიაროს და შეამოწმოს, და ნებისმიერ პასუხს შეუძლია დააბრუნო Revert to this point-ით, თუ არასწორად წავიდა. იხილე ეფექტური მოთხოვნები დოკუმენტაციაში და ჩვენი გზამკვლევი როგორ დავწეროთ მოთხოვნები AI აპის ბილდერებისთვის.

მომხმარებლის ისტორიის ჩამონათვალი

• ასახელებს მომხმარებლის კონკრეტულ ტიპს
• აღწერს საჭიროებას და არა დიზაინს
• შეიცავს ნამდვილ «რათა» მიზეზს
• აქვს სამი-ექვსი შემოწმებადი მიღების კრიტერიუმი
• ფარავს მინიმუმ ერთ კიდურა შემთხვევას ან შეცდომას
• ამბობს, რა არის ფარგლებს გარეთ
• საკმარისად პატარაა, რომ ერთ ჯერზე აშენდეს და შემოწმდეს
• კრიტერიუმები შემოწმებულია აშენების შემდეგ, ერთ-ერთი-ერთზე

კითხვები