איך להגדיר היקף ל-MVP: לצמצם את הגרסה הראשונה למה שבאמת חשוב

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

ראיתי הרבה מוצרים ראשונים נבנים, ואלה שמתקשים כמעט אף פעם לא נכשלים כי הצוות היה עצלן. הם נכשלים כי ההיקף היה שגוי כבר מהשבוע הראשון. יותר מדי נדחס לגרסה הראשונה, התקציב אזל לפני שמישהו למד דבר, ועד ההשקה הצוות הוציא הכול רק כדי להגיע לקו הזינוק — בלי כסף שנותר כדי להגיב למה שמשתמשים אמיתיים באמת עשו.

אז זה המדריך שאני נותן לאנשים לפני שנכתבת שורת קוד אחת. הוא לא עוסק בטקסי Agile או במסגרות מפוארות. הוא עוסק בשאלה כנה אחת — מהו הדבר הקטן ביותר שנוכל לבנות שאומר לנו אם הרעיון הזה אמיתי? — ובמשמעת להמשיך לענות עליה ככל שהפיתוי להוסיף "עוד פיצ'ר אחד" חוזר ומתגנב. כי הוא תמיד חוזר ומתגנב.

מה MVP באמת הוא (ומה הוא לא)

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

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

ההבחנה הזו חשובה יותר משזה נשמע. תפיסת "ה-20% הראשונים" מובילה לדבר שבור בכל כיוון ושימושי באף כיוון. "דבר אחד, כמו שצריך" מוביל למשהו שאדם יכול להרים, להשתמש בו באמת, ולהיות לו דעה עליו. הדעות הן כל הפואנטה. אי אפשר לשפר על בסיס שתיקה.

מלכודת הבנייה המוגזמת, ולמה כל כך קל ליפול בה

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

החצי השני של המלכודת הוא רגשי. לקצץ פיצ'רים מרגיש כמו להודות שהרעיון שלכם קטן. הוא לא — זו הודאה שעדיין אינכם יודעים אילו פיצ'רים חשובים, וזו פשוט האמת. כל פיצ'ר שאתם בונים לפני שיש לכם משתמשים הוא הימור בעיניים עצומות. חלק מההימורים האלה יהיו שגויים, ואלה שאתם מקצצים מה-MVP הם ההימורים הזולים ביותר לטעות בהם, כי מעולם לא הימרתם עליהם.

מצאו את המשימה האחת שה-MVP שלכם חייב לבצע

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

כדי למצוא את שלכם, השלימו את המשפט הזה בקול: "משתמש מגיע למוצר שלי כדי ______, והוא מרוצה אם ______." החלל הראשון הוא המשימה. השני הוא איך תדעו שזה עבד. אם אינכם יכולים למלא את שני החללים בנשימה אחת, עדיין לא מצאתם את הליבה — ואינכם מוכנים להגדיר היקף, קל וחומר לבנות.

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

מיינו כל פיצ'ר ל"חובה", "כדאי" ו"לא עכשיו"

ברגע שנתתם שם ללולאת הליבה, קחו את רשימת הפיצ'רים הגדולה שלכם ומיינו כל אחד לשלושה דליים. הדליים בוטים בכוונה, כי בוטות היא מה שעוצר את שיחות ה"אבל אולי" האינסופיות.

• חובה: לולאת הליבה ממש לא מתפקדת בלעדיו. אם תסירו אותו, אין מוצר. שמרו על הרשימה הזו קצרה באופן מזעזע — בדרך כלל שלושה עד שישה פריטים.
• כדאי: זה משפר את המוצר, אבל הלולאה עדיין עובדת בלעדיו. כל מה שכאן מחכה לגרסה שתיים. בלי יוצאים מן הכלל בבנייה הראשונה.
• לא עכשיו: הפיצ'רים שאתם בוחרים במודע לא לבנות כעת. לכתוב אותם חשוב — כך אתם מרגיעים את עצמכם, ואת הצוות, שהרעיון אינו ננטש, אלא רק מתוזמן.

הטריק שגורם לזה לעבוד הוא הדלי השלישי. רוב האנשים מתווכחים רק על חובה מול כדאי, וזה מתיש ולעולם לא נגמר. רשימת "לא עכשיו" היא המקום שבו נמצאת ההקלה — היא הבטחה לעצמכם העתידי שהרעיון המגניב בטוח ומתוזמן, רק לא כעת. ברגע שאנשים בוטחים ששום דבר לא נזרק, הם מפסיקים להיאבק כדי לשמור הכול בגרסה הראשונה.

הגדירו היקף לפי זמן וכסף, לא לפי רשימת פיצ'רים

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

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

דוגמה אמיתית: צמצום היקף של רעיון לניהול עבודות

תנו לי להמחיש את זה במקרה שעבדנו עליו — אנונימי, אך נאמן לאופן שבו זה מתנהל. חברת חימום ואינסטלציה קטנה הגיעה אלינו בבקשה לאפליקציה לצוות השטח שלה. התדריך, על הנייר, היה עצום: תזמון עבודות בזמן אמת, מעקב GPS אחר הרכבים, פורטל לקוחות, חיוב אוטומטי, מלאי חלקים בכל רכב, בונה הצעות מחיר, תיעוד צילומי, וחבילת דוחות עבור הבעלים. מוצר באמת שימושי, בסופו של דבר. כבנייה ראשונה, דרך מובטחת להוציא תקציב של שנה לפני שלומדים דבר.

אז עשינו את התרגיל. שאלנו את הבעלים את המשפט: "משתמש מגיע לזה כדי ______, והוא מרוצה אם ______." אחרי כמה הלוך ושוב, התשובה האמיתית צפה. הכאב היומי הגדול ביותר של הטכנאים לא היה תזמון או חיוב — הוא היה מסע הניירת הלוך ושוב. הם היו מסיימים עבודה, רושמים שעות וחלקים על דף, נוסעים בחזרה, ומישהו במשרד היה מקליד הכול מחדש למערכת הנהלת החשבונות, לעיתים קרובות ימים לאחר מכן, לעיתים קרובות עם שגיאות. לולאת הליבה הייתה פשוט: לכוד את מה שקרה בעבודה, פעם אחת, באתר, כך שאף אחד לא יקליד מחדש.

מה עבר את הסף — ומה לא

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

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

הטעויות שהורסות בשקט את היקף ה-MVP

אפילו צוותים שמאמצים את "לשמור על זה קטן" נוטים להיתקל באותם כמה דברים. אף אחד מהם אינו דרמטי. הם דליפות איטיות שמנפחות מחדש את ההיקף בזמן שאתם לא מסתכלים, עד שיום אחד למוצר ה"מינימלי" יש שוב שלושים מסכים ולוח זמנים של שישה חודשים.

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

אם תישמרו רק מאחת מאלה, שתהיה זו האחרונה. הגדרה ברורה וכתובה של "גמור" — "טכנאי יכול לרשום את השעות והחלקים של עבודה בטלפון שלו, והמשרד רואה זאת מיד" — היא הכלי החזק ביותר לשמור על היקף כן. כל תוספת מוצעת מועמדת מול המשפט הזה. אם היא אינה משרתת את המשפט, היא רעיון לגרסה שתיים, לא משנה כמה טובה.

תהליך פשוט להגדרת היקף ל-MVP שלכם

לסיכום, הנה הרצף שהייתי עובר עם כל אחד לפני התחלת בנייה ראשונה. הוא נמוך-טכנולוגיה בכוונה — אתם יכולים לעשות את רובו עם מסמך ושיחה כנה, הרבה לפני שאתם צריכים מפתח בחדר.

1. 1
   תנו שם ללולאת הליבה

   השלימו את המשפט: "משתמש מגיע כדי לעשות ___, ומרוצה אם ___." אם אינכם יכולים, אינכם מוכנים להגדיר היקף — המשיכו לדבר עד שהמשימה האמיתית צפה.
2. 2
   שפכו כל פיצ'ר, ואז מיינו

   הוציאו את כל רשימת המשאלות מהראש אל הנייר. מיינו כל פריט ל"חובה", "כדאי" או "לא עכשיו". שמרו על רשימת ה"חובה" קצרה באכזריות.
3. 3
   קבעו את הקופסה

   החליטו על התקציב ועל המועד האחרון לפני שתסגרו את רשימת הפיצ'רים. התאימו את הרשימה לקופסה, לא להפך.
4. 4
   כתבו את הגדרת ה"גמור"

   משפט קונקרטי אחד שמתאר את לולאת הליבה הפועלת. זו המגן שלכם מפני נפיחות היקף לכל שאר הפרויקט.
5. 5
   בנו, השיקו, צפו, ואז החליטו

   שלחו את הליבה למשתמשים אמיתיים. צפו במה שהם באמת עושים. תנו להתנהגות שלהם — לא לניחושים הקודמים שלכם — לבחור מה בא הלאה מרשימת ה"כדאי".

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

שאלות נפוצות