كيف يسير مشروع برمجيات من العرض إلى التسليم

من أوائل أسئلة أي مؤسسة تريد تطوير برمجيات: كيف ستسير العملية. متى سترى ماذا، وما المتوقع منها، ومتى يُعدّ العمل منتهيًا.

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

الاجتماع الأول

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

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

الاستكشاف

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

هذه أرخص مراحل المشروع وأكثرها توفيرًا للمال. تصحيح احتياج أُسيء فهمه في الوثيقة أسهل بكثير من تصحيحه في الشيفرة.

العرض

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

التصميم

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

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

التطوير

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

مع كل تغيير تعمل اختبارات آلية. إذا فشل اختبار لا تتقدم تلك النسخة. شرحنا كيف نفعل ذلك في موقعنا في مقال مستقل.

الاختبار والقبول

يتم القبول وفق المعايير المكتوبة في العرض. معايير ملموسة لكل ميزة من نوع «في هذه الحالة تعطي هذه النتيجة». تجرّب المؤسسة هذه المعايير ببياناتها، وتُسجَّل النقاط غير المطابقة وتُصحَّح.

عندما لا تكون معايير القبول مكتوبة، يصبح الجدل حول «هل يعمل؟» حتميًا. شرحنا السبب في مقالنا عن معايير القبول.

الإطلاق

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

الصيانة

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

تُسلَّم الشيفرة المصدرية والوثائق وخطوات النشر إلى المؤسسة. وبذلك تستطيع المؤسسة، إذا أرادت يومًا أن تواصل مع فريق آخر، أن تفعل ذلك.

دور المؤسسة

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

باختصار

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