كل مشروع برمجي يبدأ بنفس الطريقة: عندك فكرة، وحددت موعد تسليم، والفريق يدخل على الكود على طول. بعد ست شهور تكتشف إن الشغل تضاعف، ولا أحد يعرف وش بالضبط كان مطلوب، والإطلاق صار حالة طوارئ. هذي مو صدفة سيئة — هذي نتيجة مشروع ما عنده نظام واضح.
إدارة المشاريع البرمجية الناجحة مو محتاجة منهجية ثقيلة ومعقدة، ولا أدوات غالية. المحتاجة عادات بسيطة، وتطبيقها باستمرار من أول يوم: حدد النطاق، قسم الشغل إلى مراحل صغيرة، تواصل بسرعة، اختبر أثناء البناء، وسلّم بالموعد اللي الكل اتفق عليه. إذا سويت هذي الخمس، باقي التفاصيل تتسهل.
الفكرة اللي براس وحَد مو مشروع. اكتب وش المفروض السوفتوير يسوي، وشو اللي راح يستخدمه، وشكل النجاح بالنسبة لهم. وبعدين اكتب وش ما راح يسوي في هذي النسخة. قائمة "ما راح نسوي" هي اللي راح تخلصك من وجع الراس بعدين، لأنها تمنع النطاق يتمدد بهدوء.
لما النطاق يكون مكتوب، أي طلب جديد يصير قرار بدل ما يكون تغيير صامت. يبون إضافة؟ تمام، لكنها تروح على النسخة الجاية، إلا إذا وافقوا يلغون شي ثاني من النطاق الحالي عشان الميزانية والوقت يظلون ثابتين.
ومن جهة العميل، عيّنوا شخص واحد مسؤول عن الموافقات. مو الكل يعلق على كل شي، وإلا راح توصلك ملاحظات متناقضة. هذا الشخص هو اللي يجمع الملاحظات، يقرر معاكم الأولويات، ويعطي الفريق جواب واحد واضح.
تاريخ الإطلاق البعيد يخوف لأنه بعيد. الحل إنك تقسّم المشروع إلى مراحل، كل مرحلة أسبوعين تقريبًا، وكل مرحلة تخلص بنتيجة ملموسة تشوفها بعينك:
كل مرحلة تنتهي بعرض حي على شاشة حقيقية. هذي طريقة شغل Q8DM في الكويت: العميل يشوف الشاشات الفعلية كل أسبوعين، مو عرض بوربوينت. الملاحظات توصل بدري، وقت التعديل يكون رخيص، وما في شغل مختفي لشهور يطلع في الآخر صدمة.
أكبر مصدر للفوضى مو الكود السيئ — الصمت. اجتماع واحد كل أسبوع، ملخص مكتوب واحد، وقائمة قرارات مشتركة. هذي تكفي. الأسئلة ما تستنى أكثر من يوم أو يومين، وكل جواب ينكتب، عشان محد يقدر بعدين يقول ما صار هالقرار.
الاختبار كذلك مو مرحلة في النهاية. كل مرحلة تنفحص لحظة ما تخلص: الفورمات، الصلاحيات، الحالات الطرفية، والشغلات اللي المستخدم راح يستخدمها يوميًا. تصحيح خطأ بنفس أسبوع كتابته ياخذ ساعة؛ تصحيحه بعد ثلاثة شهور ياخذ أيام، لأن الفريق نسي شلون الكود يشتغل أصلاً.
وقبل الإطلاق، سوي دورة كاملة وحدة: ثبّت النظام على جهاز نظيف، مشي على كل الشاشات كمستخدم جديد، جرّبه على الجوالات اللي الناس فعلاً راح يستخدمونها، وتأكد من نسخ الاحتياط والاسترجاع. إذا ظهرت مشكلة، صلحها وأعد الدورة من جديد.
الإطلاق مرحلة، مو نهاية الطريق. اطلعوا بالتاريخ المتفق عليه وبالنطاق المتفق عليه، حتى لو فيه تحسينات صغيرة تقدر تستنى. وبعد الإطلاق اجمع بيانات الاستخدام الحقيقية، وخطط النسخة الجاية من اللي المستخدمين يسوونه فعلاً — مو من اللي انحزر في اجتماع.
من سنة 1998، Q8DM يشتغل برمجة وتصميم وتدريب لشركات في الكويت بنفس هذا الانضباط: مراحل واضحة، عروض أسبوعية، اختبار صادق، وتسليم في الوقت المحدد. إذا عندك فكرة برمجية واقفة براسك، أو مشروع بدأ ينزلق للفوضى، تواصل معنا على q8dm.com ونرتب الأمور معاك قبل ما الموعد يضغط.