تخطَّ إلى المحتوى

من يملك ماذا

تُحسم الملكية على ثلاث طبقات، ومعظم الخلافات تقع لأن الناس يقصدون الطبقة الخطأ.

flowchart TD
  Q["Who owns this?"] --> RC{"A role's core<br/>accountability?"}
  RC -- Yes --> A["Role Cards"]
  RC -- No --> T{"One of the six recurring<br/>cross-boundary decisions?"}
  T -- Yes --> B["Decision Rights — DACI"]
  T -- No --> C["This table"]
  C --> N{"Not listed?"}
  N -- delivery or client --> PM["PM breaks the tie"]
  N -- technical --> CTO["CTO breaks the tie"]
  PM --> ADD["Add the row — same day"]
  CTO --> ADD

بطاقات الأدوار تغطي المسؤوليات الأساسية. وحقوق اتخاذ القرار تغطي القرارات الستة المتكررة. وهذه الصفحة تغطي الصنف الثالث: أشياء صغيرة ملموسة تقع بين الأدوار وتكلّف عشر دقائق جدال كل بضعة أسابيع.

الشيء المالك ملاحظة
سكربت الـ DB migration Backend Lead حتى لو كتبه junior — فالموقَّع عليه هو نموذج البيانات.
الـ API contract: الشكل، الإصدار، التغييرات الكاسرة Backend Lead الشكل يحدّده تصميم الـ API. والـ frontend والـ mobile يستهلكانه ولا يغيّرانه منفردين.
المكوّنات المشتركة وأنماط الواجهة Frontend Lead ويشمل ذلك متى لا يُضاف مكوّن جديد.
مكتبة أو SDK جديدة من طرف ثالث Team Lead — والـ CTO إن غيّرت الـ stack تغيير الـ tech-stack قرار DACI.
ملف AGENTS.md ووثائق الـ repo Team Lead للـ repo البند الخامس من الـ DoD — يُحدَّث في نفس الـ PR الذي غيّر السلوك.
اختبار متذبذب على main Team Lead للـ repo وليس «من يلاحظه».
الـ CI pipeline للـ repo Team Lead للـ repo القالب يأتي من توفير المشروع.
الشيء المالك ملاحظة
إبلاغ العميل بتأخر موعد PM ليس مطوّرًا أبدًا، ولا يُسمع أول مرة في demo.
الإجابة على سؤال تقني من العميل الـ PM يوجّه، والـ Team Lead يجيب الطلبات لا تذهب إلى الرسائل الخاصة للمطورين.
معايير القبول BA المطوّر الذي ينتظر كتابتها معطَّل، لا متعثّر.
تقرير أن شيئًا خارج النطاق PM الـ BA يرفع الإشارة، والـ PM يقرر، والـ CEO إن كان تجاريًا.
تغيير نطاق يزيد الكلفة الـ PM يقترح والـ CEO يعتمد يصبح change request لا خدمة مجانية.
محضر الاجتماع وقراراته من دعا إلى الاجتماع ما لم يُكتب لم يحدث.
الشيء المالك ملاحظة
بيانات اعتماد الإنتاج والأسرار CTO في Key Vault. لا في هذا الـ wiki ولا في الـ repo.
إنشاء مشروع Azure DevOps جديد Backend Lead ينفّذ قائمة التوفير.
منح صلاحية على repo أو بيئة Team Lead، بأقل امتياز الخطوة السابعة من التوفير.
حسابات الأطراف الثالثة المملوكة للعميل الـ PM يطلب، والعميل يملك لا نحتفظ ببيانات اعتماد مزوّدي العميل.
تسليم الكود وبيانات الاعتماد الـ PM يتأكد من الدفعة الأخيرة أولًا حدّ الـ Warranty.
الشيء المالك ملاحظة
درجة خطورة الـ bug QA Lead لا المبلِّغ ولا المطوّر الذي كتبه.
قرار الإصدار للإنتاج الـ PM و الـ QA Lead معًا البوابة المزدوجة المقصودة. DACI.
اعتبار bug «لن يُصلَح» الـ QA Lead مع الـ PM وما يراه العميل يمرّ عبر الـ PM.
صيانة حزمة الـ regression الـ QA Engineer يبنيها والـ QA Lead يعتمدها
الـ Definition of Done لـ story QA تتحقق والـ PM يقبل دورة التسليم.
الشيء المالك ملاحظة
الاستجابة الأولى لمشكلة إنتاج L1 Technical Support نموذج الدعم.
تحديد warranty أم billable الـ PM، عند الـ triage الـ L1 يرفع الإشارة ولا يقرّر.
مشكلة إنتاج خارج ساعات العمل لا أحد — لا نقدّم ذلك الـ SLA ضمن ساعات العمل، بلا مناوبة pager. لا تدعها تتحول إلى وعد ضمني.
كتابة الـ postmortem الـ Team Lead الذي ملك الإصلاح قالب الـ postmortem.
إرسال hotfix مباشرة إلى الإنتاج الـ Team Lead يقترح، والـ PM و QA Lead يعتمدان نفس البوابة المزدوجة لأي إصدار.

احسمه في حينه — الـ PM لكل ما يمسّ التسليم أو العميل، والـ CTO لكل ما هو تقني — ثم أضف الصف في نفس اليوم. الخلاف الذي يتكرر مرتين ولا يصبح صفًا هو تحديدًا ما وُجدت هذه الصفحة لمنعه.

👤 المسؤول: Wahid Bitar🗓 آخر مراجعة: 2026-07-26

Read this page in English