برنامه‌ریزی برای تولید نرم‌افزار: بایدها

قبل از شرح قسمت ششم نوشته‌های تست جوئل، گفتم که از بایدها و نبایدهای برنامه‌ریزی و مدیریت پروژه‌های نرم‌افزاری می‌نویسم. در نوشته‌‌ای به مبحث نبایدها پرداختم. این نوشته به موضوع بایدها می‌پردازد.

برنامه ریزی برای تولید نرم‌افزار: بایدها

وقتی می‌خواهید برای تولید یک نرم‌افزار برنامه‌ریزی کنید باید همیشه در نظر داشته باشید که تولید نرم‌افزار بر خلاف سایر صنایع، بسیار ریسک پذیر است. در تولید نرم‌افزار شما با استفاده از توان نیروی انسانی اقدام به ایجاد یک محصول می‌کنید که چنانچه بر اساس اصول مهندسی ساخته نشده باشد، یا به سرانجام نمی‌رسد یا آن‌قدر تیم را مشغول نگهداری و رفع باگ می‌کند که از جنبه اقتصادی آن به شدت کاسته می‌شود. بر این اساس و با تکیه بر نظرات و تجربیات شخصی، ظرایفی که باید در برنامه‌ریزی برای تولید نرم‌افزار مورد توجه قرار بگیرد را با هم بررسی می‌کنیم:

• نظارت بر وضعیت پروژه: همیشه و همیشه در برنامه‌ریزی محصول نرم‌افزاری باید بتوانید وضعیت جاری پروژه را ارزیابی کنید. در نوشته گزارش پیشرفت پروژه در تیم‌های نرم‌افزاری در این خصوص صحبت کردم. از دید برنامه‌ریزی اگر نتوانید مشخص کنید که چه مقدار از کارها انجام شده و چه مقدار باقیمانده، همیشه در برابر تغییرات در برنامه (که کم هم نیستند) حالت منفعل خواهید داشت. زمان مناسب برای دریافت فیدبک از اجرا و پیشرفت پروژه به گمان من بازه‌های یک هفته‌ای است.
• ریسک‌های تولید را باید قبل از شروع کار شناسایی و در حین انجام پروژه مرتباً مانیتور کنید. رفتار مشتری و تغییرات احتمالی که در کار به وجود خواهند آمد یا مشکلات پلتفرم (شبکه، دیتابیس، دسترسی‌ها و ...) که روی استقرار نهایی کار تاثیر گذارند بخشی از این ریسک‌ها هستند.
• حوزه و چارچوب کار بایدمشخص شده باشد، اگر ابهامی هست تا رفع نشده، برنامه‌ریزی نکنید. پس از برنامه‌ریزی در ارائه زمان‌بندی‌ها به مشتریان یا افراد ذی‌نفع در پروژه همیشه تاریخ پایان کار را اعلام کنید.
• بایدبرای کارها milestone تعریف کنید. برنامه‌ریزی برای اجرا و استقرار یک پروژه شش ماهه در سه فاز 2 ماهه خیلی راحت‌تر از برنامه‌ریزی بلندمدت برای یک فاز اجرای طولانی 6 ماهه است و ریسک fail شدن کارها هم کمتر.
• در برنامه‌ریزی بایداهداف را واقع‌بینانه تعریف کنید. اگر کاری مثلاً 10 نفر ساعت تخمین زده شده، اجرای آن در یک روز کاری ممکن نیست. توجه داشته باشید که مدیر پروژه باید نسبت به زمان مفید کاری هر یک از اعضای تیم در یک روز کاری آگاه باشد. تصور اینکه اعضای یک تیم‌ نرم‌افزاری از ابتدا تا انتهای وقت اداری، بدون وقفه به کار و کدنویسی و دیباگ مشغولند تصور نادرستی است!
• چه در تیم‌های پروژه محور و در چه تیم‌هایی که به تولید نرم‌افزارها در قالب package مشغولند، ارتباط درست بین بخش‌های مختلف به خصوص بازرگانی و فنی یک نیاز جدی و جزء بایدهاست. تصور کنید که اگر از توقف یک پروژه به دلیل اختلافات مالی با کارفرما اطلاع نداشته باشید، چطور می‌خواهید وقتی که به خاطر این عدم اطلاع برای پروژه‌ای بدون سود صرف شده را به تیم بازگردانید؟
• بایدمسئولیت را به عهده بگیرید. اگر هیچ کس مسئولیت برنامه‌ریزی را به عهده نگیرد، شرایط به گونه‌ای رقم خواهد خورد که افراد تیم بیشتر از آنکه به دنبال پیشبرد کارها باشند، به دنبال راهی برای توجیه کردن و رفع مسئولیت از خود خواهند بود!
• برنامه‌ریزی شما بایددر برابر حدی از تغییرات منعطف باشد. برنامه‌هایی که بیش از حد fix شده باشند، معمولاً به نتیجه نمی‌رسند و کارهای برنامه‌ریزی شده آن‌ها تاخیر می‌خورند. این به معنی دست بالا گرفتن زمان‌های تخمینی نیست. در واقع ترکیبی است از واقع‌بینی، در نظر گرفتن زمان مفید کاری و تجربه.