SOW של הפרויקט המדריך

מבוא

SOW (Scope or Statement of Work) – הוא מסמך תכולת העבודה, מסמך הבקרה הראשי על פיתוח המערכת.

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

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

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

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

 

יתרונות ה- SOW ברורים:

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

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

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

SOW במחזור חיי הפרויקט

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

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

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

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

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

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

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

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

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

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

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

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

 ·         מה יהיה כשנגיע לבדיקות, מול מה נבדוק? מול תיק האפיון המקורי? מול הצעת הספק? מול תיק העיצוב האחרון? איפה הוא?

 ·         מה קרה לכל ההשקעה העצומה שהשקענו בשלבים הקודמים?

 ·         איפה היועץ שביצע את האפיון וליווה את המכרז? היכן הפיקוח שלו? היכן האחריות שלו?

 ·         האם מראש נגזר על הלקוח והספק להתנהל בעימותים אינסופיים וביחסי lose-lose?

 ·         מתי נלמד לנהל פרויקטים בלי חריגות וכשלים?

 

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

 

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

כיצד בונים SOW?

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

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

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

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

 ·         תוכן עניינים

 ·         דפדוף נוח "מעלה ומטה" במסמך

 ·         תמיכה בתמצית מנהלים

 ·         הצגה מרוכזת של רשימת האיורים

 ·         אינדקס

 ·         חיפוש

 ·         הדפסות סלקטיביות

 ·         הצגה בפורמט PDF

 ·         פעולת "התחל" - resume

 ·         שליחת תזכורות והצבעות בדוא"ל

 ·         קישור לתיקייה

 

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

האיור הבא ממחיש כיצד נאספים פריטי המידע של פרק 2 – יישום למשל אל תיקיית הפרויקט.

 

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

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

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

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

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

תיעוד קומפוננטיאלי – תמ"ר

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

השיטה מתבססת על:

 ·         תיעוד "בזמן" (JIT) של רכיבים חיוניים בלבד בהתאם לצורך, לתקציב ולמחזור החיים של המערכת

 ·         שיטה אחידה לשימור הידע לתחזוקת המערכת באמצעות תבניות מובנות וקבועות

 ·         ניהול מרכזי של רכיבי התיעוד באמצעות כלים ארגוניים

 

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

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

תמ"ר מורכב מארבעה שלבים:

 ·         יצירת הרכיבים

 ·         הכנה לשילוב

 ·         מאגר רכיבים ארגוני

 ·         כלים לניהול ותצוגה

 

תרשים התהליך בשיטת תמ"ר

תוצרים

תיקיית הפרויקט

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

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

 ·         תוצרי מערכת מוחשיים.

 

התיקייה מנהלת את התוצרים עצמם או קישורים לתוצרים (בעיקר המוחשיים) הנמצאים בספריות אחרות, כגון: סביבת הפיתוח והייצור של המערכת.

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

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

להלן המלצת מפת"ח לתיקייה לשלב הבקשה להצעות ובתוכה מסמכי ה-SOW:

מסמך תכולת הפרויקט SOW

בלשונית תוצרים בקיט זה מוצגת המלצת מפת"ח ליצירת מסמך SOW בכלי Office סטנדרטיים.

המסמך משלב למעשה בין ארבעה מקורות קלט כמבואר במדריך זה:

 ·         גוף הבקשה להצעות שהוצא ע"י הארגון

 ·         מענה המציע

 ·         שאלות שנשאלו על ידי המציעים במהלך הבקשה להצעות ותשובות הארגון

 ·         שאלות הבהרה שנשאלו על ידי הארגון ונענו על ידי המציעים

 

כל מקור קלט עוצב בצורה שונה על מנת להבליט את השוני ביניהם.

ניתן לבצע מיזוג זה בצורה ידנית על ידי העתקה והדבקה מממסמך למסמך.

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

 

דוגמה ל- SOW ממוחשב בפורטל הארגון/הפרויקט

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

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

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