همه ما می دانیم که محدوده و محتوا پروژه (scope)، فعالیت های مورد نیاز پروژه را تعریف می‌کند. و مدیریت محدوده و محتوا، بخشی از نقش‌های مدیر پروژه است، به خصوص هنگامی که پروژه در حال انجام است و ناگهان متوجه میشویم که دامنه پروژه ما به مراتب فراتر از مرزهای اولیه خود گسترش یافته است و ما در معرض ناپایداری محدوده و محتوای پروژه خود قرار گرفته‌ایم. اولین اقدام برای جلوگیری از خزش محدوده و محتوا، شناسایی چگونگی بروز آن است.
خزش محدوده و محتوا (Scope Creep) چیست؟
خزش محدوده و محتوا (گاهی اوقات به عنوان “خزش مورد نیاز” و یا حتی “خزش ویژگی” شناخته می شود) اشاره به اینکه چگونه نیازهای پروژه در طول چرخه حیات پروژه افزایش می یابد، مثلا تولید یک محصول با سه ویژگی اساسی آغاز میشود، اما در ادامه با 10 ویژگی اساسی به پایان میرسد. ویا در میانه پروژه، نیازهای مشتریان تغییر می کند و باعث ارزیابی مجدد نیازهای پروژه میشود. معمولا خزش در محدوده و محتوا پروژه به همین واضحی و روشنی رخ نمی دهد و این تغییرات معمولا به آرامی رخ می‌دهد. مشکل اینجاست که این تغییرات کوچک در هنگام وقوع توجه کسی را به خود جلب نمی کند و اغلب مدیر پروژه، ذینفعان و تیم پروژه به راحتی از کنار آن عبور می کنند، اما در انتهای پروژه، انباشته این خزش ها باعث تغییرات وسیعی در محدوده پروژه شده اند که باعث تحمیل هزینه فراوانی بر پروژه خواهد شد.
علل خزش محدوده:
- ناشناخته ها (Unknown):
پروژه ها به قلمرو ناشناخته می پردازند. گاهی اوقات پیچیدگی مشکلی که ما با آن مواجه هستیم دست کم گرفته می شود.
- کمال گرایی(Perfectionism) :
گاهی اوقات فراموش می کنیم که به اندازه کافی و مورد نیاز، خوب وکافی است. این ماهیت ذهن است که به “بیشتر” تمایل دارد. طبیعی است که بیشتر بخواهید. ثروت بیشتر ، زمان بیشتر، ویژگی های بیشتر. اما ویژگی های بیشتر بی فایده، بی فایده هستند و تنها بار هزینه ایی و زمانی و.. به پروژه شما تحمیل میکنند.
- آرام کردن اختلافات (Placating conflict):
ما هر کاری میکنیم تا از بروز درگیری جلوگیری کنیم. ما حتی حاضر هستیم تا محدودهو محتوای پروژه را گسترش دهیم تا تمامی ذی‌نفان متضاد و متعارض را راضی نگاه داریم. زمانیکه ما از این طریق به آرام کردن اختلافات میپردازیم پروژه ای را بهوجود میآوریم که کسی قادر به انجام آن نیست.
- اکتساب، حاکمیت (Acquisition):
گاهی به منظور حفظ منابع مصرف شده در یک پروژه شکست خورده، شروع به تعریف پروژه های دیگر برای افزایش کارآیی و یا بیرون کشیدن پروژه از شکست میکنیم. اما این پروژه های جدید بار مختص به خود را به پروژه تحمیل میکنند و از طرفی در بعضی موارد، افزایش کارآیی غیر ممکن است. همانطور که در کتاب 1970 توسط نیکلاس تامالین و رون هال توضیح داده شد، الگوی زندگی او برای مقابله با پروژه های با محدوده در حال رشد، پنهان کردن الگوی شکست است. مانند دونالد کوهورست، بعضی از پروژه ها محدوده خود را گسترش می دهند تا از تصدیق شکست ها جلوگیری شود. شکست و یا راه اندازی مجدد باید گزینه های واقع بینانه برای هر مدیر پروژه باشد.
- پیشرفت شغلی (Career advancement):
مدیران یا رهبران یک پروژه می توانند قدرت های سازمانی خود را تقویت کنند. مدیران ارشد باید یاد بگیرند که این تاکتیک ها را تشخیص دهند و تنها بر اساس اصول مدیریت صحیح، گسترش دامنه را تأیید کنند. گاهی به دنبال ایجاد یک پیشرفت مسیر اشتباهی بکار گرفته میشود. جذابیت ظاهری یک اقدام و عدم بررسی تمامی جنبه های یک تصمیم میتواند باعث خزش محدوده ومحتوا و ایجاد بار منفی برای پروژه شود.
- انتظار کاربران (Users need this feature):
همیشه یک کاربر وجود دارد که نیاز به یک ویژگی بیشتر دارد. و اگر این کاربر یک مشتری کلیدی باشد، این ویژگی قطعا به لیست ویژگیها افزوده خواهد شد. اما اغلب نیازهای اضافه مشتریان غیرمنطقی هستند. این آرزوها برای مشتریان هیچ هزینه ای ندارند، اما قطعا تیم پروژه برای آنها هزینه می کنند.
برای فهم بهتر، مثالی از یک بسته نرم افزاری که برای کارکنان فروش ما طراحی شد را برایتان شرح میدهم. توسعه‌دهندگان ما متقاعد شدند که بدون تغییر در برنامه، “فقط یک ویژگی دیگر” به بسته نرم افزاری اضافه کنند. آنها توافق کردند که در حال حاضر کد منبع این ماژول را ویرایش میکنند، بنابراین هیچ تغییر بزرگی در کار نیست، با این حال، در مرحله بعدی، تیم تضمین کیفیت ما با یک لیست طولانی تر از ویژگی ها برای تست، مواجه شد. تغییری کوچک در کد منبع باعث بروز تغییرات کیفی بسیاری در حوزه های دیگر شده بود، که بر برنامه زمان بندی آنها تاثیر گذاشت.
- اتحاد همه سوء تفاهم ها (The union of all misunderstandings):
اگر محدوده و محتوا، در ابتدا به وضوح تعریف نشده باشد، بدفهمی ها قوت میگیرند. هنگامی که این اتفاق می افتد، برای حفظ توافق در مورد اینکه پروژه باید ادامه یابد، ممکن است ما مجبور به گسترش دامنه پروژه باشیم تا شامل همهی توافق های اولیه شود. جنگ اول به از صلح آخر!
جمع بندی
خزش محدوده و محتوا در اغلب پروژه ها رخ می دهد، اما آیا خزش همیشه بد است؟ یک مدیر پروژه موفق، کسی است که بتواند در مواقعی که لازم است تغییرات لازم را در پروژه پیاده سازی کرده و از تغییرات غیرمفید در پروژه جلوگیری کند. در واقع وقوع تغییر در پروژه اجتناب ناپذیر است. بی شک با گذشت زمان اطلاعات بیشتری از پروژه و عدم قطعیت های آن در اختیار تیم پروژه قرار می گیرد. پس”وقتی نمی توان از وقوع تغییر جلوگیری کرد، باید آن را کنترل نمود. اگر یک فرایند سفت و سخت برای جلوگیری از تغییر در محدوده وجود داشته باشد، مدیران پروژه به طور غریزی، تغییرات محدودهای که برای پروژه سودمند هستند را رد میکنند. ما این را “کشتن محدوده” می نامیم. تیم پروژه باید تغییراتی را که حامی یا دیگر اشخاص مجاز، مفید تشخیص میدهند اعمال کنند. خزش محدود علل متعددی میتواند داشته باشد. با شناخت ریشه این تغییرات میتوانیم تصمیم گیری بهتر و هدفمندتری برای مدیریت پروژه خود داشته باشیم.
دیدگاهتان را بنویسید