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