به نظر من باید کسایی که تو کار برنامه‌ریزی هستن یه سری کار فرهنگی بکنن، برای این‌که جا بیفته که برنامه زمان‌بندی چیزی نیست که تو چند روز نوشته یا تجدید نظر بشه.
یه هفته وقت داشتم که برنامه زمان‌بندی یکی از پروژه‌ها رو با شرایطی خاص تجدید نظر کنم. این کار دقت زیادی می‌خواست. متاسفانه تو پروژه‌های دیگه هم کارهای فوری پیش اومد و در نهایت فقط دو روز برام وقت موند که روی تجدید نظر برنامه زمان‌بندی کار کنم. تو این فرصت کم، خواستم یه منبع مصرفی جدید هم برای پروژه تعریف کنم تا کنترل‌هایی روش انجام بدم. بعد از این‌که همکارهای دیگه مقدارهای اون رو برام استخراج کردن (اولین باری بود که خودم مجبور نشدم برم سر و وقت نقشه‌ها)، مدت کمابیش زیادی صرف وارد کردن اون‌ها شد. وقتی بعد از تموم شدن کارها خواستم برم نمودارش رو ببینم، پراجکت هنگ کرد. دوباره رفتم تو پراجکت، برنامه رو باز کردم و سعی کردم نمودار رو ببینم، باز هم هنگ کرد. کامپیوتر رو ریست کردم و دوباره آزمایش کردم… هنگ کرد. فایل رو برای کس دیگه‌ای فرستادم تا آزمایشش کنه، اونجا هم هنگ کرد. برگشتم به برنامه و چیزهای مختلفی رو تغییر دادم؛ تنها کاری که باعث می‌شد برنامه هنگ نکنه، حذف کردن اون منبع مصرفی جدید بود!
راه حل مسخره‌ای که در آخر مجبور شدم استفاده کنم و هنوز هم راه دیگه‌ای به نظرم نرسیده که بهتر از اون باشه، این بوده که چون عملا از هزینه‌ها …
دقیقا همزمان با شروع نمایشگاه کتاب آموزش پریماورا 5 هم از چاپخونه بیرون اومد. این کتاب 280 صفحه هست و کانون نشر علوم اون رو چاپ کرده.
این کتاب برای سطح مقدماتی و متوسط مناسبه و پیش نیازی نداره، به جز آشنایی با اصول برنامه ریزی و کنترل پروژه.
تمام مباحث پریماورا، به عبارت بهتر مباحث پیشرفته اون، توضیح داده نشده. ولی سعی کردم تمام مسایلی که برای نوشتن برنامه های نه چندان حرفه ای و کنترل کردن اون ها لازم هست رو توش بگنجونم.
یه نکته که در مورد این کتاب، کتاب قبلیم که در مورد پراجکت 2003 بود و کتاب بعدیم که در مورد پراجکت 2007 خواهد بود، و در مورد تمام کتاب های مشابه فارسی و انگلیسی هم صادقه، اینه که کتاب تنها کار با نرم افزار رو توضیح می ده، نه چگونگی برنامه ریزی و کنترل پروژه. می دونم که خیلی از مخاطب ها دنبال کتابی کاربردی هستن که اصول برنامه ریزی و کنترل پروژه رو توضیح بده؛ برای همین هم مدتیه که به فکر همچین کتابی هستم و منابعی هم براش پیدا کردم، که احتمالا بعد از چنتا کتابی که با ناشرها قرارداد دارم، میرم سراغ اون.
این کتاب، تنها کتابیه که در مورد پریماورا 5 به زبان فارسی وجود داره، و ترجمه کتابیه که تا این تاریخ و تا جایی که من خبر دارم، تنها کتاب انگلیسی در مورد پریماورا 5 هست. نویسنده کتاب انگلیسی، نویسنده معروفیه که کتاب های زیاد و معمولا جالبی در مورد پریماورا و پراجکت نوشته. …
یکی از قابلیت‌های خوبی که به پراجکت 2007 اضافه شده، اینه که وقتی مقدار یکی از فیلدها تغییر داده بشه، تمام فیلدهایی که وابسته به اون باشن و مقدارشون تغییر کنه با رنگ پس‌زمینه متمایز می‌شن.
به این ترتیب می‌شه دونست که هر تغییری چه تاثیری روی برنامه داشته.
تمام نوارهای نمودار گانت گرد گوشه شدن. احتمالا به نظرشون اینطوری قشنگ‌تره، ولی من مدل قبلی رو خیلی بیشتر دوست دارم.
مدت‌ها بود كه می‌خواستم سايتی در مورد مسايل كاريم بزنم. وقتی كارهای اوليه رو انجام دادم، ديدم كه بهتره به جای ايجاد يه سايت خشك و ثابت، سايتی درست كنم كه يه قسمت وبلاگ هم داشته باشه و به اين ترتيب زنده بمونه.
تو اين وبلاگ در مورد مسايل مربوط به برنامه ريزی و كنترل پروژه می‌نويسم. با اين حال، بعضی موضوع‌های حاشيه‌ای كه كمابيش به مديريت پروژه ربط دارن هم مطرح خواهند شد.
برخی گمان می‌کنند که مدیریت کیفیت فقط به معنی آزمایش خروجی‌های پروژه و مطمئن شدن از درستی آن‌هاست. آزمایش‌ها بخشی از مدیریت کیفیت هستند، ولی فقط واپسین گام. هدف اصلی مدیریت کیفیت این است که کار را به گونه‌ای انجام دهیم که احتمال نامناسب بودن خروجی تا حد معقولی کم شود. هدف اصلی پیشگیریست و نه درمان و جنبه‌ای که به کاهش هزینه‌ها کمک می‌کند نیز همان بخش پیشگیریست.
مدیریت کیفیت، مانند همه حوزه‌های دیگر در مدیریت، باید غیرانفعالی انجام شود تا کارآمد باشد. برخورد غیرانفعالی با کار یکی از اصل‌های NUPP نیز هست که در ادامه این فصل به‌کوتاهی بررسی خواهد شد.
تمدن بشری وابسته به انتقال آموخته‌هاست. اگر قرار بود هر دانشمندی همه علوم را از آغاز به تنهایی کشف کند، هیچ‌گاه نمی‌توانست از حدی جلوتر برود. به‌جای تکرار آنچه دیگران به دست آورده‌اند، هر دانشمندی یافته‌های پیشین را می‌آموزد و سپس گامی جلوتر می‌رود. همین مسئله باید در مدیریت پروژه هم وجود داشته باشد:
به‌جای این‌که همه جنبه‌های مدیریت پروژه را شهودی و بر پایه تجربه شخصی پیش ببرید، بهتر است که از انبوه تجربه‌های دیگران که در قالب استانداردها و متدولوژی‌هایی مانند پم‌باک، پرینس۲ و P3.express مستند شده‌اند استفاده کنید و سپس، مانند یک دانشمند، آن را گامی جلوتر ببرید.
به‌جای این‌که کارتان را در هر پروژه از صفر آغاز کنید، بهتر است از درس‌آموخته‌ها و اطلاعات گردآوری شده در پروژه‌های مشابهی که پیشتر در سازمان انجام شده است استفاده کنید.
برخی گمان می‌کنند که ثبت درس آموخته به این معنیست که در پایان پروژه اندکی به خاطرات گذشته بیندیشند و از آن یادداشت بردارند. چنین کاری به هیچ وجه کارا نیست. به جای آن، ثبت درس آموخته باید دایمی و تدریجی باشد.
سیستم‌های ماکسیمالیستی، ازجمله پرینس۲، بدون اختصاصی‌سازی نخستین کاربردی نیستند و کسانی که می‌کوشند پروژه خود را عینا همانند ظواهر آنچه در منوآل پرینس۲ گفته شده است پیش ببرند به نتیجه مطلوبی نخواهند رسید.
گذشته از اختصاصی‌سازی نخستین، باید دایما در طول کار هم مشغول اختصاصی‌سازی تدریجی باشید تا سیستم مدیریت پروژه با شرایط محیطی انطباق پیدا کند.
هرآن‌چه در پروژه انجام می‌دهیم باید با سطوح بالاتر سازمان هماهنگ و همسو باشد. با این‌همه، درجه حساسیت کارهای مختلف یکسان نیست و مدیریت ریسک از مواردیست که نیاز به هماهنگی بیشتری دارد.
مهم‌ترین دلیل برای حساسیت بالای مدیریت ریسک این است که برخی از ریسک‌ها بر بیش از یک پروژه اثر می‌گذارند و وقتی اینگونه باشد بهتر است که واکنش به ریسک در سطحی بالاتر از پروژه‌ها و با رویکردی همه‌جانبه انجام شود.
لایه مدیریت پرتفولیوی سازمان باید فهرستی از ریسک‌هایی که میان پروژه‌ها مشترک هستند بسازد و پیگیری کند. این فهرست باید در اختیار مدیران پروژه‌ها نیز باشد تا در پروژه‌هایشان لحاظ کنند و اطلاعات تکمیلی احتمالی را به لایه مدیریت پرتفولیو بفرستند. از سوی دیگر، مدیران پروژه‌ها نیز باید فهرست ریسک‌های خود را در اختیار لایه مدیریت پرتفولیو بگذارند که چنانچه ریسک‌های مشترک تازه‌ای میان پروژه‌ها کشف شد مدیریتش به لایه بالاتر منتقل شود.
بسیاری از سازمان‌ها سیستم مدیریت پرتفولیوی ساخت‌یافته ندارند. اگر در چنین سازمانی کار کنید چالش‌هایتان به نبود روند مناسبی که در این بخش توضیح داده شد محدود نخواهد شد و شاید کار چندانی هم از دستتان ساخته نباشد. با این‌همه، برای کاستن دشواری‌ها می‌توانید جلسه‌های مشترک ماهانه‌ای با دیگر مدیران پروژه‌ها داشته باشید تا درباره ریسک‌های پروژه‌هایتان همفکری کنید. این کار جای …
باید دایما با ذی‌نفعان در ارتباط بود. منتظر نمانید که به شما مراجعه کنند، چون آن زمان شاید دیر باشد و هر چه زودتر انتظارها و مشکل‌ها را کشف کنید آسان‌تر می‌توانید در پروژه لحاظشان کنید. یک راهکار که در متدولوژی P3.express به‌کار گرفته می‌شود ارزیابی ماهانه رضایت ذی‌نفعان است. این ارزیابی سرنخ‌های فراوانی برای یافتن مشکل‌ها در اختیارتان می‌گذارد.
راهکار دیگری که در P3.express وجود دارد ارتباط متمرکز است. این فعالیت در پایان هرکدام از گروه‌های فعالیتی اجرا می‌شود و در هر زمان پیام ویژه‌ای را برای مخاطبان از پیش‌تعیین شده می‌فرستد. اطلاعاتی که اینگونه مکاتبه می‌شود از بروز بسیاری مشکل‌ها جلوگیری می‌کند.
همیشه باید زمان و توان بایسته صرف شناسایی و مشارکت دادن ذی‌نفعان پروژه کنیم. گام نخست، یعنی شناسایی ذی‌نفعان، کار ساده‌ای نیست و باید برایش از اعضای تیم کمک بگیرید. همان‌گونه که در اصل پیش بررسی کردیم، این کار را به شکلی انجام دهید که کارکرد تیم‌سازی هم داشته باشد.
باید با ذی‌نفعان شناسایی‌شده به شکل‌های مختلف ارتباط برقرار کرد. نوع مناسب ارتباط بستگی به نوع ذی‌نفع دارد. گاهی ارتباط رسمی مناسب‌تر است و گاهی غیررسمی. گاهی ارتباط باید با جزئیات فراوان باشد و گاهی کلان. گاهی باید جنبه‌های پیچیده فنی را در ارتباط وارد کنید و گاهی باید از آن خودداری کنید.
یکی از راه‌های ارتباط که برای بسیاری از ذی‌نفعان کاربرد دارد، فرستادن گزارش است. به یاد داشته باشید که گوناگونی افراد بیش از آن است که یک نوع گزارش برای همه آن‌ها مناسب باشد و درنتیجه بهتر است بیشتر از یک نوع گزارش طراحی کنید.
فردی آغاز به ساخت و پیش‌فروش مجموعه آپارتمانی بزرگ و کمابیش کم‌هزینه‌ای کرده بود. پس از فراری شدن سازنده مشخص شد که حدود ۵۰۰ آپارتمانی که در حال ساخت بود (اگر شمارشان را درست به یاد بیاورم) به هزاران نفر پیش‌فروش شده بود! خریدارانی که بیشتر اندوخته مالی خود را در اختیار این کلاه‌بردار قرار داده بودند بسیار آزرده و خشمگین بودند و به‌تدریج درگیر تحصن و اعتراض شدند. قوه قضائیه برآن شد که پادرمیانی کند. برنامه این …
هنگامی که متخصصی فنی تبدیل به مدیر می‌شود، ارتقای مقام پیدا نکرده، بلکه حرفه‌اش تغییر کرده است. خبرگی در مسایل فنی تضمینی برای خبره بودن در مسایل مدیریتی نیست، زیرا این دو نیاز به مهارت‌ها و شخصیت‌های کاملا متفاوتی دارند. علاقه واقعی برخی افراد به انجام کارهای فنیست و مدیر شدن، که گاهی ناچارند به دلیل فشارهای محیطی بپذیرند، کار را برایشان تلخ می‌کند. از سوی دیگر، چنین کسانی بیشتر اوقات نیز مدیران خوبی نمی‌شوند و به موفقیت پروژه‌ها آسیب می‌زنند.
رویکرد مناسب این است که افرادی که علاقه به کار فنی دارند در حرفه خود باقی بمانند و از راه‌های دیگری ارتقای مقام پیدا کنند. از سوی دیگر، هر سازمانی باید بر یافتن و پرورش مدیر سرمایه‌گذاری کند. وجود رشته‌های مدیریتی مناسب در دانشگاه‌ها نیز به دستابی به این هدف کمک می‌کند.
نسخه هفتم پم‌باک به جای «توجیه‌پذیری» بر ارزش یا به عبارت دیگر ارزش‌آفرینی متمرکز است و توجیه‌پذیری را مقوله‌ای زیرمجموعه آن می‌داند.
ارزش تعریفی یکه ندارد، ولی بهترین تعریف برای آن که با منابع تخصصی نیز سازگار است، نسبت منافع به هزینه است. برای نمونه:
پروژه ۱ – منافع: معادل ده میلیون پیتزا، هزینه: معادل چهار میلیون پیتزا
پروژه ۲ – منافع: معادل ده میلیون پیتزا، هزینه: معادل دو میلیون پیتزا
در این حالت ارزش پروژه دوم دو برابر پروژه نخست است و می‌توان گفت که پروژه دوم باارزش‌تر است.
توجه داشته باشید که در گفتار روزمره بسیاری از افراد، «ارزش» برابر «منفعت» است. متاسفانه حتی در برخی از منابع مربوط به پروژه، به‌ویژه منابع چابک، ارزش به هر دو معنی به کار می‌رود و باعث سردرگمی فراوان می‌شود. در این کتاب ارزش به معنی نسبت منافع به هزینه‌ها به کار می‌رود.
هنگامی که به جای واقعیت‌های عینی با جنبه‌های انسانی سر و کار داشته باشیم، روش‌های متعین کارایی کافی نخواهند داشت و لازم است که تطبیقی پیش برویم. از آن‌جایی که مدیریت ذی‌نفعان مسئله‌ای کاملا انسانی‌ست، باید رویکردتان در این حوزه تطبیقی باشد و به‌جای ساخت برنامه‌ای کاملا تفصیلی در آغاز کار، برنامه‌ای ساده آماده کرده، زمینه‌ای فراهم کنید که بتوانید با اجرای آن برنامه بازخورد مناسب دریافت کرده، برنامه‌ها را برای دوره بعد بهبود دهید.
برای تطبیق با محیط باید دایما کارایی برنامه‌های مدیریت ذی‌نفعان را ارزیابی کنید. برای نمونه، اگر گزارشی برای گروهی از ذی‌نفعان می‌فرستید، با آن‌ها تماس بگیرید و گفتگو کنید تا مطمئن شوید که پیام اصلی گزارش به خوبی منتقل شده است. شاید به این نتیجه برسید که گزارش برای برخی از آن افراد کارآمد بوده است، ولی گروهی دیگر هنوز گزارش را مطالعه نکرده‌اند. شاید گروه دوم محدودیت زمان دارند و لازم است گزارش ساده‌تر و کوتاه‌تری برایشان بفرستید.
فکر خوبیست که در هر متدولوژی‌ای که دارید روند ارزیابی رضایت ذی‌نفعانی که در P3.express شرح داده شده است را نیز پیاده‌سازی کنید. در این سیستم، نظرسنجی گمنامی برای همه ذی‌نفعان درونی و بیرونی پروژه فرستاده می‌شود. از نتیجه نظرسنجی برای طراحی برنامه‌های بهبود در دوره بعد کمک گرفته می‌شود.
در متدولوژی P3.express چرخه‌هایی ماهانه برای کار پروژه وجود دارد. هر چرخه شماری فعالیت پایانی دارد و یکی از این فعالیت‌ها ارزیابی رضایت ذی‌نفعان است. برای این کار رضایت ذی‌نفعان درونی (اعضای تیم) و بیرونی پروژه با نظرسنجی‌های بی‌نام ارزیابی می‌شوند. پس‌ازآن، فعالیت دیگری وجود دارد تا با کمک این اطلاعات برنامه‌ای برای بهبود پروژه در چرخه بعد طراحی شود.
پیشنهاد P3.express این است که برای ساخت برنامه بهبود اعضای تیم را گرد هم آورید، اطلاعات را در اختیارشان بگذارید و با تسهیل‌گری با روش‌هایی مانند دلفی (Delphi technique) از ایشان درخواست کنید که برنامه‌های بهبود را طراحی کنند.
چنین کاری امتیازهای فراوانی دارد، ازجمله:
چنین جمعی می‌تواند ایده‌های جالبی بیافریند، فراتر از آنچه به‌تنهایی یا با کمک گروهی کوچک شدنیست.
با این کار نشان می‌دهید که دیدگاه اعضای تیم برایتان باارزش است و از آن‌جایی که خودشان برنامه‌های بهبود را طراحی کرده‌اند، به آن پایبندتر خواهند بود و امکان موفقیت برنامه‌ها بالاتر می‌رود.
در گذشته رایج بود که پیشرفت پروژه‌های نرم‌افزاری را بر پایه تعداد خط برنامه‌ای که نوشته شده است بسنجند. زمانی شرکتی برنامه‌نویس بسیار خبره‌ای را استخدام کرد و در پایان ماه از او خواستند که تعداد خط برنامه‌ای که نوشته است را اعلام کند. مقداری که گزارش کرده بود عددی منفی بود! او در مدت ماه مشغول بررسی کدهای پیشین و اصلاح آن‌ها بود و در بسیاری موارد کدهای تکراری یا اضافه را پاک کرده بود. کار این فرد کمک فراوانی به پروژه کرده بود، ولی با معیار ارزیابی موجود اینگونه برداشت نمی‌شد.
این شیوه ارزیابی پیشرفت، که به وضوح کارایی مناسبی ندارد، امروزه چندان رایج نیست. دلیل اصلی برای از بین رفتن این روش، رواج شیوه‌های چابک و مخالفت آن‌ها با این نوع ارزیابی است. شیوه‌های رایج ارزیابی در پروژه‌های چابک کارایی نسبتا مناسبی دارند، ولی متاسفانه آن‌ها نیز به شکل دیگری منحرف شده‌اند. برای نمونه، در بسیاری از این روش‌ها فهرستی از کارها برای دوره پیش رو انتخاب می‌شوند. در برخی پروژه‌ها شمار کارهای تکمیل شده در پایان دوره را با آنچه انتخاب شده بود مقایسه می‌کنند و این مسئله برایشان معیار ارزیابی مهمیست. این معیار درست نیست، زیرا برنامه‌نویسان را تشویق می‌کند که در آغاز دوره کارهای کمتری را انتخاب کنند و آن هم به نوبه خود منجر به کاهش خروجی می‌شود، زیرا «کار به اندازه …