المدير التقني ل ivi ،
Evgeny Rossinsky (
eross ) ، على دراية جيدة بالمشاركين في
مؤتمراتنا حول التقارير المتعلقة بالجانب التقني
للتيار . ولكن لديك اليوم نسخة من تقرير يوجين حول
TeamLead Conf حول كيفية انعكاس التحول الرشيق في قادة الفريق.
منذ وقت ليس ببعيد في ivi ، مررنا بتحول Agile وحققنا أرباحًا جيدة منه من حيث:
- الأعمال
- سرعة التطوير
- الوقت للسوق
- مقاييس أخرى مثيرة للاهتمام.
لكن عواقب هذا القرار الإبداعي ضربت قادة الفريق بشكل خطير. التقرير حول كيفية التعامل مع هذا ، وما هي الأدوات التي يجب استخدامها.
قبل التحول
لفهم ما سأتحدث عنه ، نحتاج إلى التعرف على منتجنا قليلاً. ثم سنقوم بتحليل سبب وجود مثل هذا التنسيق للأوامر ولماذا اخترنا هذا المسار.
التطوير في ivi تحت
خمس منصات رئيسية :
- iOS
- Android
- الويب
- تلفزيون ذكي
- Windows + Xbox.
وبالطبع الخلفية ، التي بدونها لا يوجد مكان. قبل أن نقرر إجراء التحول ، تم تشكيل فرقنا من خلال الكفاءات.
الأشخاص الذين يعرفون ، على سبيل المثال ، Swift أو Objective C:
- يجلس في نفس الغرفة ؛
- تلقي المهام من مديري المنتجات ؛
- العمل عليها وتحقيق نتيجة.
يبدو أن كل شيء على ما يرام ، ولكن هناك مشكلة واحدة - تختلف الأنظمة الأساسية اختلافًا شديدًا من حيث المنتج واستهلاك المستخدم للمحتوى.
وهذا يعني أنه
في كل فريق بدأ تراكم أولوياته وأولوياته
في الظهور . على سبيل المثال ، لا يحب مستخدمو تطبيق الويب الدفع ، ويتم استهلاك المحتوى من خلال نموذج إعلاني. تظهر الميزات المطلوبة لهذه المنصة بشكل طبيعي في الأعمال المتراكمة. تتميز أجهزة التلفاز الذكية بأنها تشتري بشكل جيد ، وتتجلى ميزات النموذج المدفوع.
اتضح الموقف التالي: توصل شخص ما إلى فكرة رائعة حول كيفية تحسين المنتج ؛ لقد كتبت الكثير من التذاكر التي تذهب إلى مديري المنتجات ، كل منهم مسؤول عن منصتهم. يقوم المدراء بتمرير الأفكار من خلال منظور إدراكهم ، وربما يقومون بتحديث شيء ما ووضعه في خطة عملهم. المشكلة هنا هي أنه يمكن إصدار ميزة واحدة على جميع الأنظمة الأساسية لأكثر من عام ، لأن "أعتقد أنها ليست أولوية على الإطلاق لمنصتي". وفي غضون عام أو ستة أشهر أو بضعة أشهر فقط ، يمكن أن يحدث أي شيء للمنتج - على سبيل المثال ، تحدث إعادة تصميم أو تغيير في المفهوم ، وتحتاج هذه الميزة بالفعل إلى طرحها ، وهي تختلف تمامًا عن جميع الأنظمة الأساسية الأخرى.
ونتيجة لذلك ، اتضح بعد مرور بعض الوقت أنه
على الأنظمة الأساسية المختلفة لدينا منتجات مختلفة تمامًا برسائل اتصال مختلفة ومنطق عمل مختلف. يبدأ المستخدم في هذه الحالة في الخلط ، لأنه ليس لديه مساحة واحدة يشعر فيها بالثقة. بالإضافة إلى ذلك ، من
الصعب جدًا إنشاء الفرضيات ، لأنه ليس من الواضح دائمًا على أي منصة ستعمل الوظيفة الأفضل. كل هذا يتوقف على حجم الشاشة ، وكيف يستهلك الناس المحتوى. وكان كل شيء يبدو مثل هذا:
يجلب المنتج العبقري الفكرة ، ويرى المطورون على منصات مختلفة أنها غير ودية إلى حد ما ، باستثناء الواجهة الخلفية ، والتي لا يهم بشكل عام ما يجب كتابته.
لذا ، بما أن الشركة لديها كفاءات كافية فيما يتعلق بالمنهجيات المرنة ، فقد اتفقنا مع العمل على أننا بحاجة إلى إزالة الحاجز بين:
تتفاعل بشكل منتج ، وتفعل شيئًا واحدًا مشتركًا.
بعد التحول
وأدى ذلك إلى بنية مع
تيار القيمة المخصصة ، حيث يشارك كل فريق في منطقة عمل محددة.
لتشكيل هيكل جديد نقوم بما يلي:
- إجراء العديد من الدورات التدريبية ؛
- تحديد المجالات الرئيسية لعملنا ؛
- أجبروا الناس طواعية على تدفق القيمة ؛
- بدأت في التنفيذ.
صحيح ، قبل ذلك ، أنشأنا فريقًا واحدًا من هذا القبيل ، على سبيل المثال قمنا
بأداء العروض ، بعد أن غسلنا ميزة واحدة على جميع المنصات بوقت ممتاز للسوق.
بالإضافة إلى ذلك ، تم اختيار الميزة بشكل جيد للغاية وكانت ناجحة على جميع الأنظمة الأساسية. لذلك كان لدينا مثال يوضح أن
كل شيء يمكن القيام به بشكل أسرع وأفضل . سمح هذا لفريق التطوير بأكمله المكون من 130-140 شخصًا بفهم أنه يمكنك العمل بشكل مختلف.
عندما حددنا تيار القيمة ، نشأ السؤال عما يجب فعله مع قادة الفريق. في السابق ، كانوا الأساس لكل شيء في اتجاههم ، ولكن الآن هناك تيار قيمة وتأثير أكبر للأعمال. ماذا فعلنا؟ لقد جمعنا أشخاصًا من كفاءات مختلفة في كل تيار قيم ، واحد على الأقل لكل واحد:
- مطور iOS
- مطور أندرويد
- مطور جافا سكريبت
- أخصائي تلفزيون ذكي
- مصمم تخطيط ،
- إلى المختبر.
اتضح أنه فريق مستقل ، لكنه
مستقل في الكلمات وعلى شرائح جميلة من مدرب رشيق. في الواقع ، ينسى الجميع أنه لا يزال هناك شيء مشترك بين الأشخاص الذين يمكنهم الكتابة بلغة البرمجة نفسها - هذا هو رمز برنامجهم ، والذي يجب من خلاله التواصل بطريقة أو بأخرى. لسبب ما ، كثير من الصمت حول هذا ، ولكن هذه حقا مشكلة كبيرة تحتاج إلى تذكرها.
لنفترض أنك وضعت أشخاصًا في طوابق أو غرف مختلفة ، وأنهم يكتبون نفس الرمز. هناك دورة إصدار وميزات لا يجب أن تتداخل مع بعضها البعض. هناك الكثير من المشاكل.
من المفهوم
لقد اعتمدنا عدة مفاهيم أساسية:
لقد حصلنا على
أوامر قيمة ومنصة . في تيار القيمة ، ينفذ الرجال ميزة معينة ، وفي المنصات هناك قائد فريق - مركز الكفاءات. داخل الأنظمة الأساسية ، يمكن أيضًا تطوير بعض الميزات ، ولكن هذا أكثر من منظور معماري لتطوير البرامج.
قدمنا مفهوم "
النقابات ". من خلال وضع نفس مطوري iOS في غرف مختلفة ، كنا بحاجة إلى إعطائهم علامة رسمية وحتى علامة غير رسمية ، حيث ظلوا هم نفس مطوري iOS ، وليس فقط المشاركين في تدفق القيمة للمنتج الإعلاني ، على سبيل المثال. ثم مع هذه النقابة تحتاج إلى القيام بشيء ما وتعليم الناس بطريقة ما التواصل داخلها.
كان السؤال التالي
ماذا تفعل مع دورات الإصدار . على تلك المنصات حيث يمكنك طرحها عندما تكون الميزة جاهزة ، لا توجد أسئلة. وفي حالة iOS أو Android ، عندما يكون من المستحيل إرسال التطبيق مرتين يوميًا للإصدار بسبب تفاصيل الحصول على موافقة Apple ، فمن الضروري تجميع بعض الحزم.
قررنا أن كل منصة لا يمكن إطلاقها على الفور سيتم إصدارها
مرة كل أسبوعين . جعلوا تقويمًا خاصًا متاحًا للجميع ، حيث ينشر الفريق تاريخ
تجميد الميزة وتاريخ الإصدار. إذا كنت ترغب في أن تصبح مهمتك متاحة لمستخدم حقيقي ، يجب أن تكون في الوقت المناسب لتجميد الميزة. كان لديك وقت - حسنا ، لم يكن لديك الوقت - أنت تنتظر القطار التالي.
Timlid في المخطط الجديد
ماذا حدث لل Timlids؟ لقد مروا بالمخطط الكلاسيكي للوعي بالمشاكل التي لا يمكن حلها.
في البداية صادفنا
إنكارًا . لأن قائد الفريق كان يقوم ببناء فريق رائع لعدة سنوات ، ورعى كل موظف ، وجذب شخصًا من المنافسين. وقد تم تكليف هؤلاء المتخصصين الآن بعمل لا يفي دائمًا بتوقعاتهم.
بالطبع ، بعد الإنكار كان هناك
غضب .
كانت هناك فضائح كثيرة ، وبعد ذلك بدأت
المساومة . طرح الجميع سؤالًا: "دعونا جميعًا نمتلك طريقتك الخاصة ، ولكن لدي مثلما كان من قبل ، لكنني سأأخذ علامة ، أكتب" Agile "في منزلي ، سأذهب في قميص مع هذا النقش ، ولكن كل شيء سيكون كما كان من قبل." لم تنجح.
لكن في النهاية ، ما توقعته حقًا - فهم الناس لماذا كنا نفعل ذلك. آمل أنهم فهموا ، على الرغم من أنهم ربما كذبوا. أظهرت أول حالة ناجحة اختلافًا حقيقيًا بين ما كان من قبل وكيف يمكن القيام به بشكل مختلف. لقد سمح لنا الوقت المنقضي إلى النصف بوضع معيار لكل شخص. حدثت الخطوة التالية ، والتي في النموذج الكلاسيكي لعلم النفس تسمى
متلازمة ستوكهولم . تعلّم الأشخاص الذين تبنوا القواعد الجديدة الوجود فيها وبدأوا في نشر هذا "الدين" ببطء. لا أستطيع أن أقول لجميع Timlids ، ولكن حوالي 30 ٪ منهم أصبحوا الآن "واعظين" نشطين في هذا الاتجاه.
المشاكل والصعوبات
الآن سأحاول سرد الصعوبات التي واجهناها بشكل هيكلي:
بسبب حقيقة أن الموظفين كانوا يجلسون في مكاتب مختلفة ، فقد الاتصال اللفظي.
أصبح الأمر صعبًا للغاية لمدة شهر ، لأنه قبل أن يكون من الممكن أن تسأل أحد الجيران بسرعة ، على سبيل المثال ، ما الذي تريد أن ترث منه ، ثم الحصول على إجابة. والآن تجلس في غرفة منفصلة ، وهناك أشخاص من حولك قد لا تحب تقنيتهم ، ولا يوجد أحد للتشاور. لطرح سؤال على شخص ما ، يجب أن تكتب في محادثة ، ويختفي الشخص الذي يمكنه الإجابة - هذا كل شيء ، أنت متروك لأجهزتك الخاصة.
بدأنا على الفور في
مواجهة مشكلات مع Code Review ، والتي أعتقد أنها ليست مشكلة ، ولكنها اكتشاف كبير. وجدنا أن
عددًا كبيرًا من الموظفين ليسوا مستقلين . لنفترض أن هناك موظفًا ، وفقًا للإحصاءات ، تجاوزت مشكلات المراجعة الحد الأقصى في المرة الثانية ، وعادة ما تكون المرة الأولى على ما يرام. وعندما غادر للعمل في تيار القيمة ، لسبب ما أصبح 5-6 تكرارات.
بدأوا في الفهم ، واتضح أن الرأي الرسمي للشخصية الأيقونية لقائد الفريق ، الذي يتحكم في جميع تدفقات المعلومات المتعلقة بنفسه ، ويجعلها مركزية ، لا يؤثر بشكل جيد على تطوير المطورين.
الناس كسالى ، يطلبون المساعدة في جميع القضايا ويتلقون إجابات مختصة. وبالتالي فإن المراجعة سريعة وباردة. كونهم وحدهم مع أنفسهم ، كان على العديد من المطورين أن
ينمو بشكل ملحوظ
فوق أنفسهم من أجل اتخاذ نفس القرارات المعمارية . لا أحد يحب أن يسمع خمس مرات متتالية أن شفرتك ليست جيدة جدًا. إنه أمر محبط ، يجعلك تعتبر نفسك موظفًا غير مؤهل بشكل كاف ، ويمكن أن يؤدي إلى الاكتئاب أو الاقتناع بأن الوظيفة ربما تكون سيئة. لكن النقطة هي أنك تحتاج إلى النظر إلى نفسك ، لفهم أنه في الوضع السابق للعملية لم تفكر في هذه الأشياء ، ولكنك الآن
تتطور ويجب أن تبدأ في التفكير فيها .
من ناحية أخرى ، كان لدينا بعض الأشياء المثيرة للاهتمام ، والتي ، في رأيي ، زائدة عن الحاجة إلى مراجعة الكود. كانت هناك قاعدة في أحد الفرق: من أجل اجتياز المهمة المراجعة ، يجب على جميع أعضاء الفريق اتخاذ قرارها. عندما جلسوا معًا ، نجحوا إلى حد ما ، والآن جلسوا جميعًا - كان لدى بعضهم اجتماع يومي يومي في وقت واحد ، والبعض الآخر كان لديه بعض الأعمال الأخرى - وأصبحت مراجعة المهام عنق الزجاجة الضيقة. مرارا وتكرارا في الماضي ، علموا أن بعض المهام كانت معلقة لمدة أسبوعين ، واضطروا إلى تغيير شيء ما.
ثم بدأ:
الانفصال والتمييز والحسد .
في السابق ، ظن شخص أنه يعرف ما يريد القيام به. ومع فصل تيار القيمة والنظام الأساسي ، بدأ الشك في أن "الجار له مذاق أفضل": المهام أكثر إثارة للاهتمام والنمو أسرع. المشكلة الثانية هي أنه عندما يصبح كل شيء
مركزًا على الميزات ،
تتدهور جودة الرمز كثيرًا. من حولك أشخاص يريدون الحصول على النتيجة بسرعة ، وليست مهمتهم الاعتقاد أنها ستحتاج إلى الدعم والتحديث بأي شكل من الأشكال ، ولا ينبغي أن ينقطع شيء عن الزملاء من الميزة الجديدة.
بدأت المواقف بالظهور حيث كانت سرعة التطور العالية لها جانب معاكس -
كود ضعيف الجودة ، والذي بدأ يتكاثر بكميات غير إنسانية. عندما يتولى قائد الفريق المسؤول تصحيح هذه الأخطاء وإعادة البيع ، يتبين أن حياته تتحول إلى قمامة كاسحة للموظفين المهملين. يسرع المطورون في الحصول على كل شيء ، والجميع سعداء ، ولا يلاحظون العمل الجبار لقائد الفريق ، والذي بفضله يعمل كل شيء في الواقع. بعد حوالي شهرين ، أعرب كل قائد فريق عن عدم رضاه عن الوضع الحالي.
لحل هذه المشاكل ، عقدنا عدة اجتماعات أولاً مع Timlids ، ثم مع جميع النقابات من أجل شرح للناس أنه من الممكن العمل بشكل مختلف. إذا كنت ترغب في تجربة شيء آخر ، فعندئذٍ تحتاج إلى القدوم إلى قائد الفريق ، ويمكنك بسهولة تبديل الأماكن. الشيء الرئيسي هو الاتفاق فيما بينهم.
تتمثل قوة المنهجيات المرنة في أنه لا يهم الجميع كيف يحدث كل شيء ، والشيء الرئيسي هو أن يوافق الناس ويرضوا.
هذا من ناحية. من ناحية أخرى ، حتى تكون هناك عدالة فيما يتعلق بمن يشارك في إعادة الهيكلة ومن يقوم بميزات جديدة ، يبدأ قادة الفريق العمل مع الأعمال المتراكمة ، وسوف أعود إلى ذلك بعد ذلك بقليل.
ثم بدأت
الصعوبات مع إدارة الإصدار . هناك مختبرين في تيار القيمة ، ومختبرين في المنصات ، وشيء ما مؤتمت ، وشيء غير مؤتمت ، تحتاج إلى التفكير في كيفية إجراء تراجع عام. وهناك مصطلحات. قررنا طواعية الإفراج مرة كل أسبوعين ، وماذا لو جاء شريك مع طلب للقيام بكل شيء بحلول الغد (وحقيبة مالية ، على سبيل المثال) ، أخبره أن ينتظر الدورة التالية؟ ومع ذلك ،
يجب البحث عن حل وسط . ثم يمكن أن يتغير المخطط الجميل مع الإصدارات كثيرًا.
مثال جيد هو القانون FZ-54 ، والذي بموجبه يجب أن تكون جميع المشتريات على الإنترنت مصحوبة بإرسال شيكات إلكترونية إلى المستخدمين وإلى الضريبة. يمكنك التحدث في المؤتمرات بقدر ما تريد والحديث عن منهجيات مرنة وحول ما هي اللوائح وما إلى ذلك ، ولكن بمجرد أن يكون هناك خطر من الحصول على عقوبة 70 ٪ من إيراداتك ، يمكنك التبديل إلى نظام مختلف تمامًا والتأكد من عدم فرض غرامة على شركتك. مثل هذه الحالات نادرة ، ولكن هناك. على وجه الخصوص ، كان علينا أن نجعل المستوى الثاني من الاتصال في حالة حدوث تغييرات في المخطط. هذا ليس سهلا ولكنه ممكن.
المشكلة التالية التي واجهناها نتيجة للتحول تتعلق
بالموظفين الجدد . في رأيي ، يجب أن ينغمس المبتدئون في بيئة قريبة قدر الإمكان من البيئة التي سيعمل فيها. وهناك ، بسبب البيئة ، سيتلقى بسرعة المعرفة اللازمة. لكننا جرنا المتخصصين الذين صنعوا هذه البيئة إلى طوابق وغرف مختلفة. تصبح حياة المبتدئ في الشركة مهمة إدارية جادة إلى حد ما ، يجب التفكير في حلها.
الأدوات
فيما يلي الأدوات التي نستخدمها.
سأبدأ القصة
بخريطة طريق لموظف جديد. لسوء الحظ ، هذا شيء لم نتعلمه بعد عن كيفية الأتمتة الكاملة ، وفي الواقع ، نفكر في كل موظف بشكل منفصل ، اعتمادًا على ما سيفعله.
كان هناك مثال مثير للاهتمام إلى حد ما: نحن بحاجة إلى تطوير
اختبار عالمي ، والذي سيكون قادرًا على اختبار جميع المنتجات تمامًا لتيار الإعلانات. لديهم الكثير من القواسم المشتركة ، ولكن لديهم أيضًا تفاصيلهم الخاصة. ليس سرا أن أحد المختبرين الذين يجيدون اختبار تطبيق الويب سيفقد لأول مرة عند العمل باستخدام الأدوات ، على سبيل المثال ، لنظام التشغيل iOS. لهذا المختبر ، أنشأ مدير مراقبة الجودة لدينا خريطة طريق خاصة. على هذه البطاقة ، اكتسب الموظف الجديد في كل اختصاص المعرفة لمدة أسبوعين ، وشارك في الانحدارات ، والمزيد. مع المطورين ، فإن الوضع مع التنفيذ هو نفسه تقريبًا. وهكذا ، حتى في المقابلة ، اكتشفنا ما ينجذب إليه المبيضات وما يهمه ، ونحاول أن نختار في أي اتجاه نرسله.
بالطبع ، في المرة الأولى التي يضخ فيها موظف جديد الكفاءات ، وهذا ، من حيث شروطنا ، يكون في فريق المنصة ، وبعد ذلك يمكنه بالفعل الانتقال إلى تيار القيمة الذي نحتاجه. بالمناسبة ، خرائط الطريق جيدة ، لكن قابليتها للتكيف لا تحتاج أيضًا إلى استبعادها.
ثم قدمنا
Guild Sync - مزامنة إجراءات النقابة .
لماذا هذا مطلوب؟ استمع الجميع إلى محاضرة حول سكروم ، والتي تحدثت عن الحاجة لعقد اجتماع يومي واقعي لإعلامك بما يحدث حولك. لكن المتخصص لدينا ، على سبيل المثال ، هو مطور Android من ناحية ، وعضو في فريق المنتج من ناحية أخرى. إذا كان عليه المشي والتواصل مرتين في اليوم ، فسيحصل على نوع من عبادة الشحن. على هذا المعدل ، يمكنك قضاء حياتك كلها في الاجتماعات. بالتأكيد ، سوف يزعج الناس.
إذا قلنا أننا مستندين إلى نموذج يتمحور حول الميزات ، فإن الاجتماع الاحتياطي اليومي أكثر أهمية في تدفق قيمته. ولكن في نفس الوقت ، يمكنك الانفصال عما يحدث في النقابة. للقيام بذلك ، تنظم بعض النقابات اجتماعات مرة واحدة في الأسبوع ، بعضها - مرتين في الأسبوع. وهنا يفكر قائد الفريق بشكل منهجي حول ما يستحق الحديث عنه. هذا لا ينبغي أن يترجم إلى كلام فارغ ، إنها استراتيجية تطوير لفريق التكنولوجيا ، وهو النقابة. هناك حاجة إلى اجتماعات Guild Sync حتى يفهم الجميع التقنيات التي ستستخدمها الشركة ، وما هي القرارات الاستراتيجية التي يتم اتخاذها بشأن هذا النظام الأساسي. يتم إجراء مراجعة جزئية للحلول المعمارية.
في بعض الفرق لدينا أكثر من قائد فريق. بشكل عام ، تعريف قائد الفريق غامض للغاية. هناك
قادة الرأي الذين يمكن أن يكونوا قادة الفريق ويحملون حل بعض القضايا التنظيمية. يمكن أن يكون هناك العديد من قادة الرأي ذوي المهارات الإدارية في الفريق. ومن ثم يمكنهم تنظيم أنفسهم ، من المسؤول عن ماذا. على سبيل المثال ، قد يذهب أحد قادة الرأي إلى تيار القيمة. في هذه الحالة ، تحتاج إلى مزامنة قراراتك المعمارية ، والتي ستحدد في المستقبل استراتيجية تطوير المنصة التكنولوجية بأكملها.
ثم بدأنا في إجراء عمليات
تخطيط داخلية وخارجية في مناطق معينة. بشكل عام ، هذه حالة موارد بشرية جزئية قياسية إلى حد ما ، وجزئيًا حالة بناء فريق. بالنسبة للاجتماعات الداخلية ، يتم أحيانًا إجراء تصويت على الموضوع الأكثر إثارة للاهتمام ، ويتم البحث عن متحدثين إما داخل الشركة ، أو ندعو شخصًا من الخارج ، ونستأجر غرفة خاصة ونناقش العديد من النقاط المهمة. في المتوسط ، لدينا رسمان داخليان شهريًا ، ولكن في بعض الأحيان أربعة. يمكن للناس من الكفاءات الأخرى أن يأتون إلى هذه الصور المصغرة للاستماع إلى كيفية عيش الجيران ومعرفة ما إذا كانوا يريدون تغيير تخصصهم. يحدث هذا أيضا.
الآن في سوق العمل في مسائل المطورين ، كل شيء ليس بسيطًا جدًا. , , . , ,
, . , , .
. , , Agile- , Guild Sync .
, , , . , , Guild Sync , .
, , , ,
, . 10 .
—
. , , -. - , , , . - , , , . , - . , , , , , - .
. , . , , , , . , , , . , - , , , , , .. .
, « ». , , .
Guild , . - , , .
, product owner' value stream. , 10 , - , , . , product owner' . backlog' . , , . , ( , , , , ).
— , .
Teamlead —
, , -
.
,
. , , , , , , — .
, , , « ». , , , . , , , , value stream. , , .
, , .
24 25 . - Saint TeamLead Conf .
, 40 , — 10 .