گزارش پیشرفت پروژه در تیم‌های نرم‌افزاری
پیشرفت پروژه‌های نرم‌افزاری رو می‌شه با «گزارش‌های پیشرفت» تیم سنجید. اما در کنار گزارش پیشرفت، توجه به مشکلات حین کار هم مهم است.
اگر از هر برنامه‌نویس یک تیم نرم‌افزاری بپرسید که وضعیت پروژه‌ای که به وی محول شده چطور است معمولاً پاسخ خواهید شنید که "95 درصدش تمومه!" یا "تمومه، فقط چند تا مشکل کوچولو مونده که برطرف بشه" اگر دو هفته یا دو ماه بعد هم از وی همین سوال را بپرسید دوباره همین جواب‌ها را خواهید شنید و اگر دلیل را جویا شوید معمولاً یک سری دلایل فنی به شما تحویل می‌شود!
چطور پیشرفت پروژه‌های نرم‌افزاری را اندازه‌گیری کنیم؟
پاسخ خیلی کوتاه به سوال فوق "استفاده از گزارش پیشرفت پروژه" است. ذهن برنامه‌نویس‌ها بیشتر معطوف به کیفیت و انجام کارهاست تا اندازه‌گیری میزان کار انجام شده یا میزان کار باقیمانده. مدیر پروژه برای اینکه بتواند ذهنیتی از وضعیت کلی پروژه نرم‌افزاری و موانع احتمالی در جهت رساندن پروژه به deadline داشته باشد باید به صورت شفاف از اعضای تیم گزارش پیشرفت بخواهد.
البته همیشه نوشتن گزارش پیشرفت برای برنامه‌نویسان سخت است، چرا که عدم پیشرفت پروژه را عیان می‌کند! این مساله قبل از آنکه به برنامه‌نویس برگردد به مدیر پروژه مرتبط است. تصور کنید که یک نقشه و مقداری مصالح را به تعدادی کارگر داده‌اید و از آن‌ها خواسته‌اید که یک ساختمان دو طبقه بسازند. آن‌ها هم شروع به کار کرده‌اند اما بعد از مدتی که به ساختمان سر می‌زنید می‌بینید کارها مطابق پیش‌بینی شما پیش نرفته است. موضوع وجدان و تعهد کاری داستان دیگری است که در نوشته جداگانه‌ای به آن خواهم پرداخت. مشکل اصلی در عدم پیشرفت پروژه ساختمانی، نبود مدیریت برای سنجش کار انجام شده و برنامه‌ریزی برای کارهای آینده است. وقتی این مدیریت وجود نداشته باشد، نتیجه روشن است: هر کدام از کارگران از ظن خودش یار می‌شود و طرح را مطابق با پیش‌بینی‌های خودش جلو می‌برد. اینجا یک نفر (یا یک تیم) لازم است که تصویر بزرگتری را از کلیت کار در ذهن داشته باشند و بتوانند اعضای تیم تولید را برای ساختن آن تصویر بزرگتر راهنمایی و رهبری کنند.
زمان و فرمت گزارش‌های پیشرفت پروژه
قبل از اینکه از اعضای تیم برنامه‌نویسی بخواهید که گزارش پیشرفت به شما بدهند، لازم است بدانید درخواست گزارش کار روزانه با گزارش پیشرفت متفاوت است. در واقع اینکه یک نفر در یک صفحه توضیح بدهد که چه کارهایی انجام داده باعث نمی‌شود که شما درکی از میزان پیشرفت کارها پیدا کنید. برای اینکه گزارش پیشرفت پروژه به شما یک دید کمی (با عدد و رقم) از میزان جلو رفتن کار بدهد باید کلیه کارهایی که در طول یک پروژه به لحاظ فنی باید انجام شود را لیست کنید و در صورت لزوم آن‌ها را تا حد امکان ریز کنید. بعد باید به هر کدام از این کارها و وظایف یک وزن بدهید که مشخص شود مثلاً اگر فلان بخش انجام شد، چند درصد از کل کار تمام می‌شود. آنگاه این وظایف را به صورت مشخص و بر اساس روالی که در تیم شما مرسوم است (ممکن است روش اسکرام باشد یا هر روش دیگر) به اعضای تیم واگذار کنید و در گزارش پیشرفت تنها از آن‌ها بخواهید اتمام یا عدم اتمام وظایف را به اطلاع شما برسانند.
نکته دیگری که در گزارش پیشرفت مهم است، دریافت مشکلات کار است. بارها پیش آمده که به خاطر تحلیل اولیه نادرست، تیم توسعه مجبور شده باشند کارهایی را از ابتدا و به روشی متفاوت انجام دهند. هزینه کشف و برنامه‌ریزی برای تغییر مسیر در ابتدای آن بسیار کمتر از انتهای آن است. بنابراین در هر گزارش پیشرفت باید مشکلاتی که سر انجام کارهای ناتمام فعلی وجود دارد بیان شود. تا اینجای کار منطق کار خیلی شبیه جلسات روزانه اسکرام شد اما واقعیت این است که مهم نیست اسم روش شما چیست، مهم نتیجه آن است.
نکته آخر در خصوص گزارش پیشرفت زمان درخواست آن است. به نظر من و بر اساس تجربیاتم، یک هفته زمان مناسبی برای دریافت گزارشات پیشرفت پروژه است. گزارشات روزانه معمولاً آزاردهنده هستند، چون ممکن است وظایف بیشتر از یک روز کاری به زمان احتیاج داشته باشند و سنجش میزان تکمیل شدن آن‌ها دشوار باشد. گزارشاتی که بیش از یک هفته باشند هم ریسک ایجاد تاخیر در delivery ها را بالا می‌برند چون مدیر پروژه دیر از مشکلات و بن بست‌های به وجود آمده در روال اجرای پروژه باخبر می‌شود.