ה-SOW של הפרויקט

המטר האחרון של  שלב המכרז, המטר הראשון של שלב הפיתוח

 

מאת: אשר יובל, מתודה מחשבים בע"מ

 

כתיבת מסמך SOW (Statement of Work) (1) ו"גלגולו" באופן שוטף לאורך תהליך הפיתוח של הפרויקט, הם "החור השחור" של ניהול פרויקטי תוכנה. לחוסר ב- SOW מסודר יש מחיר כבד, המתבטא בחריגות חמורות בלוחות הזמנים, במשאבים, בתכולה של הפרויקט ובאיכות המערכת. חוסר ב- SOW מעכיר את יחסי הספק-לקוח, ובמקום שיהיו במצב של win-win הם מגיעים למצב של  lose-lose שבו כולם רק מפסידים. מאידך, כתיבה מסודרת של מסמך SOW איננה תוספת משמעותית לתקורות הניהול של הפרויקט. כל המידע והידע הנדרשים לבנייה של SOW ולתחזוקתו השוטפת נמצאים כבר בפרויקט! כל שנדרש הוא "לאסוף את הפתקים", לנצל ולשמר את התיעוד הקיים (מסמכי אפיון, מסמכי המכרז וכו') ולהשתמש באופן מושכל בכלים הזמינים על שולחן העבודה של כולנו. אין צורך בשום רכש נוסף.

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

ייזום

ייזום פרויקט הוא משימה לא קלה. צריך לשכנע את ההנהלה בעצם הצורך במערכת חדשה (או שדרוג של מערכת קיימת), צריך ללמוד מה קורה בארגונים דומים ומה "מצב השוק"; צריך לבדוק את ההיסטוריה בארגון, לראיין מספר אנשים, לבנות מצגת תמציתית ולכתוב מסמך ייזום של 7-10 עמודים. מפת"ח מסדיר באופן ברור שלב חשוב זה, כולל קישור לתכנית העבודה השנתית (שגם לגביה יש למפת"ח משנה סדורה). מפת"ח (מתודולוגית פיתוח ותחזוקה) (2) גם מספק גלופות מוכנות, דוגמאות, נוהל מקוצר וכו', אשר מקלים מאד על תהליך הייזום ובדיקת איכות התוצרים. במתודולוגיות אחרות נקרא שלב זה בשם קונספט(Concept)  וכלים רבים מאפשרים גם הצגה גראפית נאה ופונקציונאלית של הרעיון המרכזי העומד מאחורי הייזום.

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

אפיון

שלב האפיון הוא כבר משימה נכבדה בהרבה. מבחינה מתודולוגית, בשיטת מפת"ח, שלב זה הוא פשוט "עיבוי והרחבה" של הייזום, אלא שעיבוי והרחבה אלה מחייבים השקעה רצינית. כאן בעצם מתחיל הפרויקט. שלב זה כולל: לימוד מצב קיים, ניתוח פערים, ריאיון משתמשים, רישום וניהול דרישות, כתיבה של טיוטות שונות של מסמך אפיון והכנת מצגות. ע"פ שיטת מפת"ח, מסמך האפיון בנוי לפי מבנה עץ המערכת (3) (בדומה למסמך הייזום ולמסמכים בשלבים הבאים). לכן מסמך האפיון הוא בעצם עיבוי של מסמך הייזום. במקרים רבים, כולל שלב זה גם בניית דגםאבטיפוס, שביחד עם התיעוד הכתוב, מאפיין את המערכת הנדרשת. בשלב האפיון מתבצעות פעולות ניהול מרכזיות, שתמשכנה אח"כ לאורך הפרויקט, כגון: ניתוח סיכונים, אמידת עלויות, קביעת מדדים, ניהול תצורה של הפרויקט והמערכת, הערכת עלותתועלת, תכנית בדיקות, תכנית הטמעה ועוד. שלב האפיון הוא "עם הפנים פנימה". נרצה לדעת "כמה באמת זה יעלה לנו", לוחות זמנים יותר מדויקים, תכולה מדויקת של המערכת ("מה בעצם היא תעשה") ומה בכלל הסיכונים והסיכויים של המערכת.  (4)  וכפועל יוצא מכל זה, כיצד מומלץ לממש את המערכת: ע"י גורם פנימי או גורם חיצוני, ע"י שדרוג מערכת קיימת או בניית מערכת חדשה, על בסיס חבילת תוכנה או פיתוח עצמי, פיתוח סדרתי או פיתוח בסבבים ויחידות מסירה? כל זה נשמע קשה ומורכב? אכן כך. אפיון עשוי להגיע ל- 10-20% מעלות המערכת הכוללת.לא מעט ארגונים בוחרים להעסיק גורם מומחה (יועץ חיצוני) לביצוע שלב האפיון. תוצרי האפיון הם נכס וקניין רוחני של הארגון ונחשבים לסוד מסחרי (או ביטחוני).

אוקיי, סיימנו בהצלחה גם את האפיון ואישרו לנו להמשיך בפרויקט. אם מדובר בארגון ציבורי, או גם בארגון פרטי שרוצה לקבל את הפיתרון הטוב ביותר, סביר שהשלב הבא הוא שלב בקשה להצעות – RFP (Request for Proposals). גם מי שלא יצא לתהליך פומבי של בקשה להצעות ופניה לספקים, סביר שיערוך "מכרז סגור", או תהליך פנימי של ניתוח חלופות, וישקול דרכי פתרון שונות. התהליך העקרוני הוא דומה.

בקשה להצעות – RFP

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

• אחד החידושים המרכזיים של מפת"ח, גם בהשוואה עם מתודולוגיות בינ"ל ידועות, הוא הכלת שלב הבקשה להצעות כחלק אינטגראלי של מחזור החיים של הפרויקט. בקשה להצעות איננה רק שלב מנהלי – היא אבן יסוד בהנדסת תוכנה ומתודולוגית ניהול פרויקטים! היא הבסיס לראיית כל תהליך הפיתוח כדיאלוג של יחסי לקוח-ספק. חידוש זה מתאים מאד לדרישות של תקני איכות בינ"ל, דוגמת ISO9000. חידוש זה דורש גם כלים תומכים.
• המפרט שנשלח לכל הספקים, כחלק מהמכרז, הוא מסמך האפיון עצמו, בתוספת פרק מנהלה. מהדורה 7 החדשה של מפת"ח,(5) מכילה, בנוסף לשיפור בגלופות העבודה ובמצגות, גם עזרים חשובים לניהול המכרז, כגון: תיקיית פרויקט, גלופת גאנט – תכנית עבודה ומדריך מקוצר שהוא למעשה רשימת תיוג (Task list) לניהול שלב המכרז. גם גלופה למענה הספק למפרט נמצאת במפת"ח (כבר ממהדורה 5). חיבור המפרט ומענה הספק, ששניהם בנויים לפי סרגל עץ המערכת, הוא הבסיס ל- SOW שנראה בהרחבה בהמשך.
• מהדורה 7 של מפת"ח מדגישה גם מאד את העיקרון שבסיום בדיקת ההצעות. לא מכריזים על "ספק זוכה" או על "הצעה זוכה" (ושולחים לכל השאר מכתב האומר: "אנחנו מצטערים להודיע לכם כי הצעתכם לא זכתה …" ומתפללים שלא יגישו תביעות משפטיות), אלא נוקטים בשיטת "זכות הסירוב". במילים אחרות, מדרגים את שלוש ההצעות הטובות ביותר (או כל מספר אחר שהוחלט עליו מראש בזמן הוצאת המכרז ותועד במפ"ל [מסמך פנימי לבדיקה, מסמך הגדרת הקריטריונים לבדיקת הצעות הספקים]) באופן הבא: ספק X – זכות סירוב ראשונה – (First refusal), ספק Y – זכות סירוב שנייה וכו'. מודיעים לספק "זכות הסירוב הראשונה" שיש כעת חודשיים (או שוב, כל משך זמן אחר שהוחלט עליו מראש בזמן הוצאת המכרז) להשלים את ההתקשרות. אם לא תושלם ההתקשרות תוך פרק זמן זה, זכות הלקוח לגשת לספק השני בלי לפתוח מחדש את המכרז. יש לציין כי בשלב זה מבוצעת פעילות הכנת מסמך ה- SOW. המסמך מבוסס על מסמך האפיון (המכרז), ועל מענה הספק. הסברים בהמשך.

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

שלב עיצוב ובנייה – פיתוח המערכת

אין ספק שהמעבר משלב בקשה להצעות לתחילת הפיתוח (עיצוב ובנייה) הוא רגע קריטי בחיי כל פרויקט. לכאורה, הכול טוב. סיימנו בהצלחה את שלב המכרז (או ניתוח החלופות), בחרנו ספק (או פתרוןחלופה מועדפת), הצטלמנו לעיתון, חיוכים, לחיצות ידיים והרמות כוסית. ירח דבש אמיתי! וכולנו יודעים שהמסע בן אלף המיילים רק מתחיל. הסיפור האמיתי של ניהול פרויקט פיתוח תוכנה עוד לפנינו. בַּלִיבָּה של הפרויקט עומדת תכולה מוגדרת שיש לספקה בלו"ז ומשאבים לחוצים. לא עוברים חודש חודשיים ואט אט מתחילות העיזים לברוח מהדיר. וחוק האנטרופיה, האויב המושבע של המחשוב וניהול הפרויקטים המסודר, שוב מנצח את כולנו. (6) לצד פיתוח המערכת (שמעטים יודעים מה בדיוק קורה שם), מתחילה סדרה של פגישות ודיונים בין נציגי הספק והלקוח, במטרה לברר: "איפה אנחנו עומדים?", "האם אתם בטוחים שתעמדו בלוחות הזמנים ובתקציב?", "למה כל הזמן משנים את תכולת הפרויקט?", "נדרשת הגדלת התקציב?" וכו'. והשאלות המתבקשות צצות ועולות:

• מה יהיה כשנגיע לבדיקות? מול מה נבדוק? מול תיק האפיון המקורי? מול תיק העיצוב האחרון? איפה הוא?
• מה קרה לכל ההשקעה העצומה שהשקענו בשלבים הקודמים?
• איפה היועץ שביצע את האפיון וליווה את המכרז? היכן הפיקוח שלו? היכן האחריות שלו?
• האם מראש נגזר על הלקוח והספק להתנהל בעימותים אינסופיים וביחסי lose-lose?
• מתי נלמד לנהל פרויקטים בלי חריגות וכשלים?

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

ה- SOW של הפרויקט

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

כיצד בונים SOW?

בעיקרון, אין דבר פשוט מבניית SOW, ולכן גם אין דבר יותר בלתי נסלח מאי בנייתו. בהיבט המתודולוגי, SOW הוא מיזוג (merge) של המפרט (מסמך האפיון) והצעת הספק. בשיטת מפת"ח, כיון ששניהם בנויים על בסיס אותו סרגל עץ המערכת, השילוב הוא עימות תכנים, סעיף מול סעיף ואימותם. גם בהיבט הטכני, זוהי פעולה פשוטה הנשענת על תכונות פשוטות של כל מעבד תמלילים מודרני (בפרט אם שני המסמכים נכתבו באותה תוכנה ונמצאים במדיה ממוחשבת). עיקר המאמץ הוא בהיבט התוכן והמהות, היינו, בהשגת הסכמת שני הצדדים – הלקוח והספק – על נוסח משותף ומוסכם בכל סעיף וסעיף של עץ המערכת. במילים אחרות, להגיע בפרק זמן קצר להסכמה על עץ המערכת של הפרויקט. דורש מאמץ? ודאי. אבל מה האלטרנטיבה? לא לעשות את זה? לצאת לדרך בלי SOW מוסכם? להתחיל מסמך חדש? ועוד הערה לגבי המאמץ: זה עתה סיימנו את בדיקת המכרז והחלטנו לתת לספק X את זכות הסירוב הראשונה. בבדיקת המכרז כבר הפגשנו, בכל סעיף, את דרישות המפרט מול מענה הספק. מדוע עכשיו, כאשר מנסים למזג את שני המסמכים למסמך אחד, מתעוררים קשיים? מה לא מוסכם? האם התרשלנו בבדיקה? האם צד אחד מנסה כעת "להרוויח" ע"ח הצד השני?

 

כיצד נעזרים  ב- SOW?

חיוני ביותר להציג את ה- SOW על הפורטל הארגוני, כך שמירב האנשים בפרויקט (ובארגון וגורמי חוץ מורשים) יוכל לצפות בו ולבחון אותו בכל רגע. לשם כך פיתחה חברת מתודה מחשבים כלי בסביבת ה- web, פשוט וזול, אשר יודע "לעבד" כל מסמך Word מסוגנן ומובנה לממשק HTML שמאפשר ניווט קל ופשוט, כולל:

• תוכן עניינים
• דפדוף נוח "מעלה ומטה" במסמך
• תמיכה בתמצית מנהלים
• הצגה מרוכזת של רשימת האיורים
• אינדקס
• חיפוש
• הדפסות סלקטיביות
• הצגה בפורמט PDF
• פעולת "התחל" – resume
• שליחת תזכורות והצבעות בדוא"ל
• קישור לתיקייה

תכונה אחרונה זו, אשר מקשרת את המסמך אל תיקיית הפרויקט, היא ציר מרכזי בכלי ובשיטה. המשמעות הטכנית של הכלי, היא היכולת להחזיק, בכל רגע נתון במהלך הפרויקט, מסמך יציב ו"סגור" – תיק המערכת הנוכחי – לצד מסמכים ונספחים המשקפים את המהלך הדינאמי של הפרויקט: דיונים וסקרים (Project reviews), סיעור מוחות, תכתובות, שינויים וכו'. המשמעות המתודולוגית של השיטה, היא ראיית ניהול הפרויקט בשתי נקודות מבט חיוניות, במקביל: הצגה שוטפת של ה- baseline המוסכם האחרון של הפרויקט, לצד שינויים ואירועים שוטפים אשר מתרחשים בפרויקט.

כיצד מתחזקים SOW?

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

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

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

 

סיכום – כלב ציד מול כלב בית

ידיד טוב שלי סח לי פעם את המשל הבא: "מה בין כלב ציד לכלב בית חית מחמד? ציידים מקצועיים יוצאים ליער לצוד איל גדול (היום זה כבר אסור באנגליה). הסוסים דוהרים, תוקעים בחצוצרות, הכלבים המלווים פותחים במרוצה – כולם שועטים "קדימה הסתער" לאתר ולצוד את האיל הגדול. והנה מקפצת לה ארנבת לרוחב השביל וממהרת להסתתר בסבך היער. ארנבת זה גם משהו, לא כן? 5-6 ארנבות זה בערך איל, לא כך? כאן נקודת המבחן האמיתית בין כלב ציד וכלב בית חית מחמד. כלב בית, סוטה מהשביל ומתחיל לרדוף אחרי הארנבת. כלב ציד לעומתו, דבק במשימה שהוצבה – הוא אחרי האיל הגדול ולא אחרי ארנבות".

כולנו בעד כלב הציד. כולנו מבינים מה הנזק של סטייה מהמשימה העיקרית והריצה אחרי "ארנבות מזדמנות", אבל חסר לנו הכלי שידריך וינחה אותנו. כלי שמלווה במתודולוגיה ברורה ובהירה. אז הנה הכלי והנה המתודולוגיה: SOW בשיטת מפת"ח אשר משמר את כל ההשקעה שלנו בפרויקט עד תחילת הפיתוח (10-20% מעלות המערכת הכוללת, כבר אמרנו?) ומגן על ההשקעות העתידיות. נחישות הביצוע כבר תלויה בכל אחד ואחת מאיתנו.

 

 

 

 

 

 

 

 

 

הערות:

1.SOW – Statement of Work – מסמך תכולת (העבודה של) הפרויקט. זהו מונח מאד מקובל בהנדסה וניהול פרויקטים, ולפיכך גם אנו נשתמש בו. למרות (ואולי בגלל) שכיחות המונח, אין הגדרה תקנית והסכמה לגבי הפורמט והמבנה שלו. במפת"ח, זהו עוד מסמך בשרשרת המסמכים אשר בנויים לפי עץ המערכת, ובכך שומרים על המשכיות ועקיבות של כל מסמכי הפרויקט, כפי שיוסבר בהמשך המאמר.

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

3. עץ המערכת הוא מושג מרכזי בשיטת מפת"ח. עץ המערכת הוא רשימת התיוג המרכזית של המערכת (הפרויקט). רשימה זו מכילה את כל הרכיבים המרכזיים של המערכת. השלמת רכיבים אלה, הגדרתם ובנייתם, היא למעשה כל הפרויקט. "בקצה העליון" מורכבת רשימה זו מחמישה רכיבי אב: 1. יעדים, 2. יישום, 3. טכנולוגיה, 4. מימוש, 5. עלות.
4. סוף שלב האפיון מתאים מאד להפעלת מודל ה- SWOT (Strengths, Weaknesses, Opportunities, Threats) על מנת לזהות את החוזקות, החולשות, ההזדמנויות והאיומים של המערכת והשלכותיהם על החוזקות, החולשות, ההזדמנויות והאיומים של הארגון. זהו נושא מעניין בפני עצמו ולא נוכל להאריך כאן.

5.בימים אלה מופצת מהדורה 7 החדשה של מפת"ח. מהדורה זו מציגה שיפורים רבים הן בתכני המתודולוגיה והן בכלי (בטכנולוגיה) שעל בסיסה בנויה המתודולוגיה. מפת"ח מהדורה 7 הוא מערכת Web מלאה הפועלת ע"ג שלוש פלטפורמות וסביבות עבודה: מחשב עצמאי (גרסת תקליטור), רשת אינטראנט ארגונית (גרסת רשת מקומית) ורשת האינטרנט (גרסת רשת עולמית). בהדרגה נבנית גם המהדורה באנגלית.

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

 

 

 

 

tweet[Google] Follow @leadersnet

 

 

מנהיגים ברשת

www.leadersnet.co.il

leaders@leadersnet.co.il

© כל הזכויות שמורות ל"מנהיגים ברשת"  מאי 2005. החומר מותר לשימוש אישי בלבד. אין לעשות בחומר שימוש מסחרי/עסקי ו/או להפיצו בכל דרך שהיא (להוציא באמצעות יצירת קישור למאמר ספציפי  ולעמוד הבית במקביל) מבלי לקבל רשות מפורשת בכתב מהנהלת האתר