مشروع التطبيق متأخر: كيف تقيس حجم التأخر الحقيقي وتقرر

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

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

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

لا تحتاج إلى خبرة برمجية لهذا القياس، بل إلى وثيقة النطاق أو العقد، وجهاز أو جهازين، وموظف يعرف العمل. نفّذه على خمس خطوات:

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

مثال افتراضي للتوضيح تطبيق حجز لمركز تدريب، نطاقه 36 بندًا (30 رحلة و6 شروط إطلاق). الموعد الأصلي انقضى، والمزود يقول «بقي شهر». بعد التجربة على النسخة التجريبية: 13 بندًا مقبولًا، و9 تعمل في المسار الأساسي فقط، و8 قيد العمل، و6 لم تبدأ. المقبول في آخر أربع دورات (كل دورة أسبوعان): 3 ثم 2 ثم 1 ثم 2، أي بمعدل 2 لكل دورة. المتبقي 23 بندًا ÷ 2 = نحو 12 دورة، أي قرابة 24 أسبوعًا بالإيقاع الحالي، لا أربعة أسابيع. وإن أضيفت أثناء العمل رحلة جديدة كل دورتين تقريبًا، كما حدث سابقًا في المشروع نفسه، فالمعدل الصافي أقل، والموعد أبعد.

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

1. تقليص النطاق للإصدار الأول

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

2. تعزيز الفريق

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

3. إعادة الجدولة ببوابات قبول

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

4. تغيير المزود

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

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

سواء قررت تقييمًا مستقلًا أو استشارة ثانية فقط، هذه المواد تختصر أسابيع من الأسئلة وتجعل الرأي مبنيًا على أدلة:

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

إن أردت مناقشة الوضع قبل أي التزام، يمكنك حجز اجتماع تقني واختيار «مشروع متعثر» موضوعًا له، ومعك هذه المواد.