דמו, אבטיפוס, פיילוט ופרודקשן: מה המדריך מבטיח

לפני שמתחילים: מה בעצם מבטיח המדריך?#

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

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

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

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

ארבעה שלבים שאסור לערבב ביניהם#

הדגמה, אבטיפוס, פיילוט ופרודקשן#

Proof of Concept — הוכחת היתכנות (PoC): בודקים אם יכולת עקרונית קיימת. המבחן מצומצם ומוגדר מראש. לעיתים הקלט מבוקר, הנתונים מלאכותיים וחלק מהשלבים ידניים. אין בכך פסול, כל עוד אומרים זאת.

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

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

Production — שימוש מבצעי: יש משתמשים שנשענים על המערכת לעבודה שלהם; קיימים ציפיות לזמינות, איכות, פרטיות, תמיכה והתאוששות. לא בהכרח נדרשים 99.99% זמינות או צוות SRE, אבל כן נדרש מישהו שיכול לזהות כשל, לקבל החלטה ולשקם שירות בהתאם לסיכון.

MVP — Minimum Viable Product אינו שלב טכנולוגי בפני עצמו. זו גרסה מינימלית ושימושית של המוצר, שמאפשרת לבחון אם הצעת הערך אכן מועילה לקהל מוגדר ולהפיק למידה ממשתמשים אמיתיים. MVP אינו שם נרדף לכל ניסוי או לאבטיפוס. MVP יכול לכלול רכיבים ידניים או פיילוט, והאות V לא אומרת שאפשר לוותר על תנאי בטיחות בסיסיים. בהקשר של סיכון גבוה, המינימום הנדרש גדול יותר.

למה ההבחנה חשובה?#

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