מ־MVP שנבנה עם Claude או Codex למוצר אמיתי

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

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

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

מה כבר למדנו, אילו חלקים בנויים היטב, מה דורש חיזוק, ואיפה המשך העבודה על התשתית הקיימת יעלה יותר מהחלפתה?

על השאלה הזו עונים באמצעות בדיקה מסודרת, לא לפי עמדה עקרונית בעד או נגד קוד שנוצר עם AI.

ל־MVP יש שני סוגים של נכסים

הנכס הראשון הוא הידע המוצרי שנצבר:

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

הנכס השני הוא התשתית הטכנית:

• איך בנויים הנתונים וההרשאות?
• היכן נמצאים החוקים העסקיים?
• מה קורה כששירות חיצוני נכשל באמצע פעולה?
• האם אפשר לבדוק שוב ושוב את התהליכים הקריטיים?
• האם מפתח נוסף יכול להבין את המערכת ולשנות אותה בבטחה?
• האם אפשר לראות מה קורה בפרודקשן ולסייע למשתמש כשיש תקלה?

MVP יכול להיות מצוין מבחינת הידע המוצרי ועדיין לא בשל מבחינה טכנית. אין כאן סתירה. בדיקת השוק ובדיקת המוכנות לפרודקשן הן שתי בדיקות שונות.

מה בדרך כלל כדאי לנסות לשמור

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

ההבנה של המשתמשים

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

התהליך שעובד

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

החלטות מוצר ומסכים

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

ידע על נתונים ואינטגרציות

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

חלקים מהקוד

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

ארבע החלטות שונות שאפשר לקבל

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

להשאיר

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

לחזק

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

להחליף

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

לבנות מחדש

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

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

מה צריך לבדוק לפני פרודקשן

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

בעלות וגישה

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

זהות והרשאות

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

שלמות הנתונים

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

תקלות והתאוששות

האם הצוות יודע שנוצרה תקלה? האם אפשר לנסות שוב בלי ליצור כפילויות? האם יש גיבוי מתאים? האם אפשר להבין בדיעבד מה התרחש ולמי?

תחזוקה

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

עלויות ותלות בספקים

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

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

תהליך הערכה מעשי

לא חייבים להתחיל במסמך אפיון ארוך. אפשר לעבוד בסדר הבא:

1. מריצים את המוצר כמשתמש. מתעדים את התהליך המרכזי, החריגים והתקלות שכבר ידועות.
2. ממפים את המערכת. מזהים את בסיסי הקוד והנתונים, הספקים החיצוניים, הסביבות והבעלות על החשבונות.
3. עוקבים אחר פעולות קריטיות. בודקים איך שינוי עובר מהמסך דרך השרת ועד לנתונים.
4. מריצים את מה שכבר קיים. בודקים אם המוצר נבנה, עולה ועובר את הבדיקות הנוכחיות.
5. מתמקדים בסיכון. הזדהות, הרשאות, מידע רגיש, תשלומים, פעולות של סוכנים ורשומות עסקיות שקשה לשחזר.
6. מסווגים כל אזור. משאירים, מחזקים, מחליפים או בונים מחדש — עם הסבר להחלטה.
7. בונים תוכנית מדורגת. קודם מגנים על ההתנהגות החשובה, ואז משפרים את היסודות בלי למחוק את הידע שנצבר.

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

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

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

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

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

להמשך: פיתוח מערכות Web סביב התהליך העסקי האמיתי.

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