איך יודעים שרעיון לאפליקציה שווה פיתוח?

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

מה צריך להוכיח, ובאיזה סדר?

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

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

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

שיחה שמייצרת ראיה, לא מחמאה

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

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

אילו ניסויים זולים נותנים תשובה אמיתית?

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

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

מה נחשב מספיק? קובעים סף לפני הניסוי

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

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

גרסת הבטא כהמשך של בדיקת הביקוש

כשמגיעים לגרסה ראשונה, יש גם דרישה טכנית לתכנן. גוגל דורשת מחשבונות מפתח אישיים שנפתחו אחרי 13 בנובמבר 2023 להריץ בדיקה סגורה עם לפחות 12 בודקים שנשארים בה ברציפות לפחות 14 יום, ורק אז לבקש גישה לפרסום (Google Play - דרישת בדיקה לחשבונות מפתח חדשים). הדרישה הזו, כפי שגוגל מנסחת אותה, חלה על חשבונות אישיים; Google Play מציעה גם מסלולי בדיקה פנימית, סגורה ופתוחה (Google Play - מסלולי בדיקה פנימית, סגורה ופתוחה). באפל, TestFlight מאפשר להזמין בודקים חיצוניים במייל או בקישור ציבורי ולקבל מהם צילומי מסך עם הערות ודיווחי קריסה (Apple - TestFlight לבדיקת גרסת בטא).

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

מתי מפסיקים לבדוק רעיון לאפליקציה ומחליטים?

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

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