برومبتات إدارة المشاريع تصبح مفيدة حين تُحوّل الفكرة العامة إلى قرارات ومهام ومخاطر قابلة للمراجعة، لا حين تطلب من الذكاء الاصطناعي «خطط المشروع بالكامل» دون بيانات. ستجد هنا 15 قالبًا عربيًا مستقلًا، لكل منها نص قابل للنسخ وملاحظة للتحقق، من تحديد النطاق إلى تسليم المشروع. ليست هذه القوالب مديرًا للمشروع ولا تمنح المساعد صلاحية جدولة أشخاص أو الوصول إلى ملفاتك دون أن تقدّمها له.
النتيجة العملية: ابدأ بميثاق صغير يحدد المخرجات، ثم قسّم العمل، وعيّن مالكي القرارات، وتتبع الاعتماديات والمخاطر. وعندما تنقص المعلومات اطلب من المساعد كتابة سؤال لا اختراع رقم. الأمثلة أدناه تصلح مع ChatGPT أو مساعد آخر بعد تزويده بالسياق؛ لا تحتاج إلى تطبيق متخصص لاستخدام معظمها.
بطاقة معلومات ينبغي تجهيزها قبل نسخ البرومبت
استخدم وصفًا مختصرًا للمشروع يحدد المشكلة والفئة المستفيدة والموعد الذي وافق عليه الفريق والميزانية المثبتة والوثائق التي تملك حق مشاركتها. إذا كانت البيانات سرية فاستخدم رموزًا وأسماء وهمية. لا تدع المساعد يفترض وجود وصول إلى البريد أو أدوات إدارة المشروع ما لم تكن متصلة بالفعل.
| الحقل | المطلوب |
|---|---|
| النطاق | النتيجة المستهدفة، ما يشمله العمل وما يُستبعد منه |
| الموارد | أفراد الفريق وأدوارهم والجهد أو الميزانية المتحقق منها |
| القيود | موعد التسليم، المتطلبات، الموافقات والتبعيات |
| الأدلة | ملفات المتطلبات والقرارات ومحاضر الاجتماع المتاحة |
تحديد النطاق وبناء خطة عمل واقعية
1. تحديد هدف المشروع ونطاقه
متى تستخدمه؟ عندما تكون الفكرة كبيرة ولا يعرف الفريق ما الذي سيسلّمه فعلًا.
أدير مشروع [اسم المشروع] لخدمة [الجمهور]. هذه المشكلة الحالية [وصف موثق] والنتيجة المطلوبة [نتيجة قابلة للملاحظة]، والمدة [المدة]، والموارد المؤكدة [الفريق والميزانية]. صغ ميثاق مشروع من صفحة واحدة: الهدف، المخرجات، ما يدخل ضمن النطاق وما يخرج منه، الأطراف المعنية، قياس النجاح، والافتراضات المفتوحة. لا تختلق موافقة عميل أو تاريخًا أو ميزانية. إذا تعارض هدفان، اعرض التعارض وسؤالًا لحسمه قبل اقتراح الخطة.
راجع النتيجة: تأكد أن «إطلاق التطبيق» تحوّل إلى مخرجات يمكن قبولها، وأن الأمور المستبعدة مكتوبة وليست مفهومة ضمنيًا.
2. تفكيك العمل إلى حزم قابلة للتسليم
متى تستخدمه؟ حين تبدو المهمة الواحدة أكبر من أن يسندها المدير إلى شخص.
هذا نطاق المشروع المعتمد [النطاق] وهذه المخرجات [القائمة]. أنشئ هيكل تقسيم عمل WBS على ثلاثة مستويات: المخرج، حزمة العمل، المهمة الملموسة. اكتب لكل حزمة شرط اكتمال واضحًا ومعلومة لازمة قبل بدئها. لا تضف خصائص لم ترد في النطاق؛ ضع أي اقتراح جديد تحت «خارج النطاق يحتاج موافقة». اجمع المهام التابعة للمخرج نفسه، ولا تُدخل اجتماعات عامة بدل العمل القابل للتسليم.
راجع النتيجة: الحزم ينبغي أن تصف نتائج يمكن التحقق منها، لا نشاطًا عامًا مثل «الاهتمام بالتصميم».
3. تحديد المعالم والمواعيد المشروطة
متى تستخدمه؟ لتخطيط إطلاق دون توزيع تواريخ اعتباطية على كل خطوة.
هذه الحزم [العمل] والمدة المتاحة [الفترة] والاعتماديات المؤكدة [المعلومات] والعطلات [الأيام]. اقترح خارطة طريق بمعالم رئيسية تبدأ بعد [تاريخ البداية]، مع شرط دخول وخروج لكل معلم. ميّز مدة العمل التي زودتك بها عن التقديرات التي تقترحها، وبيّن أين تنقص معلومات القدرة الإنتاجية. أعطني خيارًا محافظًا وخيارًا مضغوطًا مع أثر كل واحد في المخاطر. لا تحوّل التقدير إلى موعد متفق عليه.
راجع النتيجة: تأكد من أن موعد التسليم النهائي يتبع قبول المعالم لا مجرد اكتمال نشاط على الورق.
4. توزيع الأدوار ومسؤولية القرار
متى تستخدمه؟ عندما يشترك أكثر من فريق في التسليم والتوقيع.
الفريق الحالي [الأدوار والأسماء أو رموز مجهلة] والمهام [القائمة] والجهة المخولة بالاعتماد [الصفة]. صمّم مصفوفة RACI مصغرة للمخرجات المهمة مع توضيح المسؤول عن التنفيذ R، والمسؤول عن اعتماد النتيجة A، ومن يستشار C، ومن يُبلّغ I. لا تعين شخصًا لم يوافق على الدور؛ ضع «يحتاج تأكيدًا» بدل الافتراض. نبهني إلى المهام التي لا تملك مسؤول اعتماد واضحًا أو تملك أكثر من شخص محسوبًا خطأً على أنه صاحب القرار.
راجع النتيجة: المصفوفة المقترحة لا تصبح تفويضًا رسميًا بمجرد أن المساعد ملأ خانة باسم شخص.
إدارة التنفيذ ومتابعة التقدم
5. اختيار أولويات الإصدار الأول
متى تستخدمه؟ إذا كانت قائمة الطلبات أطول من الوقت أو الميزانية.
هذه احتياجات المستخدم [القائمة]، وقيود الفريق [القيود]، ومعايير التقييم [الأثر/الجهد/المخاطر]. رتّب العناصر إلى ضروري للإطلاق، يمكن تأجيله، ويحتاج معلومات؛ واذكر سبب تصنيف كل عنصر وفق المعايير المعطاة. لا تضع درجات أثر أو تكلفة رقمية لم تقدم بياناتها. صغ سؤالين لأصحاب المصلحة حول المقايضة بين الميزات. اقترح نسخة إطلاق صغيرة تُختبر مع [شريحة تجريبية] من دون وعود نجاح.
راجع النتيجة: راقب الميزات التي وُصفت «ضرورية» بلا دليل على أنها تمنع إكمال رحلة المستخدم الأساسية.
6. اكتشاف الاعتماديات وتعارض التسلسل
متى تستخدمه؟ عندما تتعطل المهام لأن فريقًا ينتظر نتيجة فريق آخر.
هذه قائمة المهام [المهام] ومدخلات كل مهمة [المدخلات] ومقدموها [الأدوار]. ابنِ قائمة اعتماديات من نوع «لا يبدأ ب قبل اعتماد أ»، وحدد العمل الذي يمكن تنفيذه بالتوازي دون مخاطرة واضحة. اكتب التبعيات غير المؤكدة بصيغة سؤال، ولا تفرض علاقة بين مهمتين لأن اسميهما متشابهان. حدد نقاط توقف حرجة تحتاج قرارًا مبكرًا، ثم اقترح ترتيب متابعة أسبوعي مع مالك كل اعتماد.
راجع النتيجة: إن ظهر تسلسل غير واقعي، راجعه مع صاحب التنفيذ بدل نقل مهمة في الجدول تلقائيًا. وبعد اعتماد ترتيب المهام، يمكنك تحويل الاعتماديات إلى رسم واضح باستخدام شرح Napkin AI لتحويل النص إلى مخططات.
7. تقدير العمل وفق قدرة الفريق الفعلية
متى تستخدمه؟ لتفادي تحويل عدد المهام مباشرة إلى تواريخ.
لدينا [عدد الأفراد والأدوار] و[ساعات متاحة للفرد أسبوعيًا] و[الغيابات]، والمهام [القائمة] مع تقديرات أصحابها إن وجدت [تقديرات]. احسب القدرة المتاحة بعد الاجتماعات والالتزامات المذكورة، ثم قارنها بإجمالي الجهد المثبت. إذا لم تتوافر تقديرات مهمة فضعها «غير مقدرة» ولا تستبدلها برقم من عندك. اعرض عنق الزجاجة المتوقع، وما البيانات التي يجب جمعها قبل تثبيت موعد تسليم. لا توزع ساعات على أشخاص من دون موافقتهم.
راجع النتيجة: افصل بين المدة التقويمية وعدد ساعات العمل؛ قد يمتد عمل قصير بسبب اعتماد خارجي.
8. إعداد لوحة متابعة أسبوعية
متى تستخدمه؟ حين يحتاج الفريق إلى متابعة التقدم بدل تقرير إنشائي.
هذه المهام الحالية [الحالة، المالك، الموعد، دليل الإنجاز]. حوّلها إلى لوحة بسيطة: لم يبدأ، قيد التنفيذ، ينتظر طرفًا آخر، يحتاج مراجعة، مكتمل. حدد قاعدة نقل المهمة بين الأعمدة وأبرز المهام المتأخرة بناء على تواريخ حقيقية فقط. لا تعتبر «80% مكتمل» حالة مثبتة ما لم يوجد معيار قياس. أخرج ثلاثة أسئلة يُسأل عنها أصحاب المهام العالقة في الاجتماع الأسبوعي.
راجع النتيجة: اللوحة النافعة تكشف سبب التعطل وصاحب القرار، لا تكتفي بألوان الحالة.
9. كتابة تقرير حالة للمسؤول التنفيذي
متى تستخدمه؟ إذا طلب المدير خلاصة لا نسخة من لوحة المهام.
هذه بيانات الأسبوع [ما اكتمل بالدليل، ما لم يكتمل، القرارات، المخاطر]. اكتب تحديثًا تنفيذيًا من 180 إلى 250 كلمة يضم الحالة العامة وسبب تقييمها، ثلاثة مخرجات مثبتة، عائقين لهما مالك، وقرارًا مطلوبًا بتاريخ محدد إن كان معروفًا. لا تصف المشروع بأنه «على المسار» إن لم تتوفر خطة أساس للمقارنة. افصل «معلومة مؤكدة» عن «تقدير الفريق»، ولا تختلق نسبة إنجاز.
راجع النتيجة: قارن كل خبر سعيد بالمخرج الموعود؛ كثرة الأنشطة ليست دليلًا على قرب الإطلاق.
التعامل مع المخاطر والتغييرات
10. إنشاء سجل مخاطر قابل للاستخدام
متى تستخدمه؟ في بداية مشروع يتضمن اعتماديات تقنية وبشرية.
هذا السياق [النطاق والفريق والاعتماديات والقيود]. اقترح سجل مخاطر، لا سجل مشكلات واقعة: اكتب حدثًا محتملًا بصيغة «إذا... فقد...» وسببه وتأثيره، ومؤشر إنذار مبكر، ومالك متابعة مقترح، واستجابة تقليل احتمال أو أثر. استخدم احتمالًا وأثرًا وصفيين عند غياب بيانات كمية، وحدد ما يلزم للتحقق من التصنيف. لا تقدم تقديرًا مئويًا بلا أساس ولا تعامل خطرًا افتراضيًا كأنه وقع.
راجع النتيجة: ميّز وقوع المشكلة بالفعل من خطر مستقبلي؛ لكل حالة طريقة تعامل وإبلاغ مختلفة.
11. تحديد إشارات الإنذار وخطة التصعيد
متى تستخدمه؟ حين يعرف الفريق المخاطر لكنه ينتظر حتى تتحقق.
هذه المخاطر التي اتفقنا عليها [السجل] وقيم تحمل المخاطر المقبولة [الحدود] وجهات التصعيد [الأدوار]. لكل خطر اقترح علامة مبكرة قابلة للملاحظة، وطريقة قياسها ومصدرها وتواتر المراجعة، والحد الذي يستدعي إشعار المالك. إذا لم تحدد الإدارة عتبة مقبولة، اقترح أسئلة لتثبيتها ولا تضع رقمًا حاسمًا من عندك. اكتب إجراءً أوليًا منخفض الكلفة عند تجاوز كل عتبة.
راجع النتيجة: يجب أن يكون الإنذار قابلاً للفحص من سجل أو حدث، لا انطباعًا مثل «الفريق متوتر».
12. تقييم احتمال الخطر وأثره بحذر
متى تستخدمه؟ للمفاضلة بين مخاطر متعددة دون دقة زائفة.
هذه المخاطر [السجل] ووقائع سابقة إن وجدت [بيانات]. اقترح مقياسًا وصفيًا من ثلاث درجات للاحتمال وللأثر مع تعريف عملي لكل درجة في هذا المشروع، ثم ضع تصنيفًا أوليًا مبررًا أو «معلومات غير كافية». افصل التأثير في الوقت عن التكلفة والجودة، وأبرز الخطر الذي يحتاج دراسة إضافية قبل ترتيبه. لا تضرب درجات ترتيبية وتعرض الناتج بوصفه احتمالًا علميًا أو خسارة مؤكدة.
راجع النتيجة: النتيجة أداة نقاش للأولويات وليست بديلًا من سجل الحوادث أو تاريخ المشروعات.
13. تقييم طلب تغيير نطاق جديد
متى تستخدمه؟ عندما يطلب صاحب مصلحة ميزة إضافية بعد اعتماد الخطة.
هذا الطلب الجديد [الوصف] والنطاق الحالي [المعتمد] والخطة [المواعيد] والجهد المؤكد [التقديرات]. اكتب مذكرة قرار تعرض لماذا الطلب خارج أو داخل النطاق، والخيارات: قبوله الآن أو مبادلته بميزة أخرى أو تأجيله، وأثر كل خيار في التكلفة والمواعيد والاختبارات والتدريب. ضع البنود التي تحتاج تقديرًا من الفريق ولا تملأ أرقامًا غير متاحة. صغ سؤال اعتماد واحدًا واضحًا إلى [صاحب القرار]، دون تنفيذ التغيير.
راجع النتيجة: إذا غيّر الطلب معيار القبول، حدّثه رسميًا بعد القرار بدل إخفائه ضمن مهمة قديمة.
قبول المخرجات وتحسين المشروع التالي
14. صياغة معايير قبول قبل التسليم
متى تستخدمه؟ حتى لا يصبح «انتهينا» محل خلاف وقت التسليم.
المخرج المطلوب [الاسم] والجمهور [المستخدم] ومواصفات العقد أو المتطلبات [النصوص]. اكتب خمس حالات قبول قابلة للاختبار تبدأ بظرف واضح وفعل ونتيجة قابلة للقياس أو الملاحظة. حدد حالات الفشل والصلاحيات والأجهزة ذات الصلة إن ذكرتها المتطلبات. لا تضف معيار أداء رقميًا أو سياسة أمنية لم يوافق عليها أصحاب القرار؛ ضعها ضمن أسئلة معلقة. أعطني قائمة أدلة توثّق قبول كل حالة.
راجع النتيجة: اتفق على المعايير قبل التوصيل لا بعد ظهور اختلاف في تفسير كلمة «جاهز».
15. إجراء مراجعة ما بعد المشروع
متى تستخدمه؟ عندما ينتهي مشروع أو مرحلة وتحتاج إلى تعلم قابل للتنفيذ.
هذه الخطة الأصلية [المعالم] وما حدث فعلًا [التواريخ والقرارات والأرقام] وملاحظات الفريق [منزوعة الأسماء إن لزم]. صغ مراجعة تتناول ما ساعد، وما عرقل، وما لم نعرفه مبكرًا. لا تلُم أفرادًا أو تنسب سبب التأخير إلى شخص دون دليل. استخرج ثلاث تحسينات قابلة للتجربة في المشروع التالي مع مالك مقترح وموعد مراجعة للنتائج، وافصل الإجراء المتفق عليه عن الفكرة التي ما زالت تحتاج موافقة.
راجع النتيجة: إذا تكرر تعثر الاعتماديات، أصلح طريقة الإبلاغ والقرار لا صياغة التقرير وحدها.
مثال تطبيقي: إطلاق متجر «سراج» الافتراضي
من الفكرة إلى الخطة القابلة للاختبار
لنفترض أن «سراج» مشروع تعليمي افتراضي لإطلاق متجر إلكتروني لمنتجات ورقية مخصصة خلال ستة أسابيع. لا نملك ميزانيته أو التزام الموردين أو القدرة التقنية لفريقه، لذا لا نضع أرقامًا على أنها حقائق. ابدأ بالقالب 1 لتحديد نطاق الإصدار الأول: صفحة منتجات، سلة، توضيح الشحن وسياسة الاسترجاع. ثم استخدم القالب 2 لتقسيم التسليم إلى حزم، والقالب 4 لتعيين صاحب الموافقة على النصوص وواجهة الدفع.
كيف تتحول المخاطرة إلى قرار لا إلى تنبؤ؟
إذا كانت بوابة الدفع تعتمد على موافقة مزود خارجي، اكتب خطرًا مشروطًا: «إذا تأخرت الموافقة فقد يتعطل اختبار الشراء». لا تقل إن التأخير وقع بالفعل. استخدم القالب 10 لتسجيل الخطر، والقالب 11 لتحديد إشارة مبكرة كعدم وصول رد رسمي قبل نقطة مراجعة متفق عليها، والقالب 13 لتقييم خيار إطلاق تجريبي مؤجل أو طريقة دفع بديلة بعد موافقة المسؤول. هذه الفروق هي ما يجعل خطة المساعد مفيدة بدل أن تبدو دقيقة بأرقام غير مبررة.
كيف تراجع خطة أنشأها الذكاء الاصطناعي؟
افحص كل مخرج أمام أربعة أسئلة: هل استند إلى معلومة قدمتها؟ هل يملك صاحب قرار؟ هل يمكن التحقق من اكتماله؟ وهل أبرز أثر التغيير في الوقت والجودة والتكلفة؟ اطلب من المساعد جدولًا منفصلًا للافتـراضات بدل دفنها في الخطة. لا تعتمد على احتمال خطر بنسبة محددة ما لم تستند إلى بيانات حقيقية، ولا تحول مقاييس وصفية إلى نسب علمية.
إدارة المشاريع ليست مجرد جداول. شخص مسؤول عن القرار وموعد لمراجعة العوائق وعميل يوافق على تعريف «مكتمل» قد يؤثرون في النتيجة أكثر من أي صياغة للبرومبت. استخدم المخرجات كنقطة عمل في اجتماع الفريق، وليس بوصفها أوامر يتم تنفيذها تلقائيًا.
كيف تطور البرومبتات بحسب نوع المشروع؟
في مشروع برمجي أضف التقنيات وقيود الاختبار؛ وفي مشروع محتوى أضف رحلة المراجعة والموافقة؛ وفي مشروع تدريبي أضف المتعلمين المستهدفين وشروط قبول المادة. إذا تكرر قالب يطرح افتراضات كثيرة، لا تطوّله دون هدف: قلّص المهمة واطلب من المساعد عرض ما يعرفه وما يحتاجه. للمبادئ العامة في كتابة تعليمات محددة، راجع هندسة البرومبتات بالعربي، ولتفسير بيانات تقدم مشروع فعلية يمكن الاستفادة من برومبتات تحليل البيانات في Excel وجداول Google.
الخلاصة
ابدأ من القالب الذي يجيب عن قرارك الحالي بدل نسخ القوالب الخمسة عشر دفعة واحدة. الأهم هو التمييز بين معلومة مثبتة وافتراض وتقدير، وتثبيت المالك وشرط القبول وطريقة المراجعة. تحديث المشروع يتطلب مراجعة الفريق والأطراف المعنية؛ الذكاء الاصطناعي لا يملك سلطة اعتماد خطة أو إلزام شخص بموعد.
المصادر والمنهج
اعتمدنا في تنظيم المراحل والمخاطر على مادة PMI الرسمية عن هياكل مخاطر مشروعات الذكاء الاصطناعي وعلى إرشادات OpenAI لصياغة تعليمات واضحة وتحسينها تدريجيًا. القوالب والأمثلة عربية أصلية صيغت لهذا الدليل بتاريخ 7 نوفمبر 2026، وليست مقتطفات من المصادر أو نتيجة تجربة ميدانية مزعومة.
