EVM برای پروژههای فناوری اطلاعات و نرمافزار
اعمال مدیریت ارزش کسب شده در پروژههای IT و نرمافزاری، نسبت به ساختوساز هم چالشبرانگیزتر و هم ظریفتر است. کار نرمافزاری انتزاعی است، نیازمندیها ممکن است در اواسط پروژه تغییر کنند، و اندازهگیری "درصد تکمیل" یک ویژگی ذاتاً ذهنی (subjective) است. با این حال، با انطباقهای مناسب، EVM ارزش فوقالعادهای برای مدیریت برنامههای فناوری اطلاعات و برای انتقال وضعیت بودجه و زمانبندی به ذینفعان غیرفنی فراهم میکند.
چالش اصلی: اندازهگیری ارزش کسب شده در نرمافزار
در ساختوساز، میتوانید پیشرفت فیزیکی را اندازهگیری کنید (متر مکعب بتنریزی شده، متر لولهگذاری شده). در نرمافزار، شما در حال اندازهگیری یک کار نامرئی هستید. سه رویکرد رایج عبارتند از:
1. استوری پوینتها (Agile EVM)
در محیطهای اسکرام (Scrum) یا کانبان (Kanban)، تیمها کار را در قالب استوری پوینتها (story points) تخمین میزنند. شما میتوانید EVM را بر اساس این موارد ایجاد کنید:
- BAC = کل استوری پوینتها × میانگین هزینه هر استوری پوینت
- PV = استوری پوینتهای برنامهریزی شده برای تکمیل تا این اسپرینت
- EV = استوری پوینتهای واقعاً تکمیل شده × میانگین هزینه هر استوری پوینت
- AC = هزینههای واقعی تیم (حقوق، زیرساخت، مجوزها) برای آن دوره
این رویکرد تنها زمانی استوریها را "انجام شده" (done) میداند که آنها با 'تعریف انجام شده' (Definition of Done) تیم مطابقت داشته باشند — و از دام "90٪ تکمیل شده" جلوگیری میکند.
2. EVM مبتنی بر نقطه عطف (Waterfall)
برای پروژههای آبشاری (waterfall) یا فازبندی شده، به نقاط عطف (milestones) وزنهای بودجهای اختصاص دهید (مثلاً نیازمندیها = 15٪، طراحی = 20٪، توسعه = 40٪، تست = 20٪، استقرار = 5٪). ارزش کسب شده تنها زمانی اعتبار مییابد که هر نقطه عطف بهطور کامل تکمیل و پذیرفته شود.
3. بستههای کاری وزندار
نرمافزار را به ماژولهای کاربردی (احراز هویت، گزارشگیری، API، رابط کاربری) تقسیم کنید. هزینه و مدت زمان هر یک را تخمین بزنید. پیشرفت را در سطح ماژول پیگیری کنید. این سنتیترین رویکرد EVM است که برای قراردادهای IT با قیمت ثابت مناسب است.
یک مثال عملی: پروژه توسعه نرمافزار
یک پروژه توسعه CRM سفارشی: BAC = 400,000 دلار، 8 اسپرینت (16 هفته). در اسپرینت 4 (هفته 8):
- کل استوری پوینتها: 800. میانگین هزینه هر استوری پوینت: 500 دلار.
- استوری پوینتهای برنامهریزی شده تا اسپرینت 4: 400. PV = 400 × 500 = 200,000 دلار
- استوری پوینتهای واقعاً تکمیل شده: 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) محدوده (Scope) ثابتی ندارد" | EVM با یک بکلاگ (backlog) اولویتبندی شده کار میکند — BAC نشاندهنده محدوده انتشار (release scope) توافق شده است، نه کل بکلاگ محصول |
| "نیازمندیها در هر اسپرینت تغییر میکنند" | از فرآیند کنترل تغییرات استفاده کنید. تغییرات تأیید شده در محدوده، BAC را بروز میکنند. تغییرات برنامهریزی نشده، انحرافاتی (variances) هستند که باید بررسی شوند. |
| "سرعت استوری پوینت (Velocity) مفیدتر است" | سرعت (Velocity) برای تیم عالی است؛ اما EVM دیدگاه مالی مورد نیاز حامیان و مدیران اجرایی را ارائه میدهد. |
| "ما پیشاپیش تخمین نمیزنیم" | EVM به یک خط پایه (baseline) نیاز دارد. حتی استوریهای با اندازههای نسبی نیز اگر بهطور پیوسته سایزبندی شوند، میتوانند پایهای تشکیل دهند. |
نکات عملی برای مدیران پروژه IT
- BAC خود را قبل از اسپرینت تنظیم کنید، نه بعد از آن: خط پایه باید پایدار باشد تا EVM معنادار شود.
- برای استوریهای در حال انجام فقط 0% یا 100% را در نظر بگیرید: از اعتبار دادن جزئی خودداری کنید؛ این کار EV را بهطور کاذب بالا میبرد و خطرات زمانبندی را پنهان میکند.
- روندهای CPI را بهصورت هفتگی پیگیری کنید: پروژههای نرمافزاری سریع حرکت میکنند. گزارشدهی ماهانه EVM ممکن است مشکلات را خیلی دیر متوجه شود.
- BAC مربوط به زیرساخت/عملیات را از توسعه جدا کنید: هزینههای زیرساختی محرکهای هزینه متفاوتی دارند و باید بهطور جداگانه پیگیری شوند.
- از EVM در سطح برنامه (Program) استفاده کنید: اگر چندین تیم چابک دارید، دادههای EV/AC آنها را در سطح برنامه برای گزارشدهی به مدیران اجرایی جمعآوری کنید.