بدون وجود هدف واضح و مشخص دست به انجام هیچ کاری نزنید
تا زمانیکه هدف روشنی از انجام کاری ندارید آن را انجام ندهید. دو جهان موازی را تصور کنید که در آن دو، همه‌چیز یکسان است به‌جز کاری که شما برای انجام، در نظر دارید. این دو جهان چقدر تفاوت خواهند داشت؟ آیا این تفاوت ارزش تلاش‌هایی که شما برای اجرای آن می‌کنید دارد یا نه؟
اگر هدف مشخصی در ذهن ندارید و کاری را صرفاً فقط به این دلیل انجام می‌دهید که بقیه نیز این کار را می‌کنند و اینکه دیگران میگویند انجامش مهم است:
- ممکن است در رابطه با مساله شما واقعاً سودی نداشته باشد بنابراین چیزی نصیب شما نشود.
- ممکن است برای شما مزایای بالقوه‌ای داشته باشد اما به دلیل آنکه هدفی در ذهنتان ندارید آن کار را به‌گونه‌ای انجام دهید که باعث شود به آن منافع نرسید.
مثال: پرتفولیو و طرح
اگر شما در انتخاب و راه‌اندازی پروژه‌ها دخیل هستید باید اطمینان حاصل کنید که بر روی منافع و مشکلاتی تمرکز کنید که از طریق اجرای آن پروژه قرار است برآورده شده یا حل گردند، نه بر روی محصولی که میتواند آن مشکل یا خواسته را برآورده کند. یک مثال کلاسیک: سازندگان آسانسورها، روزانه انتقادهای زیادی در خصوص سرعت آسانسورها دریافت می‌کردند پس پروژه‌های زیادی برای افزایش سرعت آسانسورها تعریف شد، اما موفقیتی به دست نیامد. این ماجرا ادامه پیدا کرد تا زمانی که آن‌ها تصمیم گرفتند به‌جای تمرکز بر روی راه‌حل‌های واضح (افزایش سرعت آسانسور) بر روی صورت مسئله تمرکز کنند (خستگی و یا ناراحتی مردم). نتیجه آن شد که در آسانسورها آیینه نصب کردند و مشکل، آسان و ارزان حل شد.
به یاد داشته باشید که مدیریت پروژه اساساً در رابطه با انجام صحیح کارها است در حالیکه مدیریت پرتفولیو با انجام کارهای صحیح مرتبط است. مهم نیست که چقدر خوب پروژه‌تان را انجام می‌دهید اگر شما پروژه غلطی را اجرا می‌کنید به نتیجه نخواهید رسید. همه‌چیز به هدفمندی شما برمی‌گردد.
مثال: کلیت پروژه
انعطاف‌پذیری محصولات در پروژه‌های مختلف، متفاوت است. در برخی پروژه‌های توسعه در صنعت IT، محصول کاملاً انعطاف‌پذیر است و شکل نهایی آن به بازخوردی که از توسعه تدریجی محصول (Increments) می‌گیریم وابسته است که نیازمند رویکرد تطبیقی (Adaptive approach in Agile) است. این عملیات ترکیبی از پرتفولیو، طرح و لایه‌هایی از پروژه است که نیازمند حداکثر توجه به هدف نهایی است. ایده خوبی است که هدف را مستند کرده و در دسترس قرار دهیم، این، یکی از اهداف “Product Vision” است که در برخی از پروژه‌های اسکرام استفاده می‌شود. توجه به ارزش کسب‌وکار (Business Value) در پروژه‌های Agile راهی برای تضمین هماهنگی باهدف است.
در دیگر مدل‌های پروژه که محصول آن‌ها نسبتاً ثابت است برای ارزیابی آنکه محصول شناسایی‌شده میتواند ما را به هدفمان برساند یا خیر مکانیسم‌های دیگری وجود دارد و برای اعضا تیم پروژه این امکان وجود دارد که بخش عمده‌ای از تمرکزشان را به‌جای هدف به محصول معطوف کنند (اصل “Focus on Products” از PRINCE2®)، اما برای آنکه مطمئن شویم آنچه قرار است ساخته شود ما را به هدفمان می‌رساند همچنان یک توجه حداقلی به هدف موردنیاز است که از طریق مقایسه منافع پیش‌بینی‌شده با منافع کسب‌شده می‌توان به آن دست‌یافت. (اصل “Continued Business justification” و تم “Business Case” از PRINCE2®).
وقتی پروژه‌ای را برای کارفرمای خارج از سازمان انجام می‌دهید، کارفرما هدف خاص خود را از آن پروژه دارد و سازمان شما نیز هدف خاص خود را دارد که این اهداف لزوماً باهم یکسان نیستند. برای کامیابی واقعی در پروژه باید هر دو هدف را درک کرده و مدنظر قرارداد.
مثال: نظارت بر پروژه
تمرکز روی هدف نهایی لازم است، اما ممکن است این هدف برای بسیاری از استفاده‌های روزانه خیلی مختصر و کلی باشد به همین دلیل برای آنکه کاربردی‌تر باشد سلسله مراتبی از پیش برنده‌ها در پروژه موردنیاز است. توجیه مزایای پروژه در ابتدا بر مبنای هدف نهایی پروژه انجام می‌گردد سپس اهداف صریح و ضمنی را برای متغیرهای پروژه (مثل زمان، هزینه و کیفیت) تعریف می‌کنیم تا مزایای توجیه شده پروژه ارضا شود این کار به‌نوبه خود ما را به هدف نهایی می‌رساند. این اهداف جزئی تر برای انجام بسیاری از وظایف روزانه مفید خواهد بود.
وقتی نوبت به نظارت می‌رسد، نظارت جزئی در پروژه با استفاده از جزئی ترین متغیرها انجام می‌گردد چون معمولاً پیگیری هدف نهایی به‌جز از طریق نظارت بر جزئیات امکان‌پذیر نیست. در این شرایط باید همچنان هدف را در ذهن داشته باشید. هدف از نظارت چیست؟
طبیعتاً یک پاسخ قابل‌قبول این است که می‌خواهیم ببینیم آیا در مسیر درست قرار داریم یا خیر؟ تا اگر در مسیر صحیح نیستیم واکنش مناسبی نشان دهیم که ما را به مسیر صحیح بازگرداند یا اهداف جزئی را اصلاح کنیم تا ببینیم آیا همچنان می‌توانیم به هدف نهایی‌مان برسیم یا خیر؟ بنابراین اهداف جزئی تر باید بتواند به ارزیابی‌های ما کمک کند و ارزیابی مناسب آن است که مقدار هر یک از متغیرهای ذکرشده در پایان پروژه را پیش‌بینی کند. مثلاً پروژه در چه زمانی قابل اتمام است؟ برای تکمیل پروژه چقدر پول لازم است؟
سایر ارزیابی‌ها نظیر مقادیر برنامه‌ریزی‌شده (Planned Values) و مقادیر واقعی تا به امروز (Actual Values) صرفاً مقادیر موقتی هستند که برای انجام پیش‌بینی‌ها نیاز دارید و مقادیر نهایی که برای اهداف مدیریتی استفاده می‌کنید نیستند.
مثال: اسناد
از هر یک از رویکردهای توسعه‌ای که در پروژه‌تان استفاده کنید، همیشه برنامه‌ریزی امری ضروری است. مساله اساسی، سطح جزئیات موجود برنامه است. اگر جزئیات کافی در برنامه وجود نداشته باشد برنامه نمی‌تواند به میزان کافی سودمند باشد و اجرای پروژه بیش از آنکه برمبنای تصمیمات یکپارچه و جامع باشد بر مبنای تصمیمات موردی خواهد بود. از طرف دیگر بسیاری افراد تلاش می‌کنند محتاط باشند و جزئیات بیشتری به برنامه‌شان اضافه کنند که تهیه و نگهداری برنامه را بسیار سخت کرده و در برابر عدم قطعیت‌های پروژه خشک و غیرقابل انعطاف می‌کند، درنتیجه برنامه غیرواقعی و بی استفاده می‌گردد.
بهترین راه برای تصمیم‌گیری در خصوص میزان جزئیاتِ لازم، آن است که برای تمامی اجزا برنامه هدفی در ذهن داشته باشید. مثلاً اگر می‌خواهید منابع را به برنامه‌تان اضافه کنید باید هدفی از انجام این کار داشته باشید و بدانید که چگونه قرار است از آن استفاده کنید؟ چگونه قرار است به پروژه کمک کند؟ چه مقدار تلاش و انرژی خواهد برد؟ و آیا ارزشش را دارد یا خیر؟
گاهی اوقات مساله تصمیم‌گیری در خصوصِ لحاظ کردن عنصری خاص در برنامه‌هاست و گاهی در خصوص روش برنامه‌ریزی و یا تهیه چیزی است. چه Business Case باشد، چه Project charter و یا یک گزارش، شما باید همواره از خودتان بپرسید که هدف از تهیه این مدرک یا سند چیست و چگونه به پروژه کمک خواهد کرد.
به دنبال یک الگو (Template) بودن، با انجام کار بر مبنای هدف مشخص در تضاد است.
مثال: گزارش وضعیت
وجود گزارش‌های عریض و طویل در پروژه‌ها شایع است. طبق این NUP، می‌بایست از خودمان بپرسیم که هدف از تهیه یک گزارش چیست و چگونه می‌توانیم به آن هدف برسیم صرف‌نظر از اینکه دیگران اغلب چه می‌کنند.
داشتن هدف اغلب اوقات منجر به تولید گزارش‌های بسیار ساده یک‌صفحه‌ای می‌شود که ذینفعان واقعاً آن را مطالعه می‌کنند و نسبت به گزارش‌های طولانی قابل‌فهم‌تر است. این نتیجه توجه به هدف است.
وقتی گزارش‌های یک‌صفحه‌ای تهیه می‌کنید ممکن است برای برخی سو تفاهم پیش بیاید و فکر کنند که سیستم نظارتی مناسبی ندارید. عملاً این کار هدف ثانویه‌ای را نیز به دنبال دارد (در کنار هدف اولیه که کمک به فهم وضعیت پروژه برای ذینفعان است) هدف ثانویه این است که در صورت لزوم بتوانید گزارشات مفصلی را برمبنای آن گزارش یک صفحه ای تهیه کنید. به‌هرحال نباید این هدف را باهدفِ تهیه گزارش اولیه ادغام کرد زیرا هدف از تهیه این دو یکسان نیست.
مثال: Business Case و Project charter
تهیه مدارکی نظیر Business Case و Project charter برای اکثر مردم معمولاً خسته‌کننده، بی‌فایده است، که صرفاً به دلیل ضرورت‌های بوروکراتیک تهیه می‌گردد در صورتیکه این مدارک همگی دارای اهداف معتبری هستند که در اکثر پروژه‌ها اعمال می‌شود. اگر شما به دنبال یافتن یک الگو هستید تا آن را پرکنید این کار بیهوده است، در حالیکه شما می‌توانید به‌جای آن، هدف واقعی از تهیه این‌گونه مدارک را دنبال کنید، ببینید این مدارک میتواند به پروژه شما کمک کند یا خیر؟ و چگونه؟ بعد با هر روشی که دوست دارید مدارک را تهیه کنید تا به هدف موردنظر برسید. در اینصورت خروجیِ آن، مدرک مناسبی خواهد بود.
وقتی به روش تهیه این اسناد برای تأمین اهداف موردنظر می‌اندیشید احتمالاً به تمام سناریوهای ممکن فکر نکرده و برخی از آن‌ها را از قلم خواهید انداخت، به‌منظور پیشگیری از وقوع چنین اتفاقی، می‌توانید بررسی کنید که منابعی نظیر PRINCE2®, PMBOK® Guide, P3.express و DSDM® چه پیشنهادی می‌دهند، سپس پیشنهادها را بر مبنای اهداف خودارزیابی کنید.
مثال: پسا پروژه
ازآنجاکه پروژه هدف مشخصی دارد، می‌توانیم آن هدف را در سرتاسر پروژه لحاظ کنیم، تحقق هدف اصولاً با پیش‌بینی‌های انجام‌شده در طول پروژه ارزیابی می‌شود. حتی زمانی که پروژه به اتمام می‌رسد نباید هدف را فراموش کنیم. به دلایل زیر مهم است که پس از اتمام پروژه، تحقق اهداف را بررسی کنیم:
- می‌توانیم بفهمیم که اهداف نهایی چگونه محقق شدند و برای پروژه‌های آینده از آن یادگیری داشته باشیم.
- گاهی، اهداف زمانی محقق می‌شوند که پس از اتمام پروژه چند فعالیت اضافی انجام شود و درک لزوم انجام این فعالیت‌ها نیاز به نظارت دارد.
نظارت پسا پروژه یک گام ضروری برای هدف محور بودن است. اساساً مسئولیت این کار، بر عهده سیستمهای مدیریت پرتفولیو و مدیریت طرح است اما ازآنجاکه بسیاری از شرکت‌ها این‌گونه لایه‌های مدیریتی را در خود ندارند این گام‌ها معمولاً مورد غفلت واقع می‌شوند. به این دلیل است که متدهایی نظیر P3.express و DSDM® این گام را به متدولوژی‌های مدیریت پروژه خود اضافه می‌کنند.
مثال: سادگی
دنیا پیچیده و بی‌نظم است، اما مدل‌های ما تقریباً انتزاعی بوده و بخشی از این دنیا را منعکس می‌کنند تا برای ما ساده تر شود. از سوی دیگر، سیستمهای ساده معمولاً بهتر کار می‌کنند، چون می‌توانیم روی ایده اصلی بهتر متمرکز شویم.
بسیاری از ما سعی می‌کنیم تا برای دستیابی به نتایج بهتر به سیستمهایمان پیچیدگی اضافه کنیم با این ذهنیت که این کار باعث می‌شود بر پیچیدگی‌های دنیا منطبق شویم اما در عمل باعث می‌شود که کار با سیستمها سخت‌تر شده و مانع دستیابی به اهدافمان شود.
مثال: سفارشی‌سازی
شرایط یک نرم‌افزار ساخت و ویرایش موسیقی نسبت به نرم‌افزاری که برای تجهیز بیمارستان و یا هواپیما تهیه می‌شود که با جانِ افراد سروکار دارد یا نرم‌افزار تهیه شده برای استفاده در ماهواره‌هایی که قرار است سال‌های سال بدون مشکل کار کند متفاوت است و همه آن‌ها با ساخت یک ویلای تابستانی، ایستگاه آتش‌نشانی یا یک کارخانه تفاوت دارند.
وقتی هدفی در ذهن داشته باشید درک بهتری از نحوه سفارشی‌سازی سیستمها و مصنوعات (Artifacts) برای پروژه‌های مختلف دارید.
مترجم: مهرزاد منصورزاده