ما توسّع النطاق غير المنضبط في البرمجيات وكيف تمنعونه؟

ما المقصود فعلاً بنطاق البرمجيات؟

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

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

لماذا تتجاوز مشاريع برمجية كثيرة ميزانيتها ومدّتها؟

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

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

47%: نسبة المشاريع غير الناجحة التي تخفق في تحقيق أهدافها بسبب عدم دقّة إدارة المتطلبات، بحسب أبحاث Pulse of the Profession الصادرة عن PMI.

كيف يُتجنَّب توسّع النطاق غير المنضبط؟

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

وقبل أن يبدأ العمل الهندسي، نكتب ما يجب أن تؤدّيه البرمجيات في وثائق تعتمدونها. فنُعدّ وثيقة متطلبات الأعمال (BRD) لتسجيل ما تحتاجه مؤسّستكم وسبب حاجتها إليه، ووثيقة تصميم البرمجيات (SDD) لوصف كيف ستُبنى البرمجيات، ووثيقة مواصفات متطلبات البرمجيات (SRS) للوظائف المحدّدة. ونستند في إعداد المواصفات إلى معيار ISO/IEC/IEEE 29148، وهو المعيار الذي حلّ محلّ المعيار الأقدم IEEE 830، لتكون المتطلبات كاملة ومتّسقة وقابلة للاختبار.

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

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

ما الذي تتضمّنه وثيقة النطاق الجيدة فعلاً؟

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

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

كيف نتعامل مع التغييرات بعد انطلاق المشروع؟

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

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

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

كيف نتأكّد من أن البرمجيات النهائية تؤدّي ما اتُّفق عليه؟

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

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

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

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

أبرز النقاط

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

المصادر

1. إدارة المتطلبات وإخفاق المشاريع: تقرير Pulse of the Profession (pmi.org)