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