ليش تتأخر المشاريع البرمجية؟ عبدالله عبدالرحيم الكندي وتقدير الوقت بواقعية

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

خرافات عن الرقم نفسه

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

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

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

خرافات عن الفريق والتعديلات

الخرافة الرابعة: «نضيف مبرمجين ونلحق». هذي لها اسم في عالم البرمجيات: قانون بروكس، من كتاب فريد بروكس الشهير «The Mythical Man-Month»، وخلاصته إن إضافة ناس لمشروع برمجي متأخر تأخّره أكثر. لأن الجدد يحتاجون وقت يفهمون، ووقت القدامى يروح في شرح وتنسيق، وكل شخص جديد يضيف خطوط تواصل جديدة مع كل اللي قبله.

الخرافة الخامسة: «تعديل صغير». زر إضافي في الشاشة صغير. لكن «خلّ العميل يقدر يلغي طلبه» يعني حالة جديدة في قاعدة البيانات، واسترداداً من بوابة الدفع، وإشعاراً للمتجر، وتعديلاً في التقارير. والتعديلات الصغيرة لما تتراكم بدون ما ينعاد التقدير، تصير السبب الأول للتأخير، ولها اسم معروف: زحف النطاق (scope creep). والعلاج مو إنك ترفض كل تعديل، العلاج إن كل طلب جديد يجي معه سؤال صريح: هذا يضيف كم يوم، وتبيه بدل وش أو فوق وش؟

خرافات عن خط النهاية

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

والخرافة السابعة: «التأخير يظهر في الأخير». الحقيقة إنه يتراكم من الأسبوع الأول، يوم بعد يوم: اجتماع تأجّل، وملف تأخر، وقرار ينتظر رد. ويبان فجأة في الأخير لأن ما أحد كان يقيس التقدّم مقابل الخطة كل أسبوع.

الطريقة الواقعية: تقدير ما يخدع صاحبه

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

لما يصير التأخير: قلّص النطاق، لا تمطّ الموعد

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

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