أثناء عملك في إحدى المهام، يخبرك مسؤول العميل قائلاً: “نحتاج إلى أن تعمل سير العمل (workflow) هذا في مناطقنا الثلاث، بحيث تخضع كل منطقة لقواعد اعتماد مختلفة، ويجب أن تفرض المنصة تطبيق هذه القواعد”. قد تتمكن من إيجاد حل سريع ومؤقت (hack) ضمن بيئة النشر الحالية، لكنك تدرك أيضاً أن هذا المطلب هو من النوع الذي سيطلبه العميل التالي أيضاً.
يتناول هذا الدرس كيفية تحديد اللحظة التي يتحول فيها طلب العميل من مجرد مهمة تسليم لمرة واحدة إلى عمل جوهري يتعلق بتطوير المنتج، وكيفية تحديد مسؤولياتك بوضوح بصفتك “مهندس نشر ميداني” (FDE). يُعرَّف مهندس النشر الميداني (FDE) بأنه المهندس الذي يعمل على تنفيذ الحلول ونشرها في بيئة العميل، مع تحويل احتياجات العميل في الوقت ذاته إلى مهام تطوير هندسي للمنتج.
قبل أن تقرر ما ستقوم ببنائه، عليك تحديد ماهية الطلب الحقيقية: هل هو مجرد طلب “لجعل النظام يعمل لهذا الحساب بحلول يوم الجمعة”، أم أنه مؤشر قوي على “افتقارنا إلى ميزة أو قدرة قابلة لإعادة الاستخدام، وأن هذا العميل يمثل أول إشارة واضحة على ذلك”؟
استكشف الفرق بين التعديلات المخصصة لعميل واحد (للمرة الواحدة) وبين بناء قدرة قابلة لإعادة الاستخدام.
يتحول الطلب إلى استراتيجية للمنتج عندما يتجاوز نطاق إعدادات هذا العميل تحديداً ليشير إلى ميزة مفقودة في المنتج نفسه. تدرك ذلك عندما لا يطلب العميل مجرد “مخرجات” (نتائج)، بل يطلب “قاعدة عمل” يجب أن تتبناها المنصة وتتولى إدارتها.
لنأخذ هذا الموقف كمثال: يريد العميل تطبيق إجراءات موافقة خاصة بمنطقة جغرافية معينة داخل المنصة نفسها، وليس في جدول بيانات (spreadsheet)، ولا كخطوة يدوية، ولا كسكربت (script) مخصص لا يفهمه إلا فريقك. هذه إشارة إلى أنهم يطلبون شيئاً يتطلب تصميماً للمنتج، ودعماً طويل الأمد، وقواعد واضحة ومحددة لكيفية عمله.
هناك طريقة سريعة للتمييز بين الأمرين: اسأل نفسك عما سيحدث بعد مغادرتك. إذا كان الحل يتطلب منك صيانة فرع برمجي مخصص (custom branch)، أو تصحيحاً برمجياً خاصاً (private patch)، أو سلوكاً استثنائياً لا يمكن لأحد شرحه دون الرجوع إلى ملاحظاتك، فإن الأمر هنا ينجرف نحو نطاق تطوير المنتج؛ لأنه يحتاج إلى واجهة رسمية وخطة دعم مستقرة.
إذا كان الأمر يتطلب دعماً، فهو يتطلب تصميماً بمجرد أن يتوقع العميل استمرار عمل ميزة ما بعد التحديثات أو عند إضافة مستخدمين جدد، تعامل معها كجزء من المنتج، وليس كحيلة تقنية لمرة واحدة.
حتى عندما يكون من المفترض أن يصبح الأمر جزءاً من صلب عمل المنتج، تظل أنت المسؤول عن دفع عجلة العمل إلى الأمام خلال فترة التعامل مع العميل. تتمثل مهمتك في إزالة العوائق التي تواجه العميل دون اللجوء إلى إعادة كتابة كود المنتج سراً أثناء العمل الميداني.
تتضمن هذه المسؤولية شقين:
أولاً: الحفاظ على استمرارية التسليم. أنت تحوّل الطلب إلى متطلب واضح، وتحدد ما هو ممكن تنفيذه في بيئة التشغيل الحالية، وتقترح مساراً مؤقتاً يتسم بالشفافية والصدق بشأن القيود المتاحة.
ثانياً: حماية سلامة المنتج وتماسكه. تعني سلامة المنتج أن يظل المنتج متسقاً وموحداً، وليس مجرد مجموعة مبعثرة من السلوكيات الخاصة بحسابات معينة والتي قد تتعارض وتتسبب في أعطال بمرور الوقت. عملياً، يعني هذا تجنب إنشاء تفرعات برمجية (forks)، وتجنب استخدام إعدادات برمجية خفية (hidden flags) لا يستخدمها سوى عميل واحد، وتجنب قطع وعود تضع فريق الهندسة في مأزق لاحقاً.
بالعودة إلى مثال الموافقات، يمكنك تطبيق عملية مؤقتة تلبي متطلبات التدقيق والرقابة بينما تجمع الأدلة والحجج اللازمة لتطوير ميزة أساسية في المنتج. أنت هنا لا ترفض الطلب، بل تنظم تسلسل تنفيذه.
يكمن الجانب المعقد في أن كل صورة من صور الفشل هذه قد تبدو في اللحظة الراهنة وكأنها “استجابة فعالة” لاحتياجات العميل. أما التكلفة الحقيقية فتظهر لاحقاً، وعادةً ما يكون ذلك عندما تكون قد انتقلت بالفعل للعمل مع عميل آخر.
إليك بعض الحالات المصغرة التي توضح كيف تؤدي هذه الإخفاقات إلى تكاليف ومشاكل لاحقة.