في المرة السابقة تحدثنا عن علاقة تقدير البرمجيات بعلم الاحتمالات. وعرفنا الكثير عن هذا الجانب. في هذه المرة سنتحدث عن علاقة تقدير البرمجيات بالتحكم في المشروع ومجرياته.
تقدير البرمجيات والتحكم في المشروع
في كثير من الأحيان عند التحدث عن علم تقدير البرمجيات يتم التحدث عنه على أنه علم للتوقعات. أي أننا نستخدمه لنتوقع نتيجة المشروع. وهذا ليس بصحيح وخطأٌ شائع.
في الحقيقة عندما نقدر المدة الزمنية أو القيمة المالية لمشروع ما. وعندما نقوم بالتعهد والالتزام بتسليم هذا المشروع في الوقت المحدد تحت المظلة المالية المحددة. فإننا في الحقيقة لا يمكننا الوصول للأهداف المرجوة من المشروع إلا بعد أن نقوم بالتحكم في المشروع جيداً.
التحكم في المشروع على سبيل المثال وليس الحصر يتمثل في إلغاء المتطلبات الغير ضرورية في المشروع، إعادة تعريف وتفصيل متطلبات وخصائص المشروع، إيجاد فريق عمل أقوى وأكثر خبرة من الموجود .. وهكذا.
بالإضافة للتحكم في المشروع وهذه الأنشطة المختلفة التي ذكرناها هناك الكثير من الأشياء التي قد تؤثر على المشروع والتي لا تكون واضحة في البداية مثلاً تحويل جزء من الفريق من أجل دعم مشروع قديم أو طلب الإدارة من الفريق إخراج نسخة مؤقتة من أجل عرضها على أحد العملاء المهمين … إلخ.
كل هذه الأحداث التي تحدث أثناء المشروع فإنها وبدون شك لا يمكن أن تكون مثل الفرضيات التي فرضت في بداية تقدير البرنامج. فعلى سبيل المثال: الخصائص تتغير، الفريق يتغير والأولويات تتغير لمتطلبات السوق وغيرها. وبالتالي فمن المستحيل أن تقوم بالربط بين التقدير الأولي وبين الخارج النهائي من المشروع لأنه في الحقيقة المشروع الذي تم تسليمه في نهاية الفترة أصبح مختلف تماماً عن المشروع الذي تم تقديره من البداية بسبب كثرة الأحداث التي تطرأ عليه.
ولهذا عملياً فعندما يتم تسليم مشروع ما بـالرقم التقريبي لعدد أعضاء الفريق وبالرقم التقريبي للمدة الزمنية والبرقم التقريبي للميزانية فإننا نقول أن المشروع قد وافق التقدير على الرغم من الشوائب والأحداث المتلاحقة التي حدثت داخل المشروع كما أسلفنا.
مما سبق يتضح أن التقدير الجيد ليس هو التوقع الجيد لأنه لا علاقة لهذا بذاك. ولكن التقدير الجيد هو الذي يساعد المشروع على النجاح وتحقيق الأهداف.
ولهذا فعلينا التحدث باستفاضة عن الدور الأساسي والصحيح للتقدير.
الدور الأساسي والصحيح لتقدير البرمجيات
عادةً ما أحب ضرب الأمثلة ولهذا أعجب جداً بأي كتاب يشرح بهذه الطريقة فالأمثلة عادة تقرب للذهن كل الأمور وبل وتقرب للذهن ما قد يصعب استيعابه من الوهلة الأولى.
لذا تعالوا لنضرب مثالاً:
لنفترض أنك ستسافر في رحلة وعليك أن تحدد ما هي الحقيبة المناسبة التي سوف تأخذها. لديك حقيبة صغيرة وهي التي تحبها لأنها صغيرة وسهلة الحمل ويمكنك أخذها معك في الطائرة. وهناك أخرى كبيرة وهي مزعجة بالنسبة لك ولن تستطيع اصطحابها في الطائرة وبالتالي ستضطر لوضعها في المكان المخصص للحقائب وستنتظرها بعد النزول من الطائرة على السير المخصص للحقائب وبهذا سوف تتأخر نوعاً ما.
وضعت ثيابك ووجدت أنها سوف تدخل بالكاد في الحقيبة الصغيرة. ماذا ستفعل؟!
سوف تقوم بكل المحاولات لإدخال ثيابك في الحقيبة، ستجلس على الحقيبة مرة، وستضغط عليها مرة، وستقوم بهزها مرة، وستستغل كل فراغ مهما كان صغيراً. حتى تنجح في مهمتك. ولكن إن فشلت، فلن يبقى لك إلا مواجهة خيارين: الأول أن تترك بعض الملابس خارجاً، والثاني أن تستبدل الحقيبة الصغيرة بالكبيرة.
البرمجيات بها نفس المشكلة بالضبط. عادة ما يواجه مخططي المشروع نفس المشكلة عندما يجدون أن تقدير البرنامج زمنياً كان أو مالياً بعيد كل البعد عن الهدف المطلوب تحقيقه. إذا كانت المسافة بين الهدف وبين تقدير البرنامج صغيرة، فيمكن لمخطط المشروع أن يضيق المسافة بالتحكم الجيد في جدول المشروع مثلاً أو تقليل بعض المزايا المطلوبة في المشروع على سبيل المثال. أما إذا كانت المسافة بين الهدف وبين تقدير البرنامج كبيرة إذن يجب إعادة النظر في الأهداف المراد تحقيقها.
1. الغرض الأساسي من التقدير ليس التكهن بنتيجة المشروع أو توقعها ولكن هو الإجابة على السؤال التالي: هل الأهداف المرجو تحقيقها مرنة نوعاً ما حتى يمكن التحكم في المشروع بصورة أو بأخرى لتحقيقها أم لا؟
2. ليس المطلوب أن يكون التقدير دقيق 100% ولكن المطلوب أن يكون التقدير مفيداً. فعندما نمتلك تقديراً جيداً، وإدارة حكيمة للمشروع، وتحديد جيد للأهداف. يمكنك أن تصل بالمشروع لبر الأمان ويمكننا حينها القول أننا حققنا ما تم تقديره من قبل.
في المرة القادمة سأختبرك لتعرف هل أنت تستطيع تقدير البرمجيات بطريقة جيدة أم لا؟! .. ابقوا معنا
المصدر مدونتي