الخميس، 1 يناير 2015


ان كانت مهمة ادارة المشاريع صعبة، فهي -بلا شك- اكثر صعوبة في مجال البرمجيات، بل هي استثنائية جدا في هذا المجال. في هذا المجال يسعى فريق العمل البرمجي لتحليل وضع ما غير منظم، واستشفاف رؤية العميل والصورة الذهنية التي لديه في التعامل مع هذا الوضع للخروج ببعض المتطلبات التي يمكن برمجتها ليخرج علينا في النهاية منتج يعبر عن هذه الصورة الذهنية ويحل المشكلة !!!

اي اننا نتعامل مع صورة ذهنية لدى العميل، نحاول توثيقها قدر المستطاع، ونحاول ان نوفر لها حل باستخدام ادوات برمجية دائمة التطور، وفي النهاية سيتم انزال هذا النظام على بيئة عمل من انظمة تشغيل مختلفة وقواعد بيانات مختلفة، وقد يتكامل هذا النظام مع انظمة اخرى مختلفة. كما نرى فهي كلها عوامل دائمة التغير (صورة ذهنية، اداوت حل تتطور باستمرار، بيئة عمل معقدة ومتشابكة)، ورغم كل هذه التحديات يظل المشروع ثابت الميزانية و محدد الوقت !!!

هذا الفيديو ناقش بعض هذه المشاكل وقدم بعض الرؤى في كيفية التعامل معها، سنحاول هنا توثيقها والتعليق عليها، ونتمنى من القارئ ان يشاركنا تجربته وخبراته في كيفية التعامل مع هذه الأمور.

بدأت المشاكل بأن:

1- متطلبات العميل غير واضحة...

وهذا ما يحدث دائما او على الأقل في اغلب الأحوال. العميل لديه مشكلة ما، لكنه ليس بالضرورة يعرف الحل، وبالتبعية فليس بالضرورة ان الحل الذي ستقدمه انت سيكون الحل الناجز الوافي. ايضا في كثير من الأحيان يكون العميل غير قادر على تشخيص مشكلته، يشكو من اعراض معينة لكنه لا يعرف اسبابها على وجه التحديد. يشكو مثلا من اخطاء كبيرة في الحسابات اخر العام، في حين ان المشكلة ليست في الحسابات وانما في المخازن مثلا وهي التي تسبب مشكلة في الحسابات !!
وهذا امر لا يدركه الا الخبراء :)
تجتمع انت والعميل ليحكي لك عن مشاكله محاولا نقل الصورة الذهنية التي لديه اليك، وانت تحاول جاهدا انت تستنبط هذه الصورة وتجعلها بقدر الأمكان اقرب ما تكون لما هي عند العميل !!!
ولأن العميل ليس لديه صورة واضحة عن متطلباته، ولأنك بدورك تحاول بشكل كبير ان تنقل هذه الصورة اليك، وهو امر مستحيل ان يتم بشكل كامل، فسيحدث حتما تغيير في المتطلبات اثناء العمل ... وهي المشكلة الثانية

2- التغيير الدائم في المتطلبات ...

هناك مقولة " ان افضل عملية توثيق لمتطلبات العميل لن تتجاوز في احسن الأحوال نسبة 80% من احتياج العميل الحقيقي"
الم نذكر ان العميل نفسه ليس لديه صورة واضحة ... اذن فهذا يحتمل نسبية كبيرة من المحاولة والخطأ. ونسبة الخطأ هنا هي في احسن الأحوال لن تقل عن 20% :)
الأمر الذي يجعل محاولات تصويب المسار او تصحيح الخطأ تتم اثناء عمليات البرمجة، فيحدث التغيير الدائم. لذلك من المهم ان نعترف ان التغيير في المتطلبات سيحدث، ومحاولة تحدي ذلك او عدم التعامل معه على انه حقيقة والتعامل معه بشكل صحيح، سيؤدي حتما الي فشل المشروع.

3- المشروع استنزف وقتا طويلا وخرج عن الميزانية ...

اليس هذا نتيجة حتمية ومنطقية لما ذكرناه في الأعلى!. التغيير الدائم في المتطلبات، سيؤدي حتما لجهد اضافي يتطلب لوقت اضافي وموارد اضافية وميزانية اضافية. الذي قد يؤدي الي ضجر العميل من المشروع ومن الفريق القائم عليه فيوقف العمل فيه ويلغيه... الم يحدث هذا كثيرا معنا ...
في احصائية اجريت سنة 95، وجدوا ان نسبة نجاح المشاريع البرمجية التي لاتنتهج منهجا مرنا Agile في اداراتها لا تتجاوز 31% !!!

4- لايوجد وقت لعمليات الأختبار ...

اذا وصل المشروع للمشاكل التي ذكرناها في الأعلى، فحتما سيأتي هذا على حساب فترة اختبار المشروع. الفريق المنفذ سيسعى جاهدا ان يسلم المشروع في ميعاده حتى يحصل على مستحقاته، ولأن الفريق قد اجبر مضطرا الي تنفيذ حزمة من المتطلبات الأضافية خارج التعاقد، فسيضحي بجزء كبير من وقت الأختبار، فيتسلم العميل نظاما غير كفئ !!!

5- وقت كثير يستهلك فيما لاينفع

دراسة اكاديمية اجريت سنة 2003 ذكرت الآتي:
" 53% من المتطلبات في المشروع يتم الغائها، حيث يكتشف انها غير ذات قيمة حقيقية في المشروع، او الوضع الراهن نفسه قد تغير"
"64% من المتطلبات التي يتم بنائها لا تستخدم، وفي احسن الأحوال تستخدم مرة كل سنة مثلا"
كان لدي تجربة شخصية مع برنامج لأحد الجامعات. في هذا البرنامج تم بناء اكثر من 120 تقرير وفقا لاحتياجاتهم، وبعد الأنتهاء منها واثناء مراقبتنا لسير العمل وكفاءة النظام، وجدنا ان اقل من 10 تقارير هي التي تسخدم بشكل دوري، واكثر من 50 تقرير لم يستخدموا على مدار اكثر من 6 سنوات :)

الحل
مبدئيا ليس هناك مايمكن ان نسميه حلا ناجزا، فهي ليست مسألة رياضية لها حل ثابت، وانما هي تفاعل انساني يحتمل الكثير من الحلول... لذلك العديد من الأطر المرنة Agile frameworks هي فقط اطر وليست منهج اداري محدد، هي اطر ترسم لك بعض الأخطاء التي لا يجب ان تقع فيها، وتنصحك بعض النصائح والتوصيات الأخرى، ثم تترك لك الحرية في التصرف وفقا لخبرتك ووفقا للموقف.
ما سأعرضه هنا هو بعض ممارسات من واقع خبرتي الشخصية في الموضوع...

1- قبل التعاقد قم بتوثيق الرؤية والأهداف وليس المتطلبات...

قلنا انه يجب ان نتقبل فكرة ان المتطلبات ستتغير مع الوقت وانه لايجب ان نقاوم المبدأ نفسه. لذلك انصح الا يتم توثيق المتطلبات البرمجية بشكلها التفصيلي قبل التعاقد، اي لا نوثق خصائص النظام system features ،  وانما نكتفي بتوثيق الرؤية المرجوة من هذا العمل، واهدافه، وسيناريو الحوار. وبعد ذلك فأي متطلب داخل اطار هذه الرؤية وتلك الأهداف الدقيقة المحددة فهو متطلب مقبول. واي متطلب خارجها، فهو خارج اطار التعاقد.
اي اننا سنكتب وثيقة من شأنها ان تضع اطارا للمشروع، كل ما يمكن ان يوصف بأنه داخل هذا الأطار فهو مقبول، وكل ما يمكن ان يوصف بأنه خارج هذا الأطار فهو مرفوض.
الذين لم يستخدموا هذا الأسلوب من قبل او لم يستخدموا "سيناريو الحوار" قد يستغربوه او يظنوا انه كلام عام، وهو ليس كذلك
- اعرف المزيد عن سيناريو الحوار من خلال هذا المقال "دور الدراما والرواية في كتابة متطلبات العميل"

2- بعد التعاقد، قم بزيادة وعي العميل...

لا يوجد مشروع -ايا كانت طبيعته- لايواجه تحديات ومشاكل. لذلك من المفيد ان تقوم بعمل ورش عمل ومحاضرات لتوعية العميل عن طبيعة المشاريع البرمجية. حاول الا تخيفه بذكر نسب فشل المشاريع :) ... لكن ارفع وعيه بالشكل الذي يضمن لك ارضية تفاهم وتفاوض في حالات المشاكل. هذه تكتسب بالخبرة ومع الوقت.

3- التفاوض حول المتطلبات ...


لابد ان يكون كل قرار حول اي متطلب نابع بعد عرضه على مثلث الموائمات. قد تكون بعض متطلبات العميل ضمن الأطار المتفق عليه، لكنه يريد اخراجها بشكل اكثر رفاهية مما سيستغرق وقتا اضافيا في تطويرها. لابد ان يكون هذا ضمن موائمة ما، الغاء متطلب اخر، زيادة زمن، او زيادة في الميزانية. من المهم ان نمنع العميل من تشتيت نفسه في الأمور الجانبية، وحثه على التركيز معنا على اهداف المشروع، والخروج بها اولا. لابد من الأجتماع المتواصل معه لترتيب اولويات التنفيذ وعرض المنجزات اول بأول







تنويه...
نموذج الرؤية المذكور في الأعلى مأخوذ من Microsoft solution framework ويمكنك الوصول لكل النماذج الخاصة به على هذا الرابط ، وقد وضعته عندي بهذا الشكل حتى اسهل على القارئ الوصول للملف بشكل سريع دون البحث عن النموذج نفسه وسط كل نماذج اطار عمل مايكروسوفت. 

روابط ذات صلة:

سلسلة صوتية عن ادارة المشاريع بمنهج اسكرم باللغة العربية.

مجموعة فيديوهات عن سيناريو الحوار باللغة العربية.

مواجهة العملاء -دروس وعبر- كلمات يكرهها العميل.

مواجهة العملاء -دروس وعبر- وثائق يكرهها العميل.

هناك تعليقان (2):

  1. نحن مؤسسة مساندة نقوم بتقديم خدمات لتنظيم أعمالك وتحقيق المبيعات، حيث نقوم بتقديم برنامج التحول الرقمي الذي يساعدك في تحويل أوراق شركتك من مجرد اراق الى ملفات على الحاسب الالي حيث ان التحول الرقمي هو البرنامج المناسب لمن يبحث عن التحديث والنظام
    كما نقوم في مؤسسة مساندة بتقديم خدمات ادارة المشاريع حيث اننا لدينا خبراء في السوق متخصصين في ادارة المشاريع
    https://mosandah.com.sa/ar

    ردحذف

Subscribe to RSS Feed Follow me on Twitter!