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