واقعیت اینه که معمولا برای ارائه وضعیت پروژه از شاخص‌های اصطلاحا حجمی، فیزیکی یا چیزهایی از اون دست استفاده می‌شه و مدیران هم روی همین شاخص‌ها تاکید دارن. مثلا می‌گن:
پیشرفت واقعی الان 40٪ هست، در حالی که مقدار برنامه‌ریزی شده‌ش 55٪ بوده.
به نظر شما یه همچنین چیزی تو ذهن مخاطب چطوری تعبیر می‌شه؟
عملا همه به این فکر می‌کنن که به اندازه حاصل تقسیم این دوتا، یعنی حدود 70٪ از کارهای برنامه‌ریزی شده رو انجام دادیم و مثلا اگه اینطور پیش بره مدت پروژه‌مون 30٪ (یا درست‌ترش 37٪) طولانی‌تر از اون چیزی می‌شه که باید بشه. پس اوضاع بده!
از طرف دیگه، با خودشون فکر می‌کنن که 40٪ کار انجام شده، یعنی یه چیزی بیشتر از یک سوم کار. مثلا این همه زحمتی که کشیدیم تازه شده یک سوم کار و حدودا باید دو برابر این مقدار جلسه بیایم و نامه‌نگاری کنیم و پول خرج کنیم و حرص بخوریم تا کار تموم بشه.
فرقی نمی‌کنه که چه شاخص‌هایی ارائه کنین، در نهایت دو تصویر در ذهن اکثر مخاطب‌ها شکل می‌گیره:
وضعیت زمانی پروژه چطوریه و به طور خلاصه، پروژه چقدر دیرتر از اون زمانی که قرار بوده تموم بشه تموم می‌شه.
الان چقدر از کار انجام شده و برای تموم شدنش باید چقدر دیگه زحمت بکشیم.
ولی مسئله اینه که هردو تصویر تعبیرهایی زمانی هستن، حتی اگه در ظاهر خلاف این باشن. پس چرا خودمون از اول شاخص‌های زمانی رو ارائه نکنیم؟ مثلا به جای جمله‌ای …
کتاب جدیدم، راهنمای آزمون PMP و استاندارد مدیریت پروژه PMBOK، چاپ شد.
این کتاب ترجمه معروف‌ترین و پرفروش‌ترین کتاب راهنمای آزمون PMP در جهانه، کتاب راهنمای آزمون ریتا.
نکته مهم در مورد این کتاب اینه که هیچ گرایشی به مطالب حفظی نداره و به بهترین شکل زمینه‌ای فراهم می‌کنه که مخاطب احساس کنه نیاز به حفظ کردن مطالب نداره و باید با درک مفهومی پیش بره.
هدف اصلی کتاب اینه که مخاطب رو برای آزمون PMP آماده کنه، ولی واقعیت اینه که منبع خیلی خوبی برای درک استاندارد پم‌باک هم هست. در نتیجه اون رو به تمام کسایی که قصد شرکت در آزمون رو ندارن، ولی می‌خوان پم‌باک رو به خوبی بفهمن هم توصیه می‌کنم. ممکنه قبلا پم‌باک رو مرور کرده باشین و ارتباط زیادی باهاش برقرار نکرده باشین و حتی به نظرتون جالب و کاربردی هم نیومده باشه. فکر می‌کنم وقتی این کتاب رو بخونین نظرتون در مورد پم‌باک عوض بشه.
در ضمن، تمام معادل‌سازی‌های این کتاب مشابه و سازگار با ترجمه‌ایه که از استاندارد پم‌باک کردم و کمی پیش از این کتاب چاپ شد.
خیلی‌ها اعتقاد دارن که مسیر پیشرفت شغلی به مدیر شدن ختم می‌شه. من با این عقیده موافق نیستم و می‌خوام توضیح بدم چرا.
آیا مدیر بودن بالاتر از کارشناس بودنه؟
زمانی جواب این سوال با قاطعیت مثبت بود و اون زمانی بود که دیدگاه ارباب-رعیتی به کار حاکم بود. این دیدگاه دیگه الان تو کشورهای پیشرفته وجود نداره و به نظر من میاد که تو ایران هم کمتر از گذشته‌س و کمتر هم می‌شه. مدیر بودن یه حرفه‌س، مثل کارشناس بودن و تفاوت این دوتا مثل تفاوت مثلا کارشناس کنترل پروژه و کارشناس تاسیسات مکانیکیه. همونقدر که صحبت درباره برتریِ مطلقِ یکی از این دو حرفه اشتباهه، صحبت درباره برتری مدیر و کارشناس هم بی‌معنیه.
یه نفر ممکنه دلش بخواد مدیر باشه و لازم باشه که برای این کار مدتی کارشناس باشه، ولی به این معنی نیست که هر کارشناسی که موفق باشه باید مدیر باشه. خیلی از افراد ممکنه در دوره کارشناس بودنشون کارشناس موفقی هم نباشن، ولی مدیرها تشخیص بدن که می‌تونه مدیر خوبی باشه و به تدریج تبدیلش کنن به یه مدیر. یه نفر ممکنه کارشناس خیلی خوبی باشه، ولی توانایی مدیریت یا علاقه به مدیریت نداشته باشه. مدیریت یه حرفه‌س، یه تخصصه. هم نیاز به علاقه و گرایش شخصی داره، هم نیاز به تخصیلات، مطالعه و تجربه.
آیا یه مدیر باید درآمدی بالاتر از افراد مجموعه خودش داشته باشه؟
نه الزاما. خیلی وقت‌ها حقوق کارشناسان برجسته‌ای که زیرمجموعه …
تمام کسانی که عضو PMI باشن یا یکی از گواهی‌های اون رو (مثل PMP) گرفته باشن، تعهد دارن که به آیین‌نامه‌ای به نام آیین نامه اخلاق حرفه‌ای PMIپایبند باشن.
این آیین‌نامه درباره اخلاق حرفه‌ای مدیریت پروژه‌س و جالبه بدونین که تو آزمون PMP هم سوال‌های زیادی ازش میاد و قراره که تا اواخر سال 2011 سوال‌ها بیشتر و حرفه‌ای‌تر هم بشن.
آیین‌نامه اخلاق حرفه‌ای رو تو چهار حوزه تعریف می‌کنه:
مسئولیت‌پذیری: ما باید خود را مالک تصمیم‌هایی که گرفته‌ایم، تصمیم‌هایی که می‌بایست بگیریم و نگرفته‌ایم، کارهایی که کرده‌ایم و کارهایی که می‌بایست کرده باشیم و نکرده‌ایم و تبعات تمامی آن‌ها بدانیم.
احترام: وظیفه ماست که برای خود، دیگران و منابعی که در اختیارمان قرار داده شده است احترام قائل باشیم.
انصاف: وظیفه ماست که تصمیم‌گیری‌هایمان بی‌طرفانه و عینی باشند. اعمال ما باید عاری از علاقه‌های شخصی، پیش‌داوری و طرفداری باشد.
صداقت: وظیفه داریم که حقیقت را بدانیم و آن را در گفته‌ها و اعمالمان مبنا قرار دهیم.
چیزهایی که بالا دیدین تعریفیه که خود آیین‌نامه ارائه می‌کنه. بعد از هر تعریف تعدادی از مصداق‌های اون تعریف رو تو کار بیان می‌کنه. مثلا از احترام نتیجه می‌شه که “همیشه حرفه‌ای برخورد می‌کنیم، حتی اگر رفتار مقابل حرفه‌ای نباشد".
کتاب راهنمای دانش مدیریت پروژه، PMBOK نسخه 4 چاپ شد. چند روزی وقت می‌بره تا به کتاب‌فروشی‌ها برسه و اگه مایل باشین می‌تونین اون رو از سایت ناشر هم مستقیم خریداری کنین.
همونطوری که می‌دونین این کتاب اولین ترجمه پم‌باک نسخه 4 نیست. دو ترجمه دیگه‌ش هم وجود داره (که من اطلاع دارم) که یکیش پیش از این‌که کار ترجمه رو شروع کنم چاپ شده بود و یکی دیگه به تازگی چاپ شده. خوب، ممکنه این سوال رو بکنین که وقتی ترجمه دیگه‌ای وجود داشته، چرا من هم ترجمه کردم. جواب اینه که به خاطر اهمیتی که پم‌باک داره، به نظر من لازم بود که ترجمه‌ای به سبک ترجمه‌های من هم در اختیار مخاطب‌ها باشه. ترجمه‌های موجود معمولا به کلمه‌ها و جمله‌ها متعهد هستن، در حالی که من خودم رو فقط به مفاهیم متعهد می‌دونم. به همین خاطر نمی‌تونین تناظر یک به یکی بین جمله‌های نسخه انگلیسی و ترجمه من پیدا کنین. هدف من این بوده که حتی با وجود این‌که متن اصلی خشک و خشنه، ترجمه‌ای روان و ساده ارائه بشه. حالا این‌که چقدر موفق بودم رو شما به من خبر بدین.
در مورد فهم پم‌باک باید این رو هم بدونین که خوندن متن به هیچ وجه کافی نیست. یکی از چیزهایی که خیلی به فهمش کمک می‌کنه، خوندن کتاب راهنمای آزمون PMP ریتا هست، که اون رو هم ترجمه کردم و به زودی چاپ می‌شه (به من قول دادن تا قبل از عید چاپ بشه). مخاطب این کتاب فقط کسایی نیستن که می‌خوان تو آزمون …
چند روز پیش مطلع شدم که PMI (موسسه مدیریت پروژه، همونی که استاندارد پم‌باک و گواهی PMP رو می‌ده) یه امتحان و گواهی برای مدیریت پروژه Agile تهیه کرده.
این رویکرد عموما برای مدیریت پروژه‌های نرم‌افزاری و مطالعاتی استفاده می‌شه و در عین حال من اعتقاد دارم که می‌شه ازش به طور موضعی در پروژه‌های دیگه هم استفاده کرد. چند روز پیش هم مطلع شدم که بعضی‌ها متودهایی تلفیقی برای مدیریت پروژه‌های ساختمانی ایران به کار می‌برن که عملا تحت تاثیر Agile بوده (به نظر من).
در هر حال، PMI هم توجهش به Agile خیلی بیشتر شده و آزمون و گواهی براش طراحی کرده، که نشون می‌ده از نظر اون‌ها هم این متود رو می‌شه به شکل وسیع‌تری به کار برد. اگه مطالب سایت رو دنبال کرده باشین می‌دونین که گواهی دیگه‌ای هم برای Agile هست، به اسم CSM (مخفف Certified Scrum Master) که خاص Scrum طراحی شده (یکی از انواع Agile) و در آینده نزدیک دوره آموزشیش هم در ایران برگزار می‌شه. تفاوت عمده آزمون PMI با اون در اینه که علاوه بر Scrum، انواع دیگه Agile رو هم پوشش می‌ده.
اگه علاقه‌مند به این موضوع باشین می‌تونین اطلاعات بیشتر رو از سایت PMI بگیرین.
بالاخره کتاب راهنمای جامع Microsoft Project 2010 چاپ شد. علاوه بر کتاب‌فروشی‌ها که به تدریج کتاب به دستشون می‌رسه، اگه مایل باشین می‌تونین اینترنتی هم بخرینش.
افراد زیادی تا حالا در مورد چاپ مجدد کتاب راهنمای جامع Microsoft Project 2007 از من سوال کردن. این کتاب دیگه چاپ نمی‌شه، چون مباحث اون رو کتاب جدید به طور کامل پوشش می‌ده و با این‌که برای پراجکت 2010 نوشته شده، برای پراجکت 2007 هم قابل استفاده‌س.
سوال دیگه‌ای که برای خیلی‌ها مطرحه اینه که اگه کسی کتاب پراجکت 2007 رو داشته باشه باز هم نیاز به این کتاب جدید داره یا نه. کسانی که با کمک کتاب قبلی پراجکت 2007 رو یاد گرفته باشن به نظر من مشکلی در کار با پراجکت 2010 ندارن و در نتیجه از این لحاظ نیازی به کتاب نخواهند داشت. با این حال مطالب جدیدی هم به کتاب اضافه شده که در موردشون تو مطالب قبلی سایت توضیح دادم و ممکنه در اختیار داشتن اون مطالب برای بعضی‌ها مفید باشه. تو نسخه جدید به موضوع ضرایب وزنی فیزیکی و شیوه عملیاتی شدن اون تو پراجکت و انواع شیوه‌های پایش (ثبت اطلاعات واقعی و به تناظر اون استخراج اطلاعات پیشرفت) خیلی بیشتر تاکید کردم و به تفصیل و همراه با مثال‌های زیاد توضیحش دادم. در آخر کتاب هم برنامه‌ریزی و کنترل پروژه‌ای فرضی از ابتدا تا انتها توضیح داده شده.
مدرک PMP داره روز به روز تو ایران بیشتر شناخته می‌شه و افراد بیشتری به این فکر می‌افتن که اون رو بگیرن. وقتی هم چنین فکری به ذهنشون می‌رسه انبوهی از سوال‌ها براشون مطرح می‌شه که به راحتی نمی‌تونن جوابشون رو پیدا کنن. این مطلب رو نوشتم که به همچین سوال‌هایی جواب بدم.
این مدرک چی هست؟
PMP مخفف Project Management Professional هست، یعنی چیزی تو مایه‌های حرفه‌ای در مدیریت پروژه. توجه کنین که مثلا نگفتن مدیر پروژه حرفه‌ای، به این خاطر که این کس ممکنه مدیر پروژه نباشه و صرفا در مدیریت پروژه حرفه‌ای باشه؛ یعنی تمام کسایی که کارشون برنامه‌ریزی و کنترله هم مخاطب مدرک می‌شن.
PMP مهم‌ترین، شناخته شده‌ترین و با ارزش‌ترین مدرکیه که تو زمینه مدیریت پروژه تو دنیا وجود داره و فاصله زیادی هم با رقبای خودش داره. به تمام معنا بین‌المللیه.
این مدرک یه گواهی حرفه‌ایه، نه گواهی آکادمیک؛ یعنی به ازای گذروندن تعدادی واحد و دریافت درجه‌ای آکادمیک داده نمی‌شه، به ازای داشتن شرایطی خاص (که جلوتر توضیح می‌دم) و قبولی در امتحان داده می‌شه. خیلی جاها برای مدارک حرفه‌ای ارزشی بالاتر از مدارک آکادمیک قائل هستن، چون نشون می‌دن که اطلاعات و مهارت‌های فرد کاملا کاربردی و واقع‌بینانه هست، در حالی که درجه‌های آکادمیک اطلاعات تئوریک رو تضمین می‌کنن که ممکنه در عمل به سادگی پیاده‌سازی نشن.
هر آدمی خصوصیت‌هایی داره که باعث می‌شه کارهایی رو بپسنده و کارهایی رو نپسنده و در نتیجه تو کارهای گروه اول بتونه موفق بشه و تو دومی‌ها به راحتی موفق نشه، اگه مشغول به دومی‌ها بشه زندگی براش نامطلوب بشه و …
به این خاطر آدم باید زمانی که داره مسیر کاری خودش رو انتخاب می‌کنه به این خصوصیت‌هاش خیلی دقیق فکر کنه. تمام کارهایی که تو زندگیتون انجام دادین و توشون موفق یا نا موفق بودین، ازشون خوشتون اومده یا خوشتون نیومده رو تحلیل کنین و ببینین ریشه در چه خصوصیت‌هایی داشته و کاری که برای آینده‌تون در نظر گرفتین بر این اساس مناسبه یا نه. باور کنین که این مسئله از بررسی وضعیت بازار کار مهم‌تره، به دو دلیل:
وضعیت بازار کار دایما تغییر می‌کنه. ممکنه کاری که امروز بازار خیلی خوبی داره بعد از این‌که توش حرفه‌ای بشین دیگه بازار خوبی نداشته باشه، و برعکسش هم صادق باشه.
تو کارهایی که بازار خوبی ندارن هم آدم‌هایی هستن که خیلی موفقن و تو کارهایی که بازار خیلی خوبی دارن هم آدم‌های خیلی زیادی هستن که اصلا موفق نیستن. چرا؟
در کنار این، معمولا آدم نمی‌تونه خصوصیت‌های ذاتی خودش یا ارتباط اون‌ها رو با کارش تغییر بده. از یه طرف دیگه، هر کسی که تو کار موفقه خوشبخته؟ نه الزاما. یکی از دلایلش اینه که کارش مطابق میلش نیست. به نظر من خوشبخت بودن خیلی مهم‌تر از موفق بودنه.
تو مطلبی با عنوان روش مناسب برای ارزیابی پیشرفت پروژه درباره امتیازهای روش تعیین پیشرفت مایل‌ستونی در خدمات طراحی و کارهای مشابه اون گفتم و توضیح مختصری هم دادم که باید چطوری تو نرم‌افزار پیاده‌سازی بشه.
نکته‌ای این وسط باید توضیح داده می‌شد که نگفتم. خیلی وقت‌ها مایل‌ستون‌های طراحی چیزی شبیه این تنظیم می‌شن:
تکمیل طراحی: 70٪
تایید: 90٪
تصویب: 100٪
یعنی وقتی مثلا مشاور طراح یه نقشه‌ای رو تموم می‌کنه و ارائه می‌کنه پیشرفتش می‌شه 70٪ (قبلش صفر بوده)، وقتی مشاور مادر تاییدش می‌کنه می‌شه 90٪ و وقتی کارفرما تصویبش می‌کنه می‌شه 100٪.
نکته‌ای که وجود داره اینه که خیلی‌ها مایل‌ستون اول رو “ارائه” در نظر می‌گیرن و این کاملا اشتباهه. این اشتباه باعث می‌شه که خیلی طراح‌ها سواستفاده کنن و طرح‌هایی کاملا ناقص رو “ارائه” کنن تا پیشرفتشون بشه 70٪ و بعد زمان خیلی زیادی صرف تکمیل واقعی و رفع اشکال و در نهایت تاییدش بشه و بعد بشه 90٪. تو این حالت هم ارزیابیمون دچار مشکل شده و هم روند بررسی و رفع اشکال طرح. پس باید جلوی چنین مشکلی رو بگیریم.
راه حل اینه که مایل‌ستون اول به جای “ارائه”، “تکمیل"باشه. وقتی طراح سندی رو ارائه می‌کنه، مشاور مادر اون رو خیلی سریع و کلان مرور می‌کنه و اگه از نظر گستره (اسکوپ) مشکلی نداشت، “می‌پذیره” که کار کامل …
یه جایی بودم، کسی گفت که “اگه می‌خوای خدا خندش بگیره، برنامه‌ریزی کن”. خوب، چنین خدایی باید خیلی بی‌مزه و نادون باشه که به چنین چیز مهمی بخنده. خیلی‌ها تو برنامه‌ریزی ضعیفن، از برنامه‌ریزیشون درست نتیجه نمی‌گیرن و بعد به جای این‌که روند برنامه‌ریزی خودشون رو زیر سوال ببرن، سعی می‌کنن خود ماهیت برنامه‌ریزی رو زیر سوال ببرن. اشتباه!
اشتباه آدما در اینه که برنامه‌ریزی‌هاشون انعکاسی از انتظارها و ایده‌آل‌هاشونه. ولی برنامه‌ریزی این نیست. برنامه‌ریزی مدلی شبیه‌سازی شده از کاریه که قراره انجام بشه، با تمام مسایلش.
برنامه‌ریزی پروژه یعنی این‌که مدیر پروژه، مشاورهاش و تمام تیم پروژه بشینن، اجرای پروژه رو با تمام مسایل و مشکلات و پیچیدگی‌هاش تصور کنن و اون رو ثبت کنن. یعنی پروژه رو چندین بار تو ذهنشون اجرا کنن، طوری که اجرای واقعی پروژه یکی از حالت‌های بررسی شده باشه.
یه جمله خیلی قشنگ هست که می‌گه:
Plan the work, work the plan
برنامه‌ریزی باید طوری باشه که بشه چنین جمله‌ای رو گفت.
برنامه زمان‌بندی یه تابلوی نقاشی نیست؛ یه گانت چارت که اول پروژه تهیه کنیم، پرینتش کنیم بزنیم به دیوار و تا آخرش پروژه هر از چندی نگاهی بهش بندازیم نیست. برنامه زمان‌بندی باید مدلی شبیه‌سازی شده از پروژه باشه. تو هر دوره باید اطلاعات واقعی رو واردش کنیم و اون تغییر شکل بده و بهمون بگه که با واقعیت‌هایی که تا حالا …
راستش تا حالا کسی از مخاطب‌های سایت چنین سوالی از من نپرسیده، ولی یه بار که تو دوره آموزش حین خدمت آموزش و پرورش درس می‌دادم این سوال رو زیاد ازم پرسیدن و الان هم یه گزارش پیشرفت جلومه که نمودارهاش سه‌بعدی‌ان. به این خاطره که می‌خوام به این سوال جواب بدم.
سوال: چه زمانی از نمودارهای سه‌بعدی استفاده کنیم؟
پاسخ: هیچوقت!
نمودارهای سه‌بعدی هیچ نکته مثبتی ندارن و خواناییشون هم همیشه کمتر از نمودارهای دو بعدیه. در نتیجه هیچ دلیلی نداریم که ازشون استفاده کنیم.
بعضی‌ها احساس می‌کنن نمودارهای سه‌بعدی قشنگ‌ترن و به همین خاطر ازشون استفاده می‌کنن. به نظر من قشنگ‌تر هم نیستن. از اون گذشته، اگه زیبایی براتون اهمیت داره، همیشه می‌تونین به روش‌های حرفه‌ای‌تری گزارش‌هاتون رو زیبا کنین، طوری که همراه با زیباتر شدن، خواناتر هم بشن. اگه دوست دارین تو این زمینه پیشرفت کنین، باید کتاب‌هایی که درباره Information Visualization نوشته شده رو بخونین و در این بین کتاب‌های استیفن فیو از واجبات هستن. این اسم براتون آشنا نیست؟ این آدم همونیه که نمودارهای گلوله‌ای رو ابداع کرده.
اگه می‌خواین بپرسین که “اگه نمودارهای سه‌بعدی به درد نمی‌خورن، اصلا چرا اکسل همچین چیزی داره؟”، جواب من اینه که “برای این‌که قابلیتی از نرم‌افزارهای رقیب کم نداشته باشه” و اگه بپرسین …
اگه می‌خواین به زمان و کارهایی که می‌کنین مسلط باشین، حتما باید یه “ژورنال” داشته باشین: یه فایل ورد یا اکسل یا حتی فایلی که با نرم‌افزارهای مخصوص این کار ساخته می‌شه. باید تمام کارهایی که در طول روز می‌کنین و مدت زمانی که برای هرکدوم صرف می‌کنین رو تو فایل وارد کنین.
خیلی مشخصه که یه فایده این کار اینه که بعدا می‌تونین به فایل مراجعه کنین و جواب بعضی سوال‌هاتون رو پیدا کنین (فلان گزارش رو چه تاریخی برای بهمان جا فرستادم؟)؛ ولی این اهمیت زیادی نداره.
فایده اصلی اینه که می‌فهمین زمانتون رو چطوری صرف می‌کنین. واقعیت اینه که همه مدت زیادی از زمانمون رو صرف کارهای کم ارزش می‌کنیم و اگه اون زمان رو کم کنیم و بذاریمش برای کارهای مهم‌تر، خیلی موفق‌تر خواهیم بود. برای این کار باید مدت زمانی که برای هر نوع کاری صرف می‌کنین رو مشخص کنین و میزان محصولی که به دست آوردین رو هم حساب کنین. بعد از این‌که اطلاعات چند ماه رو تحلیل کنین (که قطعا یه کارشناس برنامه‌ریزی و کنترل پروژه باید خیلی تو این کار وارد باشه)، مطمئنا تحت تاثیر جواب‌ها قرار می‌گیرین. قدم بعدی اینه که برای تغییر سیستمتون برنامه‌ریزی کنین و همچنان ارزیابی رو ادامه بدین. می‌دونم که اکثرا تا حالا چنین کاری نکردین؛ این همون ماجرای کوزه‌گریه که از کوزه شکسته آب می‌خوره. یه کم هم به فکر خودتون باشین.
تو خیلی از پروژه‌ها علاوه بر اجرا، طراحی هم داریم. اشتباه رایج اینه که پیشرفت طراحی رو هم مثل اجرا تعیین می‌کنیم. مثلا می‌گیم که نقشه‌های سیستم اعلان حریق فلان ساختمون ماه پیش 32٪ بوده و این ماه شده 58٪.
این روش به دو دلیل درست نیست:
تعیین پیشرفت واقعی طراحی عینی نیست. چطوری می‌خوایم بگیم که 58 درصد کار انجام شده؟ مثلا تعداد ساعت‌های کاری که روش انجام شده رو به برآورد اولیه تقسیم کنیم؟ بعیده برآورد اولیه کاملا درست باشه. چیکار می‌کنیم؟ عملا شهودی می‌شه. ولی پیشرفت کارهای اجرایی اینطوری نیست. مثلا پیشرفت ساخت یه دیوار رو وقتی می‌خوایم تعیین کنیم خیلی راحت مقدار ساخته شده‌ش رو به کل مقدارش تقسیم می‌کنیم و این کل مقدار کاملا مشخصه.
نتایج طراحی معمولا پیش از تکمیل کاملا در دسترس مشاور مادر و کارفرما قرار نمی‌گیره و اون‌ها پیش از تکمیل نمی‌تونن دقیقا بدونن که چقدر کار انجام شده. این هم باز با دیوارکشی فرق می‌کنه، چون وقتی پیمانکار داره یه دیوار رو می‌سازه هرکسی می‌تونه بره، اون رو ببینه و بفهمه که چقدر کار انجام شده.
نتیجه هم اینه که پیمانکار یا مشاور طراح، مشاور مادر و کارفرما دایما در مورد درصدهای پیشرفت اختلاف نظر خواهند داشت.
به خاطر تمام این مسایله که معمولا تو همه جای دنیا پیشرفت طراحی رو مثل کارهای اجرایی ارزیابی نمی‌کنن. امیدوارم متوجه شده باشین که منظورم مشخص کردن پیشرفت …
یکی از چیزایی که معمولا تو گزارش‌ها وجود داره، سرفصلیه با اسم “موانع و مشکلات پروژه”. این سرفصل خیلی مهمه و حتما هم باید تو گزارش‌ها باشه، حتی من همیشه تاکید می‌کنم که اگه مشکلی وجود نداره هم سرفصل رو بذارن و بعد زیرش بنویسن که این دوره مشکلی نبوده.
چیزایی که برای این سرفصل نوشته می‌شه معمولا مشکلایی داره و می‌خوام درباره این مشکلا و راه بهتر کردنشون بگم. اولین نکته اینه که باید عنوان این سرفصل رو عوض کنیم. “موانع و مشکلات” جالب نیست، منفیه. به جاش بذاریم “مشکلات و راه حل‌ها”. این باعث می‌شه همه یادشون باشه که اگه به مشکلی اشاره می‌شه، به این خاطره که راه حلش پیدا بشه.
خیلی وقتا تو این سرفصل آیتم‌های اینطوری می‌بینیم:
عقب افتادن کارها به خاطر تاخیر مشاور در ارائه نقشه‌ها.
این آیتم به هیچ دردی نمی‌خوره؛ نق زدنه و گزارش جای نق زدن نیست. آیتم درست اینه:
عقب افتادن فلان کار، به خاطر این‌که طبق زمان‌بندی مصوب انتظار داشتیم مشاور بهمان نقشه رو تو فلان تاریخ به ما تحویل بده، در حالی که در بهمان تاریخ تحویل داده.
این می‌شه یه ادعای درست و حسابی که جای بررسی داره. وقتی ادعا اینطور دقیق باشه خیلی بهتر هم آدم رو به سمت پیدا کردن راه حل هدایت می‌کنه. خوب، برای این‌که این آیتم کامل بشه باید یک یا چند راه حل هم بدیم. مثلا برای این آیتم فرضی:
وقتی یه کارشناس پیشرفت می‌کنه چی می‌شه؟ می‌شه مدیر. این تصور خیلی اشتباهه.
این تصور از چند جهت اشتباهه:
مدیریت با کار کارشناسی خیلی تفاوت داره؛ مثل این می‌مونه که من بگم کارشناس طراح تاسیسات برقی هستم و دلم می‌خواد پیشرفت کنم بشم کارشناس اجرایی سازه؛ ربطی نداره.این پیشرفت نیست، تغییره. خیلی‌ها هستن که وقتی کار کارشناسی رو ترک می‌کنن و مدیر می‌شن حوصله‌شون سر می‌ره، چون کاری که دوست دارن کار کارشناسیه، نه مدیریتی.
درسته که مدیریت از لحاظ سازمانی بالاتر از کارشناسیه و معمولا آدم‌ها بعد از مدتی کارشناس بودن تبدیل به مدیر می‌شن، ولی این هم باعث نمی‌شه که آدم فکر کنه پیشرفتش در گروی اینه که بشه مدیر. آدم می‌تونه کارشناس قوی‌تری بشه، freelance و مشاوره‌ای کار کنه، کارهای هیجان‌انگیزتر بگیره، با شرکت‌های قوی‌تر کار کنه، تو انتخاب کار و شرایط انجامش دستش بازتر باشه، درآمد خیلی بالاتر داشته باشه و …
مدیریت یه تخصصه. آدم وقتی می‌تونه مدیر باشه که دانش و مهارت کافی داشته باشه؛ البته به نظر خیلی‌ها باید یه سری خصوصیت‌های ذاتی و غیر اکتسابی هم داشته باشه. پیشرفت در کار کارشناسی برای مدیر شدن کافی نیست و فرد حتما باید مهارت‌های مدیریتی خودش رو هم ارتقا بده. حتی کارشناس خبره بودن شرط لازم برای مدیر بودن هم نیست، اگه مدیر اطلاعاتی کلی درباره جنبه‌های فنی کار داشته باشه کافیه. این اشتباه رو زیاد …