ماتریس اولویتبندی بدهی فنی
چرا این پرامپت اهمیت دارد
High-debt organizations spend 40% more on maintenance and ship features 25-50% slower than peers, and technical debt costs US companies over $2.4 trillion annually — the cost of not prioritizing isn't just slower engineering, it's a compounding tax on every future feature the team ships.
ما از آن برای چه استفاده میکنیم
Your team has a scattered list of known technical debt items sitting in a backlog nobody has prioritized, and you need a defensible remediation plan before the next quarterly planning meeting with product and finance stakeholders.
پرامپت
Act as an engineering leader who needs to defend a technical debt remediation roadmap to a CFO and a VP of Product in the same meeting. CONTEXT: - Our team's available capacity for debt remediation next quarter: [E.G. "1 engineer, 20% time" OR "2 sprints total"] - Current business priority: [GROWTH / STABILITY / COST-CUTTING] - Raw list of known technical debt items: [PASTE YOUR LIST — one item per line, however informal] TASK: For each debt item, score it 1-5 on each of these four dimensions: 1. Delivery drag — how much does this slow down future feature work in the affected area? 2. Incident risk — how often is this implicated in production issues, outages, or urgent fixes? 3. Revenue/customer exposure — does this affect paying customers, SLAs, or revenue-generating flows directly? 4. Remediation cost — how much effort would fixing this actually take (5 = very cheap, 1 = very expensive)? Then compute a priority score and rank all items. CONSTRAINTS: - Do not recommend more remediation work than the stated capacity allows — sequence items into what actually fits. - Do not treat all debt as equally urgent — explicitly deprioritize items that score low on both delivery drag and incident risk, even if they're technically embarrassing. - Justify the top 3 items in plain English a non-engineer could read and approve without a glossary. OUTPUT FORMAT: 1. Scored Table: Item | Delivery Drag | Incident Risk | Revenue Exposure | Remediation Cost | Priority Score 2. Recommended Sequence: which items fit in the stated capacity, in order 3. Plain-English Justification: 1 paragraph per top-3 item, written for a non-technical stakeholder
نتیجه
Scored Table:
| Item | Delivery Drag | Incident Risk | Revenue Exposure | Remediation Cost | Priority Score |
|---|---|---|---|---|---|
| Auth tokens don't expire | 2 | 5 | 5 | 4 | 16 |
| No test coverage on checkout service | 4 | 4 | 5 | 2 | 15 |
| Deploy script has 3 manual steps | 3 | 3 | 2 | 5 | 13 |
| Reporting dashboard queries primary DB directly | 2 | 2 | 1 | 3 | 8 |
Recommended Sequence (fits 20% time / 1 engineer for the quarter):
- Fix auth token expiration first — highest incident risk and direct revenue/compliance exposure, and at remediation cost 4 it's genuinely cheap to fix. This alone likely consumes 2-3 weeks of the available capacity.
- Add test coverage to checkout service next — this is the most expensive item on the list (cost 2), so it should be scoped to the highest-risk checkout paths only this quarter, not full coverage. Partial coverage of the payment and cart-abandonment flows is achievable in the remaining capacity.
- Deploy script and dashboard query issues are explicitly deferred to next quarter — both score below the auth and checkout items, and capacity is fully allocated after the above two.
Plain-English Justification:
Auth tokens don't expire: Right now, if someone's login session is ever compromised, whoever has that token can access their account indefinitely — there's no automatic cutoff. This is both a security exposure and, depending on our contracts, could put us in breach of customer data-handling commitments. It's also a relatively fast fix, which is why it's first.
No test coverage on checkout: Every time we change anything near checkout, we're relying on manual QA and hope to catch payment bugs before customers do. Given checkout is where we make money, a bug slipping through here has a direct and immediate revenue impact — but building full test coverage is a genuinely large effort, so we're scoping this to the highest-traffic paths first rather than promising full coverage this quarter.
Deploy script manual steps: This one is annoying and occasionally causes a bad deploy, but it doesn't touch customers directly or put revenue at risk the way the other two do — it's a real problem, just not this quarter's problem given our capacity.
Technical debt backlogها معمولاً به یکی از دو شکل از بین میروند: یا هر آیتم توسط مهندسی که بیشترین کلافگی را از آن دارد «بحرانی» علامتگذاری میشود، یا فهرست بهکلی نادیده گرفته میشود چون هیچکس نمیتواند جملهای مثل «این ماژول هیچ پوشش تستی ندارد» را به چیزی تبدیل کند که یک مدیر محصول یا CFO حاضر باشد برایش بودجه تخصیص دهد. این prompt پیش از هرگونه توالیبندی رفع مشکل، یک مرحله امتیازدهی بر اساس تأثیر کسبوکار را اجباری میکند تا برنامه حاصل بتواند از یک مکالمه نقشهراه در حضور افراد غیر فنی جان سالم به در ببرد.
دلیل وجود هر بخش از prompt
نقش: این prompt به AI دیدگاه یک رهبر مهندسی را میدهد که باید یک نقشهراه رفع مشکل را در یک جلسه واحد هم به CFO و هم به VP of Product توجیه کند — نه صرفاً یک مهندس ارشد که کیفیت کد را بررسی میکند. این چارچوببندی اهمیت دارد؛ چون یک بازبین صرفاً فنی آیتمها را بر اساس ظرافت و صحت رتبهبندی میکند، اما رهبری که هم پاسخگوی بودجه است و هم پاسخگوی تحویل، آنها را بر اساس آنچه واقعاً به کسبوکار آسیب میزند رتبهبندی میکند.
زمینه: این prompt از شما میخواهد ظرفیت فعلی sprint تیمتان و اولویتهای جاری کسبوکار (رشد، ثبات، کاهش هزینه) را مشخص کنید؛ چون یک آیتم یکسان از technical debt بسته به آنچه سازمان در حال حاضر برای آن بهینهسازی میکند، رتبه متفاوتی میگیرد. یک استارتاپ در حال رشد و یک شرکت در دوره ثبات نباید از یک فهرست یکسان technical debt، خروجی اولویتبندی یکسانی دریافت کنند.
وظیفه: هر آیتم technical debt در چهار بُعد امتیازدهی میشود — کندی تحویل (چقدر کار روی ویژگیهای آینده را کُند میکند)، ریسک حوادث (چقدر در مشکلات محیط تولید دخیل است)، میزان دسترسی به درآمد/مشتری، و هزینه رفع — به جای یک رتبهبندی مبهم «شدت». یک امتیاز واحد تفاوتهای متمایز را در عددی خلاصه میکند که هیچکس نمیتواند با آن موافق یا مخالف باشد.
محدودیتها: این prompt صریحاً «فقط همه چیز را refactor کنید» را بهعنوان خروجی ممنوع میکند و برنامه را ملزم میسازد که ظرفیت sprint اعلامشده را رعایت کند؛ چون یک تمرین اولویتبندی که کار بیشتری از آنچه تیم توان جذب دارد توصیه کند، یک برنامه نیست — بلکه یک آرزونامه است.
قالب خروجی: خروجی بهصورت جدول رتبهبندیشده ارائه میشود (نه نثر آزاد)، و این عمداً طراحی شده تا بتوان آن را بدون هیچ کار قالببندی اضافهای مستقیماً در یک دک بررسی نقشهراه گذاشت. یک پاراگراف توجیه به زبان ساده برای ۳ آیتم برتر نیز ضمیمه میشود که یک ذینفع غیر فنی واقعاً بتواند آن را بخواند و تأیید کند.
The prompt
بهعنوان یک رهبر مهندسی عمل کنید که باید یک نقشهراه رفع technical debt را در یک جلسه واحد هم به CFO و هم به VP of Product توجیه کند.
زمینه:
- ظرفیت موجود تیم برای رفع technical debt در سهماهه آینده: [مثلاً «۱ مهندس، ۲۰٪ زمان» یا «۲ sprint کل»]
- اولویت فعلی کسبوکار: [رشد / ثبات / کاهش هزینه]
- فهرست خام آیتمهای technical debt شناختهشده: [فهرست خود را اینجا وارد کنید — هر آیتم در یک خط، هر چقدر هم غیررسمی]
وظیفه:
برای هر آیتم technical debt، آن را در هر یک از چهار بُعد زیر از ۱ تا ۵ امتیاز دهید:
۱. کندی تحویل — این آیتم چقدر کار روی ویژگیهای آینده در حوزه مربوطه را کُند میکند؟
۲. ریسک حوادث — چقدر در مشکلات محیط تولید، قطعیها، یا رفعهای اضطراری دخیل است؟
۳. دسترسی به درآمد/مشتری — آیا مستقیماً بر مشتریان پرداختکننده، SLA ها، یا جریانهای درآمدزا تأثیر میگذارد؟
۴. هزینه رفع — رفع این مشکل واقعاً چقدر تلاش میبرد؟ (۵ = بسیار ارزان، ۱ = بسیار گران)
سپس یک امتیاز اولویت محاسبه کرده و همه آیتمها را رتبهبندی کنید.
محدودیتها:
- بیشتر از ظرفیت اعلامشده کار رفع مشکل توصیه نکنید — آیتمها را بهگونهای توالیبندی کنید که واقعاً در آن جا بگیرند.
- همه technical debt را به یک اندازه فوری تلقی نکنید — آیتمهایی را که هم در کندی تحویل و هم در ریسک حوادث امتیاز پایینی دارند صریحاً به اولویتهای پایینتر منتقل کنید، حتی اگر از نظر فنی شرمآور باشند.
- ۳ آیتم برتر را به زبان سادهای توجیه کنید که یک غیر مهندس بتواند بدون نیاز به واژهنامه بخواند و تأیید کند.
قالب خروجی:
۱. جدول امتیازدهی: آیتم | کندی تحویل | ریسک حوادث | دسترسی به درآمد | هزینه رفع | امتیاز اولویت
۲. توالی پیشنهادی: کدام آیتمها در ظرفیت اعلامشده جا میگیرند، به ترتیب
۳. توجیه به زبان ساده: ۱ پاراگراف برای هر یک از ۳ آیتم برتر، نوشتهشده برای یک ذینفع غیر فنیخروجی واقعی چه شکلی دارد
برای تیمی با ظرفیت «۱ مهندس، ۲۰٪ زمان» در یک دوره رشد، با فهرست خامی شامل «عدم پوشش تست روی سرویس checkout»، «توکنهای احراز هویت منقضی نمیشوند»، «داشبورد گزارشگیری مستقیماً از پایگاه داده اصلی query میزند»، و «اسکریپت deploy ما سه مرحله دستی دارد که همیشه یک نفر آنها را فراموش میکند»، یک خروجی نمونه چنین خواهد بود:
نکات عملی و کاربردی
- این prompt را پیش از چرخه برنامهریزی بعدی اجرا کنید، نه در حین آن — مکالمه امتیازدهی اختلاف نظرها درباره اولویتهای کسبوکار را آشکار میکند که بهتر است پیش از تخصیص ظرفیت حل شوند، نه در میان یک جلسه نقشهراه پرتنش.
- از توجیههای زبان ساده عیناً استفاده کنید وقتی که برای درخواست بودجه یا نیروی انسانی اقدام میکنید — آنها بهطور ویژه ساخته شدهاند تا بدون نیاز به ترجمه در لحظه، در برابر مخاطبان غیر فنی دوام بیاورند.
- هر بار که اولویت کسبوکار تغییر کرد (مثلاً از رشد به ثبات) این prompt را مجدداً اجرا کنید — یک فهرست یکسان از technical debt باید توالیبندی معناداری متفاوتی تولید کند، و اگر نکرد، ورودیهای امتیازدهی نیاز به بازبینی دارند.
- مرحله deprioritization صریح را نادیده نگیرید — فهرست technical debt ی که در آن همه چیز «مهم» است، رایجترین دلیلی است که نقشهراههای رفع مشکل هرگز از تماس واقعی با یک sprint جان سالم به در نمیبرند.