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