مدیر پروژه و تغییر دامنه

هر پروژه ای که کار می شود باید در زمان خاص و با هزینه خاص تمام شود . که در این زمان و با این هزینه نیازمندی هایی که تعریف شده اند پیاده سازی می شود . این همان مثلث آهنین مدیریت پروژه می باشد : هزینه ,  زمان و دامنه .

دامنه (Scope) چیست ؟ دامنه متمایز گر و جداکننده چیز های داخل و خارج پروژه می باشد . به عبارت ساده تر مشخص می کند چه چیزی در طی پروژه باید انجام شود و چه چیزی نیاز نیست انجام شود .

http://www.targotennisberg.com/tarkvara/wp-content/uploads/2008/06/scope_creep.jpg

اصطلاح Scope creep چیست ؟ Scope creep یعنی تحدی از حدود و این زمانی اتفاق می افتد که شما خط دامنه را تغییر دهید.

معمولا این تغییر  شامل اضافه کردن مواردی که در بیرون از دامنه بودند به داخل دامنه است .  و این یعنی پروژه بزرگ تر از قبل خواهد شد .

بر طبق PMBOK تعریف دقیق Scope creep عبارتست از : اضافه کردن ویژگی و قابلیت جدید به دامنه بدون در نظر گرفتن تاثیر آن برروی هزینه و زمان پروژه (مثلث آهنین) .

بزرگ شدن دامنه پروژه یعنی هزینه اضافی و زمان بیشتر و دست آخر یعنی Fail پروژه . علت شکست تعداد زیادی از پروژه های نرم افزاری به همین دلیل بوده است .

تغییر دامنه می تواند از موارد زیر سرچشمه گرفته باشد :

  • کنترل تغییر ضعیف (Change control)
  • عدم جمع آوری لیست نیازمندی ها قبل از شروع پروژه به صورت کامل
  • عدم تاثیر دادن و تاثیر گرفتن از Product Owner

تغییر دامنه در دو سطح می تواند اتفاق بیفتد :

  1. تغییر دامنه فنی و تکنیکی (Technical Scope Creep)
  2. تغییر دامنه کسب و کار (Business Scope Creep)

مثالی که در عنوان تغییر دامنه فنی و تکنیکی می توان زد بدین گونه می باشد که تیم توسعه می خواهد قابلیت جدیدی را به پروژه اضافه نماید که قبلا این ویژگی در نیازمندی های اصلی در هنگام Initiate پروژه جزو دامنه نبوده است .

تغییر دامنه کسب و کار وابسته به کسب و کار مشتری می باشد . که این مورد به عنوان یک عامل خارجی در نظر گرفته می شود . معمولا در ایران اگر این مورد اتفاق بیفتد ,  تیم توسعه به هیچ عنوان زیر بار نمی رود و جوابشان این می باشد که : به ما ربطی ندارد .

بهترین راه برای مقابله با Scope Creep پرهیز از مواجه با آن می باشد . در زیر روش هایی برای مقابله یا پرهیز از Scope Creep بر شمرده شده است :

  • اولین راه همان Agile است ( به راه راست رستگار شوید)
  • حتما در اول شروع پروژه Product Owner را به جمع خود اضافه نمایید.
  • جمع آوری نیازمندی ها به صورت کامل در هنگام شروع پروژه .
  • CBB خود را بسازید – CBB مخفف Change Control Board می باشد که شامل یک کمیته از اعضای تیم توسعه می باشد معمولا اعضای کنه کار گروه و البته حرفه ای  . ریسک پیاده سازی مواردی که باید تغییر پیدا کنند  توسط این کمیته بررسی می شود .
  • پروژه را متوقف نمایید . تغییرات را دامنه بندی نمایید و بر طبق دامنه جدید عمل نمایید البته اگر ریسکش را به جان می خرید .

یاشیاسیز

اگر به تازگی با چابک یا اسکرام آشنا شده اید پیشنهاد می کنم این کتابچه چند صفحه را بخوانید و اگر مطالب بیشتری نیاز داشتید شاید این مطلب اول تا آخر چابک برای شما مفید باشد.

مطالب را هم دوست داشتید می توانید از طریق این لینک عضو فید دنیای چابک شوید تا مطالب جدید برای شما ارسال شود

در ضمن دوره های آموزشی نیز برگزار می کنیم که شاید برای شما یا تیم شما نیز مفید باشند اگر اینگونه بود خوشحال می شوم با من تماس بگیرید

اسد صفری

اسد صفری – مربی تحول چابک سازمان و تیم های نرم افزاری. مدارک حرفه ای: CSP - CSM - PSM - PSPO - CDA - Management 3.0 برخی تجربیات: رئیس دفتر تحول چابک شرکت داده ورزی سداد(بیشتر از ده تیم نرم افزاری) - مربی چابک شرکت رامند (تیم های موبایل و گیم سازی) - مدیر تولید نرم افزار SimplyDesk برای شرکت فرانسوی PCI - مربی مشاور شرکت های:خدمات انفورماتیک، ارکید فارمد، فراداده، الفبا برخی از سوابق مشاوره کوتاه مدت و تدریس : علی بابا، فناپ، تجارت الکترونیک پارسیان، بیمه سامان، انیستیتو ایزایران، مهندسین مشاور تجارت (بانک تجارت)، بیمه ایران، پارس آنلاین، شرکت رهنما، ورانگر، انتشارات پزشکی کوثر و صنایع ارتباطی آوا، فولا آلیاژی یزد، پارک علم فناوری کردستان و ... . عضو انجمن های بین المللی Agile Alliance - Scrum Alliance

11 دیدگاه

  1. Salar   •  

    معمولا بدترین قسمت همون جمع آوری نیازمندی ها هست که خود مشتری هم نمیداند چی می خواد!
    کار کردن با همچین مشتری هایی یعنی جنگ با رستم.

    کم کم داره فاصله پست ها زیاد میشه! مثل ما نشوید ها گارداش 😉

    • مرتضی   •  

      فکر کنم مشتری ها تیم توسعه دهنده نیستند!! شاید اصلا چیزی از برنامه نویسی و … ندانند. بنابراین نمی توانند انتظارات واقعی از نرم افزار داشته باشند. تنها راه حل این مشکل هم اطلاع رسانی و بالا رفتن سطح اطلاعات نرم افزاری بین ایرانیان است. کمی هم حوصله و توضیحات بجا هر مشتری را نرم می کند و نیاز به جنگ نیست!!!!;)

  2. sirasad   •  

    Salar :

    کم کم داره فاصله پست ها زیاد میشه! مثل ما نشوید ها گارداش ;)

    مگه شما چگونه هستید ؟ واقعا وبلاگ خیلی مشغولم میکنه .
    تصمیم گرفتم یکم مدیریت شده با وبلاگ کار کنم . یه مدت میشه که کل زمانی که در اینترنت هستم رو فقط به وبلاگ اختصاص میدم . وقتی تو خیابون راه میرم موضوع پست بعدی رو مشخص میکنم و … .

  3. علی نوبر   •  

    سلام

    مطلب خوبی بود.

    منظور شما از CCB، همان کمیته بررسی تغییرات است دیگر؟

    موفق باشید.

  4. Pingback: توسعه محصول موفق « دنیای چابک

  5. نوید   •  

    نمی فهمم چطور agile می تونه از Scope Creep پیشگیری کنه؟

    • sirasad   •  

      نمی تونه پیشگیری بکند بلکه موثر برای مقابله با Scope Creep می باشد . بدلیل تعامل زیاد مشتری ما راحتتر می توانیم CBB داشته باشیم.

      اصلا یکی از مهمترین اساس Agile مقابله و مدیریت Scope Creep می باشد. چون ما در Agile در هنگام Initiate پروژه به صورت 100% نیازمندی ها را از Product Owner دریافت نمی نماییم و آن ها را به تدریج در طول اسپرینت ها دریافت می کنیم , پس احتمال زیاد دارد با مقوله Scope Creep روبرو شویم و بهترین راه این است که نیازمندی های جدید را طی یک Sprint جدید پیاده سازی بکنیم البته با در صورت صلاح دید در CBB .

      موفق باشید

  6. Pingback: دنیای چابک » توسعه محصول موفق

  7. Pingback: اسکرام فقط Scrum نیست « دنیای چابک

  8. Pingback: دنیای چابک » اول تا آخر Agile

پاسخ دهید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *