تتآكل المتطلبات فور خروجها من مرحلة المسودة: تُعمَّم الوثيقة للمراجعة، يردّ ثلاثة أشخاص ويلتزم اثنان الصمت، تصل ملاحظات متناقضة مع بعضها، ويبدأ العمل التنفيذي رغم ذلك لأن الموعد النهائي لا ينتظر آخر توقيع. يشغّل هذا النظام المسار الكامل — الصياغة، التعميم، المتابعة، التوفيق، الاعتماد — كسير عمل واحد محكوم بدل خمس خطوات منفصلة، بحيث لا يبدأ أي عمل تنفيذي دون أن يكون لكل متطلَّب مالك مُسمّى. إنه ضمانة قابلية التتبّع وقد تحوّلت إلى نظام تشغيل: خريطة أصحاب المصلحة تخبرك بمن تعمِّم عليه، ووثيقة المتطلبات هي الأداة الخاضعة للحوكمة، وأي عمل من gap-analysis أو options-analysis أسهم في الصياغة يبقى أثره ظاهراً حتى في النسخة النهائية الموقَّعة.
- مخرجات
stakeholder-mapلديك، أو على الأقل قائمة بمن يجب أن يراجع ومن يملك سلطة الاعتماد النهائي على كل مجال من مجالات المتطلبات. - مسودة أولى لـ
requirements-doc(من الـ playbook الأساسي)، أو ملاحظات المقابلات الخام مع أصحاب المصلحة ومحاضر الاجتماعات التي ستُبنى منها. - أي مخرجات
gap-analysisأوoptions-analysisسبق أن حدّدت النطاق، حتى لا تتعارض الوثيقة مع قرارات اتُّخذت بالفعل. - الموعد النهائي للتنفيذ ومن ينتظر الاعتماد لبدء عمله — فهذا ما يحدّد مدى شدّة المتابعة.
-
اكتب مسودة وثيقة المتطلبات أو استوردها
افتح المجلد الذي يحوي ملاحظات أصحاب المصلحة (وخريطة أصحاب المصلحة وتحليل الفجوات وتحليل الخيارات إن وُجدت) في Claude Desktop واطرح السؤال في المحادثة مباشرة — لا حاجة إلى Terminal. إن وُجدت مسودة
requirements-docبالفعل، استوردها بدل إعادة الصياغة من الصفر.أنت تطلباستخدم stakeholder-notes.md وstakeholder-map.md لصياغة requirements-doc.md: متطلَّب مرقّم واحد في كل صف، مع وصف بلغة واضحة، وصاحب المصلحة الذي يتتبّعه المتطلَّب مذكوراً بالاسم، والأولوية (must/should/could)، وحقل «اعتماد المالك» يُترك فارغاً. حدّد أي متطلَّب استنتجته أنت بدل أن تسمعه مباشرة.ما تحصل عليه وثيقة متطلبات مرقّمة يذكر كل صف فيها صاحب المصلحة الذي جاء منه، مع حقل اعتماد فارغ — ضمانة التتبّع مبنية في شكل الوثيقة منذ الصف الأول.
المتطلبات المُستنتَجة تُحدَّد بوضوح ولا تُمرَّر بصمت. الاستنتاج غير المُعلَّم هو بالضبط ما يكسر التتبّع لاحقاً.
-
ابنِ قائمة التعميم والمتابعة
حوّل خريطة أصحاب المصلحة إلى ورقة متابعة حيّة: من يراجع ماذا، وما الحالة الراهنة لكل بند. هذا ما يجعل «من لم يردّ بعد» عملية بحث سريعة لا تمريناً في الذاكرة.
أنت تطلبمن stakeholder-map.md وrequirements-doc.md، ابنِ circulation-tracker.md: صف واحد لكل صاحب مصلحة، وأرقام المتطلبات التي يخصّه مراجعتها، وعمود حالة (لم تُرسل / أُرسلت / رُوجعت / اعتُمدت / متضاربة)، وتاريخ آخر تواصل. أخبرني من يملك سلطة الاعتماد النهائي ومن هو مستشار فقط.ما تحصل عليه ورقة متابعة توضّح لكل صاحب مصلحة نطاقه وحالته ومستوى سلطته — المرجع الوحيد لمعرفة من يدين لك بردّ.
-
عمِّم الوثيقة وصِغ رسائل المتابعة
أرسل الوثيقة، ودَع Claude يصيغ رسائل المتابعة حتى تبقى المتابعة مهذّبة ومحدّدة بدل أن تكون تذكيراً غامضاً.
أنت تطلباكتب رسالة تعميم قصيرة لـ requirements-doc.md مخصّصة لكل مجموعة من أصحاب المصلحة في circulation-tracker.md — فقط المتطلبات التي تخصّهم، مع موعد نهائي واضح وشرح لما يعنيه «الاعتماد». ثم اكتب رسالة متابعة من سطر واحد يمكنني إرسالها لأي شخص ما زالت حالته «لم تُرسل» أو «أُرسلت» بعد 3 أيام عمل.ما تحصل عليه رسالة تعميم مخصّصة لكل مجموعة، إضافة إلى سطر متابعة جاهز للإرسال — بحيث تكلّفك المتابعة نسخاً ولصقاً لا صياغة جديدة في كل مرة.
-
سجّل الردود وحدّث الحالة أولاً بأول
كلما ردّ صاحب مصلحة — في اجتماع، أو بريد، أو تعليق — أدخِل الردّ وحدّث ورقة المتابعة. تتكرر هذه الخطوة طوال فترة المراجعة.
أنت تطلبهذه ملاحظات بريا على المتطلبات 4 و7 و12: [الصق الملاحظات]. حدّث circulation-tracker.md لتعليم حالتها، وأخبرني إن كانت ملاحظاتها اعتماداً واضحاً، أم طلب تعديل، أم تضارباً مع ملاحظات شخص آخر مسجَّلة بالفعل.ما تحصل عليه صف محدَّث في ورقة المتابعة، إضافة إلى حكم صريح: اعتماد نظيف، أم طلب تعديل، أم تضارب — بحيث تظهر التناقضات فوراً بدل أن تظهر في النهاية.
-
عالج الملاحظات المتضاربة
حين يريد صاحبا مصلحة أمرين مختلفين على المتطلَّب نفسه، لا توفّق بينهما بأخذ المتوسط — أظهر التضارب صراحةً واحسم الأمر عبر صاحب قرار مُسمّى.
أنت تطلبالمتطلَّبان 7 و12 عليهما ملاحظات متضاربة: [الصق كلتا الملاحظتين]. اعرض التضارب بوضوح — ماذا يريد كل صاحب مصلحة ولماذا يهمّه — وأخبرني من يملك السلطة النهائية على هذا المتطلَّب وفق خريطة أصحاب المصلحة. اصغ السؤال الذي يجب أن أطرحه على ذلك الشخص لحسم الأمر.ما تحصل عليه ملخّص واضح للتضارب، وصاحب القرار المُسمّى وفق خريطة أصحاب المصلحة، وسؤال جاهز للإرسال — تُصعَّد التعارضات دائماً إلى مالك، ولا تُقسَّم أبداً بالتساوي بصمت.
لا تدع صياغة أي متطلَّب تنجرف نحو «أسهل صيغة يتّفق عليها الجميع». المالك المُسمّى هو من يقرّر؛ ويُسجَّل قراره على المتطلَّب نفسه، لا في عبارة غامضة.
-
تحقّق من الاكتمال قبل إغلاق الجولة
قبل إعلان الجولة منتهية، تأكّد أن كل متطلَّب يملك بالفعل ما تفرضه الضمانة: اسماً وحالة.
أنت تطلبدقّق requirements-doc.md وcirculation-tracker.md معاً: اذكر أي متطلَّب ليس له بعد صاحب مصلحة مُسمّى، أو أي صاحب مصلحة يملك سلطة الاعتماد لكن حالته ليست «اعتُمدت». لا ينبغي أن يبقى شيء خارج هذه القائمة قبل إغلاق الجولة.ما تحصل عليه قائمة فجوات — متطلبات أو أصحاب مصلحة ما زالوا معلَّقين — أو، في أفضل حال، تأكيد أن كل متطلَّب يتتبّع اسماً وأن كل توقيع مطلوب موجود.
-
ثبّت النسخة المعتمدة
حين يكتمل كل توقيع مطلوب، جمّد الوثيقة كنسخة رسمية واجعل مسار الاعتماد ظاهراً داخل الوثيقة نفسها، لا في ذهنك فقط.
أنت تطلبأنتج requirements-doc-signed-v1.md: وثيقة المتطلبات الكاملة مع سجلّ اعتماد مُرفق — صاحب المصلحة وتاريخ الاعتماد وحالة كل متطلَّب. ضع علامة «مُجمَّدة للتنفيذ» في الأعلى. أي بند لم يُعتمد يُذكر صراحة في الأسفل كبند مفتوح معروف.ما تحصل عليه نسخة رسمية مُجمَّدة مع سجلّ اعتماد ظاهر لكل متطلَّب، وأي بنود مفتوحة مذكورة صراحة — الأداة التي يمكن أن يبدأ منها التنفيذ، مع مسار توثيقي مبني فيها.
- مسار سريع لتغيير صغير: ادمج الخطوات 2 إلى 4 في اجتماع مراجعة جماعي واحد حين يكون عدد أصحاب المصلحة أقل من 5 والتغيير منخفض المخاطر — ومع ذلك سجّل الاعتماد كتابياً بعد الاجتماع، حتى لو كان النقاش شفهياً.
- التغذية من workshop-synthesis: إن جاءت المتطلبات من ورشة عمل، ابدأ الخطوة 1 بمخرجات
workshop-synthesisبدل الملاحظات الخام — فهي تجمّع المحاور حسب المشارك مسبقاً، ما يسرّع تتبّع صاحب المصلحة. - نطاق عالي الحساسية أو خاضع للتنظيم: أضِف عمود مصفوفة اعتماد رسمية (RACI) إلى ورقة المتابعة، واشترط أن يكون الاعتماد ردّاً مكتوباً ومؤرّخاً وموقَّعاً باسم صريح — لا اعتمادات شفهية على أي شيء يمسّ الامتثال أو الالتزامات الخارجية.
- طلبات تغيير متكرّرة بعد الاعتماد: بعد التجميد، وجِّه أي طلب جديد عبر ملحق خفيف لـ
requirements-docبصف اعتماد خاص به، بدل تعديل النسخة v1 المُجمَّدة — يحافظ ذلك على سلامة المسار التوثيقي.
- لا تدع التنفيذ يبدأ على وثيقة فيها أي متطلَّب «must» غير موقَّع. مالك واحد غير مُسمّى هو بالضبط الفجوة التي تتحوّل بعد ثلاثة أسابيع إلى إعادة بناء ميزة كاملة — وكل الغاية من هذا النظام أن هذا لا يحدث.
- لا تحسم تضارباً باختيار الإجابة الأسهل كتابةً. كل تضارب يُصعَّد إلى الشخص صاحب السلطة المُسمّاة على ذلك المتطلَّب — Claude يصيغ سؤال التصعيد، ولا يتّخذ القرار.
- لا تُعامل «عدم الردّ» كاعتماد ضمني. الصمت يُسجَّل في ورقة المتابعة كـ«لم يردّ»، ويبقى خارج قائمة الموقَّعين، ويُتابَع — لا يتحوّل أبداً بصمت إلى نعم.
- Claude يتابع ويصيغ؛ لا يملك العلاقة. الإنسان هو من يجري المحادثات الفعلية مع أصحاب المصلحة المتباطئين — استخدم هذا النظام لتعرف بدقة من هو ذلك الشخص وماذا تسأله، لا لتحلّ محلّ السؤال نفسه.
ستحصل في النهاية على وثيقة متطلبات انتقلت من مدخلات أصحاب المصلحة إلى نسخة رسمية مُجمَّدة، يتتبّع فيها كل متطلَّب صاحب مصلحة مُسمّى، وصُعِّد كل تضارب وحُسم بدل أن يُمرَّر بصمت، وسُجِّل كل توقيع مطلوب — يمكن أن يبدأ التنفيذ منها على أرض صلبة.
أسئلة يطرحها الناس
- ماذا يحدث إن لم يردّ صاحب مصلحة على الإطلاق؟
- يبقى مسجَّلاً كـ«لم يردّ» في ورقة المتابعة ويُتابَع برسالة المتابعة — لا يتحوّل الصمت أبداً إلى اعتماد ضمني. وإن كان يملك السلطة النهائية على متطلَّب ما، لا يمكن وضع علامة «مُجمَّد» على ذلك المتطلَّب حتى يردّ هو أو يعتمده مندوب مُسمّى بالنيابة عنه.
- كيف تُحسم رغبة صاحبي مصلحة في أمرين متناقضين؟
- لا تُقسَّم الفروق بالتساوي. يُعرَض التضارب بوضوح لكلا الموقفين، ثم يُصعَّد إلى من يملك السلطة النهائية على ذلك المتطلَّب وفق خريطة أصحاب المصلحة — Claude يصيغ سؤال التصعيد، لكن شخصاً مُسمّى هو من يتّخذ القرار الفعلي، ويُسجَّل ذلك القرار على المتطلَّب نفسه.
- هل يمكن أن يبدأ التنفيذ قبل اعتماد كل متطلَّب؟
- فقط إن كانت البنود غير الموقَّعة مذكورة صراحة كبنود مفتوحة معروفة في الوثيقة المُجمَّدة، ويُفضَّل أن يقتصر ذلك على المتطلبات الأدنى أولوية («should»/«could») لا «must». فحص الاكتمال في الخطوة 6 موجود تحديداً لرصد هذا قبل أن يتحوّل إلى فجوة صامتة.
- بمَ يختلف هذا عن مجرد تشغيل الـ playbook الخاص بـ requirements-doc مرة واحدة؟
- الـ playbook الأساسي `requirements-doc` ينتج الأداة نفسها. هذا الـ playbook يُشغِّل تلك الأداة عبر دورة حياتها الكاملة — التعميم، المتابعة، حسم التضارب، والاعتماد المُجمَّد — بحيث لا تُكتَب فحسب بل تُحكَم. تلك هي طبقة التنسيق فوق الوثيقة الواحدة.