التقدير وتحديد النطاق

نُقدِّر بـ نطاقات، لا برقم واحد أبدًا. الرقم الواحد وعدٌ لا نقدر على الوفاء به؛ أما النطاق فصادق حيال عدم اليقين ويمنح العميل مع ذلك ما يخطّط عليه.

مسار الـ three-point / PERT

flowchart LR
  I["Backlog item"] --> O["Optimistic (O)"]
  I --> M["Most likely (M)"]
  I --> P["Pessimistic (P)"]
  O --> E["Expected = (O + 4M + P) / 6"]
  M --> E
  P --> E
  E --> R["Quote a RANGE<br/>with confidence"]

كيف نُحجِّم

• التحجيم المبكّر ← T-shirt sizes (S / M / L / XL). سريع، وكافٍ لتشكيل عرض أو مقارنة خيارات قبل تنقيح الـ backlog.
• backlog مُنقَّح ← three-point / PERT لكل عنصر. المُقدِّر يُعطي Optimistic و Most Likely و Pessimistic؛ والقيمة المتوقّعة هي (O + 4M + P) / 6، والنطاق المُقدَّم يعكس التشتّت.
• اجمع، ولا تُحسِب المتوسّط بشكل أعمى. اجمع القيم المتوقّعة؛ ووسِّع النطاق حيث تتجمّع مخاطر الـ risk register.

التبطين للمجاهيل

التبطين صريح ومُسمّى، لا مخفيًّا داخل التقديرات:

• التكامل مع نظام خارجي/طرف ثالث لا نتحكّم به.
• أصول أو صلاحيات أو محتوى من العميل على المسار الحرج.
• تقنية جديدة لم يُسلِّمها الفريق من قبل.

نصيحة

بطِّن النطاق، لا النقطة. المجاهيل توسّع الطرف المتشائم — لا تُضخّم سرًّا “الأكثر ترجيحًا”.

Fixed-price مقابل T&M

النموذج	يُستخدم حين	المخاطرة على
Fixed-price	النطاق مُحدَّد ومستقر (MoSCoW ضيّق، acceptance criteria واضحة).	علينا — لذا يهمّ ضبط النطاق وبند الـ change-request.
Time & Materials	النطاق استكشافي أو متطوّر أو مقاد بالاكتشاف.	على العميل — نُفوتر الجهد الفعلي مقابل تقدير بنطاق.

الافتراضي: fixed-price لنطاق محدود، و T&M لأي شيء استكشافي. والمزيج (fixed لنطاق الـ Must، و T&M لعناصر الـ Could) شائع.

الاعتماد

ثلاثة أدوار، وثلاث مهام مختلفة. وهي غير متبادلة، ولا يستطيع أحدها أداء دور الآخر منفردًا:

مَن	يملك	المعنى
كل قائد اختصاص — backend، frontend، mobile، QA	أرقام عمله هو	يعتمد القائد تقدير الـ stack الذي يقوده. ولا يقدّر أحد عمل اختصاص آخر بالنيابة.
الـ PM	دمج الأجزاء في مدى واحد، والتأطير التجاري	النموذج والنطاق والتبطين كما يُقدَّم للعميل. والـ PM لا يغيّر رقم قائد — بل يجمع الأرقام.
الـ CEO	اعتماد السعر	الرقم الذي يُقتبَس للعميل التزام تجاري، وهو للـ CEO. وهي نفس الموافقة المذكورة في sdlc.md عند «قبول المشروع».

استثناءان، كلاهما للـ CTO، وكلاهما مكتوب لا متروك كعادة:

1. تحت ضغط الوقت يجوز للـ CTO أن يضع التقدير التقريبي مباشرةً، بدل انتظار كل قائد اختصاص. وهذا مخرج الطوارئ لا الوضع الافتراضي — استخدمه للإجابة السريعة، ثم يؤكّد القائد المعني الرقم أو يصحّحه قبل وصوله إلى SOW.
2. ويجوز للـ CTO أن يعترض على تقدير أي قائد — بما في ذلك حين يضغط الـ PM أو الـ CEO باتجاه رقم مختلف. وهذا هو النصف الأهم. فالتقدير الذي يتحرّك بسبب ضغط تجاري لا بسبب معلومة جديدة لم يعد تقديرًا، والـ CTO هو من يستطيع قول ذلك.

ولا يجعل أيٌّ من الاستثناءين الـ CTO مُقدِّرًا افتراضيًا. فالأرقام يملكها القادة.

• التقديرات تُغذّي الـ SOW؛ ولا يخرج SOW بتقدير من رقم واحد.