اولویت‌بندی بدهی فنی: تبدیل کوهی از مشکلات شناخته‌شده به یه لیستِ مرتب برای رفع ایرادها

توی هر تیم مهندسی یه بک‌لاگ بدهی فنی هست که هیچ‌کس واقعاً بهش اعتماد نداره. موارد مختلف وقتی بهش اضافه می‌شن که یه موضوعی روی اعصاب یکی از بچه‌ها بره، و اولویت‌بندیشون هم دقیقاً به همین شیوه انجام میشه؛ یعنی بر اساس اینکه کی آخرین بار شکایت کرده، نه بر اساس ریسک واقعی قضیه. این روش کار همیشه نتیجه‌ش اینه که کل یه فصل کاری صرف رفع یه موضوع جزئی و اعصاب‌خردکن میشه، در حالی که سیستمی که بیشترین احتمال رو داره تا قطعی بعدی رو به بار بیاره دست‌نخورده باقی می‌مونه؛ فقط چون هیچ‌وقت با معیاری ملموس و واقعی نسنجیدنش.

این Prompt قبل از اینکه هر تصمیمی برای اولویت‌بندی گرفته بشه، یه مرحله امتیازدهی ساختاریافته رو روی تک‌تک آیتم‌های بک‌لاگ پیاده می‌کنه. برای این کار از چهار تا بعد استفاده می‌کنه: شعاع تخریب (blast radius)، احتمال بروز حادثه، هزینه تاخیر، و میزان زحمت. دلیلش هم واضحه؛ چون این چهار تا با هم دقیقاً نشون می‌دن که «اولویت» توی یه سیستم عملیاتی واقعاً چه معنایی داره، و هیچ‌کدومشون هم مستقیماً به این ربط پیدا نمی‌کنن که اون موضوع چقدر روی اعصاب مهندسی می‌ره که هر روز مجبوره اون مشکل رو دور بزنه و باهاش سر کنه.

چرا چهار تا بعد، نه فقط یه امتیاز؟

گذاشتن یه فیلد تکی مثل «اولویت: بالا/متوسط/پایین»، اون‌قدر حجم زیادی از اطلاعات رو حذف و فشرده می‌کنه که دیگه به درد نمی‌خوره. تازه این همون فیلدی هست که بیشتر از هر چیزی تحت تاثیر اون کسی قرار می‌گیره که توی جلسه برنامه‌ریزی از همه بلندتر داد میزنه. اما وقتی نمره رو به چهار بخش تقسیم می‌کنیم: شعاع تخریب (اینکه چند تا سیستم یا کاربر درگیر می‌شن)، احتمال بروز حادثه (اینکه این مورد خاص با توجه به قابلیت‌هایی که قراره به‌زودی عرضه بشن چقدر احتمال خرابی واقعی داره)، هزینه تاخیر (اینکه آیا مشکل با گذشت زمان بدتر می‌شه یا نه)، و میزان زحمت (اینکه حل کردنش واقعاً چقدر انرژی و زمان می‌بره)، همه مجبور می‌شن بحث‌هاشون رو برای رتبه‌بندی دقیقاً در چارچوب همین واژه‌ها جلو ببرن. جمله «این خیلی رو مخمه» توی هیچ‌کدوم از این چهار تا بخش جا نمیشه، و اصل هدف هم دقیقاً همینه.

چرا مسیر اضطراریِ «باید حل بشه» مهمه؟

قرار نیست هر خطری رو در مقایسه با میزان زحمتش رتبه‌بندی کنیم. مثلاً یه باگ در زمینه تطابق با قوانین یا یکپارچگی داده‌ها که به‌ندرت پیش میاد ولی هر بار اتفاق بیفته خسارت واقعی میزنه، نباید فقط چون فرمول‌های ریاضی این‌طوری دراومدن به یه آیتم کم‌خطرتر ولی پرتکرارتر ببازه. این Prompt خیلی شفاف این مدل موارد رو جدا می‌کنه و می‌فرسته توی دسته‌بندی اختصاصیِ «باید حل بشه» که کلاً لیست رتبه‌بندی‌شده رو دور میزنه؛ چون حل کردنشون توی یه نمره ترکیبی، یا فوریت ظاهریِ همه آیتم‌های دیگه رو الکی بالا میبره، یا یه خطر و تعهد کاملاً جدی رو زیر خرواری از گلایه‌های جزئی مربوط به سرعت و عملکرد دفن می‌کنه.

چرا صداقت در تخمین زحمت یه شرط جداگونه‌ست؟

تخمین‌های زحمت برای رفع بدهی فنی، خیلی وقت‌ها صرفاً حدس‌هایی هستن که لباس عدد تنشون کردن. وقتی یه تیم با یه تخمین حدسیِ ۳ روزه دقیقاً مثل یه تخمین ۳ روزه که از روی کد بررسی و تایید شده رفتار کنه، در نهایت ظرفیت اسپرینت رو به دلایلی هدر می‌ده که هیچ‌کس نمی‌تونه ردش رو بگیره. مجبور کردن مدل به اینکه مشخص کنه کدوم تخمین‌ها مطمئن و کدوم‌ها تقریبی هستن، خروجی رو نسبت به چیزهایی که واقعاً می‌دونه صادق نگه میداره.

چطور از این خروجی استفاده کنیم

جدول رتبهبندیشده و بخش موارد ضروری (must-fix) رو مستقیم ببر توی جلسات برنامهریزی اسپرینت. سقف سفتوسختِ ۵ مورد برای هر سهماهه اصلاً الکی و دلبخواهی نیست؛ گذاشتنش تا به جای اینکه با هر اسپرینت فقط به حجم بکلاگ اضافه بشه و هیچ مشکلی واقعاً حل نشه، مجبورت کنه یه تصمیمِ تعهدآورِ واقعی بگیری. اگه ظرفیت واقعی تیمت بیشتر از ۵ مورد هست، سقف رو ببر بالا؛ ولی به جای اینکه تهش رو باز بذاری، روی عددی نگهش دار که مجبور باشی پای انتخابت وایسی و ازش دفاع کنی.