אפיון תוכנה: מה צריך להחליט לפני שמעריכים את היקף הפיתוח

להגדיר איזו החלטה ההערכה אמורה לאפשר

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

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

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

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

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

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

להפריד בין מה שידוע לבין מה שעדיין מניחים

לבדוק קודם את מה שעשוי לשנות את היקף העבודה

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

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

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

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

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

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

לתאר אילו תוצאות יוכיחו שהגרסה עובדת

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

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

לצרף להערכה את התנאים שעליהם היא נשענת

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

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

לסיים את הבירור בהחלטה

מקבל ההחלטה בפרויקט צריך לצאת עם החלטה ועם הבסיס שלה. שלב הבירור יכול להסתיים גם בלי פיתוח; מדריך GOV.UK מכיר במפורש בעצירה כתוצאה אפשרית. השתמשו במסמך כדי לבחור למה מתחייבים עכשיו:

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