محدِّد أولويات الدين التقني: حوّل كومة من المشكلات المعروفة إلى قائمة إصلاحات مرتبة
لماذا تهم هذه المطالبة
Teams that prioritize tech debt by gut feeling or by whoever complained most recently routinely spend a full quarter fixing a low-impact annoyance while the actual system most likely to cause the next outage sits untouched for another two quarters, because nobody scored it against anything concrete.
فيم نستخدمها
A tech lead has 40 open technical debt tickets accumulated over a year, a sprint planning meeting in two hours, and no agreed-upon method for deciding which 5 items the team will actually commit to fixing this quarter instead of just the ones the loudest engineer complained about last.
المطالبة
Act as a staff engineer who specializes in technical debt triage and has to defend every prioritization decision to both engineering leadership and the business side, not just to other engineers. Context: - Team size and sprint capacity: [TEAM SIZE AND STORY POINTS OR HOURS AVAILABLE PER SPRINT] - Known tech debt items: [PASTE YOUR LIST OF TECH DEBT ITEMS, ONE PER LINE, WITH A ONE-SENTENCE DESCRIPTION OF EACH] - Roadmap context: [WHAT THE TEAM IS SHIPPING IN THE NEXT 1-2 QUARTERS, SO WE KNOW WHICH SYSTEMS WILL SEE THE MOST CHANGE OR LOAD] - Incident history: [ANY OUTAGES, SEV1/SEV2 INCIDENTS, OR CUSTOMER ESCALATIONS THAT TRACE BACK TO ANY OF THESE ITEMS, IF KNOWN] Task: For each tech debt item, score it on four dimensions using a 1-5 scale and produce a single composite score: 1. Blast radius - how many systems, teams, or customers would be affected if this item causes a failure 2. Incident probability - how likely this item is to cause a production incident in the next two quarters, given the roadmap context above 3. Cost of delay - how much more expensive or risky this item becomes the longer it's left unaddressed (interest accrual, not just current pain) 4. Effort to fix - estimated engineering time, flagged clearly as either a confident estimate (based on reading the actual code or system) or a rough guess Then rank all items by composite score and draw a clear line recommending the top items that fit within the stated sprint capacity for this quarter. Constraints: - Recommend no more than 5 items for this quarter's commitment, regardless of how many items are on the list - Any item with a safety, data-integrity, or compliance dimension must be flagged as a must-fix regardless of its composite score, and called out separately from the ranked list - Do not let "this annoys me as an engineer" stand in for blast radius or incident probability - every score needs a one-sentence justification tied to actual system behavior or business impact - If effort estimates are guesses rather than informed by code inspection, say so explicitly rather than presenting false precision Output format: A markdown table with columns: Item | Blast Radius (1-5) | Incident Probability (1-5) | Cost of Delay (1-5) | Effort (1-5, lower is less effort) | Composite Score | Recommendation (Fix this quarter / Defer / Must-fix regardless of score) Followed by a short narrative (3-4 sentences per item) explaining the reasoning for the top 3 recommended items, and a separate callout box listing any must-fix safety/compliance items that bypass the ranking entirely.
النتيجة
| Item | Blast Radius | Incident Probability | Cost of Delay | Effort | Composite | Recommendation |
|---|---|---|---|---|---|---|
| Auth service still on sync HTTP calls to 3 downstream services, no circuit breaker | 5 | 4 | 5 | 3 | 17 | Fix this quarter |
| Legacy billing cron job has no idempotency key, double-charges on retry | 4 | 3 | 4 | 2 | 13 | Must-fix regardless (compliance/financial risk) |
| Admin dashboard still uses deprecated internal API v1, scheduled for shutdown in 5 months | 2 | 5 | 3 | 3 | 13 | Fix this quarter |
| Test suite takes 47 minutes, no parallelization | 2 | 1 | 2 | 4 | 9 | Defer |
| Inconsistent error logging format across 6 microservices | 2 | 1 | 2 | 2 | 7 | Defer |
Why the top 3
Auth service sync calls (score 17): This is the clearest must-fix for pure risk reasons. With three downstream dependencies and no circuit breaker, a single slow dependency degrades login for the entire platform, and the roadmap shows two new services calling into auth next quarter, which only raises the odds of a cascading timeout. Effort is a confident estimate at 3 because the team already scoped this during the Q2 reliability review.
Billing cron double-charge bug: This bypasses the ranking entirely and goes in the must-fix box. A double-charge is a compliance and trust issue regardless of how rarely the retry path triggers; probability of occurrence doesn't matter when the downside is a refund process and a support escalation every time it fires.
Admin dashboard on deprecated API v1: Incident probability is scored a 5 specifically because the shutdown date is fixed and known — this isn't a maybe, it's a scheduled failure if untouched. Blast radius is lower than the auth item because only internal admin users are affected, which is why it ranks third despite the certain failure date.
Must-fix callout: Billing cron idempotency bug — financial and compliance exposure independent of composite score. Recommend assigning to this sprint even if it displaces one of the ranked items above.
لكل فريق هندسي قائمة ديون تقنية لا يثق بها أحد تماماً. تُضاف العناصر إليها حين يضيق أحدهم ذرعاً بشيء، وتُرتَّب أولوياتها بنفس الطريقة — حسب حداثة الشكوى، لا الخطر الفعلي. هذا النهج ينتج باستمرار فصلاً كاملاً يُصرف على إصلاح إزعاج بسيط بينما يبقى النظام الأكثر احتمالاً لإحداث العطل القادم بلا لمسة، لأن أحداً لم يقيّمه أمام أي معيار ملموس.
يفرض هذا الأمر جولة تصنيف منظّمة على كل عنصر في القائمة قبل اتخاذ أي قرار بشأن الأولويات. يستخدم أربعة أبعاد — نطاق التأثير، احتمالية الحادثة، تكلفة التأجيل، والجهد — لأن هذه الأبعاد الأربعة معاً تجسّد ما تعنيه «الأولوية» فعلاً في نظام إنتاجي، ولا يرتبط أي منها مباشرة بمدى إزعاج المشكلة للمهندس الذي يضطر للتعامل معها يومياً.
لماذا أربعة أبعاد، لا درجة واحدة
حقل واحد بسيط مثل «الأولوية: مرتفعة/متوسطة/منخفضة» يُفقد الكثير من المعلومات المفيدة، وهو أيضاً الحقل الأكثر عرضة لمن يرفع صوته أكثر في اجتماع التخطيط. تقسيم الدرجة إلى نطاق التأثير (عدد الأنظمة أو المستخدمين المعرّضين)، احتمالية الحادثة (مدى احتمال فشل هذا العنصر تحديداً، بالنظر إلى ما سيُطرح لاحقاً)، تكلفة التأجيل (هل تتفاقم المشكلة كلما طال بقاؤها)، والجهد (ما الذي يكلفه إصلاحها فعلاً)، يفرض أن تُصاغ كل حجة للترتيب بهذه المصطلحات بالتحديد. عبارة «هذا يزعجني فعلاً» لا تنطبق على أي من هذه الأربعة، وهذا هو المقصود.
لماذا يهم مخرج «الإصلاح الواجب»
لا ينبغي ترتيب كل الأخطار مقابل الجهد. خطأ يتعلق بالامتثال أو سلامة البيانات، يحدث نادراً لكنه يُلحق ضرراً حقيقياً كل مرة يُفعَّل، لا ينبغي أن يُهزَم أمام عنصر ذي احتمالية أعلى لكن مخاطر أقل لمجرد أن الحسابات تخرج بهذا الشكل. يفصل هذا الأمر بوضوح هذه العناصر في فئة «واجب إصلاحه» منفصلة تتجاوز القائمة المرتبة، لأن دمجها في درجة مركّبة يُضخّم إلحاحية كل عنصر آخر ظاهرياً أو يدفن مسؤولية فعلية تحت كومة من شكاوى الأداء الطفيفة.
لماذا تُعد صدقية تقدير الجهد قيداً منفصلاً
تقديرات الجهد للدين التقني غالباً ما تكون تخمينات متنكرة في هيئة أرقام، والفريق الذي يعامل تقديراً مُخمَّناً لثلاثة أيام معاملة تقدير مؤكَّد بفحص الكود لثلاثة أيام ينتهي به الأمر بتجاوز سعة السبرنت لأسباب لا يستطيع أحد تتبعها. إلزام النموذج بتحديد أي التقديرات موثوقة وأيها تقريبية يحافظ على صدق المخرجات حول ما تعرفه فعلاً.
كيف تستخدم المخرجات
اجلبوا الجدول المرتب وقائمة «واجب الإصلاح» مباشرة إلى اجتماع تخطيط السبرنت. الحد الأقصى الصارم بخمسة عناصر لكل فصل ليس اعتباطياً — فهو موجود لفرض قرار تعهد حقيقي عوضاً عن قائمة تكبر كل سبرنت دون أن يُصلح فيها شيء فعلياً.