EVM לפרויקטי תוכנה ו-IT
יישום Earned Value Management על פרויקטי IT ותוכנה הוא מאתגר ומורכב יותר מאשר יישומו בבנייה. עבודת תוכנה היא מופשטת, דרישות יכולות להשתנות באמצע הפרויקט, ומדידת "אחוזי ההשלמה" של תכונה מסוימת היא סובייקטיבית מטבעה. עם זאת, עם ההתאמות הנכונות, EVM מספק ערך עצום לניהול תוכניות IT ולתקשור סטטוס התקציב ולוח הזמנים לבעלי עניין שאינם טכניים.
האתגר המרכזי: מדידת Earned Value בתוכנה
בבנייה, ניתן למדוד התקדמות פיזית (מטרים מעוקבים שיצקו, צינורות שהונחו). בתוכנה, אתה מודד עבודה בלתי נראית. שלוש הגישות הנפוצות ביותר:
1. Story Points (Agile EVM)
בסביבות Scrum או Kanban, צוותים מעריכים עבודה ב-story points. ניתן לבנות EVM על בסיס זה:
- BAC = סך כל ה-story points × עלות ממוצעת לכל story point
- PV = story points שמתוכננים להסתיים עד ספרינט זה
- EV = story points שהושלמו בפועל × עלות ממוצעת לכל story point
- AC = עלויות צוות בפועל (משכורות, תשתיות, רישיונות) לתקופה
גישה זו מזכה ב-EV עבור stories רק כאשר הם עומדים ב-"Definition of Done" של הצוות — מה שמונע את מלכודת ה-"90% הושלם".
2. EVM מבוסס אבני דרך (Waterfall)
עבור פרויקטי מפל-מים (waterfall) או שלבים (phase-gate), הקצה משקלי תקציב לאבני דרך (למשל, דרישות = 15%, עיצוב = 20%, פיתוח = 40%, בדיקות = 20%, פריסה = 5%). ה-Earned Value נצבר רק כאשר כל אבן דרך מושלמת ומתקבלת במלואה.
3. חבילות עבודה משוקללות
פרק את התוכנה למודולים פונקציונליים (אימות, דוחות, API, ממשק משתמש). הערך עלות ומשך זמן עבור כל אחד מהם. עקוב אחר ההשלמה ברמת המודול. זו הגישה המסורתית ביותר של EVM, ומתאימה לחוזי IT במחיר קבוע.
דוגמה מפורטת: פרויקט פיתוח תוכנה
פרויקט פיתוח CRM מותאם אישית: BAC = 400,000$, 8 ספרינטים (16 שבועות). בספרינט 4 (שבוע 8):
- סך כל ה-story points: 800. עלות ממוצעת ל-story point: 500$.
- story points שתוכננו עד ספרינט 4: 400. PV = 400 × 500$ = 200,000$
- story points שהושלמו בפועל: 320. EV = 320 × 500$ = 160,000$
- עלות בפועל (משכורות צוות + תשתיות): AC = 195,000$
SPI = EV ÷ PV = 160,000 ÷ 200,000 = 0.800 (פיגור של 20% מול התוכנית)
EAC = BAC ÷ CPI = 400,000 ÷ 0.821 = 487,211$
VAC = 400,000 − 487,211 = −87,211$
EVM ו-Agile: התנגדויות נפוצות
| התנגדות | תשובה |
|---|---|
| "ב-Agile אין תכולה (scope) קבועה" | EVM עובד עם backlog מתועדף — ה-BAC מייצג את תכולת השחרור שהוסכם עליה, לא את ה-backlog השלם של המוצר. |
| "דרישות משתנות בכל ספרינט" | השתמש בתהליך בקרת שינויים. שינויי תכולה מאושרים מעדכנים את ה-BAC. שינויים לא מתוכננים הם סטיות (variances) שיש לחקור. |
| "מהירות ה-story point שימושית יותר" | מהירות (Velocity) מצוינת לצוות; EVM מספק את המבט הפיננסי שנדרש על ידי נותני חסות ומנהלים. |
| "אנחנו לא מעריכים מראש" | EVM דורש קו בסיס. אפילו stories בגדלים יחסיים יכולים להוות בסיס אם הם מוערכים באופן עקבי. |
טיפים מעשיים למנהלי פרויקטים ב-IT
- קבע את ה-BAC שלך לפני הספרינט, לא אחרי: קו הבסיס חייב להיות יציב כדי ש-EVM יהיה משמעותי.
- ספור רק 0% או 100% עבור stories שנמצאים בתהליך: הימנע מזיכוי חלקי; זה מנפח את ה-EV ומסווה סיכוני לוח זמנים.
- עקוב אחר מגמות CPI באופן שבועי: פרויקטי תוכנה זזים מהר. דיווח EVM חודשי עשוי לתפוס בעיות מאוחר מדי.
- הפרד BAC של תשתיות/תפעול מול פיתוח: לעלויות תשתיות יש מניעי עלות שונים ויש לעקוב אחריהם בנפרד.
- השתמש ב-EVM ברמת התוכנית (Program): אם יש לך מספר צוותי Agile, אגד את נתוני ה-EV/AC שלהם ברמת התוכנית לדיווח מנהלים.