چهار تاکتیک برای ترکیب دو روش چابک و آبشاری
ازنظر تئوری این دو روش قابلیت ترکیب شدن ندارند؛ اما در عمل، تقریباً همیشه این اتفاق میافتد. در ادامه به 4 تاکتیک که به ما در ترکیب این دو روش متناقض کمک میکنند میپردازیم. اگر مایلید بیشتر در این مورد بخوانید، روشهای مدیریت پروژه را بررسی کنید.
چه مسئلهی پیش رو قرارداد خدمات مشاورهای باشد و چه یک پروژهی نرمافزاری داخلی، بخش فناوری اطلاعات به انعطافپذیری و بهرهوری محصول علاقهمند است. اما برای اینکه مدیریت سطوح بالاتر و سازمانهای مالی پروژه را بپذیرند، مفهوم آبشاری تقریباً همیشه بهعنوان یک الزام معرفی میشود. اگر خوب نگاه کنید متوجه میشوید که این دو تقریباً 2 فلسفهی متناقض هستند. پس چگونه میتوان آنها را باهم ترکیب کرد؟ در بسیاری از پروژههای نرمافزاری، بخصوص پروژههایی که مشاورانی دارد، تلفیق این دو روش امر دشواری است.
#1 تاکتیک مقابلهای: مدیریت توانمند حساب
ازآنجاییکه شیوهی آبشاری شامل خصوصیات ثابت مانند بودجه و برنامهی ثابت است، خروجیهای انعطافپذیر (با تعریف مبهم) برای اسپرینتها مستلزم مهارت در حفظ توزان است. بااینحال این توزان زمانی امکانپذیر است که «ویژگیِ» ثابت بودن آبشاری کاملاً برقرار نباشد (بهطور مثال زمانی که مشتری نداند دقیقاً چه چیزی میخواهد) و یا انعطافپذیر باشد (مانند زمانی که یک مدیر اجرایی تصمیم میگیرد به بعضی کارها تقدم بدهد). اما مراقب باشید؛ این تاکتیک فقط با اعمال حساسیت بالا و جدیت فراوان مؤثر است.
بهترین روش: ابتدا و انتهای هر اسپرینت صراحتاً انتظارات موردنظر در پروژه را مدیریت کنید. علاوه بر این، از مشتریان برای تحویل هر گزینه در طول اسپرینت رسیدِ تحویل بگیرید.
بدترین روش: سر خود را در برف کنید و انتظار داشته باشید، مشکلات خودشان حل شوند.
2 # تاکتیک مقابلهای: نمایش چشمگیر دستور تغییرات
در پروژههای آبشاری، مشتریان به ایدهی دستور تغییرات عادت دارند (و البته قرارداد شما هم این موارد را lلزام میکند). بنابراین از این سازوکار از ابتدا و به دفعات استفاده کنید. چهبسا در یک پروژهی 700 هزار دلاری، بیش از 50 دستور تغییر صادر شود. دستورات تغییرات باید به صورت رسمی به شرح کار [1] اضافه شوند و برای اینکه ارزش قراردادی داشته باشد، با امضای مشتری به تأیید برسند.
بهترین روش: بیدرنگ برای هر مورد مبهم دستور تغییر صادر کنید. دستور تغییر باید شامل تغییرات زمانی، مالی و جزئیات ویژگیها باشد.
بدترین روش: سفارش تغییر را فراموش کنید و به تعویق بیندازید؛ به “درک شفاهیِ” تغییر که قطعاً بهسرعت فراموش خواهد شد اکتفا کنید.
3 # تاکتیک مقابلهای: خاتمهی صریح مرحلهی شناسایی نیازمندیها
در پروژههای نرمافزاری متداول، فاز اولیه با هزینۀ ثابتِ 10 تا 25 درصد از کل تلاش پروژه، به فرایند شناسایی نیازمندیها اختصاص مییابد. خروجی این فرایند (شناسایی نیازمندیها)، شرحی از نیازمندیهای اساسی پروژه است. هرچندکه یافتن بسیاری از جزئیات بعد از فاز اول دور از انتظار نیست، این موارد جدید مشکل مجری پروژه نیست، مشکل سازمان مشتری یا مصرفکننده است. این جزئیات را نباید بدون دستور تغییر، به صورت نیازمندیهای الزامی پروژه پذیرفت. شاهد پروژههایی هستیم که نیازمندیهای آن حتی بعد از استقرار پروژه شناسایی میشوند.
بهترین روش: در مستندات نیازمندیهای پروژه بعد از فرایند شناسایی نیازمندیها، باید با عبارات تخصصی نشان داد که کل نیازمندیهای الزامی قرارداد در محتوای مستندات ذکر شده است و با امضای یک معاون از هر دپارتمان اصلی طرف مشتری یا مصرفکننده تأیید شود.
بدترین روش: سهلانگاری و تائید هر تغییری در هر مرحلهای از پروژه و بدون دستور تغییر.
4 # تاکتیک مقابلهای: الزام عدم تعدی از هر بخش اساسی در قرارداد
تا اینجا تمام تاکتیکها در حیطهی سازوکارهای مقابلهای در روند پروژه بود؛ که معمولاً برای مقابله خیلی دیر است. اما در این تاکتیک، با عبارات تخصصیِ شرح کار (SOW)، یک اصل چابک را با چارچوب آبشاری تلفیق میکنیم. در بخش اقلام تحویلی در شرح کار، هر بخش اساسی (معمولاً بین 5 و 10 بخش) باید در انتهای خود عبارات زیر را داشته باشند:
- علیرغم آنچه ذکر شد، کل کارِ مربوط به پروژه در اجرا و استقرار این بخش اساسی، از X ساعت فراتر نخواهد رفت.
- وقتی کار مربوط به این بخش به 25 درصد، 50 درصد و 75 درصد از محدودهی تعیینشده رسید، مشاور باید به مشتری اعلام دارد که نیاز به جلسهی بازبینی وظیفه است.
- در این جلسه، مشاور کاملاً مشتری را از موارد مغایر و مکشوف که اقلام تحویلی را در خطر میاندازند مطلع میسازد و راهکار ممکن را پیشنهاد میکند.
- بعد از جلسه، مشتری درخواست دستور تغییر را که شامل اصالاحاتی در نیازمندیها، زمانبندی یا بودجه است اعلام میدارد.
بهترین روش: با موضوعات کوچک باتسلط و آرامش برخورد کنید اما برای هر وظیفهای که از وضعیت قرمز فراتر برود و یا بیش از چند هفته منسدد باشد، درخواست جلسۀ بازبینی وظیفه کنید. ناتوانی در حفظ وظایف در چارچوب خطوط قرمز، موجب نارضایتی شدید رهبران پروژه میشود.
بدترین روش: این عبارات را از شرح کا ر (SOW) حذف کنید و از کل مسئله در روند پروژه تا آزمون پذیرش کاربر [2] (UAT) طفره بروید.
اما…
تمام تاکتیکهای فوق تاحدی کارسازند، اما تلاش این تاکتیکها ایجاد پلی برای عبور از تناقضات است. اگرچه پروژههای چابک مستحق دفاع و طرفداریاند، اما ممکن است سازمان مشتری یا مدیریت آن نتواند با انعطافپذیری کنار بیاید و بر لیست نامتغیر اقلام تحویلی اصرار کند. در این صورت باید این موضوع را قبل از عقد قرارداد در نظر داشته باشید. چه بسا بهتر باشد که همان روشهای آبشاری محض را دنبال کنید و به مدیریت امور به همان شیوه بپردازید. در اینصورت شاید باید انگیزش بیشتری ایجاد کنید و زمانبندی را طولانی تر کنید؛ اما حداقل میتوانید به طریق منسجمتری به مدیریت ریسک بپردازید.
علت ریشهای
در بیشتر پروژههای نرمافزاری متداول، نیازمندیهای پروژه جلوتر مشخص نمیشوند و برای پشتیبانی از روش آبشاری و مدیریت سختیگرانۀ پروژه، جزئیات کافی وجود ندارد؛ نظر به پیچیدگیهای پروژههای CMR [3] میتوان به جرئت گفت که استفاده از روش آبشاری ناممکن است. چرا؟
چقدر احتمال دارد که کاربران نیازمندیهای خود را چنان کامل و دقیق عنوان کنند که شما کژ برداشت نکنید؟
آیا کابران نظر و اولویتهایشان را در طی پروژه تغییر نمیدهند؟ آیا کانالهای مشتری، محیط رقابتی و قوانین تجاری داخلی در چرخۀ حیات پروژهی CRM تغییر نخواهند کرد؟
آیا مشتری، دادهها، قرایندهای تجاری و یکپارچهسازیهای میانسیستمی را چنان کامل میداند که در روند پروژه هیچ چیز غیرمنتظرهای عنوان نمیشود؟
آیا مشتری میتواند تمام مقررات دولتی، الزامات قراردادی کاربر، امکان دعاوی قضایی و استانداردهای داخلی را که شما باید با آنها منطبق شوید، پیشبینی کند؟
بنابراین، مشخص شدن میزانی از نیازمندیها و الزامات در روند پروژه اجتنابناپذیر است. ازاینرو بایست در سرتاسر لیست اقلام تحویلی پروژهی خود، جایی برای مجهولات قرار بدهید.
اگر نیاز به بررسی دقیقتری دارید، روشهای چابک و چارچوبهای مقیاسگذاری چابک را در خط دید مطالعه کنید.
[1] statements of work (SOWs)
[2] User Acceptance testing
[3] Customer-managed relationship