الأدوار والقرارات

الغاية من هذا القسم إنهاء غموض الملكية في فريق من ١٨ شخصًا. لكل دور بطاقة تحدّد ما يملكه، وما لا يملكه، ولمن يسلّم. انظر الهيكل التنظيمي لبنية التبعية الإدارية.

الصفحات الخمس، والسؤال الذي تجيب عنه كل واحدة

إذا كنت تسأل…	اقرأ
«عمّ أُساءل؟»	بطاقات الأدوار
«كيف يبدو يومي فعليًا؟»	الحلقة اليومية
«هل ما أقدّمه كافٍ عند مستواي؟»	التوقعات حسب المستوى
«من يملك هذا الشيء تحديدًا؟»	من يملك ماذا
«من يقول الكلمة الأخيرة؟»	حقوق اتخاذ القرار (DACI)

اقرأها بهذا الترتيب أول مرة. وبعدها، الصفحة الوحيدة المقصود البحث فيها لا قراءتها هي من يملك ماذا.

جدول RACI عبر دورة التسليم

R = ينفّذ العمل · A = مُساءل (واحد لكل صف) · C = يُستشار · I = يُبلَّغ

المرحلة	CEO	CTO	PM	BA	Team Lead	Dev	QA	L1	العميل
Discovery	I	C	A	R	C	I	I	I	C
Estimate & SOW	A	C	R	C	C	I	I	I	C
Build	I	C	A	C	R	R	C	I	I
QA & UAT	I	I	A	C	C	C	R	I	C
Handover	I	C	A	C	R	I	C	C	C
Warranty & support	A	C	C	I	R	R	C	R	C

الـ CTO مُستشار (Consulted) لا مسؤول (Accountable) في كل مراحل التسليم: فالمسؤولية التقنية تجري عبر حقوق اتخاذ القرار ومن يملك ماذا، لا عبر هذا الجدول. وL1 ينفّذ العمل في الـ warranty والدعم ويُبلَّغ فيما عداهما. أمّا العميل فيُستشار حيث يغيّر رأيه النتيجة، ويُبلَّغ حيث لا يغيّرها — ولا يكون مسؤولاً أبداً عن مرحلة نُديرها نحن.

ملاحظة

يبقى الـ PM مُساءلًا عن التسليم حتى حين يتأخر العميل في إعطاء ملاحظاته — فمتابعة ذلك جزء من عمل الـ PM، وليست عذرًا لتوقّف العمل.

كيف تتراكب الطبقات

تُجاب أسئلة الملكية على واحدة من ثلاث طبقات. وقصد الطبقة الخطأ هو ما يحوّل سؤالًا صغيرًا إلى جدال.

flowchart TD
  RC["Role Cards<br/>standing accountability"] --> WOW["Who Owns What<br/>the gray-zone artifacts"]
  WOW --> DR["Decision Rights<br/>the six recurring calls"]
  RC -.- L["The Daily Loop<br/>how the work actually flows"]
  RC -.- EL["Expectations by Level<br/>what good looks like"]

نصيحة

إذا وقع خلاف على شيء غير مذكور في أي من هذه الصفحات، فاحسمه في حينه — الـ PM لما يخصّ التسليم والعميل، والـ CTO لما هو تقني — ثم أضف الصف إلى من يملك ماذا في نفس اليوم.