روش مناسب برای ارزیابی پیشرفت طراحی
تو خیلی از پروژه‌ها علاوه بر اجرا، طراحی هم داریم. اشتباه رایج اینه که پیشرفت طراحی رو هم مثل اجرا تعیین می‌کنیم. مثلا می‌گیم که نقشه‌های سیستم اعلان حریق فلان ساختمون ماه پیش 32٪ بوده و این ماه شده 58٪.
این روش به دو دلیل درست نیست:
- تعیین پیشرفت واقعی طراحی عینی نیست. چطوری می‌خوایم بگیم که 58 درصد کار انجام شده؟ مثلا تعداد ساعت‌های کاری که روش انجام شده رو به برآورد اولیه تقسیم کنیم؟ بعیده برآورد اولیه کاملا درست باشه. چیکار می‌کنیم؟ عملا شهودی می‌شه. ولی پیشرفت کارهای اجرایی اینطوری نیست. مثلا پیشرفت ساخت یه دیوار رو وقتی می‌خوایم تعیین کنیم خیلی راحت مقدار ساخته شده‌ش رو به کل مقدارش تقسیم می‌کنیم و این کل مقدار کاملا مشخصه.
- نتایج طراحی معمولا پیش از تکمیل کاملا در دسترس مشاور مادر و کارفرما قرار نمی‌گیره و اون‌ها پیش از تکمیل نمی‌تونن دقیقا بدونن که چقدر کار انجام شده. این هم باز با دیوارکشی فرق می‌کنه، چون وقتی پیمانکار داره یه دیوار رو می‌سازه هرکسی می‌تونه بره، اون رو ببینه و بفهمه که چقدر کار انجام شده.
نتیجه هم اینه که پیمانکار یا مشاور طراح، مشاور مادر و کارفرما دایما در مورد درصدهای پیشرفت اختلاف نظر خواهند داشت.
به خاطر تمام این مسایله که معمولا تو همه جای دنیا پیشرفت طراحی رو مثل کارهای اجرایی ارزیابی نمی‌کنن. امیدوارم متوجه شده باشین که منظورم مشخص کردن پیشرفت فعالیت‌هاس، نه پیشرفت عناصر ساختار شکست کار (خلاصه فعالیت‌ها) که وابسته به ضرایب وزنی می‌شه.
توصیه می‌شه که پیشرفت کارهای طراحی مایل‌ستونی مشخص بشه (تو پم‌باک هم هست). اول باید تعدادی مایل‌ستون برای پیشرفت مشخص کنیم. مثلا این‌که پیشرفت طراحی صفر باقی می‌مونه، بعد از این‌که تکمیل شد می‌شه 70٪، بعد از این‌که تایید شد می‌شه 90٪ و بعد از تصویب می‌رسه به 100٪. به جای این‌ها مقادیر دیگه‌ای هم می‌شه استفاده کرد و حتی می‌شه تعداد مایل‌ستون‌ها رو هم کم و زیاد کرد. فقط یادتون باشه که تو تنظیم مایل‌ستون‌ها باید یه نکته رو در نظر داشته باشیم: هر مایل‌ستون باید متناظر با یه رویداد عینی و قابل ارزیابی باشه. تکمیل (همراه با ارائه)، تایید و تصویب همگی رویدادهایی رسمی و مشخص هستن.
یه نکته خیلی مهم رو هم باید رعایت کنین که متاسفانه خیلی جاها در نظر نمی‌گیرنش. وقتی قراره پیشرفت یه قسمتی از برنامه مایل‌ستونی باشه، باید مقدارهای برنامه‌ریزی شده‌ش هم مایل‌ستونی باشن. اگه اینطور نباشه مثلا یه جا گزارش می‌گیریم که پیشرفت برنامه‌ریزی شده یه فعالیت 36٪ هست و مقدار واقعی صفر. چرا؟ اگه با یه معیار هر دو پیشرفت رو محاسبه کنیم ممکنه پیشرفت واقعی بیشتر از 36٪ هم باشه، ولی چون هنوز تحویل نشده صفر در نظر گرفته می‌شه. تو این حالت عقب‌افتادگی نشون داده می‌شه و این اصلا درست نیست. پس باید در زمان برنامه‌ریزی فکری هم برای این ماجرا بکنیم.
حالا درباره این صحبت می‌کنیم که چطوری می‌شه این سیستم رو تو نرم‌افزار پیاده کرد. ممکنه خیلی از شماها به stepهای پیشرفت پریماورا فکر کنین. این stepها حالتی شبیه پیشرفت مایل‌ستونی دارن، ولی اصلا برای این کار نیستن. دلیلش هم اینه که شما مثلا می‌تونین سه‌تا step برای یه فعالیت طراحی کنین و باهاش اون سه‌تا مایل‌ستونی که مثال زدم رو پیاده‌سازی کنین. ولی هیچ جا مشخص نمی‌شه که این stepها از نظر زمانی چه حالتی دارن و پیشرفت برنامه‌ریزی شده هم مثل همیشه خطی محاسبه می‌شه. پس این رو می‌ذاریم کنار.
ادامه توضیح‌هایی که می‌دم تو پراجکت و پریماورا یکسان هستن. کاری که باید بکنیم ساده‌س، هر آیتم طراحی که قبلا یه فعالیت بود رو باید خرد کنیم به تعدادی فعالیت (یا مایل‌ستون). این حالت اولیه برنامه‌س:
حالا اون رو به همچین چیزی تبدیل می‌کنیم:
حالا موقع مشخص کردن ضرایب وزنی باید مراقب این فعالیت‌های جدید باشیم. اگه اون سیستمی که مثال زدم، یعنی 70٪ تکمیل، 90٪ تایید و 100٪ تصویب رو در نظر بگیریم، باید وزن هر آیتم رو به این صورت بین زیرمجموعه‌هاش تقسیم کنیم:
- انجام طراحی: صفر
- تکمیل: 70٪ وزن آیتم مادر
- تایید: 20٪ وزن آیتم مادر (مجموع تا این مرحله می‌شه 90٪)
- تصویب: 10٪ وزن آیتم مادر (مجموع تا پایان این مرحله می‌شه 100٪)
حالا برنامه‌مون کامل شده و پیشرفت‌های برنامه‌ریزی شده‌ش هم مطابق با سیستم مایل‌ستونی هست.
اگه چنین کاری رو کردین، می‌تونین یه کار خیلی خوب هم بکنین. هرکدوم از مراحل تکمیل (ارائه)، تایید و تصویب حداقل یه نامه هم دارن که مرجعش می‌شه. شماره نامه‌ها رو هم تو یه فیلد برای هر ردیف ذخیره کنین، یه روزی به دردتون می‌خوره.
آخرین نکته اینه که اگه مشاور مادر یا کارفرما هستین و قصد دارین برای قراردادهای بعدیتون از این سیستم استفاده کنین، حتما اون رو تو قرارداد قید کنین. اینطوری کارتون راحت‌تر پیش می‌ره.