كم سيستغرق مشروع البرنامج؟ قراءة التقديرات بصدق
لا أحد يستطيع أن يخبرك بدقة كم سيستغرق مشروع برمجيات وهو ما زال فكرة، ومن يعطيك تاريخًا واحدًا واثقًا في الاجتماع الأول يخمّن. فقد وجد ستيف ماكونيل، المؤلف المتخصص في تقدير المشاريع البرمجية، أن التقديرات الموضوعة في مرحلة الفكرة الأولى قد تخطئ بمعامل أربعة في أيٍّ من الاتجاهين، وهذا في أفضل الأحوال ومع مقدّرين مهرة. والجواب الصادق نطاقٌ يضيق كلما حسم الاستكشاف والمتطلبات حدود المشروع.
لذا فالسؤال المفيد ليس «كم يستغرق؟» بل «ما النطاق، وعلى أي افتراضات بُني، ومتى نستخدم الجزء الأول؟».
الجواب المختصر
- التقديرات المبكرة نطاقات لا تواريخ، وقد يمتد النطاق في مرحلة الفكرة إلى ستة عشر ضعفًا بين أدناه وأعلاه.
- يضيق النطاق كلما اتُّخذت القرارات: تعريف معتمد للمنتج، ثم متطلبات مكتملة، ثم تصاميم معتمدة.
- تتوقف المدة على عدد الإجراءات، والتكاملات، ونقل البيانات، والمحتوى بلغتين، وسرعة قراراتك أنت.
- التقدير الجيد يسرد افتراضاته واستثناءاته والمدخلات التي يحتاجها منك.
- لتنتهي أسرع، ابنِ أقل في النسخة الأولى. أما إضافة أشخاص في وقت متأخر فتزيد التأخير غالبًا.
«التاريخ الواحد في الاجتماع الأول ليس تقديرًا، بل أسلوب مبيعات. اطلب نطاقًا والافتراضات التي يقوم عليها، وتوقّع أن يضيق النطاق كلما اتخذت قراراتك.» — عبدالقادر وهيبة، مؤسس «ذوات» ورئيسها التنفيذي
لماذا تكون التقديرات المبكرة غير مؤكدة إلى هذا الحد
في البداية يكون كل ما يحدد حجم العمل تقريبًا مجهولًا: أي المزايا، وكيف تتصرف كلٌّ منها، وما الاستثناءات، وكيف تبدو البيانات، وبأي الأنظمة يجب أن يتصل. ولا يمكن أن يكون التقدير أكثر يقينًا من المشروع الذي يصفه.
ويُظهر «مخروط عدم اليقين» الذي عرضه ماكونيل في ورقة نشرتها شركة Construx عام 2010 كيف يضيق الخطأ مع تقدّم المشروع عبر محطاته:
| موضع المشروع | قد يتراوح التقدير من | إلى |
|---|---|---|
| الفكرة الأولى | 0.25 ضعف | 4 أضعاف |
| تعريف المنتج المعتمد | 0.5 ضعف | ضعفين |
| اكتمال المتطلبات | 0.67 ضعف | 1.5 ضعف |
| اكتمال تصميم الواجهات | 0.8 ضعف | 1.25 ضعف |
وفي الورقة عبارتان تستحقان الحفظ: أن المخروط يمثّل أفضل دقة ممكنة في التقدير، فالتقدير المتهاون أسوأ منه؛ وأنه لا يمكن أن تكون أدق من ذلك، بل يمكن فقط أن تكون أكثر حظًا. ونصيحة ماكونيل للمؤسسات أن تتجنب الالتزامات حتى يضيق المخروط.
والخبر الجيد أن المخروط يضيق مبكرًا؛ إذ يلاحظ ماكونيل أن الجزء الأكبر من تضيّقه يحدث خلال أول 20 إلى 30% من المدة الزمنية الكلية للمشروع. وهذا بالضبط ما تشتريه لك مرحلة الاستكشاف والمتطلبات المكتوبة كما ينبغي.
ما الذي يحدد المدة فعلًا
- عدد الإجراءات: كل إجراء مستقل يدعمه النظام، كالطلبات أو الموافقات أو الفوترة، يضيف تصميمًا وبناءً واختبارًا.
- التكاملات: كل اتصال بالمحاسبة أو ببوابة دفع أو بواتساب أو ببوابة حكومية يأتي بتوثيقه واختباره ومفاجآته.
- نقل البيانات: تنظيف السجلات القديمة ونقلها يسير بالتوازي مع البناء، وكثيرًا ما ينتهي آخرًا. ويشرح مقال نقل بياناتك إلى النظام الجديد السبب.
- اللغتان: الواجهات والمحتوى والتقارير بالعربية والإنجليزية تحتاج إلى بناء وتدقيق في الاتجاهين.
- قراراتك ومدخلاتك: الإجابة عن الأسئلة، واعتماد التصاميم، والمحتوى، وبيانات الاختبار، ووقت الموظفين للاختبار، كلها على المسار الحرج للمشروع. فأسبوع في انتظار قرار أسبوعٌ يُضاف إلى النهاية.
- الاختبار والإطلاق: اختبار قبول المستخدم والتدريب والانتقال من طريقة العمل القديمة تأخذ وقتًا حقيقيًا، وهي أول ما يُضغط حين يتأخر الجدول.
كيف يبدو التقدير الجدير بالثقة
يوصي عبدالقادر وهيبة بأن تطلب ثلاثة أشياء مع كل تقدير: النطاق، والافتراضات التي يقوم عليها، وأول تاريخ تستطيع فيه استخدام شيء فعلًا. وفوق ذلك ابحث عن:
- مراحل بمحطات ترى فيها شيئًا يعمل، لا موعد تسليم نهائي فحسب.
- استثناءات مسرودة، مثل نقل البيانات أو المحتوى أو رسوم الأطراف الثالثة، لتعرف ما ليس داخل الرقم.
- مدخلاتك مسمّاة ومؤرخة: ما الذي يحتاجه المورّد منك، ومتى.
- خطة لإعادة التقدير بعد اكتمال الاستكشاف والمتطلبات.
- هامش احتياطي معلن، لا مخفيًا في مهام منفوخة.
واحذر العلامات المعاكسة: تاريخ واحد بلا نطاق، ولا أسئلة عن بياناتك أو تكاملاتك، ولا ذكر لما يحدث إن تأخرت قراراتك.
تاريخ ثابت أم نطاق ثابت أم سعر ثابت: اختر ما الذي يتحرك
الوقت والنطاق والكلفة مترابطة؛ تستطيع تثبيت واحد أو اثنين، لا الثلاثة معًا دون أن تدفع الجودة الفرق. فإن كان موعد الإطلاق غير قابل للتحريك، بسبب موعد نظامي مثلًا، فثبّت التاريخ ودع النطاق يتحرك، وقرّر مسبقًا أي المزايا يمكن أن تتبع في إصدار ثانٍ. وإن كان النطاق غير قابل للتفاوض، فاقبل أن يكون التاريخ نطاقًا. ويتناول مقال كم تكلّف البرمجيات المخصصة فعلًا جانب السعر من المعادلة نفسها.
كيف تنتهي أسرع دون أن تضحي بالجودة
- ابنِ نسخة أولى أصغر: أسرع طريق إلى إطلاق مبكر أن يكون ما تبنيه أقل. ويبيّن مقال النسخة الأولى من نظام منشأتك كيف تختار.
- قرّر بسرعة: سمِّ مالكًا واحدًا يستطيع الإجابة عن الأسئلة خلال يوم أو يومين.
- ابدأ العمل على البيانات في الأسبوع الأول: فهو أبطأ من المتوقع في كل مرة تقريبًا.
- أجّل التكاملات غير الضرورية: فقد يكفي تصدير ليلي في النسخة الأولى بدل اتصال لحظي.
- لا تضف أشخاصًا متأخرًا: فقد لاحظ فريدريك بروكس عام 1975 أن إضافة القوى العاملة إلى مشروع برمجي متأخر تزيده تأخرًا، لأن القادمين الجدد يأخذون من وقت من يؤدّون العمل.
حين يكون المشروع متأخرًا بالفعل
اطلب نطاقًا محدّثًا، وأسباب التأخر، وما الذي ما زال مجهولًا. ثم اختر عن وعي بين تحريك التاريخ، أو تقليص نطاق الإصدار الأول، أو الاثنين معًا. والتأخر الذي لا يفسّره أحد، والعروض التي تتوقف، والمورّد الذي يصمت، كلها علامات إنذار. ويتناول مقال كيف تنقذ مشروع برمجيات متعثرًا ما تفعله إن بلغ الأمر ذلك الحد.
أسئلة شائعة
لماذا تتأخر مشاريع البرمجيات كثيرًا؟ غالبًا لأن الالتزامات تُقطع بينما النطاق ما زال غير مؤكد، ثم يُكتشف عدم اليقين أثناء البناء. ويزيد على ذلك تأخر القرارات، وتمدد النطاق، وبطء نقل البيانات.
هل أستطيع الحصول على سعر ثابت وتاريخ ثابت؟ لنطاق محدد جيدًا نعم، وسيضمّن المورّد المخاطرة في السعر. أما في مرحلة الفكرة، فتثبيت الاثنين يعني عادةً سعرًا منفوخًا أو نطاقًا يُقلَّص لاحقًا. ثبّتهما بعد الاستكشاف، حين يصغر عدم اليقين.
كم يستغرق نظام أعمال نموذجي؟ يتوقف على الإجراءات والتكاملات والبيانات المعنية. وإرشاد «ذوات» نفسها أن موقعًا مركّزًا قد يستغرق بضعة أسابيع، ومنصة كاملة أطول، مع الاتفاق على جدول واقعي ومحطات واضحة قبل بدء العمل. فتشكّك في أي رقم دقيق يُعطى قبل تحديد النطاق.
هل يتضمن العقد غرامات على التأخير؟ قد تركّز الغرامات الانتباه، لكنها تدفع المورّدين أيضًا إلى نفخ التقديرات أو اختصار الاختبار. والمحطات المرتبطة ببرنامج يعمل، مع الدفع مقابل كل منها، تحميك عادةً على نحو أفضل.
هل يجعل النهج المرن (Agile) المشاريع أبطأ؟ لا. فالعمل المرن يسلّم برنامجًا قابلًا للاستخدام في دورات قصيرة، ويتيح لك تغيير الأولويات كلما تعلمت. وهو لا يزيل عدم اليقين، لكنه يكشفه مبكرًا، حين تكون معالجته أرخص.
المصادر: ستيف ماكونيل — مخروط عدم اليقين في تطوير البرمجيات (ورقة Construx، 2010) · فريدريك بروكس، The Mythical Man-Month (Addison-Wesley، 1975)
تريد تقديرًا تستطيع التخطيط على أساسه فعلًا؟ يبدأ نهج «ذوات» في البرمجيات المخصصة بمرحلة الاستكشاف، ليقوم النطاق الذي تخطط عليه على حدود مشروعك الحقيقية. احجز مكالمة.