الصورة الكاملة (SDLC)

كل صفحة أخرى في هذا الـ wiki تُجيب سؤالاً واحداً بإتقان. وهذه الصفحة تُجيب السؤال الذي يخطر لك حين تفقد الخيط: أين أنا الآن، وما الذي يجب أن يتحقّق لأتقدّم، ومَن يقول نعم.

هذه الصفحة تملك شكل دورة الحياة — التسلسل والبوابات ومَن يقرّر. وهي لا تُعيد ذكر القواعد؛ كل مرحلة ترتبط بالصفحة التي تملكها، وإذا ظهر رقم أو حدّ هنا وفي مكان آخر، فالصفحة الأخرى هي التي تفوز.

المشروع من أوله إلى آخره

flowchart LR
  L["Lead / Sales"] --> D["Discovery & BA"]
  D --> E["Estimate & SOW"]
  E --> K["Kickoff"]
  K --> P["Provisioning"]
  P --> B{"Build<br/>2-week cadence"}
  B --> G["Handover / go-live"]
  G --> W["Warranty"]
  W --> S["Paid support"]
  S --> C["Closure"]
  C -.new scope.-> L

الـ Build هو المرحلة الوحيدة التي تدور — يعمل باستمرار على cadence ثابت مدّته أسبوعان حتى يُسلَّم النطاق. وكل ما قبله يحدث مرّة واحدة لكل ارتباط، إلا الـ Estimate والـ SOW فيُعاد الدخول إليهما مع كل طلب تغيير. أمّا الـ warranty والدعم المدفوع فليسا حدثين بل حالتان مفتوحتان تسريان من الـ go-live فصاعداً.

#	المرحلة	تعمل	المسؤول (Accountable)	الصفحة التي تملكها
0	Lead / المبيعات	مرة واحدة	CEO	حقوق اتخاذ القرار · بطاقات الأدوار
1	Discovery والـ BA	مرة واحدة	PM (والـ BA ينفّذ)	مخرجات الـ Discovery والـ BA
2	التقدير والـ SOW	مرة واحدة، ويُعاد مع كل طلب تغيير	CEO (والـ PM يقود)	التقدير · قالب الـ SOW
3	الـ Kickoff	مرة واحدة	PM	أجندة الـ Kickoff
4	التجهيز (Provisioning)	مرة لكل repo/ارتباط	Backend Lead	توفير مشروع جديد
5	الـ Build	باستمرار، على cadence مدّته أسبوعان	PM	دورة التسليم · اللوحات
6	الـ Handover / go-live	مرة واحدة	PM	حدّ الـ Warranty
7	الـ Warranty	نافذة ثابتة من الـ go-live	CEO (والـ PM يديرها)	حدّ الـ Warranty
8	الدعم المدفوع	مفتوح	CEO (وL1 أول استجابة)	نموذج الدعم
9	الإغلاق	مرة واحدة	PM	حدّ الـ Warranty

دور مسؤول واحد لكل مرحلة — وللـ R/A/C/I كاملاً انظر الـ RACI. وشيئان يجريان بالتوازي مع كل ما سبق: طلبات التغيير، وبعد الـ go-live الدعم والحوادث.

أربع قواعد تمسك التسلسل، وكلٌّ منها مملوكة في مكان آخر:

• نُقدّر قبل أن نوقّع، ونحدّد النطاق قبل أن نُقدّر. الـ Discovery ينتهي عند مخرج محدّد — backlog دقيق بما يكفي للتسعير — لا حين يتوقّف العميل عن الكلام. انظر معايير مخرج الـ Discovery.
• المبيعات تملك الـ lead ولا شيء غيره. ولا يصحّ أي التزام يسمعه العميل قبل أن يؤكّده الـ CEO. انظر بطاقات الأدوار.
• الـ Kickoff ليس اجتماعاً بل اختبار توافق. ينتهي حين تُكتب معايير خروجه، لا حين تنتهي الدعوة. انظر معايير مخرج الـ Kickoff.
• التجهيز قائمة تحقّق لا اجتهاد. نفس قالب الـ repo، ونفس الـ pipelines، ونفس الـ branch policies، ونفس البيئات الأربع، لكل عميل. والـ repo الذي ينقصه ملف من اليوم الأول ليس مُجهَّزاً. انظر توفير مشروع جديد.

الموبايل الـ native يُشحن بطريقة مختلفة. نفس اللوحة، ونفس بوابات الـ PR، ونفس المراجعات — لكن الـ build الموقّع يُروَّج عبر مسارات المتجر بدل dev/qa/uat/prod. ← الموبايل الـ native

ملاحظة

أربعة أمور يفهمها الناس بالمقلوب. الاختبار ليس مرحلة — يعمل على كل PR ويمنع الدمج. والمطوّرون يكتبون كل اختبار آلي في نفس الـ PR الذي يحمل التغيير؛ والـ QA تملك الاستكشافي والـ regression اليدوي. والمعمارية تُقرَّر أثناء البناء — الـ ADR يُدمج في الـ PR الذي ينفّذه، لا في مرحلة تصميم قبله. والـ artifact يُبنى مرة واحدة ويُروَّج؛ وإعادة البناء لكل بيئة تعني أن أحداً لم يختبر ما شُحن.

ما بعد الـ go-live

العمل بعد الـ go-live ليس عملية منفصلة. يدخل نفس اللوحة — الـ bugs وتذاكر الدعم عبر مسار الـ expedite، وطلبات التغيير عبر الـ backlog المعتاد — ويمرّ بـنفس الـ branch policies وبوابات الـ PR. واستثناء واحد لسلّم البيئات، واحد فقط: يمكن لـ branch من نوع hotfix/<id> أن يذهب مباشرة إلى prod، تحت نفس موافقة المفتاحين كأي إصدار. ولا يسلك أحد ذلك المسار وحده، وهو ليس تجاوزاً للبوابات — انظر الـ Pipelines والبيئات ومن يملك ماذا.

• سؤال الـ triage يُطرح مرّة واحدة عند الاستقبال: هل هذا عيب عندنا أم نطاق جديد؟ L1 يشير، والـ PM يقرّر. والخطأ فيه يكلّف إمّا الثقة وإمّا الهامش. انظر حدّ الـ Warranty.
• الدعم متدرّج وضمن ساعات العمل. L1 ← L2 ← المطوّر الأصلي. لا توجد pager rotation، ولا نسمح بأن تتحوّل إلى وعد ضمني. انظر نموذج الدعم.
• للحوادث قناة واحدة وصوت واحد تجاه العميل. انظر الاستجابة للحوادث وقالب الـ Postmortem.
• الـ bug في الإنتاج يأخذ اختباراً فاشلاً قبل أن يأخذ إصلاحاً. انظر استراتيجية الاختبار.

كل البوابات، بالترتيب

مُطبَّقة (Enforced) تعني أن أداة ترفض المتابعة. وموافقة (Approval) تعني أن شخصاً بعينه يجب أن يقول نعم. ومعيار (Standard) يعني أن البوابة مكتوبة ومتوقّعة لكن لا شيء يمنعك — ولهذا بالذات يكون تجاوزها مرئياً.

وهذا الجدول هو الفهرس الوحيد في هذه الصفحة. حلّ محلّ ثلاثة فهارس متداخلة، لأن القارئ الذي عليه التوفيق بين ثلاث قوائم لا يثق بأيّ منها.

البوابة	النوع	الصفحة المالكة
قبول المشروع	موافقة — CEO	حقوق اتخاذ القرار
مخرج الـ Discovery — الـ backlog قابل للتقدير	معيار	الاكتشاف
اعتماد التقدير من قائد الاختصاص المالك	موافقة — قائد الاختصاص	التقدير
اعتماد السعر	موافقة — CEO	التقدير
توقيع الـ SOW، بعرض سعر كمدى	موافقة — العميل	قالب الـ SOW
مخرج الـ Kickoff — النطاق والأدوار والجدول والتواصل	معيار	الـ Kickoff
الـ repo مُجهَّز — ملفات اليوم الأول والسياسات والبيئات الأربع	معيار قابل للتحقّق في دقيقة	توفير مشروع جديد
Definition of Ready — الدخول إلى الـ board	معيار — مرئي على الـ board	دورة التسليم
حدّ الـ WIP لكل عمود	معيار — مرئي على الـ board	اللوحات
الـ PR مرتبط بعنصر عمل، ومن النوع الصحيح	مُطبَّقة — branch policy والـ build	اللوحات
الـ Build validation — قائمة البوابات المانعة	مُطبَّقة — branch policy على main	الـ Pipelines والبيئات
مسارات الاختبار وبوابة الـ diff coverage	مُطبَّقة — نفس الـ branch policy	استراتيجية الاختبار
موافقة المراجِع، ومنع الموافقة الذاتية	مُطبَّقة — branch policy	الـ Branches والـ PRs
الـ QA مقابل معايير القبول	موافقة — QA	دورة التسليم
توقيع العميل في الـ UAT	موافقة — العميل / PM	دورة التسليم
Definition of Done — يحكم الوصول إلى Done	معيار — مرئي على الـ board	دورة التسليم
الترويج إلى uat ثم prod	موافقة — فحص بيئة في الـ pipeline	الـ Pipelines والبيئات
الـ go / no-go إلى الإنتاج	موافقة — بمفتاحين	حقوق اتخاذ القرار
الـ hotfix مباشرة إلى prod	موافقة — نفس المفتاحين	من يملك ماذا
تطبيق الـ migration على uat / prod	آلية مُطبَّقة + خطوة بشرية مقصودة	الـ Pipelines والبيئات
طلب التغيير — موافقة العميل كتابةً قبل بدء العمل، والـ CEO أولاً إذا غيّر التكلفة	موافقة	طلبات التغيير
الـ Handover	موافقة — الـ PM يؤكّد	حدّ الـ Warranty

حين لا تعرف مَن يقرّر

تُحسَم الملكية على ثلاثة مستويات، ومعظم الخلافات تحدث لأن أحدهم مدّ يده إلى المستوى الخطأ.

اسأل هذا أولاً	إذا كان الجواب نعم، اقرأ
هل هي مسؤولية دوري الثابتة؟	بطاقات الأدوار — ثم قرّرها بنفسك
هل هي واحدة من القرارات المتكرّرة العابرة للحدود؟	حقوق اتخاذ القرار (DACI)
أي شيء آخر	من يملك ماذا — وإذا لم تكن مذكورة، فالـ PM لكل ما يخصّ التسليم أو العميل، والـ CTO لكل ما هو تقني، ثم أضِف الصفّ

ما لا تملكه هذه الصفحة

لا شيء في هذه الصفحة يُعدّ حدّاً أو سقفاً أو رقماً تنقله من هنا. الـ Definition of Ready والـ Definition of Done، وحدود الـ WIP، وحجم الـ PR، وعدد المراجعين، وبوابات الـ coverage، ومعتمِدو البيئات، ومدّة الـ warranty، ومستويات الـ Severity، وشروط الدفع — كلها تعيش في الصفحات المرتبطة أعلاه، وتلك الصفحات هي التي تفوز. وإذا تعارضت هذه الصفحة مع صفحة مالكة، فهذه الصفحة هي الخطأ: أصلحها بـ PR.