بازی ششم در مسابقات بیسبال سال 1986 است؛ یک بازی حساس بین نیویورک متز و بوستون رد ساکس! رد ساکس بسیار موفق ظاهر شده و کافی بود یک گیم دیگر از این مسابقه را ببرد تا به عنوان قهرمانی دست یابد.

کار را در لحظه‌ آخر خراب کردیم


اما تا اواخر بازی چنین اتفاقی نیفتاده است. حالا گیم آخر است. هر دو تیم برابرند. موکی یک توپ کاملا عادی را برای بیل بروکنر می‌فرستد، اما در کمال شگفتی، توپ از لای پاهای بیل قل می‌خورد و همین باعث می‌شود تا متز بازی را ببرد و قهرمان شود. بیل بروکنر برای 22 سال در لیگ ماژور بیسبال آمریکا بازی کرد، 2715 ضربه زد و با چوب بیسبالش به یک سوم توپ‌های ارسالی ضربه زد و آمار بسیار قابل قبولی به‌جا گذاشت، اما آقای بیل بروکنر به خاطر کدام بازی مشهور شده است؟ بله، دقیقا به خاطر همین بازی 1986 که اشتباهی فاحش در آن انجام داد!
یکی از اشتباه‌های فاحش در پروژه را به سختی می‌توان بخشید: اینکه تمام طول پروژه را به خوبی پیش‌رفته‌ای، به آخر رسیده‌ای و چون کمی زودتر پیروزی پروژه را اعلام کرده‌ای، ناگهان چیزی آن اواخر همه‌چیز را خراب می‌کند. من به تجربه (و البته از خلال شکست‌های خودم) آموخته ام که در آخرین هفته‌های پروژه باید مدیریت اجرایی بسیار دقیقی داشته باشید، هر روز وضعیت پروژه را به اعضای تیم اطلاع دهید و برای هر مشکلی که ممکن است پیش بیاید، به سرعت راه‌حلی دست و پا کنید. اجازه ندهید مثل بیل بروکنر توپی از لای پاهایتان قل بخورد، بازی را ببازید و آن وقت هم به پروژه‌ خود آسیب کلان وارد کنید و هم به شهرت‌تان در مقام مدیر پروژه.

چطور اتفاق می‌افتد
1_کسی تغییری در لحظه‌ آخر در محصول ایجاد و این تغییر چیز دیگری را تخریب کرده است.
اگر یکی از طرفداران سریال طنز مونتی پایتون(1) باشید، احتمالا قسمتی را به یاد دارید که در آن مرد فربه و چاقی تا خرخره غذا خورد و سپس وقتی به او یک برگ نعنا بیشتر دادند، به معنای تحت‌الفظی کلمه و به خاطر حجم غذایی که بلعیده بود، منفجر شد - تنها یک برگ نعنای اضافی کافی بود تا این آدم تعادلش را از دست بدهد و به کلی تخریب شود! این داستان شباهت زیادی دارد با اتفاقی که ممکن است اواخر یک پروژه رخ دهد؛ یعنی زمانی که تغییرات در لحظه‌ آخر بر محصول اعمال می‌شوند. در یکی از آخرین پروژه‌هایم، نقش صاحب کسب و کار را برعهده داشتم و به تیم پروژه دستور اکید دادم که در آخرین هفته‌های پروژه تنها در صورتی محصول را تغییر دهند که تغییر مورد نظر اساسی و کلیدی باشد. اما یکی از مشتری‌ها، توسعه‌دهنده‌ محصول را قانع کرد تا یک تغییر «آسان» در محصول ایجاد کند. توسعه‌دهنده این تغییر را ایجاد کرد و یکی از ویژگی‌های محصول را که پیشتر کار می‌کرد، از کار انداخت. تغییر «آسان» مورد نظر مشتری نه تنها در محصول نهایی پیاده‌سازی نشد، بلکه منابع بسیار ارزشمندی بر سر پیاده‌سازی ناموفق آن و نیز تشخیص و خنثی‌کردن اثرات‌ مخرب تغییر یادشده هدر رفت.
2- ارتباط بین اعضای تیم به موقع نیست
همان طور که پیش از این گفتم، به نظر من حفظ و اجرای ارتباطات بسیار دقیق و منظم بین اعضای تیم در آخرین هفته‌های پروژه اهمیت دارد. من یکی از طرفداران پروپاقرص جلسات روزانه‌ای هستم که هر صبح برگزار می‌شود و فعالیت‌های روز قبل را مورد بررسی و ارزیابی قرار می‌دهد و موضوعات مهم و برنامه‌های کاری روز جاری را عنوان می‌کند. همچنین مهم است اطمینان حاصل کنیم که همه قواعد پروژه در جلسات روزانه بیان می‌شوند و همه می‌توانند از نظرگاه خاص خود فعالیت‌ها را ارزیابی کنند و نیز نقش موثر خود بر روند پروژه را درک نمایند.
همچنین به باور من، نباید مدت این جلسات از حد مشخصی بیشتر شود و احتمالا سقف سی‌دقیقه سقف مناسبی است، چرا که اگر زمان بیش از حد زیاد باشد، انرژی اعضای تیم را پیش از شروع کار روزانه هدر می‌دهد یا شاید اساسا اعصاب آنها را خرد کند. همچنین، اگر به حد کافی کوتاه نباشد، احتمالا نمی‌تواند ماندگاری خوبی داشته باشد و پس از چند جلسه کنار گذاشته خواهد شد.
3- پروژه درست قبل از اتمام به بن‌بست می‌رسد.
وقتی به عنوان مشاور کار می‌کردم و مسائل مالی بر پروژه‌ای فشار می‌آورد، دائما به دنبال این بودم که کدام آدم‌ها را از پروژه کنار بگذارم تا پول کافی برای اتمام پروژه وجود داشته باشد. این کار به لحاظ مدیریت هزینه تنها زمانی مقبول و موفق است که آدم‌های مورد نظر - آدم‌هایی که کنار گذاشته می‌شوند - دیگر کاری برای انجام در این پروژه نداشته باشند، اما در مواردی که فعالیت‌های آنها به‌طور کامل انجام نشده باشد، بقیه‌ تیم مجبورند مسوولیت آنها را نیز تقبل کنند و آن وقت است که شما به دست خودتان ریسکی را در برابر موفقیت پروژه‌تان آفریده‌اید. واقعیت این است که اگر کسی هنوز فعالیت خود را تمام نکرده باشد و شما وی را از پروژه کنار بگذارید، آن وقت انگار هیچ پولی صرفه‌جویی نکرده‌اید.

نکات کلیدی
از تغییرات در لحظه‌ آخر اجتناب کنید، چون این تغییرات می‌توانند به ازکار افتادن یکی از ویژگی‌های محصول بینجامند.
جلسات بحث و بررسی مختصر را هر روز صبح برگزار کنید و در آنها وضعیت پروژه و کارهای مورد نیاز برای آن روز را مرور کنید و همچنین مشکل‌های پروژه را در این جلسات به طور کامل به بحث بگذارید.
زودتر از موعد پیروزی پروژه را اعلام نکنید؛ بازی‌های بیسبال زیادی در همان گیم آخر واگذار شده‌اند؛ تمرکزتان را حفظ کنید!
یادداشت:
(1) مونتی پایتون (Monty Python) یک گروه کمدیِ سوررئالیستی در بریتانیا بود. این گروه یکی از مشهورترین و محبوب‌ترین سریال‌های کمدی تاریخ انگلیس را با نام «سیرک پرنده‌ مونتی پایتون» از 5 اکتبر 1969 آغاز کرد. 45 قسمت و 4 سری حاصل فعالیت‌های تلویزیونی این گروه بود و آنها را تقریبا در کل اروپا و حتی آمریکا به شهرت رساند.


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

راه حل: ورق را برگردانید
1- تمرکز خود را حفظ کنید
انسجام تیم پروژه را حفظ کنید و آنها را بر اتفاقات لحظه‌های متمرکز نگه دارید. اطمینان حاصل کنید که تیم پروژه نسبت به اینکه چه اتفاقاتی هر روز رخ می‌دهد، کاملا آگاه است و می‌داند چه کسی مسوولیت انجام کدام فعالیت‌های کلیدی، رفع کدام مشکلات مهم و تصمیم‌گیری در باب چه موضوعی را برعهده دارد. مواظب باشید اعضای تیم پیش از اتمام پروژه کاملا درگیر وظایف پروژه‌های دیگر نشوند.
2- تیم پروژه را به ارتباط با یکدیگر وادار کنید
ترجیح من این است که جلسات کوتاه‌تر و متناوب‌تری را در آغاز یا پایان یک روز کاری برگزار کنیم و در آنها وضعیت پروژه و وظایف هر فرد را بررسی کنیم.
در برخی از پروژه‌ها یک «اتاق جنگ» درست می‌کردم تا در آنها بتوانیم وظایف، مشکلات و تصمیم‌گیری‌های کنونی در مورد پروژه را به دقت به بحث بگذاریم. گاه حتی اعضای تیم پروژه را داخل این اتاق جنگ نگه می‌داشتیم تا تصمیم‌گیری‌های بسیار مهم انجام شوند؛ این کار به سهولت مباحثات بین افراد می‌انجامید و تصمیم‌گیری‌ها با دقت بالاتری انجام می‌گرفت.
3- محصول را تثبیت کنید
هرچه به لحظه ارائه‌ محصول نزدیک‌تر می‌شوید، باید در مورد اعمال تغییر در محصول هوشیاری و احتیاط بیشتری به خرج دهید؛ به‌خصوص تغییراتی که برای کارکرد محصول ضروری نیستند. هر بار که تغییری اعمال می‌کنید، باید در نظر بگیرید که ممکن است سهوا تغییری در خصیصه‌ای دیگر ایجاد کرده باشید. هیچ وقت خودتان را مجبور نکنید تمام دقایق پروژه‌ خود را به پیاده‌سازی خصیصه‌ها و ویژگی‌های اضافی در محصول بگذرانید.