איך בונים POC עם בית תוכנה
שלב 1: מגדירים השערה (שבוע 0)
לפני שפונים לבית תוכנה כלשהו, כתבו את השאלה האחת שה-POC חייב לענות עליה. לא שלוש שאלות. אחת.
השערות טובות:
- "מודל הסיווג שלנו מעבד 10,000 מסמכים בשעה, בדיוק של יותר מ-85%, על הנתונים האמיתיים שלנו."
- "האינטגרציה עם SAP מסנכרנת נתוני מלאי כמעט בזמן אמת, בלי Middleware."
- "משתמשים משלימים את תהליך הבקשה להלוואה בפחות מ-4 דקות."
השערות גרועות:
- "המוצר יכול לעבוד." (עמום מדי. מה זה "לעבוד"?)
- "המשתמשים יאהבו את זה." (תחושה, ולא מדד.)
- "זה אפשרי טכנית." (אפשרי באיזו עלות, באיזה לוח זמנים ובאיזו איכות?)
שלב 2: מגדירים היקף בלי רחמים (שבוע 0 עד שבוע 1)
מסמך ההיקף של POC צריך להיכנס בעמוד אחד. אם הוא דורש יותר, אתם בונים יותר מדי.
מה נכנס:
- ההשערה שנבדקת
- הרכיבים הטכניים שנבדקים
- מדדי הצלחה עם מספרים
- נתונים או מערכות שהלקוח צריך לספק
- לוח זמנים (2 עד 6 שבועות)
- מה מחוץ להיקף, במפורש
דוגמה אמיתית:
השערה: מודל ה-NLP שלנו מסווג פניות תמיכה ל-12 קטגוריות, בדיוק של יותר מ-90%, על פניות אמיתיות.
היקף: אימון המודל על 5,000 פניות היסטוריות (הלקוח מספק). העלאה לסביבת בדיקות. סיווג של 500 פניות חדשות. מדידת הדיוק בכל קטגוריה.
מדדי הצלחה: דיוק ממוצע של יותר מ-90% בכל הקטגוריות. אף קטגוריה לא מתחת ל-80%. זמן עיבוד של פחות מ-2 שניות לפנייה.
מחוץ להיקף: העלאה ל-Production, ממשק משתמש, אינטגרציית API, בדיקות משתמשים, Pipeline לאימון מחדש של המודל.
לוח זמנים: 3 שבועות
תקציב: 37,000 ש״ח
שלב 3: מסכמים על התוצרים (שבוע 1)
ה-POC מספק ראיות. המוצר יגיע אחר כך. בפועל, התוצרים הם:
- דוח טכני עם הממצאים, המדדים וההמלצות
- אב טיפוס עובד שמדגים את היכולת שנבדקה (לא מלוטש ולא מוכן ל-Production)
- המלצה להחלטה: ממשיכים, משנים גישה או עוצרים
- השלכות על הארכיטקטורה: מה התוצאות אומרות על הפיתוח המלא (בחירות טכנולוגיות, אזורי סיכון, הערכות מעודכנות)
ודאו שבית התוכנה מבין שה-POC יכול להיגמר בהמלצה "אל תבנו את זה". אם האינטרס של בית התוכנה הוא להמליץ תמיד להמשיך, כי הפיתוח המלא הוא ההכנסה הבאה שלו, ה-POC מאבד את הערך שלו ככלי בדיקה.
שלב 4: תנו נתונים אמיתיים (השלב שרוב הלקוחות מדלגים עליו)
הסיבה מספר 1 לתוצאות מטעות ב-POC: בודקים על נתוני דוגמה במקום על נתונים אמיתיים.
נתוני דוגמה נקיים. בנתונים אמיתיים יש שדות חסרים, פורמטים לא עקביים, מקרי קצה ונפחים שנתוני דוגמה אף פעם לא מכסים. מודל AI שמתפקד יפה על 200 רשומות דוגמה יכול לקרוס כשמזינים לו 20,000 רשומות אמיתיות ומבולגנות.
מה להכין:
- נתוני Production מייצגים (מותממים אם צריך, למשל בגלל חוק הגנת הפרטיות)
- גישה למערכות שמתחברים אליהן (אפילו גישת קריאה בלבד לסביבת Staging)
- נפחי תנועה או דפוסי עסקאות מציאותיים
- תיעוד של המוזרויות בנתונים שעלולות להשפיע על התוצאות
שלב 5: מריצים את ה-POC (שבועות 2 עד 5)
בית התוכנה בונה ובודק. המעורבות שלכם בשלב הזה מצומצמת, אבל מוגדרת:
- פגישת פתיחה לאישור ההיקף, הגישה לנתונים ומדדי ההצלחה
- פגישת מעקב שבועית (30 דקות) לבדיקת ההתקדמות ולהסרת חסמים
- סקירה מסכמת להערכת התוצאות מול מדדי ההצלחה
אל תיכנעו לפיתוי להרחיב את ההיקף באמצע. "כבר כשאנחנו שם, אפשר לבדוק גם..." זה בדיוק איך POC של 3 שבועות הופך לפרויקט של 10 שבועות. אם עולות שאלות חדשות בזמן ה-POC, רשמו אותן ל-POC המשך או לשלב האפיון.
שלב 6: מעריכים את התוצאות ביושר (שבועות 5 עד 6)
יש שלוש תוצאות אפשריות:
ירוק: ההשערה אומתה. הטכנולוגיה עובדת, האינטגרציה אפשרית, הביצועים עומדים בדרישות. ממשיכים לאפיון ולפיתוח מלא, עם הרבה יותר ביטחון.
צהוב: אימות חלקי. הגישה עובדת, אבל עם הסתייגויות: ביצועים נמוכים מהצפוי, צורך ברכיבים נוספים, מורכבות גבוהה ממה שחשבו. הפיתוח המלא עדיין אפשרי, אבל צריך לשנות גישה, לעדכן את לוח הזמנים או להגדיל את התקציב.
אדום: ההשערה הופרכה. הטכנולוגיה לא עובדת עם הנתונים שלכם, האינטגרציה לא מעשית, או שהביצועים פשוט לא מספיקים. זו בעצם התוצאה הכי שווה של POC. הוצאתם 45,000 ש״ח וגיליתם שהגישה לא עובדת, לפני שבניתם אותה ב-900,000 ש״ח.
מהעבודה שלנו: פיילוט שהרוויח את השליטה ברמזורים
מערכת ניהול התנועה מבוססת ה-AI שבנינו לחברת טכנולוגיות תנועה ישראלית התחילה בצומת אחד ובשאלה אחת: האם ה-AI יבחר תוכניות רמזור טובות יותר מהתזמון הקבוע? השקענו כשלושה שבועות בחיבור המערכת למצלמות ולבקרי הרמזורים הקיימים של העירייה. במשך כחמישה שבועות היא רצה במצב צל: בחרה מבין 10 תוכניות רמזור שהרגולטור אישר ותיעדה כל החלטה, בלי לגעת ברמזורים. רק אחרי שניצחה את התזמון הקבוע בבדיקות מדודות, היא קיבלה שליטה בזמן אמת. התוצאה: 25% פחות המתנה בצמתים ועד 30% פחות עיכובים לאוטובוסים. תוך כשלושה חודשים, הפיילוט בצומת אחד הפך לפריסה בכל העיר.
כמה לתקצב ל-POC
| היקף הפיתוח המלא | תקציב ה-POC | משך ה-POC |
|---|
| בין 150,000 ל-300,000 ש״ח | מ-15,000 ש״ח, ויכול להגיע ל-30,000 ש״ח | 2 עד 3 שבועות |
| בין 300,000 ל-900,000 ש״ח | מ-30,000 ש״ח, ויכול להגיע ל-60,000 ש״ח | 3 עד 4 שבועות |
| בין 900,000 ל-1.5 מיליון ש״ח | מ-45,000 ש״ח, ויכול להגיע ל-90,000 ש״ח | 4 עד 6 שבועות |
| יותר מ-1.5 מיליון ש״ח | מ-75,000 ש״ח, ויכול להגיע ל-150,000 ש״ח | 4 עד 8 שבועות |
POC צריך לעלות 3% עד 7% מהתקציב הכולל הצפוי. אם בית תוכנה מציע POC שעולה 15% עד 20% מהפיתוח המלא, הוא בונה MVP מוקטן ולא בודק השערה.
טעויות ששורפות את תקציב ה-POC
בונים ממשק משתמש לבדיקה טכנית
אם השאלה היא "ה-Backend יעמוד ב-50,000 חיבורים בו זמנית?", לא צריך ממשק משתמש. בנו סביבת בדיקה (Test Harness), ואת הממשק השאירו לשלב העיצוב.
בודקים עם הצוות הלא נכון
יש בתי תוכנה ששמים ג׳וניורים על POC (תקציב קטן, צוות קטן). אבל POC דורש מהנדסים בכירים: אנשים שמקבלים החלטות ארכיטקטורה נכונות, מזהים בעיות מהר ומביאים תובנות מעבר ל"עובד" או "לא עובד".
לא מגדירים מדדי הצלחה מראש
"נדע כשנראה" הוא לא מדד הצלחה. אם אי אפשר למדוד אם ה-POC הצליח, אי אפשר להחליט באחריות אם להמשיך או לעצור. הגדירו מדדים ספציפיים ומדידים לפני שהעבודה מתחילה.
נותנים ל-POC לתפוח לתוך MVP
POC מאמת הנחה אחת. MVP מאמת ביקוש בשוק. אלה שני תרגילים שונים, עם היקף ותקציב שונים. כשבעלי העניין מתחילים לבקש "ואפשר להוסיף גם הרשמה ודשבורד?", עברתם מ-POC לפיתוח מוצר.
ואחרי ה-POC?
אם ה-POC אישש את ההשערה, הצעד הבא הוא בדרך כלל שלב אפיון (4 עד 8 שבועות), ולא קפיצה ישר לפיתוח. ה-POC הוכיח שהרעיון עובד. האפיון מגדיר איך בונים את המוצר המלא: ארכיטקטורה, היקף, לוח זמנים ותקציב.
הסדר הוא: קודם POC, אחריו אפיון, ורק אז פיתוח.
כל שלב מוריד סיכון לפני ההשקעה הבאה, שהיא גדולה יותר. ה-POC עולה 45,000 ש״ח ובודק היתכנות. האפיון מתחיל ב-15,000 ש״ח, יכול להגיע ל-45,000 ש״ח ומגדיר את המוצר. הפיתוח מתחיל ב-600,000 ש״ח ויכול להגיע ל-1.5 מיליון ש״ח. בכל שער יש לכם את המידע להחליט אם ההשקעה הבאה שווה את זה.
שאלות נפוצות
כמה עולה POC?
POC טוב מתחיל ב-30,000 ש״ח ויכול להגיע ל-90,000 ש״ח, לפי היקף הפיתוח המלא. כלל אצבע: 3% עד 7% מהתקציב הכולל הצפוי של הפרויקט.
כמה זמן לוקח POC?
2 עד 6 שבועות. POC שנמשך שלושה חודשים הוא כבר MVP מוקטן, ולא בדיקה של השערה.
מה ההבדל בין POC ל-MVP?
POC עונה על שאלה אחת: האם הרעיון עובד טכנית. MVP הוא מוצר ראשון שמגיע למשתמשים אמיתיים ובודק את השוק. הסדר הנכון הוא קודם POC, אחריו אפיון, ורק אז פיתוח.
איך אנחנו מריצים POC ב-Globalbit
כל POC אצלנו מתחיל במסמך היקף של עמוד אחד, ששני הצדדים חותמים עליו. ההשערה, מדדי ההצלחה, לוח הזמנים והתקציב נסגרים לפני שמתחילים לפתח. על POC אנחנו שמים מהנדסים בכירים, אותם אנשים שיתכננו את הארכיטקטורה של הפיתוח המלא, כי איכות ה-POC תלויה בניסיון ולא בכמות הקוד. בדוחות ה-POC שלנו יש גם תוצאות וגם המלצות ארכיטקטורה לפיתוח המלא, כך ששלב האפיון מתחיל מראיות טכניות אמיתיות ולא מהנחות. ואם ה-POC מראה שהפרויקט לא צריך להמשיך כמו שתוכנן, אנחנו אומרים את זה. בצורה ברורה. ספרו לנו על ה-POC שאתם צריכים.
