خواننده‌های فارسی زبان از کتاب قواعد زمان‌بندی پروژه خیلی خوب استقبال کردن، ولی نکته مهم در اینه که استقبال خواننده‌های انگلیسی زبان به مراتب بیشتر بوده و به همین خاطر می‌خوام پیشنهاد کنم که اگه هنوز این کتاب رو مطالعه نکردین، حتما نگاهی بهش بندازین. نسخه فارسی رو می‌تونین از اینجا و نسخه رایگان انگلیسی رو از اینجا تهیه کنین. البته این دو نسخه دقیقا مشابه هم نیستن؛ توصیه‌هایی بومی که برای خواننده‌های ایرانی لازم بودن رو تو نسخه انگلیسی حذف کردم.

گذشته از وجود چند هزار نفری که نسخه انگلیسی رو دریافت کردن، چندین موسسه مدیریت پروژه با دریافت مجوز اون رو از طریق خبرنامه‌هاشون در اختیار مشتری‌هاشون گذاشتن، به دو نسخه پرتقالی و روسی ترجمه شده، یک مدرس مدیریت پروژه اون رو در آمریکا تدریس می‌کنه و تا حالا مجموعا ۸۰۰ پیام تشکر به دستم رسیده (بیشتر از پیام‌های تشکری که تو ده سال گذشته بابت کتاب‌های فارسیم گرفتم).

خیلی از استانداردها و منابعی که در مورد زمان‌بندی نوشته شدن درباره شناوری‌های زیاد از حد نوشتن. این‌که شناوری‌ها نباید از حدی بیشتر باشه یکی از ۱۹ قاعده‌ایه که تو کتاب قواعد زمان‌بندی پروژه هم توضیح دادم.

بعد از انتشار کتاب، خیلی از خواننده‌های ایرانی و تعدادی از خواننده‌های غیر ایرانی از من درباره‌ش سوال کردن و به این نتیجه رسیدم که توضیحات بیشتری به ویرایش بعدی کتاب اضافه کنم؛ ولی تا اون زمان این مطلب رو نوشتم که برای همه توضیح داده باشم.

زیاد بودن شناوری به خودی خود هیچ مشکلی ایجاد نمی‌کنه. شناوری‌های زیاد از حد دلیل ایجاد مشکل نیستن، ولی نشونه‌ایه که به ما می‌گه احتمالا جای دیگه‌ای مشکلی وجود داره. مثل این می‌مونه که یه دکتر مثلا نشونه‌ای رو روی ناخن شما ببینه و مشکوک بشه. اون نشونه روی ناخن به خودی خود مشکلی برای شما ایجاد نمی‌کنه (مگر این‌که خیلی حساس به ظاهرتون باشین)، ولی ممکنه جای دیگه‌ای مشکل مهمی داشته باشین و به همین خاطر باید ماجرا رو بررسی کرد.

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

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

مطلبی جامع در مورد ماهیت و شیوه محاسبه فیلد Duration % Complete پریماورا نوشتم که تو سایت PlannerTuts منتشر شده. اگه علاقه‌مند به این نوع موضوع‌ها هستین حتما نگاهی بهش بندازین.

مطلب به زبان انگلیسیه؛ اگه نیاز به معادل فارسیش داشته باشین می‌تونین ایبوک ساختار مقادیر پیشرفت در Primavera P6 رو تهیه کنین؛ البته اون مطلب انگلیسی تشریحی‌تره.

قسمت دوم مطلب من درباره شیوه محاسبه و عملکرد فیلد Schedule % Complete پریماورا تو سایت plannertuts منتشر شد (به زبان انگلیسی).

قسمت اول این مطلب تئوری فیلد رو توضیح می‌داد و قسمت دوم عملکرد فیلد رو با تعدادی مثال نشون می‌ده.

تو روزهای اخیر که ثبت نام سری جدید دوره‌های اسکرام شروع شده، عده زیادی از کسایی که درگیر پروژه‌های غیر نرم‌افزاری هستن به این فکر می‌کنن که چنین دوره‌هایی می‌تونه براشون مفید باشه یا نه. تو این مطلب می‌خوام نظر شخصی خودم رو در این مورد بگم.

سیستم‌های مدیریت پروژه کلاسیک، مشابه اون چیزی که تو پم‌باک و پرینس۲ توضیح داده می‌شه، طوری طراحی شدن که برای همه نوع پروژه قابل استفاده باشن. با این حال پروژه‌های نرم‌افزاری تفاوت‌هایی با پروژه‌های دیگه دارن و احساس می‌شه که سیستم‌های کلاسیک برای مدیریت اون‌ها به اندازه کافی موفق نیستن. تلاش‌هایی که تو این زمینه شده، منجر شده به تدوین گروهی از سیستم‌های مدیریت پروژه مدرن که عموما تم و رویکرد مشابهی دارن و به همشون Agile (چابک) گفته می‌شه. موفق‌ترین و پر استفاده‌ترین سیستم اجایل هم Scrum (اسکرام) هست.

حالا بریم سراغ تفاوت‌های پروژه‌های نرم‌افزاری و غیر نرم‌افزاری. دلیل ریشه‌ای که باعث ایجاد این تفاوت شده، تغییرات خیلی زیاد تو پروژه‌های نرم‌افزاریه. مثلا وقتی یه پروژه ساخت کارخونه، بیمارستان یا راه دارین، از اول پروژه تعریف می‌شه و معمولا تا آخر کار تغییرات زیادی نمی‌کنه؛ ولی پروژه نرم‌افزاری اینطوری نیست. مشتری نرم‌افزاری رو سفارش می‌ده و به هر شکلی که هست محصول تعریف می‌شه، ولی با جلو رفتن کار انقدر نظرش عوض می‌شه و با دیدن قسمت‌های انجام شده انقدر ایده‌های جدید به نظرش میاد یا چیزهایی که از قلم افتادن یادش می‌افته، که عملا محصولی که در آخر کار به وجود میاد ربطی به محصولی که از اول تصور کرده بودیم نداره.

حالا چه دلیلی وجود داره که کسایی مثل من که تو پروژه‌های غیر نرم‌افزاری کار می‌کنن بخوان اسکرام یاد بگیرن؛ از نظر من دو دلیل می‌تونه وجود داشته باشه:

1. تلاش برای به‌کارگیری آموزه‌های اجایل
2. درک بهتر سیستم‌های کلاسیک

تلاش برای به‌کارگیری آموزه‌های اجایل

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

هرچی که باشه، این ترکیب کار ساده‌ای نیست و به نظر نمیاد که صرفا آشنایی با این دو سیستم برای به وجود آوردن ترکیب کافی باشه. من فکر می‌کنم در آینده سیستم‌های جدیدی از سنتر این دو گروه سیستم به وجود بیاد که بتونه بهتر از هردو راهگشا باشه.

درک بهتر سیستم‌های کلاسیک

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

همین ماجرا در مورد سیستم‌های مدیریت پروژه هم وجود داره. وقتی آدم رویکرد یه سیستم جدید رو ببینه که اصول برای جانشینی سیستم‌های کلاسیک ساخته شده، اون سیستم‌های کلاسیک رو بهتر درک می‌کنه.

از نظر من این دلیل مهم‌ترین چیزیه که می‌تونه باعث بشه یادگیری اسکرام برای ماها مفید باشه.

اجایل و پم‌باک

یکی از تغییرات نسخه پنجم پم‌باک، که الان نهایی نشده و تو مرحله پیش‌نویسه، پشتیبانی از سیستم‌های اجایله. این‌که استاندارد شماره ۱ مدیریت پروژه دنیا این سیستم‌ها رو کاملا به رسمیت شناخته اهمیتشون رو نشون می‌ده، هرچند که شیوه پشتیبانی کردنش ممکنه یه مقدار عجیب باشه.

به نظر من پم‌باک تغییری کلی نکرده، اون سنتزی که گفتم اتفاق نیفتاده، بلکه فقط سعی کرده بعضی قسمت‌ها رو کمی کلی‌تر کنه که با سیستم‌های اجایل هم سازگار باشه.

اگه قصد دارین درک کاملی از نسخه آینده پم‌باک داشته باشین، باید سیستم‌های اجایل رو هم تا حدی بشناسین.

یکی دیگه از تحول‌های مهم یکی دو سال اخیر، اینه که PMI (موسسه مدیریت پروژه، که استاندارد پم‌باک رو هم تدوین می‌کنه و گواهی‌های PMP رو هم صادر می‌کنه)، گواهی جدیدی برای سیستم‌های اجایل در نظر گرفته. این هم قاعدتا نشونه دیگه‌ای از اهمیت پیدا کردن سیستم‌های اجایله.

دارم به سفارش سایت plannertuts قسمتی از مطالب کتاب ساختار مقادیر پیشرفت در Primavera P6 رو براشون تدوین می‌کنم.

اولین مطلب درباره فیلد Schedule % Complete هست و اون رو به طور کامل و همراه با تمام جزئیات توضیح می‌ده. اگه این موضوع براتون جالب باشه احتمال می‌دم که این مطلب براتون مفید باشه.

می‌تونین مطلب رو تو این آدرس مطالعه کنین. البته فعلا قسمت اولش منتشر شده و مثال‌ها تو مطلب جداگانه‌ای به زودی منتشر خواهند شد.

به زودی سه دوره اسکرام تو ایران برگزار می‌شه که ممکنه براتون جالب باشه. تو اسکرام سه نقش وجود داره و برای هرکدوم از این نقش‌ها هم یه دوره تو Scrum.org تعریف شده که قراره اینجا طبق همون سیلابس برگزار بشه:

• دوره Professional ScrumMaster: برای تربیت ScrumMasterها. این افراد کسایی هستن که مسئولیت مربی‌گری و رهبری پروژه‌های اسکرام رو به عهده دارن.
• دوره Professional Scrum Product Owner: این فرد مسئولیت هماهنگ کردن تیم پروژه و سایر ذی‌نفعان و تحقق نیازها و خواسته‌های اون‌ها رو به عهده داره.
• دوره Professional Scrum Developer: این افراد کسایی هستن که کارهای پروژه رو انجام می‌دن و علاوه بر اون مدیریت پروژه رو هم به عهده دارن. به خاطر این نقش دومه که نیاز به چنین دوره‌ای دارن.

برای کسب اطلاعات بیشتر به این آدرس مراجعه کنین.

نسخه انگلیسی کتاب ساختار مقادیر پیشرفت در Primavera P6 منتشر شد و می‌تونین اون رو از این آدرس دریافت کنین.

برای تهیه نسخه فارسی کتاب به این آدرس مراجعه کنین.