🧠 دليل التفكير الاحترافي
PMP Core Mindset, Agile & AI
🎯 كيف تستخدم هذا الدليل في الامتحان؟
مرحباً بك في دليلك الأهم لاجتياز اختبار PMP. هذا الملف ليس ملخصاً نظرياً للحفظ، بل هو "البوصلة" التي ستوجهك لاختيار الإجابة الصحيحة في أصعب السيناريوهات. معهد PMI لا يختبر فقط حفظك للعمليات، بل يختبر طريقة تفكيرك (Mindset) كمدير مشروع وكقائد خادم (Servant Leader). اجعل هذه القواعد عدستك لقراءة الأسئلة:
- استبعاد الخيارات الخادعة: استخدم هذه القواعد لفلترة الخيارات "الدكتاتورية" (مثل: فرض القرارات، معاقبة الفريق، أو التصعيد المباشر للإدارة دون محاولة الحل).
- القاعدة الذهبية (قيّم ثم تصرّف): الإجابة التي تقترح التنفيذ الفوري دون تحليل هي غالباً خاطئة (Assess → Analyze → Act).
- تحديد السياق: اسأل نفسك دائماً قبل الإجابة: هل نحن في بيئة تنبؤية (Predictive) أم رشيقة (Agile)؟ هذا الدليل يفصل لك قواعد كل بيئة بوضوح.
- لا تحفظ، بل تشرّب العقلية: اجعل هذا الملف بجانبك أثناء التدرب على حل أسئلة Intelligent PMP، وكلما أخطأتم في سؤال، عودوا إليه لتعرفوا أي قاعدة تم خرقها.
PMP Core Mindset — العقلية الأساسية لإدارة المشاريع
1. افهم المشكلة وحلّلها قبل أن تتصرف
إذا ظهر انحراف أو مشكلة، لا تقفز مباشرة إلى التنفيذ. اجمع المعلومات، ثم اختر الإجراء المناسب.
2. لا تعالج الأعراض؛ ابحث عن السبب الجذري
ابحث عن Root Cause بدل معالجة النتيجة الظاهرة فقط.
3. الفريق ليس مجرد منفّذ؛ أشركه في الحل
شجّع الفريق على المشاركة في تحليل المشكلة وصناعة الحل بدل فرض الحل عليهم مباشرة.
4. عند وجود مقاومة للتغيير، افهم المقاومة أولًا
افهم مخاوف أصحاب المصلحة، وتواصل معهم، ثم عالج أسباب المقاومة.
5. لا تفرض الحل على الفريق عندما يكون الـCoaching هو المطلوب
التوجيه والتدريب غالبًا أفضل من إعطاء الأوامر.
6. القواعد الأساسية للفريق تُطبّق على الجميع
لا تمنح استثناءً لشخص بسبب منصبه. السلوك المتفق عليه ينطبق على الجميع.
7. لا تلجأ إلى التصعيد كخطوة أولى لحل أي مشكلة
حاول أولًا فهم المشكلة وحلها في المستوى المناسب، ثم صعّدها فقط إذا تعذر حلها.
8. التواصل ليس مجرد إرسال معلومات
التواصل الفعّال يعني أن تصل المعلومة المناسبة إلى الشخص المناسب، بالطريقة والوقت المناسبين.
9. أصحاب المصلحة يحتاجون استراتيجيات مختلفة
لا تتعامل مع جميع أصحاب المصلحة بالطريقة نفسها.
10. صاحب المصلحة عالي القوة والاهتمام يحتاج إدارة وثيقة
حافظ على مشاركته وتواصلك المستمر معه.
11. لا تفترض أن الصمت يعني الرضا
عدم الاعتراض لا يعني الموافقة. تحقق من الفهم والتوقعات.
12. التغيير ليس عدوًا؛ التغيير غير المُدار هو المشكلة
لا ترفض طلب التغيير تلقائيًا ولا تقبله تلقائيًا. قيّم تأثيره واتبع الآلية.
13. لا تغيّر الـBaseline من أجل إخفاء الانحراف
افهم الانحراف واتخذ الإجراء المناسب بدل تعديل خط الأساس عشوائياً.
14. المخاطر تتعامل معها قبل أن تتحول إلى Issues
تعامل مع المخاطر استباقيًا، ومع القضايا بإجراءات علاجية مناسبة.
15. لا تتعامل مع كل خطر بالطريقة نفسها
اختر استراتيجية الاستجابة بناءً على طبيعة الخطر وليس كقاعدة واحدة.
16. عند ظهور Issue، استخدم المعلومات والحقائق المتاحة
حل المشكلة بناءً على البيانات، وليس على الافتراضات أو العواطف.
17. الجودة تُبنى في العملية ولا تُفحص فقط في النهاية
ركّز على منع الأخطاء أثناء التنفيذ.
18. إذا كان الفريق Agile، لا تحوّل Agile إلى Waterfall مصغّر
حافظ على الشفافية والتعاون والمبادئ التكيفية.
19. في Agile، الفريق المتمتع بالاستقلالية أقوى من مدير يتحكم بكل شيء
دور القائد هو التيسير وتمكين الفريق.
20. التحسين المستمر يبدأ من التعلم، وليس من اللوم
ركّز على ما يمكن تعلمه بدل البحث عن شخص لإلقاء اللوم عليه.
21. إذا كانت المعلومة غير واضحة، لا تبنِ قرارًا على افتراض
ابحث عن المعلومة أو تواصل مع الطرف المناسب قبل اتخاذ قرار مؤثر.
22. القرار الجيد يعتمد على السياق، وليس على قاعدة محفوظة أعمى
اقرأ السيناريو كاملًا وافهم السياق قبل اختيار الإجابة.
23. اختر الإجراء الذي يعالج السبب ويحقق أكبر قيمة
ابحث عن الخيار الأكثر اتساقًا مع الهدف وأفضل ممارسة.
24. لا تنفق دون مبرر؛ قيّم القيمة والتكلفة والبدائل أولًا
قارن التكلفة بالقيمة المتوقعة والمخاطر قبل الاختيار.
25. في أسئلة "What should the PM do FIRST?" لا تقفز إلى التنفيذ
ابحث أولًا عن الفهم والتحليل والتواصل وتحديد السبب، إلا إذا كان السيناريو يتطلب استجابة فورية بسبب خطر أو تهديد واضح.
26. Tailoring — لا توجد منهجية واحدة تناسب كل المشاريع
فصّل العمليات والأدوات بما يتناسب مع سياق المشروع.
27. Value Delivery — القيمة هي البوصلة
انظر إلى النتائج والمنفعة التي يحققها المشروع للأعمال.
28. Compliance & Ethics — الامتثال والأخلاقيات منذ البداية
حدّد المتطلبات وادمجها في التخطيط والتنفيذ.
29. Predictive Change → Impact Assessment → Change Control
في البيئة التنبؤية (Predictive)، أي تغيير على النطاق أو التكلفة أو الجدول الزمني المعتمد يجب تقييم أثره أولاً، ثم تمريره عبر عملية التحكم المتكامل بالتغيير (Integrated Change Control).
30. عند النزاع حول متطلب، ارجع إلى الوثائق المعتمدة والتتبع
لا تعتمد على الذاكرة أو الادعاءات الشفهية. ارجع أولًا إلى Requirements Documentation والوثائق المعتمدة، واستخدم Requirements Traceability Matrix عندما تحتاج إلى تتبع أصل المتطلب وحالته واعتماده.
🧠 Agile PMP Mindset — القواعد الذهبية لحل أسئلة Agile
1. لا تفرض الحل على الفريق
ساعد الفريق على فهم المشكلة واختيار الحل المناسب.
2. الفريق مسؤول عن كيفية تنفيذ العمل
لا يفرض مدير المشروع أو Product Owner طريقة التنفيذ التقنية (HOW).
3. Product Owner يحدد القيمة والأولوية؛ الفريق يحدد طريقة التنفيذ
Product Owner → Product Value / Priority / WHAT
Developers/Team → HOW
يتعاون الطرفان، لكن لا يفرض Product Owner الحل التقني على الفريق.
4. Servant Leadership يعني التمكين والتيسير
دور القائد دعم الفريق وإزالة العوائق، وليس التحكم.
5. استخدم Coaching عند الحاجة للتطوير
وجّه الفريق وساعده على التطور بدل إعطائه أوامر مباشرة.
6. عندما يوجد Impediment، أزل العائق
ركّز على إزالة العائق أو معالجة سببه.
7. لا تصعّد المشكلة مباشرة
حاول تسهيل الحوار والوصول إلى حل قبل التصعيد.
8. الخلاف بين الأطراف → Facilitate Collaboration
لا تنحز لأحد؛ سهّل النقاش للوصول إلى فهم مشترك.
9. Daily Scrum للتنسيق
ليس لاجتماع حل المشاكل بالتفصيل. المشاكل تُناقش بشكل منفصل.
10. Sprint Planning يحدد ماذا سننجز وكيف
الفريق يتعاون في تحديد ما يمكن إنجازه.
11. الفريق يحدد مقدار العمل
لا تجعل المدير يحدد للفريق مقدار العمل الذي سينجزه.
12. Product Owner مسؤول عن قيمة المنتج
فكر في دور Product Owner عند ترتيب الـ Backlog.
13. Stakeholders لا يفرضون العمل مباشرة على الفريق
تُدار طلبات المنتج عبر Product Owner وProduct Backlog والآليات المناسبة.
14. Feedback فرصة للتكيف
استخدم الـ Feedback لتحسين المنتج والأولويات.
15. Sprint Review → المنتج والقيمة
للحصول على ملاحظات أصحاب المصلحة حول المنتج (Increment).
16. Retrospective → طريقة العمل والتحسين
لتحليل ما حدث وتحسين أداء وعملية الفريق.
17. Review و Retrospective ليسا الشيء نفسه
Review (ماذا بنينا؟) | Retrospective (كيف عملنا؟).
18. في Agile، التغيير متوقع
افهم التغيير وأعد ترتيب الأولويات بما يحافظ على القيمة.
19. Welcome Change لا تعني Accept Immediately
يجب فهم التغيير وتقييمه وإدارته ضمن إطار العمل.
20. لا تضحي بهدف الـSprint لطلب جديد
لا تُدخل طلبًا جديدًا أثناء الـSprint بطريقة تُهدد Sprint Goal. قيّم الطلب وتعاون مع Product Owner والفريق وفق Scrum.
21. Working Product مقياس التقدم
القيمة تظهر من خلال Increment عملي قابل للاستخدام.
22. Definition of Done تحدد الاكتمال
إنجاز البرمجة وحده لا يكفي؛ تحقق من معايير الـ DoD.
23. User Story ليست Task
Story (حاجة للمستخدم - يملكها الـ Product Owner) | Task (عمل تقني وكيفية التنفيذ - يملكها الـ Team).
24. Sprint ينتج Increment بقيمة
الهدف إنتاج منتج يضيف قيمة وقابل للتسليم.
25. الاعتماد بين الفرق يُعالج بالتنسيق
استخدم Scrum of Scrums لمعالجة التبعيات.
26. Kanban → ركّز على Flow و WIP
Too Much WIP → Limit WIP → Improve Flow.
27. لا تخلط Scrum مع Kanban
لا تطبق قواعد أحدهما على الآخر تلقائياً.
28. Technical Solution لا تُفرض باسم القيمة
وازن بين متطلبات القيمة التجارية والمتطلبات التقنية.
29. فخ الامتحان: مدير المشروع يوزع المهام
إذا رأيت خياراً يقول أن مدير المشروع أو مالك المنتج يقوم بـ "توزيع المهام (Assigning Tasks)" على فريق الأجايل، فهذا خيار خاطئ يجب استبعاده فوراً؛ التدخل في المهام التقنية يخالف مبدأ استقلالية الفريق (Self-organizing Team).
30. فخ الامتحان: الفريق يرتب الأولويات المالية
إذا طُلب من الفريق ترتيب الأولويات للأعمال بناءً على العائد المالي، فهذا خطأ أيضاً، لأن ترتيب قيمة "القصص والميزات" من مهام الـ Product Owner.
31. Epic → Decomposition → User Stories
الميزات الكبيرة (Epics) لا تُنفذ دفعة واحدة؛ يجب تفكيكها (Decomposition) إلى قصص مستخدم أصغر يمكن فهمها وتقديرها وإنجازها خلال Sprint واحد.
32. فرّق بين Definition of Ready و Definition of Done
Definition of Ready (DoR): الشروط والمعايير التي تؤكد أن قصة المستخدم واضحة ومفهومة وجاهزة للبدء بها في الـ Sprint.
Definition of Done (DoD): المعايير التي تؤكد أن العمل اكتمل تماماً ومستوفٍ للجودة وجاهز للتسليم.
🔥 خريطة Agile السريعة في الامتحان
| إذا رأيت في السؤال | فكّر مباشرة |
|---|---|
| Team لا يعرف ماذا يفعل | Coach / Facilitate |
| Team محجوب أو متعطل | Remove Impediment |
| Conflict | Facilitate Collaboration |
| Product Priority | Product Owner |
| كيف ننفذ العمل؟ | Team / HOW |
| Business Value | Product Owner / VALUE |
| Stakeholder Feedback | Review / Backlog / Adapt |
| مشكلة في طريقة العمل | Retrospective |
| مشكلة في المنتج | Sprint Review |
| Daily Scrum طويل | Keep focused / discuss details separately |
| طلب تغيير (Agile) | Evaluate → Prioritize → Adapt |
| New request أثناء Sprint | لا تقفز مباشرة لإدخاله |
| متى نبدأ العمل بالقصة؟ | Definition of Ready (DoR) |
| العمل مكتمل (Done) | Definition of Done (DoD) |
| ميزة كبيرة جداً (Epic) | Decomposition → User Stories |
| نزاع حول متطلب (تنبؤي) | Requirements Traceability Matrix (RTM) |
| WIP / Bottleneck | Kanban / Limit WIP |
| اعتماد بين فرق | Scrum of Scrums |
| Team يعرف كيف يعمل | لا تفرض عليه HOW |
| مدير يريد التحكم بكل شيء | ⚠️ Agile Mindset mismatch |
وأقوى قاعدة في Agile: لا تسأل فقط "ما الحل؟" بل اسأل: "من يملك القرار؟"
- Product Owner: Product Value / Priority / WHAT
- Developers/Team: HOW (كيف ننفذ؟)
- Scrum Master: كيف أساعد الفريق على النجاح؟
- Stakeholders: Feedback واحتياجات وقيمة.
🧠 AI Mindset — عقلية الذكاء الاصطناعي
- الإنسان هو المسؤول النهائي عن القرار.
- AI يساعد ويقترح؛ الإنسان يراجع ويقرر.
- كلما زادت خطورة القرار، زاد مستوى التدخل والمراجعة البشرية.
- لا تثق بمخرجات AI كحقائق مطلقة؛ تحقق منها.
- البيانات الحساسة أو السرية تحتاج حماية وضوابط مناسبة قبل استخدامها مع AI.
- مخاوف الأمن والخصوصية لا تُتجاهل عند استخدام AI.
- انتبه إلى التحيز (Bias) وجودة البيانات.
- القرارات الحساسة التي تؤثر على الأشخاص أو المال أو المخاطر تحتاج Human Oversight.
- ميّز بين Automation و Assistance و Augmentation.
- المهمة الروتينية منخفضة المخاطر → Automation.
- المهمة المعقدة التي تحتاج مراجعة بشرية → Assistance.
- المهمة الاستراتيجية المعقدة → Augmentation.
- في Stakeholder Management، استخدم AI لتعزيز قدرات مدير المشروع، وليس لاستبداله.
- في Schedule، يمكن أن يعمل AI كأداة Assistance لتحليل الجدول وحل التعارضات ودعم التنبؤ.
- في Risk Management، حدّد مستوى تدخل AI بناءً على طبيعة المهمة والمخاطر.
- لا تستخدم AI لمجرد استخدامه؛ يجب أن يضيف قيمة حقيقية.
- AI جزء من سياق إدارة المشروع، وليس بديلًا عن People و Process و Business Environment أو عن الحكم المهني لمدير المشروع.