تقدير الوقت والجهد في المشاريع البرمجية: لماذا تخطئ التقديرات وكيف تصبح أدق

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

1. لماذا تخطئ التقديرات البرمجية

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

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

2. مخروط عدم اليقين: الدقة تتحسن مع تقدم المشروع

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

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

3. تفكيك العمل إلى أجزاء قابلة للتقدير

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

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

4. التقدير بثلاث قيم بدل رقم واحد

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

• التقدير المتفائل: المدة إذا سارت الأمور كلها بسلاسة دون عوائق.
• التقدير الأرجح: المدة المتوقعة في الظروف المعتادة مع عوائق محدودة.
• التقدير المتشائم: المدة إذا ظهرت المشكلات المحتملة المعقولة، لا الكوارث النادرة.

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

5. التقدير النسبي ونقاط القصص في الفرق الرشيقة

تستخدم كثير من الفرق التي تعمل بمنهجيات رشيقة أسلوب التقدير النسبي، حيث لا تُقدر المهام بالساعات بل بوحدات نسبية تُسمى «نقاط القصص» Story Points، تعبّر عن الحجم والتعقيد وعدم اليقين معًا. فبدل أن يسأل الفريق «كم ساعة تحتاج هذه المهمة؟»، يسأل «هل هي أكبر من تلك المهمة التي أنجزناها أم أصغر؟». والبشر عادة أدق في المقارنة منهم في التقدير المطلق.

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

6. عرض التقدير على الإدارة والتعامل مع تغير النطاق

طريقة عرض التقدير لا تقل أهمية عن دقته. فالتقدير الذي يُقدم رقمًا واحدًا يُفهم غالبًا كالتزام قاطع، ثم يتحول أي تجاوز له إلى أزمة ثقة. ومن الممارسات التي تجعل التواصل أوضح:

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

الخلاصة

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