فكرت كثيراً في الموضوع الذي أفتتح به مدونتي باللغة العربية وبعد تفكير عميق لم أجد أفضل من موضوع (تقدير البرمجيات). هذا العلم قلما أجد مطوراً أو مهندس برمجيات يعرفه معرفة تامة. صدقوني قلة قليلة جداً من يعرف قواعد وأصول هذا العلم النفيس.
في البداية كما تعلمنا من علمائنا أن من بركة العلم أن ننسبه لأهله. ولهذا فأنا لا أقول أنني أكتب كل سطر من رأسي بل إن هذه المقالات مستوحاة من كتاب لــ (ستيف ماكونيل) بعنوان (Software Estimation : Demystifying the Black Art).
فنقول متوكلين على الله ومستعينين به وبحوله وقوته:
ما هو علم تقدير البرمجيات؟
قد يظن القاريء العزيز أنه يعرف ما هو تقدير البرمجيات أو بالإنجليزية (Software Estimation)، وبالطبع إذا كنت تقرأ هذا المقال فلا شك إما أنك مهتم بهذا العلم أو أنك تريد أن تعرف عن هذا العلم أو تظن أنك تعرف ما هو تقدير البرمجيات. ولكن الحقيقة المرة أن معظم هؤلاء لا يعرف ما هو تقدير البرمجيات بحق.
إذا قمنا بفتح أي قاموس يتكلم عن هذه اللفظة فستجد أنه يصف عملية التقدير بأنها عملية تقدر شيئاً ما تقديراً قابلاً للتغيير لأنه تقدير مبدأي. دعنا نركز قليلاً فيما قلت ها هنا وخاصةً: قابلاً للتغيير ومبدأي.
هل عندما يطلب منك مديرك في العمل أن تقدر الوقت اللازم لشيء ما، هل هو يطلب منك تقديراً قابلاً للتغيير ومبدأي؟ في الغالب لا، لأنه يطلب منك في الحقيقة خطة محددة وتعهد ما لكي تنفذ هدفاً محدداً.
تعالوا لنضرب مثالاً:
المدير: أحمد أريد منك تقديراً لهذا البرنامج وكم سيكلفنا من الوقت؟ هذا هو الملف الذي به كل المعلومات. تفضل.
أحمد: حسناً. سأبلغك بردي غداً إن شاء الله.
المدير (غداً): شكراً يا أحمد لقد قرأت ملفك بخصوص تقدير البرنامج وأرى أن شهراً يعتبر وقتاً مناسباً. ابدأ في البرنامج على بركة الله.
المدير (بعد شهر ونصف) وبحدة شديدة: أحمد لماذا كل هذا التأخير؟! لقد قمنا بتخطي المهلة المحددة!
أحمد: في الحقيقة لقد كان هذا تقديراً عاماً قابلاً للتغيير. لقد ظهرت متغيرات كثيرة أثناء عمل المشروع. ولهذا زاد الوقت وربما يمتد لشهر إضافي.
المدير بصوت مرتفع للغاية: ماذا؟! لقد قمت بنشر حملاتي التسويقية للبرنامج منذ فترة على أن يتم الإصدار من نصف شهر مضى وأنت تطلب مهلة إضافة تقدر بـ 100% من الوقت الذي مضى!
في الحوار السابق اتضحت عدة أخطاء ارتكبت من المبرمج والمدير. وسنتكلم فيها فيما بعد. ولكن ما يهمنا الآن والشاهد هو أن المدراء عندما يسألون المبرمجين أو المسئولين عن تقدير البرمجيات عن المدة الزمنية اللازمة لهذا المشروع فإنهم عادة ما ينتظرون خطة وتعهد تام من أجل تحقيق هدف معين وهذا لقلة وعيهم بهذا العلم بالإضافة إلى أنهم لا يميزون بين المصطلحات المختلفة كالتقدير الزمني، التعهد أو الالتزام، الهدف، والتخطيط!
لذا وجب علينا أن نقوم بتعريف ثلاثة مصطلحات: التقدير، التعهد، والهدف.
ما هو التعهد وما هو الهدف؟ وما هي العلاقة بين تقدير البرمجيات وبينهما؟
في الحقيقة إن التعريف الذي ذكرناه بخصوص التقدير في البداية من القاموس هو تعريف صحيح ولعلنا نكتبه مرة أخرى مع بعض التنقيحات فالتقدير للبرمجيات يعني تقدير البرمجيات زمنياً أو مالياً مع إضافة أن هذا التقدير يتفاعل مع عوامل عدة منها أهداف العمل، التعهدات، والتحكم في مجريات المشروع.
أما الهدف فهو: نتاج أساسي لأهداف العمل وغالباً ما يكون هدف مستقبلي مستقل عن عملية التقدير تماماً.
تعالوا نأخذ بعض الأمثلة للأهداف:
* علينا بإصدار النسخة الثانية في نهاية الشهر الجاري من أجل اللحاق بمؤتمر جايتكس المقام في الإمارات.
* هذه الوظائف عليها أن تنتهي قبل مطلع الشهر الجاري لكي نستطيع التوافق مع قرارات الحكومة الجديدة.
* زادت المصاريف بصورة ملحوظة ولهذا تحددت ميزانية المشروع بمئة ألف جنيه.
كما رأينا فأهداف المدراء لا علاقة لها من قريب ولا بعيد بالتقديرات فهي تطلق هكذا ولا علاقة واضحة بينهما. في الحقيقة كما أسلفت أن متغيرات العمل قد تفرض بعض الأهداف التي يعتبرها أصحاب الأعمال واجبة التحقيق. ولكن كون أن هذه الأهداف واجبة التحقيق في نظرهم فهذا لا يعني مطلقاً أنها ممكن أن تنفذ. وهذه حقيقة يجب أن يعيها متخذي القرار وأن يتفهمها من يتصدى لهذا العلم أيضاً.
أما التعهد أو الالتزام: فهو بكل بساطة وعد من أجل تحقيق هدف معين في تقدير زمني معين. والتعهد عادة ما يكون أشد إلزاماً من التقدير الزمني المطلق فإياك أن تخلط بينهما.
وبعد أن عرفنا هذه الفروق. هل ما زلت تعتقد أنك تعرف ما هو تقدير البرمجيات؟! انتظر .. سندخل في نقطة أخرى.
هل هناك علاقة بين تقدير البرنامج والتخطيط؟
ربما يكون التقدير والتخطيط موضوعان مترابطان ولكنهما مختلفان تماماً. فالتقدير ليس بتخطيط. والتخطيط ليس بتقدير.
فيمكننا القول بأن التقدير هو عملية لا تعتمد على أي شيء، مجرد عملية تحليلية ولا تكون متحيزة لأي عامل من العوامل. أما عملية التخطيط فهي عملية متحيزة لعوامل دون عوامل، كما أنها تستخدم للوصول لهدف محدد بعينه دون أخر.
والفارق بينهما واضح فكوني أقوم بعملية تحليلية لكم سيستغرق هذا المشروع من باب العلم مغاير تماماً لوضع خطة دقيقة لتنفيذ هدف معين في ظروف معينة.
النقطة الثانية هي أن التقدير يمثل الأساس لعملية التخطيط. ولكن التخطيط ليس شرطاً أبداً أن يوافق التقدير المكتوب.
فعلى سبيل المثال إذا كانت التقديرات بعيدة تماماً عن الأهداف (لاحظ الفرق بين التقدير والهدف كما أسلفنا) فعلى عملية التخطيط أن تضع هذا في الحسبان وتفرض نسبة عالية من المخاطرة. وأما إذا كانت التقديرات قريبة من الأهداف فهذا يعني أن عملية التخطيط سوف تحمل القليل من المخاطرة.
ولهذا فكلما زادت دقة التقدير كلما كانت عملية التخطيط أفضل. انظر العلاقة الهامة لتعرف أهمية علم تقدير البرمجيات.
كيف تتحدث مع مديرك عندما يطلب منك تقدير مشروع ما زمنياً اومالياً؟
ضربنا مثالاً سابقاً عن هذه النقطة ولكن نعود لنقوم بتفصيله ووضع مثال أخر. لنفرض الحوار التالي:
المدير: كيف تقدر هذا المشروع؟ إننا نريده في خلال ثلاثة أشهر من الآن لكي نلحق بالمؤتمر قبل البدء.
مدير الفريق: دعني أرى ثم أرجع لك …
وبعد فترة …
مدير الفريق: سيكلفنا سبعة أشهر لكي نقوم بإنهاء كل المتطلبات المطلوبة في المشروع
المدير: ألا تفهم ما قلته لك .. إننا نريده أن ينتهي في ثلاثة أشهر وليس سبعة!!
وربما يترك المدير النقاش وهو يقول لنفسه ما هذا الرجل! ألا يفهم ما تطلبه متطلبات العمل!
وربما يترك مدير الفريق النقاش وهو يقول لنفسه ما هذا الجهل المطبق ياله من مدير غير طبيعي! كيف نقوم بتطبيق شيء يحتاج لسبعة أشهر في ثلاثة أشهر!
أخوتي ما حدث في هذا النقاش من صدام ناتج عن قلة إدراك المدير بالمصطلحات التقنية المتشعبة التي سقتها لكم في البداية من تقدير وأهداف وعهود وخطط. وأيضاً ما حدث من صدام ناتج عن قلة وعي مدير الفريق بهذه الجزئية والتي تحتم عليه أن يقوم بتوعية المدير على نحو يستطيع من خلاله التواصل لحل مشترك يرضي جميع الأطراف.
فهذا هو النقاش المثالي الفعال:
المدير: كيف تقدر هذا المشروع؟ إننا نريده في خلال ثلاثة أشهر من الآن لكي نلحق بالمؤتمر قبل البدء.
مدير الفريق: دعني أتأكد من شيء ما أولاً .. هل تنتظر كل الخصائص 100% بعد ثلاثة أشهر أم أنك تستطيع التنازل عن بعض منها في مقابل تسليمك جزء من البرنامج في المدة الزمنية المحددة؟! بمعنى أخر ما الأهم بالنسبة لك أن تكتمل الخصائص كلها أم أن يصبح معك منتج تسوق له إلى أن تتم كل الخصائص؟!
المدير: أن يكون معي منتج للتسويق. ونتمنى وجود الخصائص كاملة 100% إن أمكن.
مدير الفريق: سنحاول أن نسلمك 100% في وقت التسويق ولكن ماذا لو لم يكن ذلك ممكناً، هل نقوم بتسليمك ما انتهى من الخصائص من أجل التسويق أم نقوم بتعديل موعد الإصدار لما بعد موعد التسويق؟
المدير: علينا أن نلحق الموعد المحدد للتسويق لذا سأختار أن يكون معي أي شيء حتى وإن لم تكن كل الخصائص مكتملة بعد.
مدير الفريق: حسناً، سأقوم ببناء خطة لكي أوفر لك أكبر قدر ممكن من الخصائص في خلال هذه المدة قبل موعد التسويق.
طبعاً لا تعليق على النقاش .. فقد ظهرت المشكلة تماماً وكيف استطاع مدير الفريق حلها بكل بساطة عن طريق وعيه التام بعقلية المدراء وكيفية التحكم في رغباتهم على نحو لا يثير المشاكل ويساعد فريق العمل على الإنتاج بكفاءة أيضاً. وهذا ناتج من وعي مدير الفريق بعلم تقدير البرمجيات وأهميته.
لذا فعليك أن تأخذها قاعدة عريضة يا من ستكون مسئولاً عن التقدير … إذا سُئلت عن تقدير شيء ما فعليك أن تسأل هل المطلوب هو تقدير أم المطلوب خطة لتحقيق الهدف؟ فالبون بينهما شاسع شاسع.
سنتكلم في المرة القادمة عن أمور أكثر تعمقاً في هذا العلم وفي تعريفه قبل الدخول في تفاصيل أكبر وأعمق .. ابقوا معنا.
المصدر: مدونتي