تا حالا اصطلاح Halo Effect رو شنیدین؟ می‌شه ترجمه‌ش کرد به اثر هاله نور.

قبلش یه سوال می‌پرسم. به نظر شما مدیر پروژه چه تخصصی‌هایی باید داشته باشه؟

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

کسی می‌تونه مدیر پروژه باشه که در مدیریت پروژه تخصص داشته باشه. ساده‌تر از این؟

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

این می‌شه گرایش PMI و همه سیستم‌های حرفه‌ای دیگه‌ای که من تا حالا دیدم.

حالا مشکل چیه؛ مشکل در اینه که اکثرا فکر می‌کنن اگه کسی تو حوزه کاری پروژه تخصص داشته باشه می‌تونه مدیر پروژه باشه. مدیر پروژه از نظر خیلی‌ها متخصص‌ترین کارشناس حوزه کاری پروژه‌س. به این می‌گن Halo Effect.

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

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

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

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

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

2. تو جلسه‌ای که دستور جلسه مشخصی نداره شرکت نکنین.

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

حالا قراره یه دوره برای CSM، یعنی Certified Scrum Master تو ایران برگزار بشه. اگه تو حوزه مدیریت تولید نرم‌افزار و اینطور چیزا کار می‌کنین که تقریبا واجبه برین، اگر هم مثل من هستین که احتمالا زیاد به دردتون نمی‌خوره، ولی ممکنه مثل من از سر کنجکاوی برین.

دوره دو روزه، به احتمال زیاد اول و دوم آذر 89.

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

احتمالا می‌دونین که عملکرد قید As Late As Possible تو پریماورا و پراجکت فرق می‌کنه. وقتی فعالیتی رو تو پریماورا ALAP کنین، شناوری آزادش صفر می‌کنه، ولی اگه این کار رو تو پراجکت کنین، شناوری کلش صفر می‌شه.

قید ALAP پراجکت باعث می‌شه که شناوری کل تمام فعالیت‌هایی که مستقیم یا غیر مستقیم وابستگی‌ای به فعالیت ALAP شده دارن هم صفر بشه.

هرکدوم از این دو نوع قید کاربردهای خودش رو داره، و خیلی خوب می‌شد اگه هر دو نرم‌افزار هر دو نوع قید رو ارائه می‌کردن، که متاسفانه نمی‌کنن.

حالا اومدیم و تو پراجکت نیاز به ALAP پریماورایی پیدا کردین. تکلیف چیه؟

می‌شه با یه مقدار عملیات آکروباتیک موضوع رو حل کرد.

این هم برنامه مثال:

فعالیتی که می‌خوایم شناوری آزادش صفر باشه، فعالیت a هست. چرا؟

فرض کنین مثلا a یه فعالیت تدارکاتیه. c رنگ دیواره، b خود دیوارکشیه، d هم بقیه کارها. a هم رنگیه که باید برای اونجا بخریم. حالا کی باید بخریمش؟

می‌شه a رو SF با c کرد تا زمان‌بندیش درست بشه. ولی تو این حالت اگه a به تاخیر بیفته، c رو به تاخیر نمی‌ندازه، در نتیجه اهمیتش تو برنامه مشخص نمی‌شه. به این خاطره که ترجیح می‌دیم a رو پیش‌نیاز c کنیم (در واقعیت هم همینطوره). حالا اگه معمولی این کار رو کنیم، a تو شروع پروژه شروع می‌شه، چون خودش پیش‌نیاز نداره. زمان مناسبش چه موقع باشه؟ بهترین گزینه زمانیه که شناوری آزادش رو صفر کنه، یعنی فعالیت قید ALAP پریماورایی داشته باشه. اگه همینطوری بهش قید ALAP بدیم، چنین نتیجه‌ای می‌گیریم:

که اصلا جالب نیست، چون c رو برده به آخر پروژه.

بعضی‌ها اینجور مواقع قید Start No Earlier Than می‌ذارن و بهش تاریخی می‌دن که a رو تا اندازه مناسب جلو ببره. ولی این راه هم مشکلش اینه که اگه زمان‌بندی c تغییر کنه، اصلاح نمی‌شه. پس جالب نیست.

من همون قید ALAP پریماورا رو می‌پسندم. راه حلش هم ساده‌س.

یادتونه قبلا درباره تاریخ‌های موثر در شناوری چه توضیحی داده بودم؟

همین ماجرا کلید حل مسئله‌س.

روی تاریخ شروع c کلیک کنید، بعد ctrl+c رو بزنین تا کپی بشه. حالا روی فیلد deadline فعالیت a کلیک کنین و از منوها paste special رو انتخاب کنین. گزینه Paste link رو انتخاب کنین و روی ok کلیک کنین.

علامت فرجه رو می‌بینین؟

الان a فرجه‌ای داره که تاریخش همون تاریخ شروع فعالیت c هست. هروقت زمان‌بندی c تغییر کنه، تاریخ این فرجه هم به تناظر اون تغییر می‌کنه و به عبارت دیگه، فرجه a همیشه همون شروع c خواهد بود. می‌دونین که فرجه شناوری فعالیت رو محدود می‌کنه.

حالا اگه a رو ALAP کنیم همچین چیزی می‌بینیم:

و این می‌شه همون چیزی که لازم داشتیم.

این کار رو با هر ترکیبی از فعالیت‌ها هم می‌شه انجام داد. اگه به جای a مجموعه‌ای از aها داشته باشیم، کافیه که به آخرین a فرجه بدین و اولین a رو ALAP کنین.

قسمت مدیریت زمان کتاب راهنمای آزمون PMP ریتا مثال‌های زیادی داره، که کاربردی هم هستن. ولی متاسفانه به نظر من اشکالات زیادی هم داره (الان نصف فصل رو ترجمه کردم).

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

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

باز جلوتر میایم و می‌خواد چیزی رو با مثال قبل توضیح بده. نتایج حل مثال قبل این بود که مدت زمان expected فعالیت‌های A و B به ترتیب 28 و 62 روزه. انحراف معیارشون هم به ترتیب 5.5 و 8 روزه. این دوتا فعالیت بالاترین انحراف معیارها رو دارن. حالا سوال اینه که ریسک کدوم فعالیت بیشتره. نظر شما چیه؟

ریتا می‌گه فعالیت B بیشتره، چون انحراف معیارش بالاتره. ولی به نظر من درست نمیاد و لازمه که نسبت انحراف معیار رو به مدت expected بسنجیم، که در این صورت ریسک A بالاتر خواهد بود. مسئله ساده‌ایه، فرض کنین یه فعالیت 10 روزه و اونیکی 100 روز، انحراف معیار اولی 8 روزه و دومی 9 روز؛ با شهودتون به من بگین که کدوم فعالیت پر ریسک‌تره؟ فعالیتی که مدت زمانش 10 روزه با انحراف معیار 8 روز (80٪) یا 100 روز با انحراف معیار 9 روز (9٪)؟

چون هرچی فکر می‌کنم این دوتا راه حل ریتا رو نمی‌دونم درست فرض کنم و از طرف دیگه دلم هم نمی‌خواد که نظر خودم رو بذارم به جای نویسنده، هردو تمرین رو حذف کردم؛ حداقل فعلا!

عقب‌افتادگی ترجمه کتاب داره روز به روز کمتر می‌شه. SPIt ترجمه‌م رسیده به 77٪، که کاملا ازش راضی‌ام.

راستی؛ من چون خیلی به SPIt علاقه دارم و از SPI خوشم نمیاد اینطوری وضعیت رو می‌گم، در حالی که مقدار SPIt و SPI تو این پروژه برابره. به نظر شما چه وضعیتی حاکمه که این دو مقدار با هم برابرن؟

سه نفر از اولین کسایی که جواب درست و کامل رو برام ایمیل کنن نسخه‌ای از کتاب رو (بعد از چاپ) هدیه خواهند گرفت (:  لطفا جواب‌ها رو فقط تا پیش از 25 تیر برام بفرستین.

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

این مقاله بازبینی بحثی قدیمی در حوزه برنامه‌ریزی و کنترل پروژه است:

پراجکت بهتر است یا پریماورا؟

منظور از پریماورا، نرم‌افزار Project Management شرکت پریماورا است. مباحث عمدتا معطوف به نسخه خاصی از نرم‌افزارها نیست، ولی مبنا نسخه 2007 پراجکت و نسخه 6 پریماورا است.

تاریخچه و زمینه

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

اولین نسخه پراجکت در 1984، در یکی از شرکت‌هایی که به مایکروسافت خدمات نرم‌افزاری می‌داد تهیه شد. یک سال بعد، مایکروسافت امتیاز نرم‌افزار را خرید و پس از آن به توسعه و انتشار آن ادامه داد. نسخه‌های سازگار با Mac OS این نرم‌افزار نیز تولید می‌شوند.

شرکت پریماورا در سال 1983 پایه‌گذاری شد و کمی پس از آن نرم‌افزارهای خود را منتشر کرد. چندی پیش شرکت اوراکل پریماورا را خرید و از این پس مالک و ناشر نرم‌افزارها به شمار خواهد رفت.

مبانی مقایسه

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

پیش از هر چیز باید مسئله مهمی را در نظر داشت. Primavera Project Management نرم‌افزاری سازمانی است، در حالی که نسخه‌های معمولی پراجکت این‌گونه نیستند. اگر قرار باشد قابلیت‌های سازمانی مبنای مقایسه قرار گیرند، باید پریماورا را با پراجکت سرور، که نسخه سازمانی نرم‌افزار برنامه‌ریزی و کنترل پروژه مایکروسافت است، مقایسه کرد. در این نوشته به قابلیت‌های غیر سازمانی توجه می‌شود. منظور از برنامه‌ریزی و کنترل پروژه غیر سازمانی، تلاشی است که در راستای مدیریتِ مستقلِ پروژه‌ها انجام می‌شود. در سیستم‌های سازمانی به ترکیبِ پروژه‌های متعددی که در یک سازمان انجام می‌شود و قابلیت‌های کارِ گروهی توجه می‌شود.

کدامیک بهتر است؟

بیایید برخی تفاوت‌های این دو نرم‌افزار را مقایسه کنیم:

• پریماورا شناوری را float می‌نامد و پراجکت slack.
• قید ALAP در پریماورا شناوری آزاد را صفر می‌کند و در پراجکت شناوری کل را.
• همپوشانی روابط را می‌توان در پراجکت بر حسب درصد نیز وارد کرد، در حالی که پریماورا چنین قابلیتی ندارد.
• پراجکت اجازه ایجاد بیشتر از یک رابطه را بین دو فعالیت نمی‌دهد، در حالی که پریماورا اینچنین نیست.
• فارسی‌نویسی در پریماورا "کمی" سخت‌تر از پراجکت است.
• فلسفه WBS در پریماورا و پراجکت یکسان نیست، هرچند که تفاوت عملیاتی چندانی ایجاد نمی‌کند.
• سیستم‌های گزارش‌دهیِ نسخه‌های قدیمی پراجکت ضعیف‌تر از پریماورا بود، ولی این اختلاف در نسخه‌های جدید کمتر شده است؛ هرچند که وضعیتِ فعلی هر دو نرم‌افزار در گزارش‌دهی بسیار ضعیف و عملا برای بسیاری از نیازها غیر قابل استفاده است.
• پراجکت با نرم‌افزارهای آفیس همنشینی بهتری دارد.
• رابط کاربر پراجکت بهتر از پریماورا است.

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

• پراجکت محدود به تعدادی فیلد اختصاصی است، ولی می‌توان در پریماورا هر تعداد فیلد که لازم است ساخت.
• فیلدهای از پیش آماده پریماورا به مراتب بیشتر از پراجکت است و کاربران پراجکت در صورت نیاز باید چنان قابلیت‌هایی را با فیلدهای اختصاصی بسازند.
• فرمول‌نویسی در پراجکت ساده‌تر و انعطاف‌پذیرتر است.
• پراجکت به قابلیت ماکرونویسی (برنامه‌نویسی VBA) مجهز است و پریماورا چنین امکانی ندارد.
• پراجکت امکانات بیشتری در roll-up (خلاصه‌سازی) دارد.
• می‌توان در پریماورا مایلستون‌های پیشرفت (step) ساخت و در پراجکت چنین امکانی وجود ندارد (کاربر باید در این حالت فعالیت را به زیرفعالیت‌هایی خرد کند). هرچند که قابلیت‌های تعریف شده برای مایل‌ستونی‌های پیشرفت پریماورا ناقص‌تر از آن هستند که آن را عملیاتی کنند.
• منابع راهنمای پراجکت (کتاب‌ها، مقالات و سایت‌ها، به زبان‌های مختلف) بسیار زیاد و منابع راهنمای پریماورا بسیار کم هستند.
• پراجکت در ایران عمومیت بیشتری دارد و در نتیجه استفاده از آن در شرکت‌هایی که با شرکت‌های مختلف سر و کار دارند ساده‌تر است.

به نظر شما این تفاوت‌ها برای تصمیم‌گیری کافی هستند؟

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

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

وضعیت ما

پیش از این که به سوال "کدام نرم‌افزار بهتر است؟" پاسخ دهیم، باید بدانیم که این پرسش و پاسخِ آن چه کاربردی دارند. آیا قصد داریم نرم‌افزار بهتر را بشناسیم تا با به‌کارگیریِ آن در مدیریت پروژه پیشرفت کنیم؟

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

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

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

سخن پایانی

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

امروز مطلبی دیدم با عنوان Project Audits vs. Project Controls، که تفاوت این دو مفهوم، یعنی کنترل و ممیزی رو توضیح می‌داد. بد نیست اگه نگاهی بندازین، خیلی‌ها تفاوت این دو مفهوم رو خوب نمی‌دونن.

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

در واقع ممیزی می‌شه کنترلی در یک سطح بالاتر: متاکنترل.

یه توصیه قدیمی برای کسایی که کارمندی کار نمی‌کنن اینه که اگه لازم شد مجانی کار کنین، ولی تا جایی که تونستین ارزون کار نکنین (اگه از گشنگی نمی‌مردین).

دلیل؟ حوصله ندارم درباره دلیلش بنویسم!

تا الان افراد زیادی به من ایمیل دادن و از وضعیت ترجمه کتاب راهنمای آزمون PMP پرسیدن.
راستش فعلا از برنامه‌ریزی عقبم، ولی دارم سعی می‌کنم که جبرانش کنم و تو همون تاریخ قبلی، یعنی نیمه مرداد تمومش کنم.
الان SPIt کارم 40٪ هست، یعنی جایی هستم که می‌بایست تو 40٪ زمانی که تا الان صرف کردم بهش رسیده باشم.
البته این ماجرا یه دلیلش هم تغییر اسکوپ کاره. بعد از اینکه ترجمه کتاب رو شروع کردم به این نتیجه رسیدم که بهتره بعضی قسمت‌های کتاب دو زبانه باشن، چون به هر حال خواننده قراره آزمون رو به زبان انگلیسی بده. این باعث شده که تعداد صفحه‌های کتاب و حجم کارم زیاد بشه.

یه نکته کوچیک اینه که فایل‌های پراجکت حدودا 90٪ فشرده می‌شن (کمتر فایلی انقدر فشرده می‌شه)، در نتیجه خیلی بهتره که موقع ایمیل کردن فایل‌ها رو فشرده کنین.