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