كيف نحدّد نطاق المشروع قبل كتابة أي سطر من الكود

معظم مشاريع البرمجيات الفاشلة لا تفشل في مرحلة التطوير — بل في الفجوة بين ما قصده صاحب المشروع وما فهمه المطوّر. وعندما تظهر هذه الفجوة، تكون عادة بعد ثلاث سباقات تطوير، ومكلفة الإصلاح.

قبل أن نفتح أي محرر أكواد، نتفق كتابياً على ثلاثة أمور: ما الذي يجب أن يفعله المنتج، من سيستخدمه فعلياً، وكيف يبدو "الانتهاء". ليست نسخة غامضة من هذه الأمور كما تُعرض في عرض تقديمي — بل نسخة محددة بما يكفي لتظهر أي خلافات حول النطاق على الورق، بدلاً من أن تظهر في عرض يوم التسليم.

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

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

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