SaaS MVP 90 დღეში: განვითარების გეგმის მაგალითი

„MVP 90 დღეში“ ამბიციურად ჟღერს და სწორედ ეს ამბიცია ღუპავს ხშირად პროექტს: გუნდი ცდილობს სრულფასოვანი პროდუქტი მოკლე ვადაში ჩაატიოს და საბოლოოდ მთავარ ჰიპოთეზას დროულად ვერ ამოწმებს. რეალისტური 90-დღიანი გეგმა ფუნქციების რაოდენობაზე კი არ არის აგებული, არამედ ერთ მკაფიო მიზანზე: გაარკვიოთ, მზად არიან თუ არა ადამიანები, გადაიხადონ იმ გადაწყვეტისთვის, რომელსაც მათი პრობლემისთვის სთავაზობთ.

პირველი ორი კვირა: კოდი კი არა, პროდუქტის საზღვრები

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

ამ ეტაპზე სასარგებლოა, ჰიპოთეზა ისე ჩამოაყალიბოთ, რომ მისი უარყოფა შესაძლებელი იყოს: არა „ადამიანებს მოსახერხებელი ინსტრუმენტი სჭირდებათ“, არამედ „5-20-კაციანი გუნდები მზად არიან ყოველთვიურად გადაიხადონ X პროცესის ავტომატიზაციისთვის“. რაც უფრო კონკრეტულია ჰიპოთეზა, მით უფრო ადვილია პირველი კვირების შემდეგ იმის გარკვევა, დადასტურდა თუ არა ის, და შედეგები აღარ განიმარტება ისე, როგორც გუნდს აწყობს.

მე-3-დან მე-8 კვირამდე: პროდუქტის ბირთვის შექმნა

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

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

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

მე-9-დან მე-12 კვირამდე: პირველი მომხმარებლები და სწრაფი იტერაციები

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

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

ბიუჯეტი და გუნდი: რეალისტური მოლოდინები

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

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

90-დღიანი MVP-ის მიზანი პროდუქტის გამოშვება კი არა, იმ კითხვაზე პასუხის მიღებაა, ღირს თუ არა მისი შემდგომი განვითარება. ეს განსხვავებული მიზნებია და მათი აღრევა ასეთი პროექტების წარუმატებლობის მთავარი მიზეზია.

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