مصفوفة تحديد أولويات الـ Technical Debt
لماذا تهم هذه المطالبة
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.
عادةً ما تنتهي قوائم الـ backlog الخاصة بالـ technical debt بإحدى طريقتين: إما أن يُصنَّف كل بند فيها على أنه "حرج" من قِبَل المهندس الأكثر انزعاجًا منه، أو تُتجاهَل القائمة برمتها لأن لا أحد يستطيع ترجمة عبارة "هذه الوحدة البرمجية لا تحظى بأي تغطية اختبارية" إلى صياغة يمكن لمدير المنتج أو المدير المالي تمويلها. يُجبر هذا الـ prompt على إجراء جولة تقييم لأثر الأعمال قبل أي تسلسل للمعالجة، بحيث تصمد الخطة الناتجة في أي نقاش حول خارطة الطريق حتى حين يكون غير المهندسين حاضرين في الاجتماع.
لماذا يوجد كل قسم من أقسام الـ prompt
الدور: يُسنَد إلى الـ AI في هذا الـ prompt منظور قائد هندسي يتعين عليه الدفاع عن خارطة طريق المعالجة أمام المدير المالي ونائب رئيس المنتج في الاجتماع ذاته — لا مجرد مهندس أول يراجع جودة الكود. هذا الإطار مهم لأن المراجع التقني البحت يرتب البنود حسب الأناقة والصحة؛ أما القائد المسؤول عن الميزانية والتسليم معًا، فيرتبها وفق ما يُلحق الضرر الفعلي بالأعمال.
السياق: يطلب الـ prompt طاقة الـ sprint الحالية لفريقك وأولويات الأعمال الحالية (النمو، الاستقرار، خفض التكاليف)، وذلك لأن البند الواحد من الـ technical debt يتفاوت ترتيبه بحسب ما تسعى إليه المنظمة في الوقت الراهن. لا ينبغي أن تحصل شركة ناشئة في مرحلة التوسع وشركة تمر بربع استقرار على نفس مخرجات الأولوية من قائمة الـ technical debt ذاتها.
المهمة: يُقيَّم كل بند من بنود الـ technical debt على أربعة أبعاد — عبء التسليم (مدى إبطائه للعمل على الميزات المستقبلية)، وخطر الحوادث (مدى تورطه في مشكلات الإنتاج)، وتعرض الإيرادات/العملاء، وتكلفة المعالجة — بدلًا من تقييم واحد مبهم للـ"خطورة"، لأن الدرجة الواحدة تُدمج مقايضات متمايزة في رقم لا يمكن لأحد مناقشته أو معارضته.
القيود: يحظر الـ prompt صراحةً تبنّي "الـ refactor لكل شيء" مخرجًا، ويشترط أن تحترم الخطة طاقة الـ sprint المُحددة، لأن تمرين ترتيب الأولويات الذي يوصي بعمل أكثر مما يستطيع الفريق استيعابه ليس خطة، بل هو قائمة أمنيات.
صيغة المخرجات: المخرج عبارة عن جدول مُرتَّب (لا نص سردي) تحديدًا لكي يمكن إدراجه في عرض مراجعة خارطة الطريق دون أي عمل إضافي على التنسيق، يعقبه فقرة واحدة بلغة واضحة تُبرر اختيار أعلى ثلاثة بنود، بحيث يستطيع أصحاب المصلحة غير التقنيين قراءتها والموافقة عليها فعلًا.
الـ prompt
تصرف بوصفك قائدًا هندسيًا يحتاج إلى الدفاع عن خارطة طريق معالجة الـ technical debt أمام المدير المالي ونائب رئيس المنتج في الاجتماع ذاته.
السياق:
- الطاقة الاستيعابية المتاحة لفريقنا لمعالجة الـ technical debt في الربع القادم: [مثال: "مهندس واحد، 20% من وقته" أو "sprintان بالمجموع"]
- أولوية الأعمال الحالية: [النمو / الاستقرار / خفض التكاليف]
- القائمة الخام لبنود الـ technical debt المعروفة: [أدرج قائمتك هنا — بند واحد في كل سطر، بأي صياغة غير رسمية]
المهمة:
لكل بند من بنود الـ technical debt، قيّمه من 1 إلى 5 على كل بُعد من الأبعاد الأربعة التالية:
1. عبء التسليم — بأي قدر يُبطئ هذا البند العمل على الميزات المستقبلية في المجال المتأثر؟
2. خطر الحوادث — ما مدى تورط هذا البند في مشكلات الإنتاج والانقطاعات والإصلاحات العاجلة؟
3. تعرض الإيرادات/العملاء — هل يؤثر هذا البند مباشرةً على العملاء الدافعين أو اتفاقيات مستوى الخدمة أو تدفقات توليد الإيرادات؟
4. تكلفة المعالجة — ما حجم الجهد الذي يستلزمه إصلاح هذا البند فعلًا؟ (5 = رخيص جدًا، 1 = مكلف جدًا)
ثم احسب درجة الأولوية ورتّب جميع البنود.
القيود:
- لا توصِ بعمل معالجة يتجاوز الطاقة الاستيعابية المُحددة — رتّب البنود في تسلسل يتناسب مع ما هو ممكن فعلًا.
- لا تعامل جميع الـ technical debt على أنها عاجلة بالقدر ذاته — أزِح أولوية البنود التي تحصل على درجات منخفضة في كلٍّ من عبء التسليم وخطر الحوادث، حتى وإن كانت محرجة من الناحية التقنية.
- برِّر اختيار أعلى ثلاثة بنود بلغة واضحة يستطيع غير المهندس قراءتها والموافقة عليها دون الحاجة إلى قاموس مصطلحات.
صيغة المخرجات:
1. الجدول المُقيَّم: البند | عبء التسليم | خطر الحوادث | تعرض الإيرادات | تكلفة المعالجة | درجة الأولوية
2. التسلسل الموصى به: البنود التي تتناسب مع الطاقة الاستيعابية المُحددة، مرتبةً بالترتيب
3. المبررات بلغة واضحة: فقرة واحدة لكل بند من أعلى ثلاثة بنود، مكتوبة لصاحب مصلحة غير تقنيشكل المخرجات الفعلي
لفريق يمتلك طاقة استيعابية تبلغ "مهندس واحد، 20% من وقته" في ربع نمو، وبالنظر إلى قائمة خام تضم: "لا تغطية اختبارية لخدمة الدفع"، و"رموز المصادقة لا تنتهي صلاحيتها"، و"لوحة تقارير الأداء تستعلم مباشرةً من قاعدة البيانات الأساسية"، و"سكريبت النشر لدينا يتضمن ثلاث خطوات يدوية ينساها شخص ما دومًا"، فإن المخرج النموذجي سيكون على النحو التالي:
استنتاجات قابلة للتنفيذ
- شغِّل هذا الـ prompt قبل دورة التخطيط القادمة، لا خلالها — فمحادثة التقييم تُبرز الخلافات حول أولويات الأعمال التي يُستحسن حلّها قبل توزيع الطاقة الاستيعابية، لا في خضم اجتماع خارطة طريق محتدم.
- استخدم المبررات المكتوبة بلغة واضحة حرفيًا حين تطلب ميزانية أو موارد بشرية — فقد صُممت تحديدًا لتصمد أمام جمهور غير تقني دون أن تضطر إلى الترجمة ارتجالًا.
- أعِد تشغيل الـ prompt كلما تغيرت أولوية أعمالك المُعلنة (من النمو إلى الاستقرار، مثلًا) — فالقائمة ذاتها من الـ technical debt ينبغي أن تُنتج تسلسلًا مختلفًا اختلافًا ذا معنى، وإن لم يحدث ذلك، فمدخلات التقييم بحاجة إلى مراجعة.
- لا تتخطَّ خطوة إزاحة الأولوية الصريحة — فقائمة الـ technical debt التي يكون فيها كل شيء "مهمًا" هي السبب الأكثر شيوعًا على الإطلاق وراء عدم صمود خرائط طريق المعالجة عند الاحتكاك بـ sprint حقيقي.