מודדים בנפרד אישור קבלה, הכנת טיוטה ותוצאה עסקית מאומתת. מציגים ללקוח שממתין מצב מדויק, דרך לחזור לבקשה וצעד הבא ברור.
נכתב בסיוע AI. אלו המלצות מעשיות להגדרת היקף; הדוגמאות הן להמחשה ואינן תוצאות של לקוחות.
מתחילים מהתוצאה שהלקוח ממתין לה
לקוח מבקש אומדן לשירות. העוזר אומר מיד שהוא עובד על הבקשה, אך האומדן עדיין תלוי בעובדות עסקיות עדכניות ובבדיקה של איש צוות. משפט ראשון מהיר יכול להרגיע. הוא אינו אומר ללקוח מתי תהיה תוצאה שימושית או אם הבקשה תישמר לאחר סגירת הדפדפן.
באפיון סוכן AI מתארים את חוויית ההמתנה המלאה לצד משימת החשיבה. מה התקבל בפועל? איזו תלות מעכבת את הצעד הבא? היכן הלקוח יכול לבדוק שוב? מי מטפל כשהנתיב האוטומטי אינו יכול להסתיים? ההחלטות האלה עוזרות לקונה להעריך את התהליך מעבר להדגמה מהירה.
דף התכנון לזמנים בהמשך הוא תרגיל מקורי עם רשומות וזמנים שהומצאו להמחשה. הוא אינו תוצאה של לקוח AgenticShip, מדד ביצועים של ספק או התחייבות לזמן תגובה. הוא עוסק בבקשה עסקית כתובה; לשיחה קולית יש אילוצי אינטראקציה אחרים שדורשים בדיקות משלהם.
בוחרים שלושה שעונים לפני שמשווים מהירות
שעון אישור הקבלה נעצר כשהממשק יכול לאשר באמת שהבקשה התקבלה. שעון הטיוטה נעצר כשהטיוטה הנדרשת זמינה. שעון התוצאה נעצר כשהתוצאה העסקית שסוכמה מאומתת. מגדירים איזו ראיה תומכת בכל אבן דרך; קבלת פלט מהמודל לבדה עשויה למלא רק חלק מהמשימה.
בדוגמת האומדן מחליטים אם הצלחה פירושה טיוטה מוכנה לבדיקה, אומדן מאושר שמוכן לשליחה או אומדן שנמסר בפועל. אלו הגדרות שונות. תור לבדיקה הוא חלק מהזמן הכולל כאשר נדרש אישור לתוצאה שנבחרה, גם אם המודל עצמו מגיב במהירות.
מתעדים בנפרד המתנה בתור, המתנה לאחזור מידע או לכלי, עיבוד במודל וטיפול אנושי נדרש, ככל שהמימוש מאפשר לצפות בהם. שומרים גם את הזמן הכולל שחלף. אי אפשר פשוט לחבר פעילויות שחופפות בזמן, ושעונים ממערכות שונות זקוקים לבסיס זמן עקבי. ציר זמן צריך לחשוף את צוואר הבקבוק במקום לייצר מספר מרשים יותר.
עוברים על בקשה S-41 עם ראיה לכל אבן דרך
הבקשה הבדיונית S-41 מבקשת להכין אומדן ולאשר אותו לשליחה בידי הצוות. לסוכן מותר לאחזר עובדות מורשות ולנסח את האומדן. אדם צריך לאשר אותו. בתרגיל לא נשלחת הודעה. לכן אבן הדרך האחרונה פירושה שהאומדן מוכן לשליחת הצוות, ולא שנמסר ללקוח.
נניח שבבדיקה סינתטית נצפה הרצף הבא. כל הזמנים הם שניות מרגע קבלת אותה בקשה. אישור הקבלה אחרי שתי שניות והתוצאה המאושרת אחרי 52 שניות מתארים חוויות שונות. אף מספר אינו יעד מומלץ; מחליפים את הערכים המומצאים בתצפיות מבדיקות מייצגות של התהליך שלכם.
| זמן שחלף | אבן דרך | הראיה הנדרשת |
|---|---|---|
| 0 שניות | הבקשה התקבלה | לבקשה המורשית יש מזהה שמור ומצב המתנה |
| 2 שניות | הוצג אישור קבלה | הממשק מאשר קבלה בלי לטעון להשלמה |
| 6 שניות | החלה בדיקת מידע עסקי | היישום מתעד את ניסיון הבדיקה בפועל |
| 31 שניות | העובדות הנדרשות זמינות | תוצאת הבדיקה עוברת את בדיקות השלמות שסוכמו |
| 39 שניות | הטיוטה מוכנה לבדיקה | הטיוטה השמורה מקושרת לבקשה ולבודק |
| 52 שניות | האומדן המאושר מוכן | החלטת הבודק המורשה מתועדת; המסירה עדיין נפרדת |
מפרידים בין הבקשה לחיבור הפתוח
דפוס הבקשה והתשובה האסינכרוניות של Microsoft מפריד בין אישור קבלת בקשה ממושכת לבין מצבה ותוצאותיה בהמשך. הוא מתאר כתובת מצב שהלקוח יכול לבדוק בזמן שהעיבוד נמשך. זו אפשרות ארכיטקטונית לבחינה, ולא ראיה שסוכן מסוים כבר מממש אותה.
ב־S-41 מבקשים מצוות הפיתוח להדגים איך הממשק מוצא את הבקשה הקיימת אחרי רענון עמוד או חיבור מחדש. מזהה בקשה צריך לאפשר גישה רק לצופה מורשה. המצב השמור שמאחוריו צריך להיות מובחן מאנימציה או משיחה שאומרת שהעבודה מתבצעת.
מגדירים מה סגירת הדפדפן עושה בפועל במימוש הנבחר. אם העבודה נמשכת, הלקוח שחוזר צריך לראות את המצב המותר העדכני שלה. אם הניתוק עוצר עיבוד, מסבירים זאת. פתיחת העמוד מחדש אינה צריכה לשלוח בשקט בקשת אומדן נוספת. ביטול וטיפול בכפילויות דורשים כללי תהליך מפורשים במקום הנחות על חלון השיחה.
מציגים מצב שהיישום יכול לבסס
משתמשים בהודעות נפרדות לקבלה, לבדיקת מידע, להמתנה לבדיקה אנושית, למוכנות ולחוסר יכולת להשלים אוטומטית. מחברים כל הודעה למעבר מצב מתועד. משפט חדש שהמודל מייצר אינו, כשלעצמו, ראיה שבדיקה התחילה או שבודק קיבל אחריות. מציגים מצב לא ידוע או לא עדכני כשאי אפשר לאחזר ראיה עכשווית.
נמנעים מאחוז התקדמות או מאומדן זמן שנותר, אלא אם התהליך הנבחר יכול לבסס אותם. הצגה חוזרת של כמעט סיימנו בזמן שממתינים לשירות חיצוני יוצרת ציפייה שהיישום אינו יכול להצדיק. נותנים למשתמש צעד הבא נתמך: שמירת המזהה, השלמת מידע חסר או חזרה לבקשה קיימת. מסבירים תלות שהתעכבה בלי לחשוף הערות פנימיות פרטיות.
בהסבר של W3C על הודעות מצב מתוארת הנגשת שינויים רלוונטיים לטכנולוגיות מסייעות בלי להזיז את המיקוד. כוללים הודעות המתנה והשלמה בבדיקה הזו. סמל טעינה לבדו אינו מסביר את המצב העסקי; בודקים את הטקסט בפועל, את התנהגות ההכרזה ואת מסלול המקלדת, במקום להניח שעדכון חזותי מגיע לכולם.
בודקים את מסע ההמתנה עם עבודה שמתעכבת או נקטעת
משתמשים ברשומות סינתטיות עם שליחה וכתיבות בעלות השפעה מושבתות. מתחילים בבקשה רגילה, ואז מעכבים בנפרד את בדיקת המידע ואת הבדיקה האנושית. מרעננים את הממשק, מנתקים אותו וחוזרים דרך הנתיב הנתמך. מוודאים שאותה בקשה ומצבה האחרון נשארים מובנים, עם אומדן מיועד אחד במקום עבודה כפולה.
לאחר מכן משביתים את אחזור המצב ומדמים עובד שהפסיק להתקדם. מוודאים שהממשק אינו מציג התקדמות ישנה כעדכנית ואינו הופך אות חסר להצלחה. מגדירים מי מקבל מקרה שלא נפתר ואיך הלקוח מוצא את הצעד הבא. משאירים מגבלות עצירת ביצוע ביישום; מסך ההמתנה אינו המנגנון שאוכף אותן.
לבסוף מבקשים מבודק להסביר אם הבקשה התקבלה, מה עוד צריך לקרות ומה עליו לעשות עכשיו. מתעדים בכל נקודת בדיקה גם את ההודעה המוצגת וגם את המצב שמאחוריה בפועל. כוללים בדיקות עם טכנולוגיות מסייעות בהיקף הקבלה. מסך טעינה נעים מועיל כשהוא מתאר נתיב אמין לתוצאה או חריגה ברורה.
משפרים את העיכוב שחשוב לתוצאה שסוכמה
מודדים בקשות מייצגות לפי גרסת התהליך וסוג מקרה משמעותי. משאירים בקשות איטיות, שנכשלו ושטרם נפתרו גלויות בנקודת דיווח מוגדרת. מדווחים יחד על שעון אישור הקבלה ושעון התוצאה, עם ההגדרות וגודל המדגם שלהם. ספירה של בקשות מהירות שהצליחו בלבד מסתירה בדיוק את החוויה שהתרגיל אמור לבחון.
משתמשים בראיות הזמנים כדי לבחור שינוי. אם רוב הזמן של S-41 עובר בהמתנה לעובדות או לבדיקה, תגובה ראשונה מהירה יותר של המודל אינה פותרת את העיכוב הזה. בוחנים אם התהליך יכול לספק את העובדות מוקדם יותר או להקצות את הבדיקה בבירור, ואז בודקים את הנתיב שהשתנה. קושרים הבטחות לזמן תגובה להיקף שנמדד ולתלויות בפועל.
מקורות ראשוניים
ההנחיות למעלה מתארות את הגישה המוצעת של AgenticShip. המקורות הבאים מספקים רקע טכנולוגי להמלצות הרלוונטיות.