در گذشته رایج بود که پیشرفت پروژه‌های نرم‌افزاری را بر پایه تعداد خط برنامه‌ای که نوشته شده است بسنجند. زمانی شرکتی برنامه‌نویس بسیار خبره‌ای را استخدام کرد و در پایان ماه از او خواستند که تعداد خط برنامه‌ای که نوشته است را اعلام کند. مقداری که گزارش کرده بود عددی منفی بود! او در مدت ماه مشغول بررسی کدهای پیشین و اصلاح آن‌ها بود و در بسیاری موارد کدهای تکراری یا اضافه را پاک کرده بود. کار این فرد کمک فراوانی به پروژه کرده بود، ولی با معیار ارزیابی موجود اینگونه برداشت نمی‌شد.
این شیوه ارزیابی پیشرفت، که به وضوح کارایی مناسبی ندارد، امروزه چندان رایج نیست. دلیل اصلی برای از بین رفتن این روش، رواج شیوه‌های چابک و مخالفت آن‌ها با این نوع ارزیابی است. شیوه‌های رایج ارزیابی در پروژه‌های چابک کارایی نسبتا مناسبی دارند، ولی متاسفانه آن‌ها نیز به شکل دیگری منحرف شده‌اند. برای نمونه، در بسیاری از این روش‌ها فهرستی از کارها برای دوره پیش رو انتخاب می‌شوند. در برخی پروژه‌ها شمار کارهای تکمیل شده در پایان دوره را با آنچه انتخاب شده بود مقایسه می‌کنند و این مسئله برایشان معیار ارزیابی مهمیست. این معیار درست نیست، زیرا برنامه‌نویسان را تشویق می‌کند که در آغاز دوره کارهای کمتری را انتخاب کنند و آن هم به نوبه خود منجر به کاهش خروجی می‌شود، زیرا «کار به اندازه …
همانند منابع پروژه که محدودند، توان اندیشیدنمان هم محدود است. همان‌گونه که کوشش می‌کنیم از منابع پروژه بهینه استفاده کنیم، باید مراقب استفاده از توان اندیشیدنمان هم باشیم. در نقش مدیر پروژه باید به اعضای تیم پروژه نیز کمک کنید تا از توان ذهنی خود بهینه استفاده کنند.
اگر خود را درگیر ریزه‌کاری‌های پروژه و جنبه‌های فنی کنید، بخشی از توان اندیشیدنتان صرف خواهد شد و توان کمتری برای وظایف واقعیتان باقی می‌ماند. البته به جز آن دشواری‌های دیگری هم ایجاد می‌شود که پیش از این بررسیشان کردیم. فرض کنید توان اندیشیدنتان مبلغ محدودیست و برآنید که آن را در بهترین حوزه‌ها سرمایه‌گذاری کنید.
آیا قاعده ۸۰/۲۰ را می‌شناسید؟ بر پایه این قاعده، حدود ۸۰ درصد منافع بسیاری از دامنه‌ها با حدود ۲۰ درصد عناصرش به وجود می‌آیند. به آنچه شخصا در پروژه‌ها انجام می‌دهید بیندیشید: احتمالا حدود ۸۰ درصد نتایج مناسبی که می‌گیرید با ۲۰ درصد از کارهایی که کرده‌اید به دست آمده‌اند. بنا بر این، شاید بتوانید در فعالیت‌های خود بازبینی کنید و با حذف برخی از آن‌ها که نتیجه چندانی در بر ندارند، عناصر پربار را تقویت کنید.
قاعده ۸۰/۲۰ یکی از راهنماهای تدوین متدولوژی P3.express هم بوده است. به‌جای هدف قرار دادن ۱۰۰ درصد منافع مدیریت پروژه ساخت‌یافته با ۱۰۰ درصد کوشش، سیستمی ساخته شده است که با کمک آن بتوانید ۸۰ درصد منافع را با …
اگر هر بار که قرار است کاری انجام دهید روند آن را دوباره کشف و تدوین کنید، انرژی فراوانی لازم خواهد بود و احتمال اشتباه نیز بالا می‌رود. به جای آن بهتر است که جنبه‌های مشترک کارها را با عناصر تکرارپذیر مستند کرده، به‌تدریج بهبود دهید.
نمونه خوبی برای عناصر تکرارپذیر، چک‌لیست است. برای نمونه، اگر قرار است اسناد مهندسی فراوانی در شرکت ارزیابی شوند، هرآنچه باید چک شود را در چک‌لیستی مستند کنید و هر بار که فرآیند تکرار می‌شود به‌جای اندیشیدن به الزامات کنترلی، از آن لیست کمک بگیرید. در زمان به کارگیری لیست، چه‌بسا موارد بهبودی نیز به ذهنتان برسد که می‌توانید در چک‌لیست اعمال کرده، هم برای مورد در دست اقدام و هم برای موارد آینده به کار ببرید.
نمونه دیگر وجود چرخه‌های تکرارپذیر در متدولوژی‌هایی مانند P3.express است. فعالیت‌هایی که هر ماه یا هر هفته با روند ویژه‌ای تکرار می‌شوند به‌تدریج تبدیل به عادت می‌شوند و توان ذهنی کمتری نیاز خواهند داشت. توانی که اینگونه صرفه‌جویی کرده‌اید را می‌توانید صرف حل مسایل دیگر کنید.
ایمیلی برای تایید به آدرسی که ثبت کردید ارسال شد. بعد از تایید ایمیل، در خبرنامه سایت مشترک خواهید شد.
توجه داشته باشید که ممکن است ایمیل در پوشه اسپم قرار گرفته باشد. در این صورت علاوه بر تایید ایمیل، آن را از حالت اسپم نیز خارج کنید تا بتوانید در آینده خبرنامه را بدون مشکل دریافت کنید.
هرگاه تفاوت اجرا و برنامه انحرافی در متغیرهای پروژه مانند زمان و هزینه ایجاد کند، یا باید متغیرها را بازبینی کرد یا انحراف‌ها را از بین برد. هر متدولوژی روند ویژه‌ای برای این کار دارد. معمولا هنگامی که اثر انحراف از حدی کمتر باشد، اعضای تیم یا رهبران تیم‌ها برای انحراف تصمیم می‌گیرند، اگر اثر از حد آن‌ها بالاتر باشد مدیر پروژه، وگرنه حامی پروژه و افراد دیگر در لایه‌های بالاتر سازمان.
بسیاری از متدولوژی‌ها حدود تصمیم‌گیری دارند، ولی بسیاری برداشت اشتباهی درباره آن‌ها دارند. برای نمونه، حدود تصمیم‌گیری در پرینس۲ تلورانس نامیده می‌شوند، و بسیاری گمان می‌کنند که این تلورانس‌ها مانند تلورانس‌های مهندسی هستند و مشخص می‌کنند که چه مواردی نیاز به تصمیم‌گیری دارند و اگر اثر موردی کمتر از تلورانس باشد نیاز به اصلاح نخواهد داشت. چنین برداشتی درست نیست: هر انحرافی نیاز به اصلاح دارد و تلورانس‌ها فقط مشخص می‌کنند که چه کسی باید تصمیم‌گیری کند.
همیشه بهتر است انحراف‌ها در زودترین زمان اصلاح شوند، زیرا هرچه بیشتر روی هم انباشته شوند اصلاح کردنشان دشوارتر خواهد شد.
وقتی انحرافی وجود دارد، باید برایش اقدامی اصلاحی طراحی کنید. افزون بر آن، لازم است که اقدامی پیشگیرانه نیز طراحی کنید که احتمال بروز مشکل‌های همانندش را در آینده کم کند. متاسفانه بسیاری فقط به اقدام‌های اصلاحی توجه می‌کنند و نه پیشگیرانه.
اگر به هر دلیلی لازم باشد که میان اقدام اصلاحی و اقدام پیشگیرانه تنها یکی را انتخاب کنید، انتخاب درست، اقدام پیشگیرانه خواهد بود. اگر غیر از این عمل کنید، همیشه با انبوهی از دشواری روبرو خواهید بود و هیچ زمانی برای کارهای زیربنایی نخواهید داشت.
روند مناسب در رویارویی با هر انحرافی این‌چنین است:
دلیل ریشه‌ای بروز این انحراف چیست؟ چگونه می‌توانم از بروز مشکل‌های همانند آن در آینده جلوگیری کنم؟
چگونه می‌توانم انحراف کنونی را اصلاح کنم؟
نگاهی به متدولوژی خود بیندازید و ببینید که این دو مسئله چگونه پوشش داده شده‌اند. اگر گمان می‌کنید ممکن است طراحی اقدام‌های پیشگیرانه را فراموش کنید و این موضوع در متدولوژی به‌اندازه کافی روشن نیست، آن جنبه را تقویت کنید تا از قلم نیفتد.
در بخش پیش نخستین چالش کلان که پذیرش تیم بود را بررسی کردیم. چالش دیگری هم وجود دارد: شاید فردی فنی باشید که به دلیل علاقه به مدیریت پروژه چنین سمتی را پذیرفته است. با توجه به ریسک‌هایی که مدیریت پروژه برای افراد فنی دارد و پیش‌ازاین بررسی‌اش کردیم، چه باید بکنید؟
در چنین حالتی باید کاملا درباره دوگانگی مسایل فنی و مدیریتی خودآگاه باشید. هر زمان که قرار است سخنی بگویید، کاری انجام دهید، یا تصمیمی بگیرید، از خود بپرسید که موضوع فنیست یا مدیریتی، و اگر مدیریتی نبود، آن را بر دوش فرد مسئولش بگذارید. این مسئله با تمرین درونی می‌شود و پس از مدتی ناخودآگاه درست عمل خواهید کرد.
یکی از مدیر پروژه‌های خبره‌ای که می‌شناختم معمار بود. در یکی از پروژه‌ها که جنبه‌های معمارانه حساسی داشت مدیر پروژه بود. در یکی از جلسه‌ها، دو شرکت مشاور مسئول در پروژه درگیر بحثی طولانی درباره یکی از جنبه‌های معماری پروژه شده بودند. به‌یکباره یکی از افراد جلسه از مدیر پروژه پرسید «آقای دکتر، دیدگاه شما چیست؟ هرچه باشد شما هم معمار هستید!» و او در پاسخ گفت «من اینجا به‌عنوان مدیر پروژه در کنار شما هستم و نه به‌عنوان معمار. در نقش مدیر پروژه می‌توانم به شما بگویم که بهتر است در این باره جلسه جداگانه‌ای برگزار کنید و با سنجش همه موارد به رای نهایی برسید. نکات مثبت و منفی تصمیم را هم مکتوب کرده، برایم بفرستید. اگر …