برای مدیریت ریسک پروژه نیاز به چهار نوع منبع دارین:
منبعی که شیوه یکپارچه‌سازی اون رو با بقیه کارهای مدیریت پروژه مشخص کنه، که بهترین منبع برای این ماجرا PMBOK هست.
منبعی که شیوه اجرای اون رو در بستر کلی پروژه مشخص کنه، که بهترین منبعش PRINCE2 هست.
منبعی که چهارچوب خود مدیریت ریسک رو به خوبی مشخص کنه، که بهترین منبعی که من می‌شناسم استاندارد M_o_R از AXELOS هست (هم خانواده پرینس۲).
منبعی که تکنیک‌ها و روش‌ها رو توضیح بده و مورد قبلی رو تکمیل کنه. برای این مورد متاسفانه فعلا پیشنهاد خاصی ندارم. البته خیلی اوقات نیازی نیست که سیستم مدیریت ریسک خیلی پیچیده بشه و حدی از تکنیک‌ها که مورد سوم توضیح داده می‌شه براتون کافی خواهد بود.
آیا این‌ها با هم سازگارن؟
بله، کاملا. هرکدوم از اون‌ها مدیریت ریسک رو از یه زاویه‌ای می‌بینن و همگی باید تا درجه‌ای اختصاصی‌سازی بشن که تو این ماجرا کاملا سازگار هم خواهند شد.
یعنی PMBOK برای مدیریت ریسک کافی نیست؟
پم‌باک برای هیچ چیزی تو مدیریت پروژه کافی نیست و هدفش اینه که شیوه یکپارچگی فرآیندهای مدیریت پروژه رو توضیح بده. در مورد همه جنبه‌ها باید از منابع دیگه هم کمک بگیرین. لطفا توجه داشته باشین که این مسئله به معنی نقص پم‌باک نیست؛ هدف و گستره پم‌باک اینه.
این استاندارد M_o_R رو از کجا می‌شه تهیه کرد؟
متاسفانه نمی‌دونم. شاید بتونین از تو اینترنت پیداش …
خیلی از ما با پرسشنامه سر و کار داریم. احتمال داره اولین چیزی که به نظرتون برسه گردآوری اطلاعات برای پایان‌نامه باشه، ولی ماجرا به اون محدود نمی‌شه. مثلا ما برای استقرار سیستم‌های مدیریت پروژه با افراد کلیدی و تعداد محدودی از سایر افراد مصاحبه می‌کنیم و برای بقیه فقط پرسشنامه می‌فرستیم.
من فقط می‌خوام یه ماجرای بسیار مهم که تقریبا هیچ کس رعایت نمی‌کنه رو توضیح بدم: قالب‌بندی پرسشنامه الکترونیکی.
یه نکته خیلی مهم در مورد پرسشنامه اینه که مخاطبتون رو نباید خسته کنین. باید کوتاه باشه و جواب دادن تا جای ممکن راحت. خیلی از کسایی که پرسشنامه‌تون رو پر می‌کنن از نسخه‌های الکترونیکی استفاده می‌کنن و در این صورت اگه می‌خواین طرف مقابلتون رو خسته و کلافه کنین تا بدترین نتیجه ممکن رو بگیرین، حتما یه فایل PDF که قابل ویرایش نیست براش بفرستین!
بهترین راه ارائه پرسشنامه الکترونیکی
بهترین راه اینه که پرسشنامه با گوگل فرمز یا نرم‌افزاری مشابه اون تنظیم شده باشه. لینک رو برای مخاطب می‌فرستین و اون هم خیلی راحت با چنتا کلیک جواب می‌ده. جواب‌ها هم خیلی خوب و تر و تمیز می‌رن تو یه فایل مشابه فایل‌های اکسل می‌شینن، آماده این‌که برین سراغشون.
راه حل بعدی
اگه به هر دلیلی نمی‌خواین از راه حل قبل استفاده کنین، حتما از «فیلد»های ورد استفاده کنین. باهاش می‌تونین مشخص کنین که چه جاهایی قراره مقداری وارد بشه …
می‌دونم که تا حالا خیلی در این مورد نوشتم، ولی واقعا به نظر من روزمرگی یکی از وحشتناک‌ترین اتفاق‌هاییه که برای کسی می‌تونه بیفته و کسای زیادی رو می‌بینم که کارشون برنامه‌ریزی و کنترل پروژه‌ش و این کار براشون چیزی بیشتر از روزمرگی نیست.
شاید این ماجرا برای بعضی‌ها مطلوب باشه که در این صورت دیگه به من ربطی نداره. با این حال خیلی‌ها هم هستن که گرفتار روزمرگی می‌شن، در حالی که خودشون دوست ندارن و دلشون می‌خواد تغییرش بدن؛ مخاطب من اون‌ها هستن. البته کسی که تو گروه اول باشه (علاقه‌مند به روزمرگی) اصولا خواننده سایت هم نیست.
یکی از بزرگ‌ترین قدم‌ها برای مبارزه با روزمرگی اینه که تو کارتون تحویل‌شدنی‌های مشخص داشته باشین. این ماجرا برای پروژه‌ها هم مهمه: این‌که چطوری بتونیم یه محصول بزرگ رو به اجزای معنی‌دار کوچیک بشکنیم و به تدریج تکمیلشون کنیم. وقتی اجزا کوچک و در عین حال معنی‌دار باشن، تکمیل شدنشون پیشرفت واقعیمون رو نشون می‌ده. این ماجرا برای پروژه‌های چابک خیلی مهم‌تر هم هست، چون با تحویل‌شدنی‌های معنی‌دار بازخورد دریافت می‌کنیم و این بازخورده که ادامه کار رو مشخص می‌کنه.
تو زندگی حرفه‌ایمون هم مسئله همینطوره. اگه تحویل‌شدنی‌های مشخصی نداشته باشین، امکان و احتمال روزمرگی خیلی زیاد می‌شه. اگه بتونین تحویل‌شدنی‌های مناسب برای خودتون بسازین، به احتمال زیاد می‌تونین از اون وضعیت نجات …
به لطف این واقعیت که ایرانی‌ها روز به روز بیشتر دارن به کشورهای مختلف مهاجرت می‌کنن، این هم داره به یه سوال رایج تبدیل می‌شه که من فلان کشور زندگی می‌کنم، کدوم گواهی رو بگیرم برای آینده شغلیم بهتره.
الان می‌خوام به جای جواب معمولی، یه مقدار «ماهی‌گیری» رو تو این ماجرا توضیح بدم.
قدم اول: پیدا کردن اون چیزایی که مهمه
اولین قدم اینه که این دو کار رو بکنین:
تو سایت‌های مختلف آگهی‌های استخدام مرتبط با شغلتون که برای اون کشور هست رو پیدا کنین و ببینین چه قابلیت‌ها و مهارت‌ها و گواهی‌هایی انتظار دارن.
برین تو لینکدین آدم‌هایی که تو اون کشور تو حوزه کاری شما فعال هستن رو پیدا کنین و ببینین که چه قابلیت‌ها و مهارت‌ها و گواهی‌هایی دارن.
یه لیست از این موارد بسازین.
قدم دوم: اولویت‌بندی لیست
حالا بر اساس بسامد اون موارد تو آگهی‌ها و پروفایل‌ها و همینطور سادگی یا مشکل بودن به دست آوردن اون مهارت یا گواهی، رده‌بندی‌شون کنین. برای این‌که مثلا بدونین گرفتن هر گواهی چقدر مشکله هم قاعدتا باید تو اینترنت جستجو کنین. چون فرض بر اینه که ایران زندگی نمی‌کنین خوشبختانه کار کردن بدون مشقت با اینترنت امکان‌پذیر خواهد بود.
وقتی لیست رو اولویت‌بندی می‌کنین رتبه‌ها رو از ۳ شروع کنین. رتبه ۱ همیشه تسلط به زبان و رتبه ۲ آشنایی با فرهنگ کشور مقصده.
تا حالا یادداشت‌های زیادی در مورد پیشرفت اینجا بوده. مثلا توصیه همیشگی من که هیچوقت کاری رو دو بار یه جور انجام ندین. هر وقت کاری روتین مثل تهیه گزارش باید انجام بدین به این فکر کنین که چطوری می‌شه یه کم روش کار رو بهتر از دفعه قبل کرد.
یه نکته دیگه که از زاویه دیگه‌ای می‌تونه به پیشرفت کمک کنه اینه که هروقت کسی ازتون می‌خواد کاری رو انجام بدین، یه قدم اضافه بر اون چیزی که ازتون خواسته شده هم بردارین. مثلا اگه ازتون خواستن گزارش خاصی تهیه کنین با محتوای مشخص، می‌شه در کنارش یه گزارش تک صفحه‌ای خلاصه هم براش تهیه کنین تا برای مخاطب‌های خاص مفید باشه. یا در کنار تحلیل‌هایی که ازتون خواستن انجام بدین یه تحلیل اضافه هم که به نظرتون برای هدفشون مناسبه انجام بدین و نتیجه رو اعلام کنین.
وقتی می‌خواین این کار رو بکنین حتما دو نکته رو در نظر داشته باشین:
اون محصول اضافه نباید تداخلی با محصول اصلی داشته باشه. یعنی محصول اصلی به همون شکلی که انتظار داشتن باید تهیه شده باشه و یه محصول مرتبط جانبی کنارش قرار بگیره. در هر حال ممکنه اون محصول جانبی بر خلاف انتظار شما همسو با نیازها و انتظارهاشون نباشه.
وقت خیلی زیادی نباید صرف محصول جانبی بکنین، چون به هر حال وقت و انرژی شما برای مجموعه مهمه و ترجیح می‌ده تو مسیری که تشخیص می‌دن برای پروژه مناسبه بره و ممکنه ایده شما همیشه همسو نباشه. پیشنهاد من …
مدتیه که انرژی زیادی روی مبحث اشتباه‌های تصمیم‌گیری و اثری که روی مدیریت پروژه می‌ذارن گذاشتم که هم موضوع بعضی دوره‌های آموزشیم برای مدیران رده بالای شرکت‌ها بوده و هم سخنرانی تو کنفرانس‌های PMI. بحث خیلی جالبیه که اثرش هم اصلا محدود به مدیریت پروژه نیست و به شکلی خیلی موثر و جدی کل زندگیمون رو تحت تاثیر می‌ذاره. کلا هم مطالعه در مورد این مبحث رو شدیدا به همه توصیه می‌کنم، هم برای بهتر شدن تو مدیریت پروژه و هم برای داشتن زندگی بهتر.
یکی از اشتباه‌ها، توهم کنترله. آزمایش کلاسیکش اینه که عده‌ای رو تک تک می‌برن تو یه اتاق و یه سری سیم بهشون وصل می‌کنن و توضیح می‌دن که هدف آزمایش اینه که آستانه تحمل آدم‌ها در برابر شوک الکتریکی اندازه‌گیری بشه. به آدم‌ها می‌گن که شوک رو از مقدار خیلی کم شروع می‌کنن و به تدریج بالا می‌برن و طرف هروقت که دید دیگه نمی‌تونه تحمل کنه اعلام کنه که بلافاصله آزمایش قطع بشه.
آدم‌ها تو این آزمایش دو دسته می‌شن، به یه گروهشون می‌گن که هروقت نمی‌تونستی تحمل کنی برای ما دست تکون بده تا بلافاصله آزمایش رو قطع کنیم. برای گروه دوم اوضاع متفاوته. جلوی دست این آدم‌ها یه دکمه قرمز بزرگ هست و بهشون می‌گن هروقت نمی‌تونستی تحمل کنی این دکمه رو فشار بده تا آزمایش بلافاصله قطع بشه.
استاندارد پرینس۲ نقش‌ها و مسئولیت‌ها رو خیلی دقیق تعریف می‌کنه، چون یه متودولوژیه. نقش‌هایی که تعریف کرده رو هم با رعایت شرایطی می‌شه تغییر داد. مثلا می‌شه بعضی‌هاشون رو شکست به چنتا، یا برعکس، چنتاشون رو با هم ترکیب کرد. مثلا دو نقش مدیر پروژه و مدیر تیم اجرایی رو می‌شه با هم ترکیب کرد؛ اگه پروژه کوچیک و ساده باشه. با این حال بعضی‌ها رو نمی‌شه با هم ترکیب کرد، مثلا مدیر ارشد (حامی) و مدیر پروژه.
تو حالت کلی کمترین تعداد افرادی که می‌تونیم تو تیم مدیریت پروژه‌مون داشته باشیم دوتاس، مدیر پروژه و مدیر ارشد. بقیه رو می‌شه کامل با این دوتا ترکیب کرد. حالا سوال خیلی‌ها اینه که چرا نمی‌شه این دوتا رو با هم ترکیب کرد. مثلا اگه پروژه خیلی خیلی ساده و کوچیک باشه، چه دلیلی داره که دو نفر مسئولیت مدیریتی براش داشته باشن؟
جواب همیشگی من اینه: مسئولیت مدیر ارشد جنبه‌های کلان پروژه و مسئولیت مدیر پروژه مسایل جزئی‌تر و نسبتا روزمره‌س. طبیعت آدم اینه که اگه دو نوع مسئولیت متفاوت به این شکل داشته باشه، ناخودآگاه اونی که انتزاعی‌تر و کلان‌تره رو فراموش می‌کنه و فقط متمرکز می‌شه روی مسایل روزمره. به همین خاطر اگه پروژه کوچیک باشه و این دو نفر رو تبدیل کنیم به یه نفر، به اندازه کافی به جنبه‌های کلان پروژه توجه نمی‌شه و از این بابت دچار مشکل می‌شیم.
یه آزمایش خیلی سال پیش‌ها انجام شده بود که الان خیلی …
به این سوال راحت نمی‌شه جواب داد، چون PMO تعریف مشخصی نداره. معمولا کسایی که چنین سوالی می‌پرسن قصد دارن سیستم‌های مدیریتی مربوط به پروژه رو بهبود بدن و به همین خاطر هم به این سوال که کامل‌تره جواب می‌دم.
روند کلی کار اینه که اول باید وضعیت فعلی رو ارزیابی کنیم. برای این کار باید با افراد کلیدی شرکت مصاحبه کرد، اسناد رو بررسی کرد، حتی اگه امکانش باشه با ذی‌نفعان خارجی مصاحبه کرد و امثال اون. از مدل‌های بلوغ مدیریت پروژه یا مدل‌های سلامت مدیریت پروژه هم می‌شه برای این کار کمک گرفت. قطعا اگه کسی از نیروهای داخلی شرکت این مسئولیت رو به عهده داشته باشه خیلی کار سریع‌تر می‌شه، ولی نباید میانبر زد. از طرف دیگه، معمولا مشاورهای خارج شرکت بهتر می‌تونن تو این زمینه کمک کنن، چون از یه طرف با دید باز و بی‌طرفانه وارد شرکت می‌شن و از طرف دیگه، تجربه بیشتری می‌تونن تو این ماجرا داشته باشن؛ هرچی باشه کسی که تو یه شرکت کار می‌کنه مشغول مسئولیت‌های مدیریتیه، نه طرح‌های بهبود سیستم‌های مدیریتی. در هر حال، من معمولا وقتی چنین مسئولیتی دارم بین یک تا سه ماه زمان صرف گردآوری اطلاعات می‌کنم، که به نظر شرکت‌ها زیاد میاد، ولی کاملا لازمه. نباید سریع نتیجه‌گیری کرد. اگه کسی خیلی سریع بعد از چند هفته شروع به «طراحی» و پیاده‌سازی کنه مسلما داره یه نسخه بی‌ربط می‌پیچه.
خیلی وقت‌ها از من درباره روش مناسب کار کردن سوال می‌شه و برای همین تصمیم گرفتم این مطلب رو بنویسم. این یه راهنمایی کلی نیست، چون من تو این ماجرا متخصص نیستم؛ فقط قصد دارم جنبه‌هایی که در مورد خودم برقراره و در طی سال‌ها بهش رسیدم رو براتون تعریف کنم.
وقتی آدم تو کار موفقه که ازش لذت ببره. به این فکر کنین که صبح‌ها که از خواب بلند می‌شین (خصوصا شنبه‌ها) با خودتون دارین فکر می‌کنین که «وای، بازم باید برم سر کار»، یا برعکس، یه حسی درونتون هست که می‌خواین هرچه سریع‌تر برین سراغ کار؟ معمولا آدم‌های موفق از گروه دوم هستن. این هم چیزی نیست که با تغییر رویکرد آدم به کار شکل بگیره، معمولا باید نوع کار رو طوری عوض کرد که خود به خود چنین حسی به وجود بیاد.
چیزهایی که کار رو برای من لذت‌بخش می‌کنن و اگه نباشن هم موفق نخواهم بود و هم زندگی برام جالب نمی‌شه این‌ها هستن:
دست‌آورد: من باید به ازای هر کاری که می‌کنم دست‌آوردی داشته باشم. چیزی که واقعا با ارزش باشه و رسما بشه اون رو محقق شده دونست. وجود چنین چیزی به من انرژی می‌ده که کارم رو خوب انجام بدم و براش انرژی بذارم. اگه یه مدتی مجبور باشم روی چیزهایی کار کنم که دست‌آورد خاصی ندارن، به شدت از نظر کاری افسرده می‌شم و بازده‌ام افت می‌کنه. مثال کمابیش تکراری: اگه قرار باشه هر ماه یه گزارش تهیه کنم، برام حس دست‌آورد رو نداره؛ یه کار تکراری و …
چند وقت پیش تو مطلبی درباره biasهای فکری نوشته بودم و این‌که چطوری باعث می‌شن تصمیم‌گیری‌های اشتباه بکنیم. تو این مدت چند نفر به من ایمیل دادن و پرسیدن که چطوری می‌شه باهاشون مقابله کرد. سوال خیلی خوبیه و می‌خوام خیلی خلاصه رویکرد خودم رو براتون بگم.
برای این‌که جلوی مشکلات ناشی از biasهای فکر رو بگیریم سه روش و سه مرحله وجود داره:
مرحله اول: درک و پذیرش
درک این‌که biasها چی هستن و چرا وجود دارن و پذیرفتن این‌که خودمون هم دچارشون هستیم، نه این‌که فقط مشکلیه برای بقیه. برای این ماجرا باید در موردشون تحقیق و مطالعه کنین و بعد سعی کنین رد پای اون‌ها رو تو تصمیم‌گیری‌های دیگران و خودتون پیدا کنین.
همین که آدم این کار رو بکنه خودش نوعی ایمنی ایجاد می‌کنه و تصمیم‌گیری‌ها بهتر می‌شن.
علاوه بر اون مطالعه این کتاب‌ها رو هم پیشنهاد می‌کنم:
Thinking, Fast and Slow، از Daniel Kahneman – این کتاب خیلی خوبیه و گذشته از این‌که اطلاعاتش خیلی به بهبود تصمیم‌گیری‌ها کمک می‌کنه، درک خیلی خوبی هم از مبنای وجود و مکانیزم عملکرد biasها می‌ده.
The Art of Thinking Clearly، از Rolf Dobelli – این کتاب مجموعه‌ای از مهم‌ترین biasها رو با مثال‌های خیلی خوب توضیح می‌ده.
این ماجرا که اختصاصی‌سازی (tailoring) برای اکثر استانداردها، از جمله PMBOK و PRINCE2، الزامیه، باعث می‌شه که اهمیت زیادی پیدا کنه، در حالی که شیوه انجام این کار برای خیلی‌ها مبهمه. تو این مطلب می‌خوام یه مقدار اختصاصی‌سازی رو توضیح بدم.
اولین نکته اینه که برای استفاده از استاندارد تو پروژه‌ها دو مرحله کار لازمه:
انطباق استاندارد با سازمان، که اصطلاحا بهش می‌گن embedding
انطابق نسخه اختصاصی‌سازی شده سازمان با پروژه‌ای که قراره شروع بشه، که بهش می‌گن tailoring
البته این رو باید بدونین که خیلی جاها به هردوی این‌ها tailoring می‌گن.
کلمه tailor وقتی حالت اسمی داشته باشه به معنی خیاطه؛ البته معمولا خیاطی که کت شلوار می‌دوزه. وقتی حالت فعل داشته باشه معنیش می‌شه: چیزی رو به شکلی بسازیم که برای کار یا فرد خاصی مناسب باشه یا چیزی که وجود داره رو به شکلی تطبیق بدیم که کاملا برای فرد یا کاری که در نظر داریم مناسب باشه. وقتی درباره tailor کردن استاندارد صحبت می‌کنیم هم همین معنی در نظره.
مرحله ۱: embed کردن استاندارد در سازمان
اولین مرحله embed کردن استاندارد تو سازمانه، یعنی نسخه‌ای اختصاصی‌سازی شده از استاندارد بسازیم که برای سازمان و پروژه‌های مختلفی که توش اجرا می‌شه مناسب باشه. ماجرا اینه که پروژه‌های مختلفی که تو یه سازمان انجام می‌شن از نظر مدیریتی خیلی به هم نزدیکن، چون سازمان انجام …
بعضی‌ها تو تشخیص تفاوت بین enterprise environmental factors و organizational process assets تو PMBOK مشکل دارن که بخشی از این مشکل برمی‌گرده به درک تفاوت واژه‌های enterprise و organization. از طرف دیگه بعضی‌ها هم احتمالا کنجکاوین که به شکل کلی تفاوت این دو رو بدونین.
organization
کلمه organization که معمولا به سازمان معادل می‌شه به هر ترکیبی از آدم‌ها گفته می‌شه که برای رسیدن به هدفی گرد هم اومدن. معمولا منظور از سازمان یه شرکت یا یه ترکیب غیر انتفاعی یا ترکیبی دولتیه، ولی می‌تونه به چیزهایی خردتر از اون‌ها هم گفته بشه. مثلا خود پروژه هم می‌تونه یه سازمان به حساب بیاد یا حتی زیرمجموعه یه پروژه هم می‌تونیم سازمان‌های مختلفی مثلا برای مدیریت، برای اجرای بخش‌های مختلف و امثال اون‌ها در نظر بگیریم.
کلمه organization تو پم‌باک معمولا به معنی شرکت یا موسسه‌های مشابه اون به کار می‌ره و تو عبارت organizational environmental factor صرفا به معنی سازمانیه که داره پروژه رو اجرا می‌کنه (مثلا پیمانکار).
enteprise
کلمه enterprise دو معنی کلی داره. معنی اول مشابه organization هست، با این تفاوت که ترکیب‌های خردتر رو در بر نمی‌گیره؛ یعنی به شرکت یا سازمان‌های غیر انتفاعی و دولتی و امثال اون‌ها گفته می‌شه. قدیم (مثلا بیست سال پیش) فقط به سازمانی enterprise گفته می‌شد که بزرگ و پیچیده باشه، ولی الان …
امسال هم مثل سال گذشته برای سخنرانی تو کنفرانس PMI بلژیک انتخاب شدم. عنوان موضوع امسال من اینه: Project managers are biased too.
مطلبی خاص و متفاوت در مورد اشتباه‌هاییه که به خاطر گرایش‌های ناخودآگاهمون تو تصمیم‌گیری‌های مدیریتی می‌کنیم و ریشه‌های اون موارد. این عوامل البته به مدیریت پروژه محدود نمی‌شن و بحث مفصلیه تو اندیشه انتقادی (critical thinking) و رشته‌های دیگه. با این حال تو این مطلب ماجرا از زاویه دید مدیران پروژه‌ها بررسی می‌شه.
به عنوان نمونه، تکنیک دلفی، که احتمالا اسمش رو شنیده باشین (مثلا تو پم‌باک هم بهش اشاره می‌شه) روشیه برای جلوگیری از بعضی مشکلات اینچنینی. ماجرا اینه که اگه برای پیدا کردن ایده‌های جدید یا راه‌حل‌های بدیل تو یه جلسه شروع کنیم از آدم‌ها نظرشون رو بپرسیم، نظر هر کسی روی نظر بقیه اثر می‌ذاره و جواب کاملی نمی‌تونیم بگیریم. برای همین می‌شه مثلا با تکنیک دلفی پیش رفت و اول از همه نظرهاشون رو مکتوب و بی‌نام گرفت و بعد از این‌که نظرها جمع‌آوری و مرتب شد به بحث بذاریمشون.
حالا یه مثال: به شما این فرصت داده شده که بازی A یا بازی B رو انتخاب کنین و این بازی یک بار براتون اجرا می‌شه. مشخصات بازی این پایین اومده و بهتره که تو حداکثر ۱۰ ثانیه جواب بدین. حتما هم صادقانه جواب بدین، طوری که انگار واقعا قراره بازی رو انجام بدین و پول رد و بدل بشه. یه سکه می‌ندازیم …
وقتی کتاب راهنمای جامع پراجکت ۲۰۱۳ منتشر شد مجبور شده بودم بخش پروژه‌های نمونه رو ازش حذف کنم که تعداد صفحه‌ها از حدی که برای ناشر مناسبه بیشتر نشه. از طرف دیگه وعده داده بودم که کتابی مستقل و خیلی مفصل‌تر برای پروژه‌های نمونه تهیه کنم،که متاسفانه تا الان فرصتش پیش نیومد.
چون خیلی‌ها به دنبال پروژه‌های نمونه بودن، به این نتیجه رسیدم که بهتره فعلا دو پیوست انتهایی کتاب پراجکت ۲۰۱۰ که پروژه‌های نمونه‌ش بود رو در اختیار خواننده‌ها بذارم تا زمانی که کتاب اصلی رو بتونم تهیه کنم.
یکی از اصول مدیریت پروژه اینه که باید درس آموخته‌های (lessons learned) پروژه رو ثبت و نگهداری و بازاستفاده کرد. وقتی می‌خوایم پروژه جدیدی رو شروع کنیم، یکی از اولین کارهامون اینه که درس آموخته‌های مرتبط رو از پروژه‌های قبلی جمع کنیم.
ولی واقعا چطوری باید این کار رو کرد؟
قبل از هر چیز باید به هدف این کار فکر کنیم. ماجرا اینه که تو هر پروژه با مسایل مختلفی مواجه می‌شیم و بر اساس تصمیم‌هایی که می‌گیریم نتیجه‌های مناسب یا نامناسبی می‌گیریم. همه این تجربه‌ها هم با سرمایه شرکت داره انجام می‌شه و دانشش باید برامون ذخیره بشه تا بتونیم بعدا ازش استفاده کنیم و دایما درجا نزنیم.
برای این‌که بتونیم این کار رو بکنیم شرایطی وجود داره:
همه باید تو این ماجرا مشارکت کنن
این کار باید تو برنامه روزانه باشه، نه مثلا موقع تموم شدن پروژه که هم حواسمون به جای دیگه‌س و هم درست همه چیز یادمون نمیاد.
اطلاعات باید طور مناسبی ذخیره بشن که بشه بعدا ازشون استفاده کرد.
حالا چطوری؟
راه حلی که من همیشه پیشنهاد می‌کنم استفاده از ویکی (wiki) یا انجمنه (forum). اولی برای تیم‌هایی که مهارت‌های کامپیوتری بالاتری دارن مناسبه (مثلا اعضای تیم پروژه‌های نرم‌افزاری) و دومی برای بقیه تیم‌ها.
یه نرم‌افزار ویکی (مثلا مشابه اون چیزی که برای ویکیپدیا استفاده می‌شه) یا یه نرم‌افزار انجمن (تالار گفتگو) مشابه اون چیزهایی که همه …