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