پس از شناسایی ریسک‌ها باید برنامه‌های واکنشی برایشان طراحی کنیم. اگر می‌دانیم که نبود دیوار بیرونی در طبقه‌هایی که به تازگی ساخته شده‌اند ریسک حادثه به وجود می‌آورد، چه کاری باید برایش بکنیم؟
یک واکنش این است که فعالیت تازه‌ای به پروژه اضافه کنیم و بی‌درنگ پس از ساخته شدن کف هر طبقه نرده‌هایی موقت در حاشیه آن نصب کنیم. این کار احتمال حادثه را کمتر می‌کند، ولی کافی نیست. شاید بتوانیم روند کارها را کمی تغییر دهیم که ساخت دیوارهای بیرونی در زودترین زمان ممکن انجام شوند. این کار باز هم احتمال رخداد ریسک را کمتر می‌کند. شاید حتی بتوانیم فعالیت‌های دیگر را کمی جابجا کنیم که تا وقتی که دیوارهای بیرونی ساخته نشده‌اند رفت و آمد در طبقه حداقل شود.
به موازات این مسایل، فکر خوبیست که اعضای تیم پروژه آموزش ایمنی هم ببینند. این واکنش افزون بر ریسک مدنظرمان بر بسیاری ریسک‌های دیگر هم اثر می‌گذارد و از این رو بسیار مفید است. اگر پروژه بزرگ و دورافتاده باشد، فکر خوبیست که امکاناتی برای کمک‌های اولیه و حتی پرستاری مقیم هم در نظر گرفته شود تا هنگامی‌که حادثه‌ای رخ می‌دهد اثرش کاهش یابد.
افزون بر اثر مالی و زمانی حادثه‌ها، مسئولیت اجتماعی ما نیز حکم می‌کند که با ریسک حادثه با جدیت برخورد کنیم. با این‌همه، وقتی همه واکنش‌های منطقی را انجام دهید باز هم احتمال حادثه وجود دارد. بنابراین برای حفاظت از …
آیا تا کنون چیزی همانند «نه، ما از پرینس۲ استفاده نمی‌کنیم چون برای شرکت ما زیاد از حد پرهزینه است» شنیده‌اید؟
پرینس۲ و همه متدولوژی‌های دیگر ساخته شده‌اند تا به شکل‌های گوناگون، از جمله کاهش هزینه، به شرکت‌ها کمک کنند. اگر سیستمی این‌چنینی پیاده‌سازی کنید و به نظرتان سربارش بیشتر از نتیجه باشد، به این معنیست که آن را به خوبی اختصاصی‌سازی نکرده‌اید.
اختصاصی‌سازی چیست؟
برای نمونه، پرینس۲ گزارشی به نام checkpoint report دارد که در دوره‌های زمانی از پیش تعیین شده از سوی مدیران تیم‌ها برای مدیر پروژه فرستاده می‌شود. پرینس۲ برای آن و دیگر موارد به‌جای عبارت «سند» از عبارت محصول مدیریتی استفاده می‌کند، زیرا الزامی نیست که آن‌ها را در قالب سند بسازید. اگر پروژه پیچیده و بزرگ باشد، شاید آن را مستند کنید، ولی در پروژه‌های کوچک‌تر حتی یک تماس تلفنی میان مدیر تیم و مدیر پروژه برای این منظور کفایت می‌کند. تنها الزام این است که تماس تلفنی در بازه‌های زمانی از پیش تعیین شده گرفته شود و در طی گفتگو موضوع‌های این گزارش بررسی شوند. هنگامی‌که نوع گزارش را تعیین می‌کنید، در عمل پرینس۲ را اختصاصی‌سازی کرده‌اید.
اگر استدلال بخش پیشین برایتان پذیرفتنی باشد، باز هم دو چالش کلان در عمل وجود خواهد داشت. نخستین چالش این است که بسیاری از کسانی که در پروژه‌ها کار می‌کنند مدیر پروژه‌ای که مهارت فنی نداشته باشد را نمی‌پذیرند. اگر چنین مدیر پروژه‌ای باشید، باید در نظر داشته باشید که ریشه دشواری این است که این افراد چه‌بسا هیچ‌گاه مدیر پروژه واقعی ندیده‌اند. همه مدیر پروژه‌هایی که داشته‌اند متخصص‌های ارشدی بوده‌اند که تصمیم‌گیری‌های کلان فنی بر دوششان بوده است و به‌جای کل تیم برنامه‌ریزی می‌کرده‌اند. قاعدتا برای انجام چنین کاری باید مهارت فنی داشت و از این روست که گمان می‌کنند فردی غیرفنی نمی‌تواند پروژه‌شان را مدیریت کند.
راهکار این است که از آغاز با شفافیت مسئله را برایشان روشن کنید. توضیح دهید که قرار نیست برایشان تصمیم‌گیری‌های فنی انجام دهید، بلکه نقشتان پشتیبانی از تیم پروژه و فراهم کردن فضای کاری مناسب است. بی‌گمان سخن گفتن در این باره کافی نیست و نیاز است که هر چه زودتر آن را در عمل به تیم نشان دهید تا بتوانید اعتمادشان را جلب کنید. اگر این کار را به‌درستی انجام دهید، پس از چند هفته تا چند ماه پذیرفته خواهید شد.
زمانی یکی از بهترین مدیر پروژه‌هایی که می‌شناختم برای مدیریت پروژه‌ای نرم‌افزاری انتخاب شد و اعضای تیم کاملا در برابرش جبهه‌گیری کرده بودند زیرا او همیشه در پروژه‌های سازمانی کار …
نسخه‌های نخستین پم‌باک برای پروژه‌های متعین تدوین شده بودند. پس از این‌که شیوه‌های تطبیقی پذیرش همگانی پیدا کردند، به‌تدریج مطالبی درباره‌شان به پم‌باک افزوده شد، ولی این موارد هیچ‌گاه با بدنه اصلی پم‌باک یکپارچه نشده بودند، بلکه به آن تحمیل شده بودند. از آن‌جایی که نسخه هفتم پم‌باک را از آغاز تدوین کردیم و به‌روزرسانی محتوای پیشین نیست، آن را از بنیان به‌گونه‌ای ساختیم که با هردو روش ساخت محصول سازگار باشد.
برخی گمان می‌کنند که «پم‌باک ۷ چابک شده است»، که کاملا اشتباه است. پم‌باک ۷ با هردو روش سازگار است و حتی بهتر است بگوییم رویکردش به مسایلیست که تاثیر چندانی از تطبیقی یا متعین بودن نمی‌گیرند.
تمدن بشری همیشه از هر دو روش متعین و تطبیقی استفاده کرده است و نشانه‌های آن را می‌توان در بسیاری پروژه‌های باستانی دید. نخستین نسل کامپیوترها محدودیت‌های فراوان و مخاطب ویژه و اندکی داشتند که باعث می‌شد ساخت نرم‌افزارهایشان نیاز به روشی متعین داشته باشد. با پیشرفت سخت‌افزار، کاهش محدودیت‌ها، و دگرگونی نوع و گستردگی مخاطب نرم‌افزارها، روش‌های متعین دیگر گزینه خوبی برای ساخت نرم‌افزار نبودند، ولی دست‌اندرکاران این نوع پروژه‌ها همچنان به عادت گذشته می‌کوشیدند روش‌های متعین را به‌کار گیرند.
تحمیل روش‌های متعین بر پروژه‌های نرم‌افزاری همچنان ادامه پیدا کرد، تا زمانی که برنامه‌نویسان و مدیران تیم‌ها بیشتر و بیشتر از وضعیت ناراضی شدند و گرایش به ساخت محصول به شیوه تطبیقی پیدا کردند. سرانجام، گروهی از این افراد دورهم گرد آمدند تا به رویکرد خود رسمیت بخشند و برای آن نام چابک را انتخاب کردند.
متاسفانه اختلاف‌ها و مشکل‌های فراوانی که در این روند به وجود آمده بود ذهنیتی منفی درباره روش‌های متعین برای این افراد و کسانی که ادامه‌دهنده راهشان شدند به وجود آورد. به عبارت دیگر، به‌جای اصلاحی تدریجی، انقلابی خونین به وجود آمد. کمی پس از انقلاب هم گروهی کوچک مهره‌های اصلی را کنار زده، قدرت مطلق را به دست گرفتند. دایما هم درباره دشمن بیرونی هشدار می‌دهند! برای اطلاعات بیشتر می‌توانید به کتاب «قلعه …
متاسفانه واقعیت این است که اختصاصی‌سازی کار ساده‌ای نیست. برخی گمان می‌کنند که اختصاصی‌سازی به معنی انتخاب هیجان‌انگیزترین عناصر از سیستم‌های مختلف و کنار هم قرار دادن آن‌هاست، با این‌که چنین کاری سازگاری درونی سیستم و بنابراین کارآیی آن را از بین می‌برد. اختصاصی‌سازی نوعی ساخت سیستم است و همچون هر ساخت سیستم دیگری باید با دیدی همه‌جانبه و موشکافانه انجام شود.
در بیشتر سیستم‌ها مسئولیت اختصاصی‌سازی با مدیر پروژه است، ولی کسی که از هر جهت دیگر مدیر پروژه بسیار خوبی باشد شاید توانایی ساخت سیستم نداشته باشد. این‌که از مدیر پروژه‌ها انتظار داشته باشیم که بتوانند سیستم‌ها را اختصاصی‌سازی کنند همیشه واقع‌بینانه و منصفانه نیست. این مسئله در DSDM که یکی از متدولوژی‌های چابک نسل نخست است به رسمیت شناخته شده است، و از این رو، در انتخابی هوشمندانه، نقشی با نام مربی DSDM به متدولوژی افزوده‌اند که مسئولیت اختصاصی‌سازی و برخی مسایل دیگر را بر دوش دارد.
پیش از اجرای هر پروژه‌ای باید چرایی انجام آن را به‌خوبی درک کرد زیرا هرآن‌چه در پروژه انجام می‌شود باید با آن همسو باشد و تصمیم‌های کلان بر آن پایه گرفته شوند. این درک محدود به مدیر پروژه نیست و همه اعضای تیم به آن نیاز دارند.
چندی پس از آغاز پروژه ناسا برای فرستادن اولین فضانورد به ماه، رییس جمهور وقت آمریکا، کندی، از ناسا بازدید کرد. در هنگام بازدید، یکی از مستخدم‌های ناسا را جارو به دست دید و مانند هر رییس جمهور دیگری که همیشه کوشش می‌کند خود را مردمی جلوه دهد، با او سلام و احوال‌پرسی کرد. از مستخدم پرسید که کارش چیست و او در پاسخ گفت «کمک می‌کنم که فضانورد به ماه بفرستیم!»
اگر بتوانید بستری در پروژه به وجود آورید که همه برخوردی همانند آن مستخدم داشته باشند، احتمال موفقیتتان به‌مراتب بالاتر خواهد بود.