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