أساليب تقدير الزمن في المنتجات الرقمية

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

واليوم نحاول فهم عدد من الأساليب الأخرى ضمن سلسلة مقالاتنا عن تقدير زمن التسليم في المنتجات الرقمية؛ وبالمثال يتضح المقال! 

ثانياً- أسلوب التقدير الجماعي Corporate Estimating

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

مثلاً إذا طرحنا سؤالاً على مطورين اثنين؛ الأول يعمل بوظيفة Back end developer

والثاني يعمل بوظيفة Front End Developer فعلى الأرجح سيختلف التقدير الزمني باختلاف وظيفة المطور الذي يجيب عن السؤال.

لكن إذا كان كلا المطورَين ضمن مجموعة نقاش واحدة، وقال الشخص الأول:  

“أعتقد أنّي سأنهي المهمة خلال ساعتين“. 

وعلى افتراض أنه يتحلى بشخصية خبيرة أو مهيمنة أو مصدر ثقة، فغالباً سيجبيه الثاني: “نعم! أعتقد أنّها ستحتاج لساعتين أو 3 ساعات”. 

 

لكن لو أجاب المطور الأول عن سؤالنا: كم برأيك سيتطلّب العمل على هذه المهمّة؟ بقوله: 

“أعتقد أنه سيلزمنا 3 أيام“.. 

فعلى الأرجح سيكون رد المطور الثاني مقارباً لذلك.. 

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

تحديات التقدير الجماعي

• انحياز التقديرات الفرديّة بعضها لبعض، وتأثّرها بالآراء المختلفة أثناء النقاش.
• هيمنة الأقوى، لكونه:
  1. مصدر ثقة وخبرة.
  2.  يملك صلاحيات ويفرض رأيه.
  3.  شخصية قويّة قادرة على المبادرة والإجابة على أسئلة التقدير الزمني بسرعة قبل غيره من الفريق.
• لا يمكن الحصول على أجوبة شفّافة في بيئة عمل غير شفّافة، مبنيّة على فرض الآراء على الموظفين سواء من الإدارة أو بين الموظفين أنفسهم.

   

هل التقدير الجماعي أفضل من التقدير الفردي؟

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

فلا المطورون وحدهم، ولا مالك المنتج وحده، ولا الزبون وحده يمتلك صورة كاملة عن طبيعة المهمّة المطلوب إنجازها بكل جوانبها. 

بمعنى آخر، التقدير الجماعي يمثّل فرصة للنقاش حول المهمة لإتمام فهمها، وبالتّالي الوصول بشكل جماعي موحّد لتقدير أقرب للدقّة.. 

مثلاً عندما يقول فرد ما: إنّ المهمة بحاجة لـ 5 ساعات، بينما يقول شخص آخر: إنها تحتاج لساعتين؛ فثمة احتمال أنّهما لا يتحدّثان عن الأمر نفسه! أو أنّ كلّ منهما يعكس فهمه لطبيعة المهمة من موقعه الوظيفي.. 

وإذا كان فهم حدود المهمّة والمطلوب فيها، لايزال متبايناً بين الأفراد، سيتمكن الفريق من حل الأمر بمزيد من النقاش؛ فالتقدير الجماعي مرتبط بالحوار والتواصل الفعّال. 

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

ثالثاً – أسلوب التقدير بالمقارنة Analogous Estimating 

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

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

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

الخلاصة: ما حصل في الماضي مؤشّر جيد لما قد يحصل في المستقبل، لكن لا بدّ من مراعاة درجة التشابه بين المهمتين، والظروف والموارد الحالية.

رابعاً – التقدير بالبارامترات Parametric Estimating

البارامترات هي جميع العوامل المؤثّرة في عمل ما، والتقدير بالبارامترات هو إدراج جميع هذه العوامل المؤثّرة، ضمن معادلة رياضية، للحصول على تقدير زمني دقيق.

مثال:

[عدد الأفراد (×) عدد القطع التي ينتجها الفرد (-) كميّة المواد الخام المتوفّرة]

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

في حين أن هذه الطريقة تنطوي على مخاطرة عالية في قطاع تطوير البرمجيات، الذي يعدّ عملاً بشرياً بالمجمل وغير روتيني.

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

خامساً – التقدير النسبي Relative Estimating

هو تقدير فطري أيضاً! مثلاً عندما نقود سيارة ونحاول تقدير مسافة الأمان مع السيارة التي أمامنا، أيّهما أسهل؟

أن أقول: المسافة هي 355 سم

أو: المسافة تتسع لسيارة واحدة تقريباً

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

لكنّ الزمن وحدة قياس مطلقة، فهل يمكن استخدام وحدة قياس نسبية بديلة لتسهيل عملية التقييم ورفع احتمالية الدقة؟

بالطبع نعم، سنحدّد وحدة قياس نسبية أسهل ودقيقة بما فيه الكفاية ضمن مهام التطوير البرمجي؛ ثم يمكننا العودة لتحويلها إلى ساعات عند تقدير الزمن في المنتجات الرقمية.

ختاماً..

مرّت معنا أساليب متعددة للتقدير، وبوسعنا أن نمزج فيما بينها سعياً للوصول إلى طريقة جيدة وعملية لتقدير الزمن في المنتجات الرقمية كما يلي: 

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

• ينبغي أن نستعمل وحدة قياس نسبيّة سهلة الاستخدام وكافية للتقدير، بدلاً من وحدة قياس الزمن المطلقة. 
• أما التقدير بالبارامترات فيجب تجنُّب استخدامه تماماً لأنّه لا يناسب طبيعة المنتجات الرقمية. 

خلاصات في أسئلة: