الـ sign-off: التعميم، والنزاع، والوثيقة التي وافق عليها الجميع فعلًا

لدى فريقك بالفعل الـ playbook الخاص بـ requirements-to-signoff — الوصفة المُجرَّبة لصياغة الوثيقة، وبناء جدول متابعة للتعميم، وإرسالها، وتسجيل الردود، وحلّ النزاعات، وقفل نسخة موقَّعة. هذه الوحدة هي الطبقة الأعلى من الوصفة. هنا تُتقِن الحكم الذي يجعل الـ sign-off حقيقيًا لا مسرحيًا — التسلسل الذي يُبقي التعميم متحرّكًا دون أن يتحوّل إلى حملة إلحاح، والانضباط في استخراج خلاف حقيقي وتصعيده إلى صاحب القرار بدل حسمه بنفسك بصمت، والفرق بين وثيقة تبدو منتهية ووثيقة وافق عليها فعلًا كل صاحب مصلحة مُسمّى.

هذه هي الوحدة الرابعة من مسار محلل الأعمال المعتمد، وهي ترث كل ما سبقها: خريطة أصحاب المصلحة التي تخبرك مَن عليه أن يوقّع، ووثيقة المتطلبات التي هي الأثر الخاضع للحوكمة. كل وحدة سابقة أنتجت وثيقة. هذه الوحدة هي حيث تتحوّل الوثيقة إلى قرار — القرار الذي يُسمَح بموجبه لفريق الهندسة بالبدء في البناء.

لماذا الـ sign-off هي حيث يصمد الضمان أو ينكسر بصمت

كل مرحلة سابقة من عملية محلل الأعمال — خريطة أصحاب المصلحة، ووثيقة المتطلبات، وتحليل الفجوات والخيارات، وحالة العمل التجارية — تُنتج أثرًا يبدو موثوقًا على الورق. لا شيء من ذلك يهمّ إن لم يُوافَق على الأثر فعلًا. معظم إخفاقات المتطلبات التي يُلقى باللوم فيها على “توثيق سيّئ” ليست مشكلة توثيق على الإطلاق. إنها مشكلة sign-off: وثيقة خرجت للمراجعة، ردّ بعض الناس وصمت آخرون، وصل الموعد النهائي، وبدأ البناء على وثيقة لم يُنهِ أحد الاتفاق عليها فعلًا.

هذه هي اللحظة التي يصمد فيها ضمان التتبّع أو ينكسر بصمت، لأنها النقطة الوحيدة في العملية كلها التي تتوقّف فيها الوثيقة عن كونها مسوّدة وتصبح التزامًا. المتطلب الذي يتتبّع إلى صاحب مصلحة مُسمّى في الوثيقة لكنه لم يحصل قط على موافقة صريحة ومؤرَّخة من ذلك الشخص ليس موقَّعًا — إنه مُنسَّق جيدًا فقط. الفجوة بين “يبدو متّفقًا عليه” و”متّفق عليه فعلًا” غير مرئية على الورق وهائلة في النتيجة: إنها الفرق بين ميزة يبنيها فريق الهندسة مرة واحدة، وميزة يعيد بناءها بعد ثلاثة أسابيع لأن فريق الدعم يُصرّ أنه لم يوافق قط على إسقاط فحص الاحتيال.

خط أنابيب sign-off يبلغ هذا المعيار يُنتج شيئًا واحدًا يهمّ أكثر من الوثيقة نفسها: سجلًّا يقول، لكل متطلب، أيّ شخص مُسمّى وافق عليه، ومتى، وبأي نسخة. كل شيء آخر في هذه الوحدة — التعميم، والمتابعة، وحلّ النزاعات — موجود ليجعل هذا السجل حقيقيًا لا مفترَضًا.

تشغيل التعميم دون فقدان الزخم

الـ playbook يعطيك الآلية: ابنِ جدول المتابعة، أرسل الوثيقة، سجّل الردود مع وصولها. الإتقان هو حكم التسلسل والوتيرة الذي يمنع مراجعة متعددة أصحاب المصلحة من التوقّف بإحدى الطريقتين الأكثر شيوعًا: الصمت، وإرهاق الردّ من المتابعة الشديدة والمبكرة جدًا.

• عمّم للسلطة أولًا، وللسياق ثانيًا. أرسل إلى أصحاب المصلحة الذين يملكون سلطة sign-off النهائية على المتطلبات ذات الأولوية الأعلى (“must”) قبل أن ترسل إلى المجموعة الاستشارية الأوسع. إن كان صانع القرار على المتطلب الأكثر احتمالًا للجدل سيحتاج أسبوعين واجتماع متابعة، تريد أن تعرف ذلك في اليوم الأول، لا قبل يوم من الموعد النهائي حين يكون الجميع قد ردّوا بالفعل.
• صمّم ما يراه كل صاحب مصلحة، لا فقط مَن يستلم البريد. صاحب مصلحة يراجع 3 من أصل 40 متطلبًا يجب أن يرى رسالة تقتصر على تلك الثلاثة، لا الوثيقة الكاملة بأربعين صفًا مع تعليمة “تحقّق من التي تخصّك”. طلب أقصر ومحدَّد النطاق يحصل على ردّ أسرع وأكثر عناية — إرسال الوثيقة كاملة للجميع هو ما يجعل المراجعة تبدو كواجب منزلي، والواجب المنزلي يُؤجَّل.
• تابع بوتيرة ثابتة، لا بحسب شعورك الغريزي بأن الوقت طال. ثلاثة أيام عمل من الصمت تستحق بالضبط متابعة واحدة قصيرة ومحدَّدة — لا نكزًا غامضًا، ولا “أردت فقط الاطمئنان” اعتذاريًا، بل تذكيرًا بما يُطلَب وبموعده. وتيرة تلتزم بها باستمرار تُقرأ كإجراء منهجي؛ أما متابعة تحدث فقط حين تتذكّرها فتُقرأ كإلحاح، والإلحاح غير المنتظم هو ما يُتلف العلاقة فعلًا.
• صاحب مصلحة يتباطأ تحديدًا في متطلب معيّن يخبرك بشيء. إن صمت أحدهم تحديدًا حول المتطلب 12 بينما يردّ بسرعة على كل شيء آخر، فهذا ليس بطئًا عشوائيًا — إنه غالبًا نزاع خفي لم يُصرَّح به بعد. تعامل مع التأخّر الانتقائي كإشارة لتطرح سؤالًا مباشرًا حول ذلك المتطلب تحديدًا، لا مجرّد جولة أخرى من رسالة المتابعة العامة.
• تتبّع “أُرسِلت” و”رُوجِعت” كحالتين مختلفتين، عمدًا. صاحب مصلحة فتح الوثيقة ولم يردّ بعد في حالة مختلفة عن مَن لم تُرسَل له الوثيقة أصلًا، وكلاهما مختلف عن مَن ردّ بـ sign-off حقيقي. دمج هذه في سلّة واحدة اسمها “بانتظار” هو بالضبط كيف يُحسَب بند لا يزال مفتوحًا كأنه أُنجِز حين تُقفَل الجولة.

جولة تعميم تبلغ هذا المعيار تُنتج جدول متابعة تكون فيه حالة كل صاحب مصلحة محدَّثة ومحدَّدة — لا “بانتظار”، بل “أُرسِلت الثلاثاء، تُوبِعت الجمعة، اجتماع محجوز الاثنين” — يستطيع فيه محلل الأعمال، في أي لحظة خلال المهلة، أن يقول بالضبط مَن عليه ردّ وما الذي فُعِل بالفعل للحصول عليه.

حلّ ملاحظات أصحاب المصلحة المتعارضة

تعليمة الـ playbook مباشرة: لا تحسِم بالمتوسط بين إجابتين، صعّد إلى صانع القرار المُسمّى. الإتقان هو الانضباط الفعلي على تطبيق ذلك في كل مرة، خصوصًا حين يكون الأسهل بكثير أن تختار الجانب الذي يبدو أكثر منطقية بنفسك وتمضي قدمًا.

• النزاع حقيقة تُستخرَج، لا مشكلة تُحَل. مهمة محلل الأعمال حين يريد صاحبا مصلحة شيئين مختلفين حول المتطلب نفسه هي عرض الموقفين بوضوح وتسليم القرار لمَن تنصّ خريطة أصحاب المصلحة أنه صاحب السلطة النهائية على ذلك المتطلب — لا تدوين النسخة التي تبدو أكثر منطقية بصمت. في اللحظة التي يحسم فيها محلل الأعمال نزاعًا بحكمه الشخصي بدل التصعيد، ينكسر التتبّع: تقول الوثيقة الآن شيئًا لم يقرّره أي شخص مسؤول فعليًا.
• تقسيم الفرق فشل قائم بذاته، مختلف عن اختيار جانب. “اشحن نسخة خفيفة من كلا الأمرين” قد يبدو دبلوماسية، لكن إن لم يطلب أيّ من الطرفين النسخة الخفيفة فعلًا، فهو خيار ثالث لم يوافق عليه أحد، اختُرِع خصيصًا لتجنّب حرج إجبار أحدهم على الاختيار. الحل الوسط صحيح فقط إن اختاره صانع القرار كحل — لا إن كان تخمين محلل الأعمال لما قد يُرضي الطرفين.
• اعرض لماذا يريد كل طرف ما يريده، لا فقط ماذا يريد. “فريق الهندسة يريد X، وفريق الدعم يريد Y” مشكلة جدولة. أما “فريق الهندسة يريد تحجيم جزء الحماية من الاحتيال لأن قواعد مكافحة الاحتيال تحتاج بيانات إنتاج حقيقية لضبطها بأمان، وشحن نسخة غير مضبوطة في الأسبوع الأول يخاطر بإيجابيات كاذبة تحجب عن عملاء شرعيين استردادًا يستحقونه؛ وفريق الدعم يريدها فعّالة من اليوم الأول لأن كل يوم بدونها يوم يمكن أن يتكرّر فيه نمط الاستغلال نفسه الذي سبّب الحادثة الأصلية” فهذا قرار يستطيع شخص أن يتّخذه جيدًا فعلًا. المنطق وراء كل موقف هو ما يحوّل سؤال التصعيد من شيء قابل للإجابة في جلسة واحدة إلى أخذ ورد يُطيل الجولة كلها.
• صانع القرار مُسمّى بموجب خريطة أصحاب المصلحة، لا بموجب الأقدمية أو مَن يصرخ أعلى. في بعض المتطلبات يقع القرار النهائي عند رئيس الوظيفة؛ وفي المتطلبات العابرة للوظائف — كنزاع يمسّ مخاطر بناء فريق الهندسة ومخاطر حوادث فريق الدعم معًا — قد يحتاج التصعيد للأعلى إلى مَن يملك المبادرة ككل. تحقّق من الخريطة قبل الافتراض؛ التخمين الخاطئ يعني إعادة التصعيد كله لاحقًا مع المالك الفعلي.
• يُسجَّل الحل مقابل المتطلب، في وثيقة المتطلبات نفسها — لا في اجتماع لم يدوّنه أحد. قرار يعيش فقط في ذاكرة أحدهم عن مكالمة هو قرار سيُعاد الجدال فيه في المرة القادمة التي يقرأ فيها أحدهم الوثيقة ببرود. تتغيّر صياغة الوثيقة لتعكس بالضبط ما تقرَّر، ويجب أن يكون سجل sign-off لذلك المتطلب قابلًا للتتبّع إلى الحل، لا مجرد “موقَّع” عام.

جولة حلّ نزاع تبلغ هذا المعيار تُنتج ملخّصًا واضحًا لكلا الموقفين، وصانع قرار مُسمّى بوضوح (لا محلل الأعمال، إلا إذا نصّت الخريطة فعلًا أن هذا القرار من صلاحيته)، وقرارًا موثَّقًا بالمنطق الفعلي وراءه، ومتطلبًا محدَّثًا تعكس صياغته القرار بدل تمويه دبلوماسي للطلبين الأصليين.

ماذا تعني “موقَّع عليه” فعليًا، على المستوى العملي

الـ playbook صريح في أن الصمت لا يتحوّل أبدًا إلى موافقة. الإتقان هو الثبات على هذا الخط تحت ضغط جدول زمني حقيقي، حين يكون الأسهل بكثير معاملة ثلاثة ردود من أربعة على أنها “منتهية تقريبًا”.

• الـ sign-off اسم وتاريخ ونسخة — لا انطباعًا عامًا. “بدت بريّا موافقة في الاجتماع” ليست sign-off. “بريّا شارما، وقّعت على requirements-doc-signed-v1.md، بتاريخ 2026-07-14” هي كذلك. إن لم تستطع ملء الحقول الثلاثة لمتطلب ما، فهو غير موقَّع بعد، مهما بدت الغرفة واثقة.
• الموافقة الشفهية لا تزال تحتاج سجلًّا مكتوبًا. صاحب مصلحة قال نعم في مكالمة أو حديث ممرّ قدّم معلومة مفيدة، لكن قيد سجل الـ sign-off لا يوجد إلا حين تُدوَّن تلك الموافقة كتابيًا — حتى لو كان ذلك مجرد صياغة Claude لرسالة تأكيد من سطر واحد يردّ عليها صاحب المصلحة بـ”مؤكَّد”. الفكرة ليست بيروقراطية لذاتها؛ بل أن الموافقة الشفهية بلا أثر مكتوب لا تُميَّز، بعد ستة أشهر، عن موافقة لم تُعطَ قط.
• الـ sign-off الجزئي ليس sign-off، ولا تُقفَل الجولة حتى تستطيع تسمية الناقص بدقّة. وثيقة بها 38 من أصل 40 متطلبًا موقَّعًا ليست “مُقفلة تقريبًا” — إنها وثيقة ببندين مفتوحين صراحةً، وهذان البندان يُذكَران في أسفل النسخة المُقفلة، لا يُدفَنان أو يُفترَض أنهما بخير. جولة تنتهي بـ”قريبة بما يكفي” بدل فحص اكتمال حقيقي هي بالضبط الفجوة التي تظهر لاحقًا كميزة يُعاد بناؤها.
• النسخة تهمّ بقدر الاسم والتاريخ. صاحب مصلحة وقّع على v1 لم يوقّع على v3، حتى لو غيّرت v3 فقرة واحدة فقط لم يكن يراجعها. أي تغيير جوهري بعد التوقيع يُبطل ذلك التوقيع للمتطلب المتغيّر تحديدًا ويعيد فتحه لذلك الشخص تحديدًا — يجب أن يعكس السجل أيّ نسخة وافق عليها كل اسم فعلًا، لا فقط أنه وافق في وقت ما.
• الوثيقة المُقفلة هي النسخة المرجعية، وتقول ذلك في سطرها الأول. “مُقفلة للبناء” في أعلى الملف، وسجل sign-off بكل اسم مطلوب مرفَق، وأي بنود مفتوحة مذكورة صراحةً — هذا المزيج هو ما يسمح لفريق الهندسة بالبدء بثقة بدل افتراض أمل بأن الجميع في الأعلى متّفقون فعلًا.

مهمتك

شغّل دورة كاملة من تعميم → حلّ نزاع → sign-off لـ مبادرة حقيقية واحدة — مبادرتك الخاصة (يُنصَح بها: تصبح هذه الإشارة الفعلية التي يبني عليها فريقك) أو العلامة النموذجية Mizan، شركة الحلول المحاسبية الخليجية التي تدير فيها محللة الأعمال نور السويدي هذا المسار بأكمله. افتح وثيقة المتطلبات، وخريطة أصحاب المصلحة، وأي تحليل فجوات أو خيارات سابق في Claude Desktop واعمل في المحادثة — لا حاجة إلى Terminal.

مخرجات الوحدة الرابعة — خط أنابيب sign-off

ترث من الوحدات السابقة: stakeholder-map.md، requirements-doc.md
(+ أي gap-analysis / options-analysis / business-case سبق أن حدّد النطاق)

1. circulation-tracker.md
   - صف واحد لكل صاحب مصلحة: النطاق، الحالة، مستوى الصلاحية،
     تاريخ آخر تواصل
   - جولة كاملة واحدة على الأقل من "not sent -> sent -> reviewed"
     لكل صاحب مصلحة مُسمّى

2. نزاع مسجَّل حقيقي
   - كلا الموقفين معروضان بوضوح، مع المنطق وراء كل منهما
   - صانع القرار المُسمّى بموجب خريطة أصحاب المصلحة (لا محلل الأعمال،
     إلا إذا نصّت الخريطة أن هذا القرار من صلاحيته)
   - سؤال التصعيد المُرسَل فعلًا، والقرار الذي عاد، بمنطقه

3. requirements-doc-signed-v1.md
   - "locked for build" مذكورة في الأعلى
   - سجل sign-off: كل متطلب، صاحب مصلحته، تاريخ التوقيع،
     والنسخة الموقَّع عليها
   - أي متطلب بلا sign-off كامل مذكور صراحةً كبند مفتوح معروف،
     لا محذوفًا بصمت

الخصوصية: احذف الأسماء/الأدوار التي لا تملك إذنًا بمشاركتها قبل أي
prompt إن كنت تستخدم مبادرة عمل حقيقية؛ عيّنة Mizan آمنة للاستخدام كما هي.

كيف تُقيَّم — معيار التقييم

هذا هو الجزء الذي لا يقيّمك عليه الـ playbook المجاني، والجزء الذي يجعل الاعتماد يعني شيئًا. تُقيَّم مخرجاتك وفق خمسة معايير. كل واحد meets / nearly / not yet، و”nearly” في أيّ منها يعني مراجعة، لا اجتيازًا.

معيار تقييم خط أنابيب sign-off

1. كل صاحب مصلحة ردّ صراحةً
   كل اسم في جدول المتابعة ينتهي الجولة بـ"signed off"، أو
   "signed off with a change"، أو "not responded" — لا يُفترَض من
   الصمت أبدًا، ولا يُستنتَج من اجتماع لم يدوّنه أحد.

2. النزاع حُسم بصانع قرار مُسمّى
   خلاف حقيقي عُرِض بوضوح (لم يُموَّه، ولم يُقسَّم بالمتوسط) وسُلِّم
   لمَن تُسمّيه خريطة أصحاب المصلحة كسلطة على ذلك المتطلب — لا
   محسومًا بصمت من محلل الأعمال.

3. القرار يحمل منطقًا حقيقيًا لا مجرد حكم
   التصعيد وردّه يُظهران لماذا أراد كل طرف ما أراده ولماذا اختار
   صانع القرار ما اختاره — "اخترنا نطاق فريق الهندسة" وحدها لا
   تبلغ هذا المعيار.

4. سجل sign-off حقيقي: اسم، تاريخ، نسخة
   كل متطلب موقَّع يتتبّع إلى شخص محدَّد، وتاريخ محدَّد، والنسخة
   المحدَّدة من الوثيقة التي وقّع عليها.

5. البنود المفتوحة مذكورة، لا مدفونة
   أي شيء لم يُوقَّع عليه بالكامل بحلول نهاية الجولة يظهر صراحةً في
   أسفل الوثيقة المُقفلة — لا يُفترَض أنه بخير أبدًا، ولا يُسقَط من
   العدّ بصمت.

الانضباط هنا هو ما سيطالب به مسؤول هندسة متشكّك قبل الالتزام بـ sprint: وثيقة تدّعي sign-off كاملًا لكنها لا تستطيع إنتاج اسم وتاريخ لمتطلب واحد تفشل بصمت — عادةً في الأسبوع الذي يبدأ فيه البناء، حين يقول أحدهم “لحظة، مَن وافق على هذا فعلًا؟” — لذا يجب اكتشافها هنا، قبل أن يفتح فريق الهندسة الملف أبدًا.

المعيار، مُجسَّدًا — نموذج إجابة مُتقَنة (Mizan)

لست مضطرًا لتخمين شكل “meets”. إليك مقتطف ناجح للعلامة النموذجية — عملك الخاص لا يحتاج أن يبدو هكذا، بل أن يبلغ المعيار نفسه. محللة الأعمال نور السويدي تدير sign-off لميزة “الاعتراض على رسوم” الذاتية الخدمة، بتكليف من المؤسِّسة المشاركة دانة القاسمي بعد حادثة الفوترة المزدوجة في 1 مارس 2026، مع متطلبات تمسّ فريق الدعم، والمالية، والبيانات، والهندسة.

circulation-tracker.md — متطلبات "الاعتراض على رسوم" في Mizan (مقتطف)

صاحب المصلحة          النطاق (أرقام المتطلبات)  الصلاحية        الحالة
--------------------------------------------------------------------
ليلى الناصر           1-6, 14-16        نهائية (الدعم)  Signed off (v1, Jul 8)
(قائدة تجربة العملاء، الدعم)

يوسف حمدان             7-11              نهائية (المالية) Signed off (v1, Jul 9)
(محلل مالي)

مايا حداد               1-3, 12-13        استشارية (البيانات) Reviewed, no
(محللة أعمال، البيانات)                                        objection (Jul 8)

بلال المنصوري          1-16, جميع        نهائية           CONFLICT في
(الهندسة)              (جدوى الهندسة)                     المتطلب 9 -- انظر
                                                            أدناه (الباقي
                                                            موقَّع v1, Jul 10)

دانة القاسمي            الكل (تصعيد     نهائية (مالكة       القرار صدر
(مؤسِّسة مشاركة)         فقط)             المبادرة)           بشأن المتطلب 9
                                                             في Jul 11

نزاع مسجَّل -- المتطلب 9، "الاعتراض على رسوم" في Mizan (مقتطف)

المتطلب 9: "يُشغِّل تدفّق الاعتراض فحص حماية من الاحتيال تلقائيًا قبل
إصدار أي استرداد، ويوقف تحرير الاسترداد حتى يجتاز الفحص."

موقف فريق الدعم (ليلى الناصر): اشحن فحص الاحتيال في v1 من اليوم الأول.
المنطق: حادثة 1 مارس أظهرت بالفعل أن العملاء سيختبرون مسار استرداد
ذاتي الخدمة بحثًا عن ثغرة استغلال بمجرد وجوده: كل يوم يشحَن فيه
التدفّق بلا فحص احتيال هو يوم يمكن أن يتكرّر فيه النمط نفسه الذي
سبّب الحادثة الأصلية، وفريق الدعم هو مَن سيتعامل مع التبعات مجددًا.

موقف الهندسة (بلال المنصوري): استبعد فحص الاحتيال من v1؛ اشحن تدفّق
الاعتراض والمراجعة أولًا، وأضف الحماية التلقائية من الاحتيال في v1.1.
المنطق: قواعد الاحتيال تحتاج بيانات نزاعات إنتاج حقيقية لضبط عتباتها
بأمان -- فحص غير مضبوط في اليوم الأول يخاطر بإيجابيات كاذبة تحجب عن
عملاء شرعيين استردادًا يستحقونه، وهو ضرر ثقة مختلف من النوع نفسه من
الحادثة نفسها.

صانع القرار المُسمّى بموجب stakeholder-map.md: دانة القاسمي تملك
صلاحية نزاعات النطاق العابرة للوظائف في هذه المبادرة -- لا ليلى ولا
بلال يملك صلاحية على وظيفة الآخر هنا.

سؤال التصعيد المُرسَل لدانة: "فريق الدعم والهندسة يختلفان حول ما إذا
كانت v1 تشحن مع حماية تلقائية من الاحتيال أو خطوة مراجعة يدوية بدلًا
منها، مع تفعيل الأتمتة لاحقًا في v1.1. حجّة فريق الدعم مخاطر تكرار
الحادثة؛ حجّة الهندسة مخاطر الإيجابيات الكاذبة من نموذج غير مضبوط.
أيّهما نشحن لـ v1؟"

القرار (دانة القاسمي، Jul 11): اشحن v1 بخطوة مراجعة يدوية لأي استرداد
يتجاوز 150 درهمًا، لا حماية تلقائية من الاحتيال -- وتُشحَن الفحوصات
التلقائية في v1.1 بمجرد توفّر حجم نزاعات حقيقي لضبطها. المنطق: هذا
يمنح فريق الدعم حماية اليوم الأول (لا شيء يتجاوز 150 درهمًا يُحرَّر
بلا نظرة بشرية) دون مخاطر الإيجابيات الكاذبة من نموذج غير مضبوط
للهندسة. أُعيدت صياغة المتطلب 9 ليعكس هذا؛ وأكّدت ليلى وبلال كلاهما
على الصياغة الجديدة في Jul 11.

requirements-doc-signed-v1.md -- سجل sign-off (مقتطف)

LOCKED FOR BUILD -- v1, 2026-07-11

رقم المتطلب   صاحب المصلحة        الحالة          التوقيع        النسخة
------------------------------------------------------------------------
1-6     ليلى الناصر            Signed off    2026-07-08      v1
7-11    يوسف حمدان             Signed off    2026-07-09      v1
9       ليلى الناصر            Re-confirmed  2026-07-11      v1 (بعد
                                (بموجب قرار                    القرار)
                                دانة)
9       بلال المنصوري          Re-confirmed  2026-07-11      v1 (بعد
                                                               القرار)
12-13   مايا حداد               Reviewed, no  2026-07-08      v1
                                objection
1-16    بلال المنصوري          Signed off    2026-07-10      v1

بنود مفتوحة معروفة: المتطلب 15 (تسميات سبب الاعتراض بالعربية الفصيحة)
بانتظار sign-off من مراجع التعريب، غير مُسمّى بعد في خريطة أصحاب
المصلحة -- تمّ تصعيده لدانة لتسمية مالك قبل بدء تحديد نطاق v1.1. ليس
عائقًا لهذا البناء: المتطلب 15 "should" لا "must".

ما أثبتّه — وما التالي

اجتز معيار التقييم وتكون قد أثبتّ ما لا يستطيع الـ playbook المجاني وحده اعتماده: أنك تستطيع إدارة مراجعة متعددة أصحاب المصلحة حتى اكتمال حقيقي، واستخراج خلاف حقيقي بدل حسمه بصمت بنفسك، وإنتاج وثيقة يستطيع فريق الهندسة البناء عليها بثقة لا بأمل. هذه هي مرحلة الـ Sign-off من “Certified Business Analyst with Claude.”

من هنا ينتقل المسار إلى النظامين اللذين يقعان على جانبي الـ sign-off في أسبوع محلل الأعمال الفعلي:

• الوحدة الخامسة — طبقة القرار: الانضباط وراء تحليل الفجوات، وتحليل الخيارات، وحالة العمل التجارية التي تُتّخذ بموجبها قرارات النطاق قبل أن تصل إلى التعميم — بحيث يكون ما تعمّمه في الوحدة الرابعة هو الشيء الصحيح للتوقيع عليه أصلًا.
• الإحاطة التنفيذية: ضغط مبادرة موقَّعة في النسخة التي تحتاجها جمهور القيادة في دقيقتين، دون فقدان التتبّع الذي أثبتته هذه الوحدة للتوّ.

أولًا، اجعل انضباط الـ sign-off قابلًا لإعادة الاستخدام: أبقِ قالبَي circulation-tracker وسجل sign-off وثيقتين حيّتين تعيد استخدامهما في كل مبادرة، لا أثرًا تعيد بناءه من الصفر في كل مرة — والتزم بالقاعدة الوحيدة التي تجعل كل هذا يستحقّ الجهد: لا متطلب يمضي إلى البناء بلا اسم وتاريخ ونسخة مرفَقة.