مدیریت تغییرات پروژهٔ نرم‌افزاری: کنترل هزینه بدون ممنوع‌کردن تغییر
3 min read
تغییر ناگزیر است؛ بی‌نظمی در تغییر اختیاری است. چرخهٔ baseline، ثبت، برآورد اثر و تصمیم با فرم نمونه برای کنترل هزینهٔ تغییرات.
«تغییر ندهید» و «هر تغییری را بپذیر» هر دو بد پایان می‌یابند. اولی محصول را با واقعیت کسب‌وکار ناسازگار می‌کند و دومی بودجه و زمان را بی‌صدا از بین می‌برد. راه میانه، تغییر را ثبت و برآورد و تصمیم‌گیری کردن است. این مقاله راهنمای عملی است و هیچ تحویل قطعی را وعده نمی‌دهد؛ بندهای حقوقی و مالی قرارداد را با وکیل نهایی کنید.
دو دیدگاه ظاهراً متضاد
اصول Agile Manifesto می‌گوید تغییر نیازمندی‌ها حتی دیر در توسعه خوش‌آمد گفته می‌شود و فرایندهای چابک تغییر را به نفع مشتری به کار می‌گیرند. Scrum Guide هم Product Backlog را فهرستی «emergent» و مرتب از چیزهای لازم برای بهبود محصول می‌داند. یعنی تغییر عیب نیست. ولی این به‌معنی بی‌هزینه‌بودن تغییر نیست. McConnell می‌نویسد دقت برآورد به پالایش تعریف نرم‌افزار بستگی دارد، پس با هر تغییر در تعریف، برآورد قبلی باید دوباره دیده شود.
چرخهٔ پنج‌مرحله‌ای (پیشنهاد نویسنده)
- baseline: فهرست نسخه‌دار قابلیت‌ها و معیارهای پذیرش فعلی، همراه برآورد؛ برای ساخت آن برنامه‌ریزی پروژه پیش از کد را ببینید.
- ثبت: هر خواسته به‌صورت یک درخواست تغییر ثبت شود. استاندارد ISO/IEC/IEEE 14764 در حوزهٔ نگه‌داری، modification request را آیتم اطلاعاتی می‌داند که تغییر پیشنهادی به محصول یا سرویس را شناسایی و توصیف می‌کند.
- برآورد اثر: اثر بر زمان، هزینه، ریسک و سایر قابلیت‌ها.
- تصمیم: پذیرش، رد یا تعویق، توسط تصمیم‌گیر مشخص.
- به‌روزرسانی baseline: نسخهٔ جدید برنامه و برآورد ثبت شود.
فرم نمونهٔ درخواست تغییر
| فیلد | توضیح |
|---|---|
| شناسه و تاریخ | برای ردیابی |
| درخواست‌کننده | چه کسی و با چه نقشی |
| شرح و دلیل | چه مسئله‌ای حل می‌شود؟ |
| اثر بر معیار پذیرش | کدام معیار تغییر می‌کند؟ |
| برآورد اثر | بازهٔ زمان و هزینه با فرض‌ها |
| گزینه‌ها | نسخهٔ کوچک‌تر، تعویق، جایگزین |
| تصمیم و مسئول | پذیرش/رد/تعویق و امضا |
قواعد تصمیم
- فقط تصمیم‌گیر معرفی‌شده می‌تواند تغییر را بپذیرد؛ نقش‌ها را با نقش‌های پروژهٔ نرم‌افزاری روشن کنید.
- تغییر بدون اثر بر معیار پذیرش و برآورد، پذیرفته نمی‌شود.
- برای تغییرهای کوچک می‌توان سقف از پیش‌توافق‌شده تعیین کرد.
- برآورد اثر باید بازه باشد و فرض‌ها را بگوید؛ برای ابزار اولیه، برآوردگر پروژه نقطهٔ شروع است، نه قول.
اشتباه‌های رایج
- پذیرش شفاهی تغییر در جلسه و فراموش‌شدن اثر آن.
- قیمت‌گذاری تغییر بدون بازنگری وابستگی‌ها.
- مخلوط‌کردن اشکال با تغییر؛ اگر معیار پذیرش از قبل مکتوب نباشد، این مرز مبهم می‌ماند.
- نداشتن نسخهٔ baseline؛ هیچ‌کس نمی‌تواند بگوید «چه چیزی عوض شد».
اگر می‌خواهید برای پروژهٔ خود فرم و چرخهٔ تغییر طراحی کنید، می‌توانید در صفحهٔ شروع پروژه گفت‌وگو را شروع کنید؛ ارسال فرم تعهدی ایجاد نمی‌کند.
منابع و مراجع
- Principles behind the Agile Manifesto — Agile Manifesto authors (agilemanifesto.org).
- The Scrum Guide — Ken Schwaber و Jeff Sutherland، نسخهٔ نوامبر ۲۰۲۰.
- ISO/IEC/IEEE 14764:2022 (نمونهٔ پیش‌نمایش) — ISO/IEC/IEEE (نمونه در iTeh Standards)، ۲۰۲۲.
- Software Development's Cone of Uncertainty — Steve McConnell، Construx Software، White Paper، Version 1، January 2010.
Author
SE
Soheil Ebrahimpour is the founder of FutureForge. He works on product design, architecture, and getting custom software into production.
Related notes
If you are unsure about architecture or the build path, we can talk about the project.
Describe the problem and the constraints. If there is a fit, we will schedule a conversation.
