בספר שאני קוראת עכשיו, Code Complete, יש פרק שלם המדבר על חשיבות האפיון. אחד מתתי הסעיפים דן בשאלה איך להתמודד עם שינויי אפיון שקורים תוך כדי פיתוח.
להלן כמה דברים שניתן לעשות כדי להוציא מתוק מעז:
- להשתמש ברשימה (checklist) של הדרישות בסוף הסעיף הזה (*) כדי להעריך את מסמך הדרישות אם הדרישות לא טובות מספיק, אז צריך להפסיק לעבוד, לחזור אחורה, ולתקן אותן לפני שממשיכים. נכון, זה נותן תחושה שאנחנו מתעכבים אם מפסיקים לקודד בשלב הזה. אבל אם אנחנו נוסעים משיקגו ללוס-אנג’לס, האם זה בזבוז זמן לעצור ולהתבוננן במפה כשאנחנו רואים שילוט לניו-יורק? לא. אם נוסעים בדרך לא נכונה, עלינו לעצור ולבדוק את הכיוון
- לוודא שכולם יודעים את מחיר שינוי הדרישות לקוחות מתרגשים כשהם מצליחים לחשוב על פיצ’ר חדש. בהתרגשותם, הדם שלהם מתדלל וזורם ללשד עצמותיהם, והם נהיים מסוחררים, ושוכחים את כל ישיבות האפיון שהיו, את טקס החתימה, ואת כל מסמך הדרישות. הדרך הקלה ביותר להתמודד עם מורעלי-פיצ’רים כאלה היא לומר: “וואו, זה נשמע רעיון מצוין. מאחר שזה לא נמצא במסמך הדרישות, אני אצור כעת לוח זמנים מעודכן והערכת עלות, כדי שתוכל להחליט אם אתה רוצה להוסיף את זה עכשיו או אחר-כך”. המלים “לוח זמנים” ו”עלות” מפכחים יותר מקפה ומקלחת קרה, והרבה פיצ’רים “חיוניים” יהפכו להיות “נחמד אם יהיה”
- ליזום הליך בקרת שינויים אם ההתלהבות של הלקוח ממשיכה, שקלו הקמת ועדת בקרה רשמית שתסקור הצעות לשינויים. זה בסדר גמור אם הלקוח משנה את דעתו ומחליט שהוא זקוק ליכולות נוספות. הבעיה היא שהם מציעים שינויים בתדירות כל כך גבוהה, שאי אפשר לעמוד בקצב. הליך מובנה של בקרת שינויים משמחת את כולם. אתם שמחים כי אתם יודעים שתצטרכו לעבוד על שינויים רק בזמן מסוים. הלקוח שמח כי הוא יודע שיש לכם תכנית לטיפול בבקשות שלו
- להשתמש בגישות פיתוח המתאימות עצמן לשינויים ישנן גישות פיתוח הממקסמות של היכולת להגיב לדרישות משתנות. גישת אב טיפוס אבולוציוני מסייעת לחקור דרישות מערכת לפני ששולחים את כל הכוחות לבנות אותה. מסירה אבולוציונית היא גישה המוסרת את המערכת בשלבים. אפשר לבנות מעט, לקבל מעט משוב מהמשתמשים, לתקן קצת את הכיוון, לעשות כמה שינויים, ולבנות עוד קצת. המפתח הוא שימוש במחזורי פיתוח קצרים כדי שאפשר יהיה להענות למשתמשים במהירות
- להיפטר מהפרוייקט אם הדרישות הן גרועות במיוחד או הפכפכות, ואף אחת מההצעות לעיל אינה אפשרית, בטל את הפרוייקט. אפילו אם זה לא אפשרי ממש לבטל את הפרוייקט, דמיינו איך זה יהיה לבטל אותו. נסו לחשב לאיזו רמה גרועה הפרוייקט יצטרך להגיע כדי שאפשר יהיה לבטל אותו. אם יש מקרה שבו הייתם נפטרים ממנו, לפחות שאלו את עצמכם מה ההבדל בין המקרה ההוא למקרה הנוכחי.
- לשמור על ה-business case של הפרוייקט הרבה ענייני דרישות נעלמים בקלות ברגע שחוזרים לסיבה לעסקית שבגללה הותחל הפרוייקט. דרישות שנראו כרעיונות טובים כשחשבו עליהם כ”פיצ’רים”, עשויים להראות כרעיונות גרועים כשמנסים לחשב את “הערך העסקי המוסף”. מתכנתים הזוכרים להתחשב בהשפעה העסקית של ההחלטה שלהם שווים את ערכם בזהב – למרות שהייתי שמח לקבל את העמלה שלי על הייעוץ הזה במזומן.