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