להתחיל מההנחה שצריך לבדוק
MVP הוא גרסה מצומצמת של מוצר שאפשר להשתמש בה כדי לבדוק הנחה עסקית או התנהגותית. ההיקף נקבע לפי השאלה שצריך לענות עליה. אתר עם הרבה מסכים עדיין יכול להשאיר את השאלה המרכזית פתוחה; תהליך אחד שלם יכול לספק מידע שימושי יותר.
לדוגמה, במערכת לניהול בקשות שירות השאלה הראשונית יכולה להיות האם צוות קטן מסוגל לקלוט, לתעדף ולסגור פנייה בלי לחזור לגיליון העבודה. זהו תרחיש להמחשה. הוא מאפשר להחליט אילו יכולות נדרשות ומה אפשר לדחות, בלי להניח שהמוצר כולו כבר מוגדר.
לבחור משתמש ותהליך שמגיע לתוצאה
תארו אדם מסוים: מה הוא עושה היום, באיזה שלב הוא נתקע ומה תהיה התוצאה הרצויה. אחר כך שרטטו את התהליך מהתחלה עד סוף. הרשמה, מסך פתיחה ודשבורד אינם תוצאה בפני עצמם; סגירת פנייה או השלמת הזמנה הן תוצאות שאפשר לבדוק.
בחרו גם את מצבי הכישלון החשובים. אם משתמש הזין פרטים לא תקינים, מי מסביר לו איך לתקן? אם השירות החיצוני אינו זמין, מה נשמר ומה מותר לנסות שוב? טיפול במצבים האלה יכול להיות חלק מהגרסה הראשונה גם כשהעיצוב פשוט.
לכתוב מה נכנס ומה מחכה
חלקו את הדרישות לשלוש קבוצות: הכרחי להשלמת התהליך, הכרחי להפעלה אחראית, ושיפור שאפשר לבדוק מאוחר יותר. הרשאות או גיבוי אינם בהכרח קישוט של גרסה מתקדמת. מצד שני, ייצוא לכל פורמט והתאמה לכל סוג לקוח יכולים להיות מחוץ להיקף ההתחלתי.
- משתמש אחד או קבוצה מוגדרת, במקום כל סוגי המשתמשים האפשריים.
- מסלול מרכזי עם התחלה וסיום, כולל הודעות שגיאה משמעותיות.
- רשימת יכולות שנדחו והסיבה לדחייה של כל אחת.
- קריטריוני קבלה שניתן להדגים על מידע בטוח.
לקבוע איך תתקבל ההחלטה הבאה
הגדירו מה תאספו במהלך הניסוי: השלמת משימה, נקודות שבהן צריך עזרה, סיבות לנטישה ומשוב איכותני. אין צורך להתחיל מכלי מעקב מורכב. שיחה ותצפית מתועדת יכולות להיות שימושיות, ובכל איסוף מידע אישי צריך לטפל בפרטיות ובהסכמה המתאימה.
קבעו מראש מה יוביל להמשך ומה יחייב שינוי. אם כולם מגיעים למסך האחרון אבל לא מבינים את התוצאה, הבעיה אינה נפתרת על ידי הוספת עוד מסכים. מטרת המדידה היא לתמוך בהחלטה על המוצר, ולא רק להפיק גרף יפה.
להשאיר בסיס שאפשר להמשיך ממנו
לפני מסירה, בדקו שאדם נוסף יודע להריץ את המוצר, לפרוס אותו ולהבין היכן נשמר המידע. תעדו מגבלות, החלטות וחובות פתוחים. גרסה ראשונה יכולה להיות קטנה, ובכל זאת צריכה להיות ברורה לצוות שימשיך לפתח אותה.
הצעד הראשון המומלץ הוא מסמך של עמוד אחד: משתמש, בעיה, תהליך, גבולות ודרך לבדיקת התוצאה. ממנו אפשר לגזור אפיון ומסלול פיתוח ממוקד, בלי להתחייב מראש לכל רעיון שיעלה במהלך הדרך.