אפיון מערכת: מדריך מעשי לפני שמתחילים לפתח
יזם מגיע עם רעיון טוב, קובץ עיצוב מוכן ולחץ בריא להוציא גרסה ראשונה לשוק. שלושה שבועות אחר כך מתברר שהמאפיין התכוון למשתמש אחד, המפתח בנה הרשאות אחרות, ומנהל המוצר בכלל רצה לסגור לקוח פיילוט עם יכולת שלא נכנסה למסמך. לא האנשים נכשלו כאן, אלא אפיון מערכת שלא נעילה החלטות. אפיון טוב לא נמדד במספר העמודים שלו, אלא במה שהוא חותם: גבולות MVP, קריטריוני קבלה שאפשר לבדוק, בעלות על נתונים וגבול ברור להחלטות של AI.
תוכן עניינים
- למה אפיון מערכת נשבר לפני השורה הראשונה
- מה נכנס לכל מסמך
- מה נכנס למסמך אפיון ומי חותם עליו
- איך אוספים דרישות וכותבים user stories
- דיאגרמות והחלטות בתוך האפיון הטכני
- איך מוצר ופיתוח עובדים על אותו בסיס
- כשלים באפיון ומה מתקנים לפני פיתוח
- איך מאשרים את האפיון ומתחילים לבנות
למה אפיון מערכת נשבר לפני השורה הראשונה
בקיק-אוף טיפוסי היזם מציג מסכים ורשימת פיצ'רים. כולם מהנהנים. בספרינט הראשון המוצר מספר שהמסך מיועד למנהל לקוח, העיצוב מציג תפריט של מנהל מערכת, והפיתוח שואל מי בכלל רשאי למחוק רשומה. אלה לא שלוש דעות על אותה מערכת, אלה שלוש מערכות שונות בתוך אותו קובץ.
אני מגדיר אפיון מערכת כרשומה המשותפת של ההחלטות, לא כנספח שמתאר מסכים. מי המשתמש, איזו בעיה נפתרת עבורו, איך מודדים שהיא נפתרה, מה נכנס לגרסה הראשונה ומה נשאר בחוץ בכוונה. כשהתשובות האלה לא כתובות, כל בעל תפקיד משלים אותן בעצמו, בדרך כלל בביטחון מלא.
הקצב הישראלי מחדד את הבעיה. לפי הדוח השנתי של רשות החדשנות, בשנת 2024 הוקמו בישראל כ-500 סטארטאפים חדשים, לעומת 622 בשנת 2023, ובמקביל נרשמה עלייה של יותר מ-50% בהגשות למסלול "תנופה", מכ-340 ב-2023 ליותר מ-500 ב-2024. הרבה רעיונות צעירים מתחרים על אותו הון ועל אותו זמן, ולכן כל סבב עבודה חוזרת שורף חלק גדול יותר מהרזרבה.
מה נועלים ב-Pre-Seed ומה משאירים פתוח
בשלבי Pre-Seed ו-Seed לא צריך מסמך כבד. צריך ארבעה דברים סגורים: בעיית משתמש חדה, מדדי הצלחה, גבול MVP והנחות שוק שאפשר לבדוק מהר. כל השאר יכול להישאר כיוון, אבל לא כהחלטה סמויה. אם עוד לא יודעים מי משלם, כותבים את זה כהנחה לבדיקה, לא כעובדה בתוך ה-backlog.
במקביל משאירים תשתית לצמיחה. מודל הרשאות, מבנה נתונים, אינטגרציות, אבטחה וניטור הם החלטות שקשה לשנות כשהפיילוט הופך ללקוחות משלמים. גם מוצר שנבנה מראש לשוק בינלאומי צריך לסגור מוקדם שפה, אזורי זמן, פרטיות ותהליכים עסקיים שונים בין מדינות. לא כדי לבנות הכל עכשיו, אלא כדי לא לסגור את הדלת בטעות.
אפיון מפחית אי-ודאות, הוא לא שלב אדמיניסטרטיבי.
מה נכנס לכל מסמך
חלק מהבלבול מתחיל בשם. בשיחה אחת, שלושה אנשים אומרים אפיון מערכת ומתכוונים לשלושה מסמכים שונים. מנהל מוצר מחפש החלטה עסקית, איש תפעול מחפש כללים למסך, וארכיטקט מחפש גבולות מערכת. עד שלא מפרידים ביניהם, כל סקירה הופכת לדיון על מה המסמך בכלל היה אמור לענות.
שלושה מסמכים שנקראים 'אפיון'
| מסמך | שאלה מרכזית | מה לא נכנס אליו | בעלים |
|---|---|---|---|
| PRD | למה בונים ולמי | ארכיטקטורה ומסדי נתונים | מנהל מוצר |
| אפיון פונקציונלי | מה המשתמש עושה ומה המערכת מגיבה | בחירת טכנולוגיה | מוצר ותפעול |
| אפיון טכני | איך בונים: ארכיטקטורה, ממשקים, אבטחה | מה המשתמש רואה במסך | ארכיטקט ופיתוח |
הסדר שבו כותבים אותם
מתחילים ב-PRD קצר: בעיה, משתמש יעד ומדד אחד שמוכיח שהבעיה הצטמצמה. אם אי אפשר לנסח את השלושה בעמוד אחד, המוצר עדיין לא ממוקד, והרחבת המסמך רק תסתיר את זה. ה-PRD גם מחליט מה לא בונים בגרסה הזאת, והחלק הזה חשוב לא פחות מרשימת היכולות.
אחריו כותבים את האפיון הפונקציונלי לזרימה המרכזית בלבד. כאן קובעים מה המשתמש עושה, איזו תגובה הוא מקבל, אילו כללים חלים על הפעולה ומה קורה בחריג. במערכת לאישור בקשות, למשל, כותבים מי מגיש, מי מאשר מעל סף מסוים, מה נחסם כשחסר מסמך, ואיזו הודעה מקבל המגיש כשהבקשה נדחתה.
ורק אז פותחים את האפיון הטכני, וגם אז רק לחלקים שמחייבים החלטת ארכיטקטורה. לא כל מסך צריך דיאגרמה, אבל כל אינטגרציה, הרשאה ושמירת מידע רגיש צריכות החלטה כתובה. כאן מוגדרים מודל הנתונים, הממשקים, גבולות המודולים והאבטחה, בלי לערבב לתוכם דיוני נראות.
הכשל שחוזר על עצמו
הכשל הנפוץ הוא לדלג ישר לאפיון טכני. הצוות מגדיר API, שדות ושירותים לפני שאיש סגר מה המשתמש עושה, ואז מפתח ממשקים מדויקים לצורך שאף אחד לא צריך. הטעות ההפוכה גם קיימת: PRD מלא בתועלות בלי אפיון פונקציונלי, כך שהפיתוח נאלץ להמציא את הכללים בזמן הכתיבה.
כלל אצבע פשוט עובד היטב כאן. מסמך שלא עונה על אחת משלוש השאלות, למה, מה, או איך, הוא חלקי. הוא יכול להיות טיוטה שימושית, אבל הוא עוד לא מוכן לחתימה ולא בסיס להתחייבות על זמן או תקציב.
מה נכנס למסמך אפיון ומי חותם עליו
מסמך אפיון מערכת יעיל הוא סט קצר וחתום, לא קובץ של מאה עמודים שאף אחד לא קורא. הטבלה הבאה היא רשימת ההשלמה שאני מביא לפגישת אפיון. כל שורה היא שכבה עם תוצר, בעלים ונקודת חתימה, והרעיון הוא לעבור עליה ולסמן בכנות מה חסר היום.
שכבות מסמך אפיון ונקודת החתימה
| שכבה | תוצר | בעלים | חותמים לפני |
|---|---|---|---|
| בעיה ומדדים | משפט בעיה, משתמש, KPI ו-Baseline | מוצר והנהלה | עיצוב |
| User stories | מזהה, עדיפות, תנאי קבלה | מנהל מוצר | פירוק לספרינט |
| תהליכים | As-Is, To-Be ותרחיש חריג | מוצר ותפעול | סקירת ארכיטקטורה |
| נתונים והרשאות | ישויות, בעלות, מטריצת תפקידים | ארכיטקט ומנהל מוצר | פיתוח |
| ממשקים | חוזה API, גרסה, retry, idempotency | פיתוח | קוד אינטגרציה |
| לא-פונקציונלי | זמינות, p95, אבטחה, פרטיות, נגישות | ארכיטקט ואבטחה | שחרור |
| AI אם קיים | מקורות, גבול החלטה, אדם בלולאה, rollback | מוצר וגורם אחראי | פיילוט |
| עקיבות | Baseline מאושר, מטריצה, תוכנית בדיקות | מוצר ו-QA | ספרינט |
מדדים לפני מסכים
השכבה הראשונה קובעת איך תדעו שהמערכת הצליחה. לפי דוח ישראל דיגיטלית של רשות החדשנות, תהליך רישוי דיגיטלי במשרד הבריאות הוערך כחוסך 200-300 שנות-רופא מבוזבזות מדי שנה. זו בדיוק הצורה הנכונה למדוד: תוצאה תפעולית, לא עמידה בתאריך מסירה. לכל תהליך מגדירים KPI כמו זמן מחזור, שיעור השלמה, שיעור שגיאות, עלות לפעולה או זמינות, מציבים Baseline לפני ההטמעה ויעד אחריה.
בשכבת הסיפורים בודקים שלושה דברים: מזהה ייחודי, עדיפות וקריטריון קבלה. בלי מזהה אי אפשר לעקוב אחרי שינוי, ובלי קבלה אי אפשר לסגור פיתוח. בשכבת התהליכים דורשים As-Is, To-Be ולפחות חריג אחד כתוב. אם הצוות לא יודע מה קורה כשנתון חסר, הזרימה המרכזית עדיין לא מובנת עד הסוף.
נתונים, ממשקים ודרישות שלא רואים במסך
בשכבת הנתונים מסמנים לכל ישות בעלים ולכל שדה רגיש מי רשאי לראות ולערוך אותו. בשכבת הממשקים לא מסתפקים בשם המערכת החיצונית. מגדירים חוזה API, גרסה, מדיניות retry ו-idempotency, כדי שקריאה כפולה לא תייצר חיוב כפול וכשל זמני לא יפיל את כל הזרימה. במערכת שמחוברת ל-ERP, CRM או סליקה, אלה לא פרטים טכניים, אלה כללי עבודה של העסק.
השכבה הלא-פונקציונלית היא זו שנשכחת ראשונה. במערכת SaaS או מוצר AI בודקים למשל נפחי שימוש, latency באחוזון 95, שיעור כשלי API, עלות חישוב לפעולה ואיכות נתונים. אם יש רכיב AI, מוסיפים מקורות נתונים מורשים, גבול החלטה, human-in-the-loop ודרך rollback לגרסת מודל קודמת. שכבת העקיבות סוגרת את הכל: Baseline מאושר, קשר בין דרישה לבדיקה, ותוכנית שמראה איך מוכיחים כל קריטריון.
עומק שונה ל-MVP ולמערכת ארגונית
ל-MVP של סטארטאפ מספיק שהשכבות קיימות בגרסה רזה: סיפורים, זרימה אחת, חוזה API, Wireframes ומסמך החלטות קצר. במערכת ארגונית שמחוברת לתשלומים ולמערכות ליבה, אותן שכבות בדיוק עמוקות יותר, כי מחיר הטעות גבוה יותר. הטעות היא למחוק שכבה, לא לכתוב אותה קצר.
זהירות אחת אחרונה לפני חתימה. אל תבנו את השכבות על נתוני הדגמה או על הנחות משתמשים שלא נבדקו. ראיון מובנה, הצלבה עם לוגים ונתוני תפעול קיימים, ו-PoC קטן לפני התחייבות לארכיטקטורה מלאה, חוסכים בדרך כלל יותר זמן מכל האצה בספרינט.
איך אוספים דרישות וכותבים user stories
איסוף דרישות טוב הוא סדר קבוע, לא סדנת סיעור מוחות. כשמתחילים מהרעיונות של כל המשתתפים, מקבלים רשימה ארוכה ומשכנעת שאין בה היררכיה. הסדר הבא מכריח את הצוות לענות על שאלות קשות לפני שהוא כותב פתרונות.
- רושמים מטרה עסקית ומדד הצלחה. לא תאריך מסירה, אלא מספר שאפשר למדוד אחרי ההשקה. בלי זה, כל דרישה נראית חשובה באותה מידה.
- ממפים בעלי עניין ותהליך As-Is. מי פותח פעולה, מי מאשר, מי רק צופה, ומה קורה כשהנתון המרכזי חסר. כאן מגלים בדרך כלל שהתהליך האמיתי שונה מהתרשים הרשמי.
- מציירים To-Be קצר. מסמנים גם מה לא משתנה בגרסה הראשונה, כדי שהמוצר החדש לא ייבלע את כל הארגון בבת אחת.
- מפרקים לפונקציונלי ולא-פונקציונלי בנפרד. אבטחה, זמינות ונגישות נבלעות בקלות בתוך תיאור מסך, ואז אף צוות לא בעלים עליהן.
- נותנים לכל דרישה מזהה והקשר. מזהה, בעלים עסקי, קריטריון קבלה מדיד, מקור נתונים, תלות טכנית וסיכון.
- כותבים user story. תפקיד, צורך ותועלת, עם תנאי קבלה בסגנון Given When Then.
- מתעדפים וחותכים. מה שלא משרת את הזרימה המרכזית יוצא מה-MVP, בכתב, לא בהבטחה בעל פה.
דוח ביקורת ממשלתי על פרויקטי מערכות מידע בחן את מחזור החיים משלב האפיון ועד העלייה לאוויר והדגיש את הצורך בבדיקת תאימות שיטתית בין המערכת המפותחת לבין האפיון המאושר. מזהים וקריטריוני קבלה הם בדיוק מה שהופך בדיקה כזו לאפשרית, במקום ויכוח על כוונות.
סיפור חלש מול סיפור שאפשר לבדוק
נניח מערכת SaaS לאישור הוצאות. סיפור חלש יקרא "המשתמש יכול לנהל הוצאות בקלות". אין בו תפקיד, אין בו מספר, ואין בו מקור נתון. QA לא יכול לבדוק קלות, ומפתח לא יכול לחסום פעולה לפי משפט כזה.
סיפור טוב נשמע אחרת: כמנהל צוות אני רוצה לקבל התראה כשהוצאה עולה על 2,000 ש"ח, כדי לאשר או לדחות לפני סגירת החודש. תנאי הקבלה משלימים אותו: Given הוצאה מעל הסף ממתינה לאישור, When המנהל פותח את תיבת המשימות, Then ההוצאה מסומנת, אי אפשר לסגור את החודש בלעדיה, וכל החלטה נרשמת ביומן עם שם המאשר.
בסוג של אפיון מערכת כזה, הסיפור הוא לא תיאור מסך יפה. הוא כלל עסקי עם התראה, חסימה ורישום. תרגיל מעשי לסיום: כתבו שלושה סיפורים לזרימה אחת בלבד, עם מספר בכל תנאי קבלה, וסמנו במפורש מה נשאר מחוץ לגרסה. אם אי אפשר לחתוך כלום, הגרסה עוד לא מוגדרת.
דיאגרמות והחלטות בתוך האפיון הטכני
אפיון טכני הוא לא שקף עם לוגואים של סטאק. הוא סט של החלטות שאפשר לבקר, לשנות ביודעין ולבדוק בעוד חצי שנה למה הן התקבלו. דיאגרמות הן הכלי שמכריח את ההחלטות האלה החוצה, כי בתרשים רואים מיד איפה עובר גבול ואיפה חסר חיבור.
לרוב המוצרים סט מינימלי מספיק: תרשים הקשר שמראה מי ומה מדבר עם המערכת, תרשים מכולות של אפליקציה, API ונתונים, זרימה אחת לתרחיש המרכזי, ומודל ישויות קצר. אם יש אישור, תשלום או מחזור חיים למסמך, מוסיפים מכונת מצבים, כי שם מסתתרים החריגים היקרים באמת.
מתי לוותר ומתי להעמיק
ב-MVP בלי אינטגרציות חיצוניות, תרשים הקשר וזרימה אחת עושים את רוב העבודה. ציור של כל שדה וכל endpoint בשלב הזה הוא בזבוז, כי הם ישתנו עם המשתמשים הראשונים. במערכת שמתחברת ל-ERP, CRM, סליקה או ספק זהויות, התמונה מתהפכת: צריך חוזה לכל ממשק ורצף כשל שמראה מה קורה כשהצד השני לא עונה, עונה פעמיים או מחזיר נתון חלקי.
השוק המקומי נוטה בדיוק לכיוון השני והמורכב. לפי דוח התעסוקה בהייטק של רשות החדשנות, מבין חברות ההייטק החדשות שהוקמו בישראל בשנים 2022 עד 2024, 22.2% פעלו בתחום התוכנה הארגונית, פינטק ומסחר מקוון היוו כ-10% כל אחד וסייבר 9.6%, כך שיותר ממחצית מהחברות החדשות פעלו באחד מארבעת התחומים. מערכות כאלה צריכות הרשאות, דוחות, עקיבות וציות כבר מהגרסה הראשונה, ולכן דיאגרמה שטחית לא תחזיק אותן.
הפשרה המרכזית בארכיטקטורה
ל-MVP אני ממליץ בדרך כלל על מונוליט מסודר עם מודולים ברורים. קל יותר להריץ, לבדוק ולפרוס אותו, וצוות קטן לא טובע בתקשורת בין שירותים. פיצול לשירותים נפרדים נכנס לתמונה כשיש עומס נקודתי אמיתי, צוותים נפרדים שמפתחים בקצב שונה, או רכיב שחייב להתקיים בעצמו מסיבות אבטחה. זו פשרה של עלות תפעול מול גמישות, ולא שאלה של אופנה.
אותו היגיון חל על בחירת React, Angular או Vue בצד הלקוח, Node.js או Python בשרת, ו-AWS, Azure או GCP בענן. כל אחת מהבחירות לגיטימית, וכולן צריכות משפט אחד במסמך: למה בחרנו בה, ומה נשבור אם נחליף אותה בעוד שנתיים.
בסוף, ארבע החלטות חייבות להיות כתובות בכל אפיון מערכת: איפה עוברים גבולות המודולים, מהו מודל ההרשאות, איפה נשמרים סודות כמו מפתחות וטוקנים, ואיך מנטרים כשלים וביצועים.
כלל מעשי: דיאגרמה בלי החלטת גבול היא ציור, לא אפיון.
איך מוצר ופיתוח עובדים על אותו בסיס
החיכוך המוכר לא מתחיל מחוסר רצון טוב. מנהל מוצר משנה ניסוח בסיפור באמצע הספרינט כי לקוח ביקש, מפתח ממלא פער בשתיקה כי לא רוצה לעצור את העבודה, ובסוף השבוע QA מגלה שאין תרחיש קבלה למה שכבר נבנה. כולם עבדו קשה. הבסיס פשוט נעלם מתחתיהם.
הפתרון הוא לא עוד ישיבת סטטוס. הפתרון הוא שלושה שערי איכות שבהם עוצרים לרגע וחותמים, לפני שהשלב הבא מתחיל.
שלושה שערים ומי עומד בכל שער
- אישור עסקי לפני עיצוב: מנהל המוצר חותם על הבעיה, על היעד ועל מה שנשאר בחוץ. מעצב לא מתחיל מסכים על כוונה שעוד מתווכחים עליה.
- סקירת ארכיטקטורה לפני פיתוח: הארכיטקט חותם על הגבולות, על מודל הנתונים ועל הסיכונים, והפיתוח חותם שההחלטות ישימות ושאפשר להעריך אותן.
- דמו מול תרחישי הקבלה לפני שחרור: QA ומנהל המוצר בודקים את מה שנבנה מול תנאי הקבלה הכתובים, לא מול זיכרון של שיחת מסדרון.
החלוקה חשובה כי היא מונעת את הישיבה שבה כולם אחראים ואף אחד לא מחליט. מוצר בעלים על בעיה ועדיפות. ארכיטקט בעלים על גבולות וסיכון. פיתוח בעלים על היתכנות והערכה. QA בעלים על כך שהקבלה בכלל ניתנת לבדיקה.
מה עושים עם שינוי היקף
שינוי לא נכנס בצ'אט. כל שינוי ב-אפיון מערכת עובר הערכת השפעה קצרה: מה הוא מזיז בזמן, בתקציב, באבטחה, בפרטיות ובביצועים. לפעמים התשובה היא כן, ולפעמים היא לדחות אותו לגרסה הבאה, אבל ההחלטה מתקבלת עם המחיר מול העיניים. זה ההבדל בין מסמך בסיס יציב, לבין backlog שזז כל הזמן בלי שמישהו אישר את התוצאה.
גם כלי AI שכותבים קוד לא מבטלים את השערים. הם מקצרים כתיבה, אבל אדם עדיין מאשר ארכיטקטורה, הרשאה וקוד שנוגע בכסף או במידע אישי. בצוות קטן של שלושה, פגישת חתך של שעה על השינוי מספיקה. כשיש ספק חיצוני או Team Extension, החלטה שלא נכתבה תישאר בראש של אדם אחד ותיעלם איתו, ולכן שם התיעוד אינו בירוקרטיה אלא ביטוח.
בלי שער, האפיון הוא הצעה.
כשלים באפיון ומה מתקנים לפני פיתוח
רוב הכשלים ב-אפיון מערכת נראים קודם בשטח ורק אחר כך במסמך. הטבלה הבאה היא כלי אבחון: אם מזהים את הסימן, התיקון שייך קודם לאפיון, לא לשכתוב של הקוד.
כשלי אפיון והתיקון לפני הפיתוח
| כשל | סימן בשטח | תיקון באפיון |
|---|---|---|
| רשימת פיצ'רים בלי בעיה | שלושה פירושים בספרינט הראשון | משפט בעיה ו-KPI אחד |
| Story בלי קבלה | QA לא יודע מתי נגמר | Given When Then עם מספר |
| אין מודל הרשאות | משתמש רואה שדה של תפקיד אחר | מטריצת תפקידים לפני קוד |
| API בלי חוזה | ריוורק בכל אינטגרציה | גרסה, retry ו-idempotency |
| AI כמו מסך רגיל | אין אחראי לתשובה שגויה | גבול החלטה, אדם בלולאה, rollback |
| שינוי היקף בצ'אט | תקציב ופרטיות זזים בלי החלטה | הערכת השפעה לפני קבלה |
| מסמך ארוך בלי חתימה | אף צוות לא עובד לפיו | Baseline קצר ומטריצת עקיבות |
פרטיות ואבטחה הן דרישה, לא סעיף אווירה
המשפט "המערכת תהיה מאובטחת" אינו דרישה שאפשר לבדוק. במקומו שואלים שאלות עם תשובות סגורות: איזה מידע באמת חייב להישמר ומה אפשר לא לאסוף, מי רשאי לראות שדה מסוים, איך מוחקים ומייצאים מידע לפי בקשה, איך נרשמות גישות ב-audit log, ומה קורה כשספק ענן או מודל AI חיצוני מעבד את המידע בדרך.
בישראל אי אפשר לדחות את זה לשלב הפיתוח. לפי הסיכום הרגולטורי לשנת 2025 של משרד ארנון, תדמור-לוי, הרשות להגנת הפרטיות חידדה את ההמלצה לבצע סקרי סיכונים ומבדקי חדירות ולבחון מחדש סיכונים לפחות אחת ל-18 חודשים, ובמאגרי מידע מסוימים קיימת חובה רגולטורית. לכן קריטריון הקבלה צריך לכלול מטריצת הרשאות, הצפנה, זמני שמירת מידע, התראות על גישה חריגה ונוהל שחזור, כולם כבדיקות שעוברות או נכשלות לפני השקה.
AI לא מאפיינים כמו עוד מסך
צ'אטבוט או סוכן שמחובר למערכת הם לא מסך נוסף. כאן כותבים מטרה עסקית, אילו נתונים מותר למודל לקרוא, מתי אסור למערכת להחליט בעצמה, מי מאשר שינוי במודל או במאגר הידע, איך מתעדים ובודקים תשובה שגויה, מהי העלות לפעולה ואיך חוזרים אחורה. בלי זה, אף אחד לא בעלים על התוצאה הראשונה שתתגלה כטעות מול לקוח.
ההבחנה הקריטית היא בין מערכת שמספקת המלצה לבין Agentic AI שמבצע פעולה. להמלצה מספיק תיעוד והסבר. לפעולה אוטונומית צריך גבול חריגה מותר, אישור מנהל כשהנתונים חסרים או כשהמודל לא בטוח, ותיעוד מלא של ההחלטה. אני מעדיף להתחיל כמעט תמיד מהמלצה עם אישור אנושי, ולשחרר אוטונומיה רק לפעולות שהוכיחו את עצמן לאורך זמן.
איך מאשרים את האפיון ומתחילים לבנות
צוות שמסיים מסמך אפיון נוטה לשאול את השאלה הלא נכונה: האם כתבנו מספיק. השאלה הנכונה היא מה המסמך חותם, ועליה אפשר לענות בכן או לא דרך חמישה תנאי יציאה. אם אחד מהם חסר, לא מתחילים לבנות את החלק שתלוי בו. זו כל הדיסציפלינה של אפיון מערכת במשפט אחד.
- יש משפט בעיה ומדד עם Baseline. יודעים מה פותרים ומה המצב היום.
- כל סיפור בגרסה הראשונה נושא מזהה וקבלה ב-Given When Then. שום "יכול לנהל" בלי מספר.
- יש זרימה ותרשים הקשר לתרחיש המרכזי. כולם רואים את אותם גבולות.
- הרשאות ושמירת מידע כתובים כבדיקה. לא כסיסמה כללית על אבטחה.
- כל שינוי פתוח עבר הערכת השפעה או הוצא מהגרסה. אין סעיפים תלויים באוויר.
אישור אינו ישיבה שבה מנידים ראשים. כל בעל תפקיד חותם על החלק שלו: המוצר על הבעיה והמדד, הפיתוח על הזרימה והארכיטקטורה, ובעל הנתונים על ההרשאות והשמירה. חתימה כזו היא התחייבות שאפשר להצביע עליה כשמתעורר ויכוח בשבוע השלישי של הספרינט.
יש הבדל בין מוכן ל-MVP לבין מוכן למערכת עם לקוחות וכסף. ב-MVP מותר לדחות סקייל, דוחות מתקדמים וחלק מהאוטומציה. אסור לדחות בעלות על נתון, מודל הרשאות וגבול החלטה של AI, כי אלה הדברים שמשתנים בכאב אחרי שיש משתמשים אמיתיים. במערכת שמשרתת לקוחות משלמים, גם חוזה API, ניטור ותוכנית שחזור חתומים לפני שהפיתוח מעמיק.
אם אין ארכיטקט פנימי, אפשר להעביר סקירת ארכיטקטורה לגורם חיצוני או לחזק צוות קיים, בתנאי שההחלטות נכנסות למסמך ולא נשארות אצל אדם אחד. מיסטרביט עובדת בשני המודלים האלה: ירון ביטון, מייסד החברה וה-CTO שלה, בוגר ממר"ם שבונה את האינטרנט יותר מ-20 שנה, ולחברה ניסיון של למעלה מעשור בפיתוח פרויקטי תוכנה מובילים. מתכנתים של החברה מוצבים בחברות רבות להשלמת ולעיתים גם להובלת צוותי הפיתוח אצלן. אם הבסיס מוכן וחסר רק מי שיאשר ארכיטקטורה וילווה את הבנייה, שיחה קצרה חוסכת מסמך של מאה עמודים.
אם יש לכם רעיון, MVP בדרך או מערכת קיימת שצריכה אפיון לפני הרחבה, מיסטרביט מלווה מהגדרת הבעיה, האפיון והארכיטקטורה ועד פיתוח תוכנה בהתאמה אישית, פתרונות AI וחיזוק צוותי פיתוח ב-Team Extension. התחילו מסקירת אפיון אחת מול חמישה תנאי היציאה, וצרו קשר עם מיסטרביט כדי לדעת בדיוק מה חתום אצלכם ומה עדיין פתוח לפני שכותבים שורת קוד.
