مدیریت تغییر دامنه پروژه
پروژهای که با «یک فروشگاه ساده» شروع شده، هشت ماه بعد یک سامانهٔ انبارداری با پنل نمایندگان و اپلیکیشن پیک است. هیچکس تصمیم نگرفت این اتفاق بیفتد. هر درخواست بهتنهایی کوچک و منطقی بود.
این را خزش دامنه مینامند و کشندهٔ خاموش پروژههای نرمافزاری است — نه به این دلیل که تغییر بد است، بلکه به این دلیل که تغییرِ بدون تصمیم بد است.
تغییر دامنه بد نیست
اول این را روشن کنیم، چون بیشتر نوشتههای این حوزه لحن دفاعی دارند.
اگر بعد از سه ماه کار روی محصول، کارفرما چیزی یاد گرفته که در روز اول نمیدانست و میخواهد مسیر را عوض کند، این موفقیت است نه شکست. کل منطق روشهای چابک همین است: بازخورد زودهنگام باید بتواند برنامه را عوض کند، وگرنه بازخورد گرفتن چه فایدهای دارد؟
پس مسئله این نیست که تغییر را جلویش را بگیریم. مسئله این است که تغییر:
- دیده شود — کسی بداند اتفاق افتاده؛
- قیمت بخورد — اثرش روی زمان و هزینه معلوم باشد؛
- تصمیم داشته باشد — یک نفر مشخص بگوید بله یا خیر.
خزش دامنه یعنی تغییری که هیچکدام از این سه را ندارد.
چطور بیصدا اتفاق میافتد
الگوهایی که در پروژهها بارها دیدهایم:
«این که چیزی نیست، نیم ساعته است.» جملهٔ کلیدی. گاهی هم راست است. اما بیست تا «نیم ساعت» میشود سه روز، و هیچکدام در برنامه نبوده. مشکل، اندازهٔ هر درخواست نیست؛ نبودِ جمعزدن است.
درخواست مستقیم به برنامهنویس. کاربر ارشد کارفرما با یکی از اعضای تیم رابطهٔ خوبی دارد و مستقیم پیام میدهد. برنامهنویس هم آدم خوبی است و انجام میدهد. کار انجام شده و هیچجا ثبت نشده و در تخمین هفتهٔ بعد هم نیست.
تفسیر در پیادهسازی. نیازمندی مبهم بوده و تیم نسخهٔ کاملتری از آنچه لازم بود ساخته، چون «قطعاً بعداً میخواهند».
«این که جزو همان بود.» اختلاف بر سر اینکه فلان قابلیت در دامنهٔ اولیه بوده یا نه. تقریباً همیشه به این برمیگردد که دامنهٔ اولیه بهاندازهٔ کافی دقیق نوشته نشده بود.
پیشگیری: دامنه را روشن بنویسید
بهترین دفاع در برابر اختلاف بعدی، دقت اولیه است — و نه لزوماً سند طولانیتر.
آنچه خارج از دامنه است را صریح بنویسید. این تنها مؤثرترین کاری است که در این حوزه میشود کرد و کمترین انجام را دارد. فهرست «شامل نمیشود» به همان اندازهٔ فهرست «شامل میشود» ارزش دارد، و نوشتنش نیم ساعت است.
عدد بگذارید. «گزارشگیری» یعنی چه؟ سه گزارش یا سی گزارش؟ «چند زبانه» یعنی دو زبان یا هفت زبان؟ هر صفتی که عدد ندارد، بعداً محل اختلاف است.
معیار پذیرش بنویسید، نه توصیف قابلیت. «کاربر میتواند سفارش را لغو کند» مبهم است؛ «کاربر تا پیش از ارسال میتواند لغو کند و مبلغ ظرف ۷۲ ساعت برمیگردد» قابل سنجش است.
نسخهٔ اول را کوچک نگه دارید. هرچه فاصلهٔ امضا تا اولین تحویل قابل استفاده بیشتر باشد، فرصت بیشتری برای انباشت تغییر هست. این یکی از دلایل اصلی منطق نسخهٔ اول محصول است.
اگر در مرحلهٔ پیش از قرارداد هستید، ساختار درست این کار همان چیزی است که در نگارش RFP نوشتهایم.
سازوکار تغییر، ساده و واقعی
فرایند سنگین تغییر — فرم و کمیته و امضا — در عمل دور زده میشود. چیزی که در پروژههای ما کار میکند، سه قدم است:
۱. هر درخواست از یک مسیر واحد وارد شود. یک نفر از سمت کارفرما مسئول است و درخواستها از او میآیند. این بیش از هر چیز دیگری جلوی خزش را میگیرد، چون کارفرما را وادار میکند اولویتهای خودش را با هم آشتی بدهد پیش از آنکه به تیم برسند.
۲. هر درخواست تخمین میخورد، حتی اگر کوچک باشد. عدد لازم نیست دقیق باشد؛ لازم است وجود داشته باشد. «این دو روز است» گفتوگو را از «انجامش بده» به «آیا دو روز ارزشش را دارد؟» میبرد.
۳. اثرش روشن گفته شود. و اینجا فرمولبندی مهم است. نگویید «نمیشود». بگویید:
«میشود. دو روز کار دارد. یا تحویل دو روز عقب میافتد، یا یکی از این کارهای هفتهٔ جاری میرود به بعد. کدام؟»
این جمله چند کار همزمان میکند: تیم را از نقش مانع خارج میکند، تصمیم را به کسی میدهد که باید بگیرد، و هزینه را قابل دیدن میکند.
بودجهٔ تغییر
روشی که در قراردادهای بلندمدت جواب داده و پیشنهادش میکنیم: از ابتدا درصدی از ظرفیت — معمولاً بین ده تا بیست درصد — به تغییرات اختصاص دهید.
دو اثر دارد. اول اینکه واقعبینانه است؛ هیچ پروژهای بدون تغییر تمام نمیشود و وانمود کردن به عکسش فقط برنامه را غلط میکند. دوم اینکه تغییر را از حالت «استثنا و مشاجره» به حالت «سهمیه و اولویتبندی» میبرد. گفتوگو دربارهٔ اینکه «کدام تغییر در سهمیهٔ این ماه باشد» خیلی سالمتر از گفتوگو دربارهٔ اینکه «این جزو قرارداد بود یا نه» است.
نقش نوع قرارداد
قیمت ثابت انگیزهٔ طرفین را رودرروی هم میگذارد: هر تغییر برای پیمانکار ضرر است و برای کارفرما رایگان به نظر میرسد. نتیجهاش مذاکره بر سر هر قلم است. برای پروژهای با دامنهٔ واقعاً روشن مناسب است و برای بقیه، منبع اصطکاک.
زمان و مواد تغییر را ساده میکند و ریسک را کامل به کارفرما میدهد. بدون سقف و بدون شفافیت، اعتمادسوز است.
سقف تضمینی یا ترکیبی — پرداخت بر اساس کار انجامشده با سقف مشخص — در عمل برای بیشتر پروژههای سازمانی متعادلترین است. مقایسهٔ کاملشان در مدلهای برونسپاری آمده.
نکتهای که فارغ از نوع قرارداد درست است: قراردادی که تغییر را غیرممکن میکند، تغییر را حذف نمیکند؛ فقط پنهانش میکند. تغییر بهصورت «رفع باگ» درخواست میشود و کیفیت آن چیزی است که هزینهاش را میدهد.
نشانههای هشدار
اگر اینها را میبینید، خزش در جریان است:
- تاریخ تحویل مدام دو هفته جلوتر میرود و هیچوقت نمیرسد.
- تیم مشغول است اما ویژگیهای اصلی هنوز تمام نشدهاند.
- کسی نمیتواند در یک جمله بگوید نسخهٔ اول شامل چیست.
- درخواستها در پیامرسان میآیند، نه در تخته.
- تیم فنی میگوید «کلی کار کردیم» و کارفرما میگوید «چیزی ندیدم».
مورد آخر معمولاً یعنی کارهای انجامشده در برنامه نبودهاند.
و اگر همین حالا وسط این وضعیت هستید
توقف کنید و فهرست کنید: چه چیزهایی از قرارداد اولیه هنوز تمام نشده، و چه چیزهایی انجام شده که در آن نبوده. این جدول را با کارفرما مرور کنید.
تقریباً همیشه واکنش کارفرما این است که خودش نمیدانسته چقدر اضافه شده. تصویر مشترک، نیمی از حل مسئله است — و نیمهٔ دیگرش تصمیم مشترک دربارهٔ اینکه از این به بعد چه چیزی واقعاً لازم است.