من همیشه چیزی رو به دوستان و همکاران توصیه کردم، چیزی که بهش می‌گم قاعده ردیابی:

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

این یعنی این‌که مشخصات پروژه، شرکتی که گزارش رو تهیه کرده، اسم فایل، تاریخ و زمان چاپ تو تمام صفحه‌ها باشه. تو فایل‌ها هم باید متادیتای کافی وجود داشته باشه. سیاست خوبی هم برای مدیریت فایل‌ها باشه. مثلا اگه گزارشی رو چاپ کردین تا کسی، حتی از همکارانتون، اون رو کنترل کنه و بعد اصلاحاتی در اون وارد کردین، بلافاصله اون رو با نام جدیدی ذخیره کنین تا فایل قبلی تو جای خودش باقی بمونه (خوشبختانه هارد ارزون‌تر از اونی شده که بخواد معیار قرار بگیره). بهتره انتهای نام هر فایل دو شماره باشه، اولی نسخه فایل و دومی زیرنسخه اون. شماره دوم اونیه که مثل نقل و نبات قراره بره بالا، و اولی اونیه که برای تغییرات اصلی که معمولا همراه با ارائه هست اضافه می‌شه.

تو پم‌باک (PMBOK) ده‌ها بار درباره مستند کردن پیش‌فرض‌ها صحبت می‌کنه. از پیش‌فرض‌هایی که در تخمین زمان و هزینه موثر بودن تا پیش‌فرض‌های تعیین داده‌های ریسک و امثال اون‌ها.

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

امروز خبردار شدم که ترجمه استاندارد عملی مدیریت ریسک پروژه، یعنی ترجمه Practice Standard for Project Risk Management از موسسه PMI (همونی که PMBOK رو هم تدوین کرده) چاپ شد.

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

استاندارد عملی مدیریت ریسک پروژه در سایت آقای روزبهی

استاندارد عملی مدیریت ریسک پروژه در سایت ناشر

چاپ کتاب رو بهشون تبریک می‌کنم و همراه با شما منتظر محصول‌های مفید بعدیشون خواهم بود.

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

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

به هر حال، نکته‌ای که می‌خواستم بگم اینه که الان متوجه شدم این قابلیت از پراجکت 2010 حذف شده! این حذف شدن تو سایت مایکروسافت هم تایید شده، ولی هیچ توضیحی دربارش نیست.

امروز چشمم افتاد به این کتاب:

و عنوان فرعیش خیلی نظرم رو جلب کرد: وقتی عملکرد ارزیابی شود، بهبود می‌یابد

When Performance is Measured Performance Improves

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

معمولا وقتی خونه هستم کار نمی‌کنم، ولی مدت اخیر چند بار ترجیح دادم که بمونم خونه و کار کنم. نتیجه این بود که گردن درد گرفتم!

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

اگه دوست دارین سری به Workspace Planner Tool سری بزنین و قدتون رو وارد کنین تا ارتفاع عناصر مختلف رو بهتون بده.

منبعی که باعث شد این سایت رو پیدا کنم هم مطلبی با عنوان Five Minute Upgrade - Make Your Workstation (more) Ergonomic بود.

هزار روز شد که این سایت فعالیت می‌کنه! زود می‌گذره...

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

به هر حال، این رو نوشتم که بگم از داشتن این سایت و ارتباطی که با شما همکاران و هم‌رشته‌هام دارم، خوشحالم.

از گوگل ریدر رسیدم به سایتی ایرانی به اسم The Coach و مطلبی با عنوان "آیا باید شرکت خودمان را داشته باشیم؟"، که نظرم رو جلب کرد. شاید برای شما هم جالب باشه.

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

تو قسمت 9.4.2.3 استاندارد پم‌باک (PMBOK)، با عنوان مدیریت درگیری‌ها، درباره حل مشکلات و درگیری‌های اعضای تیم پروژه صحبت می‌کنه. از نظر استاندارد حل درگیری‌ها از وظایف مدیر پروژه هست. تو این راستا چند توصیه خوب به مدیران پروژه‌ها می‌کنه:

• وجود درگیری در پروژه طبیعیه و می‌تونه راهی برای کشف انتخاب‌های بهتر باشه
• باید در حل درگیری به "مسایل" توجه کرد، نه به "افراد"
• باید در حل درگیری به مسایل کنونی توجه کرد، نه به مسایل گذشته

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

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

امروز متوجه شدم که ادسافت برنامه شمسی‌ساز پراجکت 2010 رو تولید کرده. ظاهرا 16ام همین ماه منتشر شده، و طبق توضیحاتشون تو ویندوز 7 هم کار می‌کنه. البته چیزی در مورد سازگار بودن یا نبودن با نسخه‌های 64 بیتی نگفته.
این سرعت عملشون واقعا برام جالب بود؛ هنوز نسخه نهایی پراجکت 2010 هم نیومده و اون‌ها شمسی‌ساز (به قول بعضی‌ها فارسی‌ساز) اون رو دادن. من تا حالا با شمسی‌ساز ادسافت کار نکردم، ولی برنامه دیگه‌ای برای اضافه کردن تقویم شمسی به ویندوز دارن که خیلی خوب کار می‌کرد و به همین خاطر فکر می‌کنم شمسی‌ساز پراجکتشون هم خوب باشه. تو توضیحاتشون به نکات جالبی برخوردم:
1. می‌شه باهاش با نسخه‌های قدیمی‌تر پراجکت هم کار کرد.
2. این‌که گفته وقتی اطلاعات به بقیه نرم‌افزارهای آفیس منتقل بشن، تاریخ همچنان شمسی باقی می‌مونه.
3. ظاهرا قفل USB نرم‌افزار یه حافظه فلش 2 گیگابایتی هم داره. البته امیدوارم منظورشون رو اشتباه متوجه نشده باشم و منظورشون یه قفل و یه حافظه اشانتیون نباشه!
قیمتش هم 170 تومنه. می‌تونین برای کسب اطلاعات بیشتر و خرید [احتمالی] به صفحه امکانات فارسی و مبدل تاریخ هجری شمسی ویژهMicrosoft Project 2010 (کنترل پروژه مایکروسافت) مراجعه کنین.