🙅🏿 🤚🏿 🕵🏽 "ما يجب فعله عندما تحبط التغييرات الهائلة في العمليات الفريق." تجربة المهندس الخلفي الذي أصبح قائد فريق 🦅 🐐 🥠

عملت لمدة 7 سنوات كمهندس خلفي في Miro ، ثم أصبحت قائد فريق. على مدى السنوات الماضية ، تضاعف فريقنا الهندسي ، وأصبح موزعًا وعالميًا ، مما أدى إلى العديد من التغييرات.

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

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

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

وفيما يلي الفيديو ونسخة من أدائي في سانت TeamLead أسيوط 2019، حيث، وذلك باستخدام فريقي كمثال، أنا أتحدث عن العمليات والأدوات التي جعلت هذه التغييرات ممكن.

التاريخ رقم 1. تغيير عملية التطوير لتقليل المهلة الزمنية

في عام 2016 ، تألف تطورنا من 20 شخصًا و 5 فرق. تفاعلت الفرق بشكل فعال مع بعضها البعض ، وتبادلت المعلومات والخبرة بسرعة. مع نمو الموظفين والفرق ، وإدخال عمليات CI / CD ومراجعات الكود ، زاد عدد الترابط بين الفرق.

على سبيل المثال ، من أجل إطلاق ميزة كبيرة على منتج ما ، كان على الفريق العمل مع 6 فرق هندسية أخرى:

إعطاء رمز لمراجعة التعليمات البرمجية.
أعط ميزة لاختبار ضمان الجودة. إذا لزم الأمر ، فإن QA سيتضمن أمر DevOps لإنشاء بيئة اختبار خاصة.
تخفيف الميزة باستخدام مدير الإصدار ، المسؤول عن جميع الإصدارات في الشركة.
قم بتوصيل أوامر إضافية إذا حدث خطأ ما أثناء الإصدار.

وهذا دون الأخذ في الاعتبار التبعيات مع فرق التسويق والتصميم والدعم الفني ، والتي تشارك أيضًا بنشاط في إطلاق الميزات.

والمزيد من التبعيات ، والمزيد من المهلة الزمنية ، أي الوقت من بداية التطوير حتى الإصدار. كلما زادت المهلة الزمنية ، قل القيمة التي نقدمها للمستخدمين.

عدد كبير من الاتصالات وسرعة التسليم المنخفضة يحبط الفريق. ماذا أفعل؟ تقليل التبعيات وتقصير المهلة.

نحن نحاول بناء ناقل في التنمية

لحل هذه المشكلة ، حاولنا أولاً بناء ناقل:

وصف جميع المراحل والعمليات ؛
تقديم SLA (اتفاقية مستوى الخدمة ، مستوى الجودة المطلوبة) لتحديد الوقت الذي يجب أن تمر فيه المهمة في كل مرحلة ؛
تصويب التدفقات لمنع المهمة من التراجع إلى المراحل السابقة للتحسينات.

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

ثم قررنا إعادة بناء الناقل لنقله داخل كل فريق.

تحاول بناء فرق متعددة الوظائف

يمكن للفرق متعددة الوظائف التعامل مع المهمة من البداية إلى النهاية: من العمل على الفكرة إلى وضع الميزة النهائية على المنتج. لهذا ، يحتاج الفريق إلى امتلاك كل الكفاءات والمعارف والعمليات اللازمة.

قررنا إجراء تجربة على عدة فرق قبل طرح التغييرات على الشركة بأكملها. لقد دخل فريقي أيضًا في التجربة ، التي تتناول بشكل أساسي المهام ذات المستوى المنخفض ( كتبت عن أحد أمثلة عملنا - تنفيذ ActiveMQ و Hazelcast). تألف الفريق من 3 مطورين خلفية ، ومهندس ضمان جودة بدوام جزئي وأنا قائد الفريق.

نحدد الترابط

بادئ ذي بدء ، حددنا التبعيات الحالية التي نريد التخلص منها:

لا يوجد مهندس ضمان الجودة متفرغ ، ونتيجة لذلك يمكننا الانتظار للاختبار من بضعة أيام إلى أسبوع.
, -.
full-time -, , .

كانت هناك تبعيات أخرى ، لكننا قررنا التركيز بشكل أساسي على الثلاثة. الآن نحن بحاجة إلى تعلم الكثير مما فعله مهندس ضمان الجودة ومدير سكروم ومدير الإصدار من قبل.

نتعلم الاختبار بشكل مستقل. في
السابق ، كتب المهندسون بشكل مستقل اختبارات الوحدة واختبروا الوظائف الأساسية ، بينما فحص الباقي ضمان الجودة. لقد تعلمنا الآن كيفية اختبار المواقف الحدودية بشكل مستقل وكتابة اختبارات شاملة لاختبار التفاعل بين العميل والخادم.

تعلم الإفراج عن نفسك
اتفقنا على أننا نريد الإفراج عنه مرة واحدة على الأقل في الأسبوع. للقيام بذلك ، نحتاج إلى مدير تحرير داخل الفريق. أصبح أحد مطوري الواجهة الخلفية من تلقاء أنفسهم.

ننفذ طقوس الصفن بمفردنا
لم يكن سيد سكروم الخارجي لديه الوقت للتعامل مع جميع الفرق ، لذلك اخترنا داخل فريقنا الشخص الذي تمنى لهذا الدور. كان بحاجة إلى تعلم كيفية إجراء التخطيط والاستمالة والرجعية بشكل مستقل.

بطبيعة الحال ، لم يرمنا أحد على المتاريس. سؤال وجواب ، مدير التحرير والسيد سكروم المعرفة ونصح في الحالات الصعبة.

الفشل الأول

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

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

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

التاريخ رقم 2. دور جديد وخوف من الخطأ

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

كقاعدة ، أحد الأسباب الأربعة التي يمكن أن تعمل مع كل منها هو حجر الزاوية في قرار التخلي عن المهمة:

   → , , .
(, , ) → , .
  , → : , .
   → .

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

في حالة أندريه ، اتضح أنه اختبر رمزه بمفرده وكان على يقين من أن كل شيء على ما يرام. ومع ذلك ، فقط في حالة ، أعطيت QA للتحقق ، ووجد 5 أخطاء في الرمز. تكرر هذا عدة مرات ، مما أدى إلى تخفيض اندريه ، وقرر عدم إجراء الاختبار بعد الآن.

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

التثبيت على النمو والتثبيت على معين

عندما أصبحت قائد فريق ، نصحني بقراءة كتاب " الوعي المرن " من قبل أستاذة جامعة ستانفورد كارول دويك . باختصار ، يصف نوعين من التفكير:

عقلية ثابتة - الاعتقاد بأن الذكاء والقدرات ثابتة مرة واحدة وإلى الأبد ، فمن المستحيل التأثير عليها ، والفشل يشير إلى نقص المواهب. يحاول الأشخاص الذين لديهم مثل هذا التفكير ألا يقوموا بمهام معقدة حتى لا يفقدوا الدافع والإيمان بأنفسهم.
عقلية النمو هي الاعتقاد بأن الذكاء والقدرات يمكن تحسينها طوال الحياة إذا بذلت جهود للقيام بذلك. الفشل هو سبب لتعلم شيء ما ، لذلك يحاول الأشخاص الذين لديهم هذا النوع من التفكير باستمرار الخروج من منطقة الراحة الخاصة بهم والقيام بمهام معقدة.

بطبيعة الحال ، لا ينقسم العالم إلى أبيض وأسود ، وفي مواقف مختلفة قد يهيمن نفس الشخص على نوع مختلف من التفكير. على سبيل المثال ، قد يعتبر الشخص أن البرمجة هي مهارة يمكن لأي شخص تعلمها ، ولكنه في نفس الوقت يعتقد أن الطهي اللذيذ موهبة متأصلة في الطبيعة ، وهذا لا يمكن تعلمه.

المخطط بأكمله موجود على موقع Carol Duque على الويب.

يصف هذا النهج موقف الشخص تجاه التغييرات التي تحدث.

الأشخاص الذين يسيطرون على عقلية ثابتة (الإعداد الممنوح)
: « , ».
, . , , .

Growth mindset ( )

, , .
, .
, .

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

بالإضافة إلى ذلك ، أخبرت الجميع في الفريق عن مثالي الخاص للعمل مع الإعدادات في وقت تغيير الأدوار من مهندس إلى قائد الفريق. هذا إضافة إلى بقية الثقة بالنفس ("لم أكن الوحيد الذي واجه هذا" ، "من الممكن حقًا تغيير هذا الموقف").

استمرار للقصة رقم 2

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

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

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

على مستوى الشركة ، لدينا OKRs ، لذلك قررنا تطبيقها على مستوى التدريب الشخصي. كانت الشروط كما يلي:

نضيف إلى OKRs الشخصية فقط ما يساعد في العمل الحالي ؛
يجب أن تكون النتائج الرئيسية قابلة للقياس في أي وقت معين وأن تساعد في الإجابة على السؤال "إلى أي مدى تقدمت مقارنة بالأسبوع الماضي؟
لكل نتيجة رئيسية قائمة بالمبادرات التي تسمح بتحقيقها ؛
(, ), , ;
OKRs 1:1.

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

ثم اتفقنا على اعتبار هذا أحد التكرارات. يمكن دائمًا مراجعة OKRs وتحسينها ، وهذا ليس شيئًا منحوتًا في الحجر ، بل هو فقط الاتجاه الذي تريد تطويره. وقد ساعد ذلك على تصور المبادرة على أنها لعبة مثيرة للاهتمام ، وقد سارت الأمور.

مثال على OKRs بواسطة Andrey

Bonus ، اتفقنا على مشاركة OKRs الشخصية داخل الفريق. يساعد على التعلم من بعضهم البعض ويعمل مثل الالتزام العام.

استمرار للقصة رقم 1

بفضل التغيير في الموقف ، بدأنا بالبحث عن أسباب الصعوبات في أنفسنا ، وليس في الخارج. الآن لم تكن هناك أعذار يمكن أن تكون قد بدت في وقت سابق: "لذا فإن العملية بنيت ، فماذا يمكنني أن أفعل". بدأنا في تحسين العمليات التي لا تناسبنا. اكتسب الفريق شعورًا بملكية العمليات الجارية.

سمح لنا ذلك بالبدء في تنفيذ عدد صغير من المهام بشكل مستقر. على الرغم من أنه كان نصف ما كان عليه من قبل ، لكننا عرضناه للبيع بشكل مستقل تمامًا وبدون أخطاء.

كل هذا أضاف لنا الثقة بالنفس. بعد مرور بعض الوقت ، قام أندريه بشكل مستقل بأتمتة حالات الاختبار المعقدة. قام روما ، المسؤول عن الإصدارات ، بتحسين العملية بحيث يمكن لكل عضو في الفريق الآن الإفراج بشكل مستقل.

ونتيجة لذلك ، بناءً على نتائج الربع ، تمكنا من تقليل المهلة مرتين بسبب تقليل التبعيات وزيادة الكفاءات داخل الفريق وتغيير الموقف تجاه الصعوبات والأخطاء.

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

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

"ما يجب فعله عندما تحبط التغييرات الهائلة في العمليات الفريق." تجربة المهندس الخلفي الذي أصبح قائد فريق