الكثير من مديري المشروعات يخطؤون في كثير من الأشياء أثناء إدارة مشروعاتهم. ومن أسوأ الأخطاء التي قد يرتكبها مدير المشروع عدم إدارة المخاطر في المشروع، بل أحيانًا تجاهل إدارة المخاطر في المشروع تمامًا.
عندما تعرفت إلى إدارة المخاطر Risk Management عام 2005 ضمن كتاب PMBOK كانت نقلة نوعية بالنسبة لي، إذ اكتشفت أشياء جديدة وممتعة، منها أن لا وجود لمشروعات بدون مخاطر ومنها أن الخطر قد يكون فرصة، وكيف يتم ترتيب المخاطر بحسب الأولويات، وكيف تُحول المخاطر إلى أرقام ومنحنيات توزع احتمالي، وهلم جرًا.
اليوم تفاجئنا إدارة المشروعات الرشيقة Agile Project Management بمفاهيم جديدة كليًا للتعامل مع المخاطر، اسمحوا لي أن أبسطها بالقواعد التالية:
- تنحو إدارة المشروعات الرشيقة Agile منحًا استباقيًا في مواجهة المخاطر، فهي تنطلق من القاعدة التي تقول إنه كلما طال زمن المشروع، زاد احتمال حصول مخاطر، لذا فإن تقسيم المشروع إلى تكرارات iterations, sprints يقلل من فرص حصول هذه المخاطر.
- تؤمن إدارة المشروعات الرشيقة Agile أن أفضل طريقة للتعامل مع خطر ما هو مواجهته في أقرب فرصة ممكنة، لذا فمن الوارد جدًا أن تخصص التكرارات الأولى لمواجهة ومعالجة المخاطر فيما نسميه بـ Risk Spikes، ذلك أنه من الأفضل أن يفشل المشروع مبكرًا وبشكل آمن على أن يفشل بعد مضي وقت طويل من العمل فيه Failing safe and fast. على سبيل المثال إذا كان هناك خطر يكمن في إمكانية توفر مادة أولية معينة يحتاجها المشروع، فإدارة المشروعات الرشيقة تحثك على مواجهة هذا الخطر بشكل مباشر، لترى إن كان بالمقدور توفيرها أم لا، قبل أن تتقدم في أعمال المشروع.
- الخطر هو قيمة سالبة Anti-value، أي أن الخطر الذي يؤخذ بعين الاعتبار هو فقط التهديدات (بعكس الدليل المعرفي لإدارة المشاريع، الذي ينص على أن الخطر يمكن أن يكون فرصة أيضًا) التي يمكن أن تواجهنا أثناء المشروع، وهذه التهديدات تحول كميًا بالأرقام إلى قيم سالبة بهدف مقارنتها بالقيم الموجبة التي تعطى للميزات التي نريد أن نعمل على إنجازها، وعلى هذا الأساس يتم ترتيب سجل الأعمال المطلوبة بالأولويات، فلو كان هناك ميزة نريد العمل عليها قيمتها 10,000$ مثلا وخطر قيمته -12,000$ فإننا نبدأ بالعمل على الخطر لأن له قيمة أعلى، وهذا ما يعطينا تركيزا أكبر في العمل، أما كيف تتم حساب قيمة الخطر فعادة ما نستخدم القيمة المالية المتوقعة Expected Monetary Value وذلك عن طريق ضرب احتمال الخطر بمقدار تأثيره (الزمني أو المالي) فيما لو حصل.
- معظم منهجيات الإدارة الرشيقة تشجع على أن يكون أعضاء الفريق Generalizing Specialists أي لديهم تقريباً نفس المستوى من المهارات بحيث يستطيع أي شخص فيهم أن يتبادل دوره مع أي شخص آخر، و ذلك تجنباً للمخاطر التي تتعلق بغياب أو فقدان بعض أعضاء الفريق. في منهجية XP مثلاً يوجد مفهوم Pair Programming حيث يعمل كل شخصان معاً، حيث يقوم أحدهما بكتابة الكود البرمجي و يقوم الآخر باختباره، ثم يتبادلان الأدوار و هكذا..
- متابعة ومراقبة المخاطر تكون عن طريق مخطط نسميه Risk Burndown Chart وهو مخطط آخر من مخططات الإدارة الرشيقة التي تتميز بكونها سهلة الفهم، يدوية ولا تحتاج لأدوات تقنية low-tech, high-touch. هذا المخطط يوضح المخاطر التي في المشروع من البداية وبطبيعة الحال تقل هذه المخاطر بمواجهتها كما ذكرنا سابقًا بشكل مبكر حتى نصل إلى نهاية المشروع، كما هو موضح مثلا هنا:
- أخيرًا وليس آخرًا، تلفت إدارة المشروعات الرشيقة انتباهك إلى أن العمل قيد الإنجاز Work In Progress – WIP يشكل خطرًا، وبالتالي كلما أسرعنا في إنجاز العمل، تخلصنا من مخاطر أكثر.
مرة أخرى، أعتقد أن أسلوب الإدارة الرشيقة سيتطور كثيرا في الأيام المقبلة وسيكون له تطبيقات مختلفة في مجالات تطبيقية عديدة لا تتوقف عند صناعة البرمجيات، وإن كانت هي الصناعة الرائدة في وضع مفاهيم إدارة المشروعات الرشيقة. وأتمنى عليك عزيز القارئ المهتم أن تبدأ من الآن بالتعرف على هذه المفاهيم وتطبيقها في مجال عملك للاستفادة منها قدر الإمكان.
مقال جميل، بالتوفيق أخي بيهس
رائع ارجو اني يوصلي كل مقالاتك
جميل
جزاك الله خير مقال ممتاز