לפני הקוד: האם המוצר פותר בעיה

לפני הקוד: האם המוצר פותר בעיה ולא רק מייצר פלט?#

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

יחידת הערך והשרשרת התפעולית#

לזה קוראים לעיתים Job to Be Done (JTBD) — העבודה שהמשתמש מנסה להשלים. במקום לתאר רק תכונה של תוכנה, מגדירים איזו התקדמות הוא רוצה להשיג, באילו נסיבות, ומה החלופה שלו. לא כל ניסוח של בעיית משתמש הוא מחקר JTBD מלא; כאן משתמשים בעיקרון כדי לא לאבד את הבעיה מאחורי הממשק.

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

בדקו ארבע שכבות ערך:

1. תוצאה: האם העבודה הסתיימה לשביעות רצון המשתמש, לא רק נוצר פלט?
2. זמן ומאמץ: כמה עבודה נדרשה, כולל תיקונים, אישורים, העברת נתונים ולמידת המערכת?
3. איכות וסיכון: האם התוצאה טובה לפחות מספיק, ומה קורה כשהיא שגויה?
4. אימוץ: האם המשתמש חוזר להשתמש, או מבצע שוב את העבודה בכלי הישן?

לזה קוראים קריטריוני קבלה (Acceptance Criteria) כאשר מפרטים מה ייחשב השלמה מוצלחת של דרישה או תרחיש. הם צריכים להיות ניתנים לבדיקה ולהגדיר גם את המצבים שבהם אין לקבל את התוצאה. זו הגדרה ממוקדת לפריט או לתרחיש; אין לבלבל אותה עם הגדרת השלמה כוללת של עבודת הפיתוח (DoD) שתופיע בהמשך.

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

הבטחות שמצריכות פירוק#

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

כשמספיק פתרון פשוט יותר#

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

עבודת בדיקה מעשית#

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