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