רוב הצוותים מניחים שה־MVP נכשל כי הם זזו מהר מדי. לחץ משקיעים, לוח זמנים קצר ומחסור במהנדסים — אלה מקבלים את האשמה. בפועל הדפוס הפוך: בונים את הדבר הלא נכון לאט, עם מחויבות גוברת ליסוד פגום, עד שהיפוך כיוון מרגיש בלתי אפשרי.
ביצענו אודיט לעשרות MVP שנכשלו בשנים האחרונות. כמעט אף אחד מהם לא נכשל בגלל מהירות. הם נכשלו בגלל עמימות מבנית — בלי תשובה ברורה למה המערכת באמת עושה, למי, ועל איזה נתונים היא עובדת.
חמשת הדברים שתמיד נשברים ראשונים
דפוס הכשל עקבי מספיק כדי שנריץ צ׳ק־ליסט אבחוני על כל קודבסיס בירושה לפני שאנחנו מציעים עבודה. חמישה כשלים מבניים מסבירים בערך 90% מהבעיות שאנחנו מוצאים.
- —אין מודל נתונים מוגדר. הצוות עיצב מסכים ואז בנה טבלאות שיתאימו למסכים. מודל הנתונים צריך להגדיר מה המערכת יודעת — המסכים הם השלכות של הידע הזה.
- —אין מערכת תפקידים. אפליקציות מרובות משתמשים צריכות הרשאות מההתחלה. התאמת מודל אימות בדיעבד היא אחת הפעולות היקרות ביותר בהנדסה.
- —אין שכבת לוגיקה עסקית. הקוד הוא CRUD טהור בלי לוגיקת תחום, בלי כללי ולידציה ובלי מצבי זרימה. הלוגיקה העסקית נשארת בראש המייסדים.
- —אין תכנון למסלולי שגיאה. נבנו רק happy paths. מצבי שגיאה נדחו ל״אחר כך״ — ואחר כך לא מגיע.
- —אין הגדרת זרימת עבודה אמיתית. מהו רצף הפעולות שמשתמש מבצע כדי להשלים את המשימה המרכזית? זה מעולם לא נכתב.
בעיית מודל הנתונים כמעט תמיד בשורש
מודל הנתונים הוא השלד של מוצר תוכנה. הכול — UI, API, לוגיקה עסקית ודיווח — נבנה מעליו. טעות שם לא מתקנת מסך אחד; היא דורשת לבנות מחדש את היסוד.
הטעות הנפוצה ביותר היא schema-follows-UI. מעצב מציג מסכים. מהנדס בונה טבלאות שיחזיקו את מה שהמסכים מציגים. אחרי חצי שנה הלקוח מבקש תצוגת דיווח שלא נשקלה. הנתונים חסרים, מפוזרים או משוכפלים — ומייצרים תשובות סותרות.
מודל הנתונים אינו פרט בקאנד. הוא התשובה לשאלה: מה המערכת יודעת, ואיך הידע הזה מאורגן?
למה מערכת תפקידים חשובה מיום אחד
כמעט כל מוצר B2B SaaS מגיע בסוף למספר תפקידים. אדמין, מנהל, מפעיל, צופה לקריאה בלבד. השמות פחות חשובים — הצורך אוניברסלי: משתמשים שונים צריכים גישה שונה לחלקים שונים במערכת.
הטעות היא לבנות קודם למשתמש יחיד ואז להוסיף תפקידים. עד אז יש עשרות נקודות קצה שמניחות שכולם יכולים הכול. שכבת האימות מולחמת מבחוץ. הכיסוי בבדיקות תמיד חלש. הפגיעויות תמיד אמיתיות.
הגישה הנכונה: לתכנן מטריצת הרשאות ביום הראשון — גם אם מממשים רק שני תפקידים בהתחלה. הסכמה וה־API כבר מוכנים למודל המלא. הוספת תפקיד מאוחר יותר היא שינוי קונפיגורציה, לא ריפקטור.
כשל בהגדרת היקף
גורם הכשל השני בשכיחותו הוא הגדרתי, לא מבני. ההיקף מעולם לא היה אמיתי.
היקף אמיתי כולל שלושה דברים: פעולות המשתמש המדויקות שהמערכת תומכת בהן, הנתונים שהמערכת צריכה לביצוע, ומה קורה כשמשהו נכשל. רוב היקפי ה־MVP מתייחסים רק לחלק מהראשון.
מה אנחנו עושים במקום
כל התקשרות מוצר מתחילה במסמך היקף שמגדיר מודל נתונים, מפת זרימות ומטריצת הרשאות לפני שמעצבים מסך אחד. זה לוקח שבועיים עד ארבעה. דילוג על השלב הזה כמעט תמיד עולה ביוקר.
- —מודל נתונים: אילו ישויות קיימות, מה הן מכילות, איך הן קשורות
- —מפת זרימות: המצבים של כל ישות ומה גורם למעברים
- —מטריצת הרשאות: מי יכול לבצע אילו פעולות על אילו נתונים
- —טקסונומיית שגיאות: מצבי הכשל שהמערכת חייבת לטפל בהם בצורה נקייה
- —מפת אינטגרציות: לאילו מערכות חיצוניות המוצר מתחבר, ואיך
השאלה האמיתית למייסדים
לפני שמתחייבים לבנות מוצר, שאלו: האם אפשר לתאר בכתב מה המערכת יודעת, למי, ומה היא מאפשרת להם לעשות? אם התשובה לא ברורה — המוצר עדיין לא מוכן לבנייה. עבודת ההיקף אינה תקורה; היא העבודה עצמה.