י יודע מהו הנושא המככב בכל תחקיר על פרויקט שנכשל?……מי שניחש שהנושא קשור לניהול ופיתוח דרישות – צדק! זהו כמובן לא הנושא היחיד, אך בהחלט נושא שחוזר בתדירות גבוהה. מסתבר שלהבין את דרישות הלקוחות, ולנהל אותן במהלך מחזור הפיתוח זהו נושא סבוך וקשה; הסיבות לכך הן רבות. בהיעדר ניהול דרישות שיטתי, ייתכן והמוצר או השירות שתפתחו לא יממש את כל הדרישות שהלקוחות בקשו מכם. בהיעדר תשתית טובה לניהול דרישות, שינויים שקורים במהלך הפרויקט, כולל שינויים בדרישות יכולים להביא להתבדרות של הפרויקט.
מחזור החיים של פיתוח מוצרים ושירותים מתחיל בהגדרת הדרישות. "כמו שנציע את המיטה כך נישן עליה". כלומר, אופן הבנת הדרישות וניהולן משפיע בצורה משמעותית על התוצר הסופי.
מאמר זה מנסה להתמודד עם הנושא באמצעות תהליך שיטתי, בהנחיית מודל ה-CMMI שמטפל בין היתר בנושא הנדסת מערכת.
הטיפול בדרישות, על פי מודל ה-CMMI מכוסה על ידי שני תחומי תהליך:
זהו תהליך ניהולי, המטפל בתהליך הניהול האדמיניסטרטיבי של דרישות המוצר או השירות ורכיביהם. תהליך ניהול הדרישות מתחיל מקבלת דרישות מהלקוח/ות ומכל בעלי העניין שעשויים לתרום הגדרה של צרכים ו/או אילוצים לגבי המוצר. בעלי העניין יכולים להיות גם גופי רגולציה, גופים מוסדיים שונים בארגון ועוד. הלקוחות מגדירים דרישות במונחי מה נדרש לעשות (למשל: ביצועים, תכונות); כמו כן, מטפל התהליך בשינויים בדרישות.
זהו תהליך הנדסי, המתרגם את דרישות הלקוח לדרישות הנדסיות; מחלק את הדרישות לדיסציפלינות (למשל: חומרה/תוכנה) או תתי מערכות. לאחר שחילקנו דרישות לדיסציפלינות, כל דיסציפלינה אחראית על מימוש הדרישות שבאחריותה. לפעמים אותה דרישה תבוצע על ידי כמה דיסציפלינות. תהליך התכן מתחיל מהדרישות ההנדסיות.
מאמר זה דן בנושא ניהול הדרישות בלבד. נושא פיתוח הדרישות יטופל במאמר אחר.
תהליך ניהול דרישות שיטתי דואג שלאורך כל מחזור הפיתוח יהיה אוסף מוגדר ומאושר של דרישות. כמו כן תהיה הלימה בין תוכניות העבודה של הפרויקט ומוצרי הביניים המופקים בתהליך לדרישות המוצר. אין הכוונה שכל הדרישות יהיו מוגדרות בתחילת הדרך. בהחלט אפשרי לפתח במודל איטרטיבי או אג'ילי. במקרים אלה כל שייאמר להלן, ניתן להתאמה כשמדובר באיטרציות, או במנות אג'יליות.
חמש הפרקטיקות בנושא ניהול שיטתי, מוצגות בדיאגרמה שלהלן, ומפורטות בהמשך:
עשה |
ואם לא תעשה… |
|
הבנת הדרישות
|
הגדר מראש מיהם ספקי הדרישות המקובלים ואת הקריטריונים לקבלת הדרישות; השג הבנה מספקי הדרישות לגבי המשמעות של הדרישות; נתח את הדרישות וודא עם הלקוח שהבנת אותן. השג אישור מהלקוח לדרישות הבסיס ובכך רתום אותו לפרויקט המתהווה. |
בהיעדר הגדרה ברורה ממי מקבלים דרישות, יש חשש מקבלת דרישות שאין צורך לבצען, או שיש סתירה בין ספקי הדרישות. במידה ואין אישור מהלקוח שדרישותיו הובנו, אין ערובה לכך שהמסר עבר במדויק; |
השגת מחויבות לדרישות |
השג מחויבות מכל בעלי העניין בארגון לפיתוח המוצר או השירות בהתאם לדרישות. במקרים רבים, האישור יושג לאחר הבנה עמוקה של משמעות יישום כל הדרישות, וקבלת המשאבים הנדרשים. |
אי אפשר להצליח ולסיים פיתוח מוצר או שירות שעומד בדרישות הלקוח בהיעדר מחויבות מגוף הפיתוח לפתח את המוצר בהתאם לדרישות. היעדר מחויבות מצד הפיתוח יכול לנבוע מאי הקצאת המשאבים הנדרשים. |
ניהול שינויים לדרישות |
הבן את משמעות השינוי וההשפעה שלו על הפרויקט מבחינת משאבים ולו"ז וכן מבחינת ההשפעה שיש לשינוי בדרישות מסוימות, על דרישות אחרות, וקבל החלטה מושכלת אם וכיצד לטפל בשינוי. |
קבלה פזיזה של שינויים בדרישות מבלי להבין את משמעותם, תגרום להתבדרות הפרויקט וחוסר שביעות רצון של הלקוחות ושאר בעלי העניין. |
ניהול עקיבות דו-כיוונית |
נהל עקיבות דו כיוונית בין הדרישות המקוריות לדרישות ברמות נמוכות יותר, ובין הדרישות למוצרי ביניים של תהליך הפיתוח, עד לבדיקות המאשרות שכל הדרישות מומשו ונבדקו. |
בהיעדר ניהול עקיבות קשה לדעת אם אכן כל הדרישות מומשו. כמו כן, במקרה של שינויים בדרישות מסוימות קשה לדעת במדויק על מה ישפיע השינוי. |
הלימה בין הדרישות לתוכנית העבודה |
במהלך כל התנהלות הפרויקט, בדוק שתוכניות העבודה אכן ממשות את כל הדרישות, לפי אבני הדרך שבתוכנית. כלומר, שיש הלימה בין אבני הדרך והתכולה שתוכננה להיות מוכנה בכל אבן דרך. במידה ומצאת סטייה, עדכן את התכנית בהתאם (באמצעות ניהול השינוי). |
עלולות להיווצר במהלך הפרויקט אי התאמות בין דרישות הלקוח/ות ותוכנית העבודה לחילופין, אי התאמות שנמצאות יכולות להיות מטופלות בצורה שאינה לוקחת בחשבון את השפעות השינוי. כתוצאה מכך, עלולים להיווצר פיגורים בלו"ז, או שיסתבר שהפרויקט לא ממש את התכולה המובטחת. |
בארגונים לא מעטים מצאתי שנושא ניהול ופיתוח הדרישות הוא "תפוח אדמה לוהט", שמעדיפים להעביר אותו מיד ליד ולדחות את הטיפול בו, עד ש…ימוסדו תהליכים אחרים, או יהיה תקציב מיוחד, או שמחכים לשינוי ארגוני שיגדיר פונקציה של הנדסת מערכות, או שיגדירו את האחריות לנושא בתפר שבין מנהל הפרויקט למנהל התוכנית, … ועוד כהנא וכהנא סיבות. ובינתיים – מתחילים לטפל בנושאים אחרים כמו ניהול בדיקות. קשה מאד לטפל בנושאים הקשורים לפיתוח מאמצע או מסוף הדרך. יתרה מזאת, תנאי לניהול בדיקות טוב הוא ניהול דרישות טוב! המלצתי – גשו ישר לעניין ! התחילו מההתחלה. בהצלחה!
==
האם הנושא מטופל בארגונכם?
איזה גוף אחראי לכך?
אשמח לשיתוף כיצד מנוהלות הדרישות בארגונכם; טוב? פחות טוב?
אשמח לשיתוף באחת הרשתות החברתיות שקישורן להלן