גיבוש הרעיון

השלב שכולם ממהרים לדלג עליו

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

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

מה קורה בפגישת הגיבוש שלנו

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

שלושת האזורים שמנחים כל גיבוש:

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

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

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

טכנולוגיה נכנסת לשיחה מהיום הראשון

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

כספיט 910 ו-T1 Mini - שני דגמים של קופות רושמות שבנינו מאפס, כולל גיבוש הרעיון. בשלב הגיבוש המיפוי לא נגע רק בפיצ'רים - הוא כלל מיפוי מלא של ממשקי החומרה: מגירת שטרות, מדפסת קבלות, קורא כרטיסים, ופרוטוקולי תקשורת עם חברות סליקה. שאלה שנשאלה בגיבוש, "מה קורה אם הסליקה לא זמינה ברגע התשלום?", הובילה לכך שתכנון מצב offline עם queue מקומי נכנס לארכיטקטורה כבר ביום הראשון. בלי הגיבוש, זה היה מגיע כדרישה חדשה שלושה חודשים לתוך הפיתוח.

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

כמה מספרים

בפרויקטים שבהם עשינו גיבוש מלא לפני פיתוח:

זמן גיבוש ממוצע: 2-3 שבועות לפרויקט מורכבות בינונית
שינויי scope לאחר תחילת פיתוח: כ-20% לעומת כ-75%, בפרויקטים ללא גיבוש

מה אתה מקבל בסיום

בסיום שלב הגיבוש יש בידיך:

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

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

מה הצעד הבא?

גיבוש הרעיון הוא השלב הראשון בתהליך שלנו. מה שמגיע אחריו:

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