سؤال يبدو بسيطًا، لكنه يضع المطوّر أمام معضلة حقيقية. فكيف تقدّر الوقت بدقة وأنت لا تملك كل التفاصيل بعد؟ خطوات عملية لتقدير يثق به فريقك.
«كم تحتاج من الوقت لإنهاء هذه المهمة؟»
سؤال يبدو بسيطًا، لكنه يضع المطوّر أمام معضلة حقيقية:
- إن أجاب بسرعة، التزم بموعد قد لا يستطيع الوفاء به.
- وإن تأخر في الإجابة، بدا وكأنه غير جاهز أو لا يفهم المهمة.
وبين الاستعجال والتردد، يقع كثير من المطورين في فخ التقديرات المتسرعة التي تتحول لاحقًا إلى ضغط وتأخير وفقدان للثقة. فكيف تقدّر الوقت بدقة وأنت لا تملك كل التفاصيل بعد؟
لا تقدّر «المهمة»، قدّر أجزاءها
عبارة مثل «ربط الواجهة بالنظام» تبدو مهمة واحدة، لكنها في الحقيقة تخفي تحتها عشرات التفاصيل:
- 1تحليل المتطلبات.
- 2تصميم الحل.
- 3تطوير الواجهة.
- 4ربطها بالـ API.
- 5الاختبار والمراجعة.
حين تقدّر المهمة كاملة دفعة واحدة، فأنت تخمّن. أما حين تقسّمها إلى خطوات صغيرة، فتصبح كل خطوة قابلة للتقدير بشكل معقول.
قاعدة: كلما صغرت الخطوة، قلّ احتمال أن تفاجئك.
اعرف ما تجهله قبل أن تكتب الرقم
قبل أن تجيب، توقف قليلًا واسأل نفسك عمّا ينقصك من معلومات:
- هل الـ API جاهز فعلًا أم ما يزال قيد التطوير؟
- هل التصميم معتمد نهائيًا أم قابل للتغيير؟
- هل هناك صلاحيات أو حالات استثنائية لم تُذكر بعد؟
كل سؤال بلا إجابة هو مصدر محتمل للتأخير، وتجاهله لا يلغيه بل يؤجل ظهوره إلى وقت أسوأ. لذلك تعامل مع تقديرك في هذه المرحلة على أنه توقّع مبدئي مبني على المتاح، لا موعد نهائي مؤكد، وصارح من حولك بذلك.
الكود ليس كل القصة
من الأخطاء الشائعة أن يحسب المطوّر الوقت الذي سيقضيه في كتابة الكود فقط. لكن الكتابة غالبًا أقصر جزء من الرحلة، فهناك أيضًا:
- تصحيح الأخطاء.
- تغيّر المتطلبات في منتصف الطريق.
- مشكلات التكامل مع الأنظمة الأخرى.
- ملاحظات المراجعة.
- الانتظار أحيانًا لردّ من فريق آخر.
لذلك احسب هذه المخاطر ضمن تقديرك، واجعل الهامش الإضافي متناسبًا مع مستوى الغموض الفعلي:
- للمهمة الواضحة: هامش صغير.
- للمهمة الضبابية: هامش أكبر.
أما إضافة نسبة ثابتة على كل المهام دون تفكير، فهي تخمين في هيئة حساب.
قدّم نطاقًا بدل رقم واحد
الرقم الواحد يتحول سريعًا في ذهن الآخرين إلى وعد، وأي تجاوز له يُعدّ إخلالًا بالالتزام. أما النطاق الزمني فيعبّر عن الواقع بصدق.
فبدلًا من أن تقول: «سأنهي المهمة خلال يومين»، جرّب أن تقول:
«أتوقع أن تستغرق المهمة من يومين إلى أربعة أيام بحسب المعلومات المتاحة، وسأعطيك تقديرًا أدق بعد مراجعة تفاصيل التكامل.»
بهذه الجملة تكون قد:
- 1قدّمت توقعًا واقعيًا.
- 2بيّنت سبب عدم اليقين.
- 3حدّدت متى سيصبح التقدير أدق.
وهذا ما يحتاجه الفريق فعلًا ليخطط بثقة.
التقدير يتطور مع فهمك
التقدير الجيد ليس رقمًا يُكتب مرة واحدة ثم يُدافع عنه مهما حدث. إنه يتغيّر كلما فهمت المهمة أكثر. فإذا اكتشفت تعقيدًا جديدًا أو معلومة غيّرت حجم العمل، فأبلغ الفريق مبكرًا واشرح أثر ذلك على الموعد المتوقع.
التأخير الذي يُعلن مبكرًا قابل للإدارة وإعادة الترتيب، أما الذي يُكتشف يوم التسليم فيكلّفك أكثر من الوقت: يكلّفك الثقة.
قبل أن تجيب: قائمة سريعة
- هل قسّمت المهمة إلى خطوات صغيرة قابلة للتقدير؟
- هل سمّيت ما لا أعرفه بعد؟
- هل حسبت العمل الذي يتجاوز كتابة الكود؟
- هل الهامش الذي أضفته متناسب مع غموض المهمة؟
- هل أقدّم نطاقًا، وأوضّح متى سيصبح أدق؟
الخلاصة
لا يُقاس المطوّر المحترف بقدرته على التنبؤ بكل ما سيحدث، فهذا مستحيل. بل يُقاس بقدرته على:
- 1فهم نطاق العمل.
- 2تسمية المجهول.
- 3حساب المخاطر.
- 4التواصل بصدق كلما تغيّرت الصورة.
والفريق في النهاية لا يبحث عن مطوّر يعد بأقصر مدة، بل عن مطوّر إذا قال موعدًا، وثق به الجميع.
