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