company_banner

Рецепт дня: готовим сообщество профессионалов, не выходя из своего отдела

    Историями о профессиональных сообществах сейчас вряд ли кого-то удивишь. Гильдии образуют по разным причинам: кто-то из интереса, кто-то — чтобы быть в тренде, а кто-то из-за недостатка общения на профессиональные темы. Это история о том, как бизнес-направление компании ЦФТ, Денежные Переводы Online, желая производить больше и быстрее, в очень короткий срок утроило штат инженеров, которых не успели нормально заонбордить, и в итоге чуть не уронили качество продукта и не «сожгли» ключевых членов команды. 

    Доклад в виде пошагового рецепта QA-лидам, fullstack feature team-лидам, SM и всем тем, кто решает задачу эффективной настройки процессов команд, представила на конференции TeamLead Conf 2020 Head of Android QA одного из флагман-продуктов компании ЦФТ Надежда Потаенко.

    Продукт ЦФТ — Золотая Корона — в 2016 году прочно стояла на позиции самой крупной системы денежных переводов без открытия счета на территории России и СНГ. В момент, о котором пойдет повествование, у пользователей появилась возможность начать отправлять переводы не только офлайн, но и через веб и мобильные фронты.

    И команду разработки начало потихонечку взрывать, потому что в эти мобильные фронты резко устремились несколько миллионов активных клиентов. 

    Стало понятно, что продукт взлетел, и его надо срочно развивать. Именно высокая востребованность продукта заставила ЦФТ очень быстро вырасти. За три года команда разработки продукта Денежные Переводы Online  увеличилась с 7 до 200+ человек. В какой-то момент старые производственные процессы просто перестали работать. Сотрудники вынуждены были отправиться на поиски новых конфигураций. 

    Из этой истории вы узнаете, как необходимость отрефакторить обычный производственный процесс может продиктовать необходимость формирования гильдии профессионалов.

    Для кого готовим?

    Гильдия, о которой мы поговорим — это 25 QA Android инженеров. Если вы не имеете отношения к качеству, это не страшно. Рекомендации, которые вы увидите здесь, легко портируются как на команду разработки, так и на команду аналитики. Информация может быть полезна даже agile-гуру и вообще всем людям, которые ищут точку опоры для создания профессионального сообщества, но пока что ее не нашли.

    Пойдемте к холодильнику и посмотрим, что там было на момент, когда Надежда начинала готовить.

    Что было в холодильнике?

    Шел 2016 год, и в компании стал развиваться продукт, который начал активно зарабатывать деньги. Ранее этот продукт разрабатывала сравнительно небольшая команда из 20 человек (4 компонентные команды: Backend, Web, iOS, Android), все сидели в славном городе Томске и были экспертами в продукте. Казалось, все идет просто идеально!

    Но как это часто бывает, заказчик с этим согласен не был. В 2017 году он начал задавать вопросы о том, почему продукт так долго релизят?

    Так много и быстро производить не получалось — просто не хватало рук. ОК, просили – получайте!

    Настал 2018, и боги провозгласили год найма и новых рук. Компания начала расти, причем не только в Томске, но параллельно в Новосибирске и в Питере. На графике видно, что в конце 2018 появилось 130 инженеров в 3 локациях, а в 2019 их стало больше 200. Это около 30 команд, которые сейчас совместно пилят один и тот же продукт: Денежные Переводы Online.

    От такого роста ожидали увеличение скорости разработки и сокращение TTM, но получили совершенно иную картину. 

    В какой-то момент, когда количество людей начало стихийно расти, скорость разработки упала более, чем в два раза. Вместе с этим просело качество продукта. А в качестве негативного бонуса, у ключевых членов старой команды началось выгорание.

    Почему так получилось? Команда разработки росла быстрее, чем в ней адаптировались процессы.

    • Не успевали качественно онбордить

    Основная боль была в отсутствии качественного онбординга. Продукт финансовый, сложный, состоит из множества слоев интеграций. И нужно потратить время для того, чтобы погрузить нового сотрудника не только в техническую составляющую, но еще и в так называемую бизнес-логику. В тот момент обеспечить этого не получилось.

    • Разный уровень hard skills в разных локациях

    Но как оказалось, это была не единственная проблема. Из-за асинхронности найма обнаружилось, что в распределенной команде сильно отличается понятие о нормальном уровне hard skills по локациям. 

    Например, в Томске инженеры предпочитали вести тестовую документацию в виде чек-листов и подробно там ничего не расписывать. В Питере считали, что это хаос и вред, и каждое ответвление flow должно быть покрыто стопочкой тест-кейсов. 

    Другой пример: в Новосибирске инженеры считали, что побегать за аналитиком и дожать из него недостающую информацию — это ОК. В Питере ребята сказали: «Ну нет! Должен быть четкий Definition of Ready. Мы ни за кем бегать не будем!»

    И та, и другая точка зрения имеет право на жизнь, но было непонятно, как все это подружить.

    • Релизила по-прежнему одна команда

    Главная боль всего 2018 и части 2019 года заключалась в том, что несмотря на увеличение количества команд, которые в изоляции друг от друга производили вполне годные фичи, стабилизацией, сборкой, багфиксингом, поставкой в прод занималась по-прежнему одна и та же релиз-команда. Конечно, она не могла качественно пропустить через себя такой объем производства.

    Выпуская релизы раз в 2-3 недели, члены команды горели на работе, потому что жили там до 2 часов ночи. Они почти ненавидели новых людей, которых зачем-то кто-то нанял. 

    В какой-то момент Надежда поняла, что надо спасать коллег по цеху.

    Шаг 1: Перемешать и поставить на плиту

    Первым шагом стало привлечение к процессу регрессионного тестирования и вообще к релиз-производству QA инженеров из фича-команд, которые раньше в этом процессе не участвовали, для того, чтобы:

    • Повысить степень причастности и ответственности;

    • Выровнять уровень понимания бизнес-логики продукта.

    Но эта попытка сразу же въехала в стройку. Стало понятно, что совместный регресс не решает ни одну из проблем. Более того, он их только обострил.

    Шаг 2: Довести до кипения

    Надежда увидела, что разные люди в команде каждый раз отстают на одних и тех же блоках. Кроме того, некоторые вообще не понимали, как работает продукт. Это выражалось в дичайшем количестве багов, причем эти баги все были с приоритетом — если не крит, то блокер. А еще надо было покричать о том, что есть баг во все возможные чаты. Хотя происходили совершенно штатные вещи. 

    Например, что-то тестили, попали на незнакомый flow, испугались, завели баг, кинули его в чат Android: кто-нибудь потом разберется. А на самом деле просто заехала новая фича, поменялся flow, а тест-кейсы еще не актуализировали. 

    Приправим все это классическими проблемами распределенных команд: в Питере сотрудники проснулись и пришли в офис, а в Томске и Новосибирске уже ушли. И команда заводила три одинаковых бага, потому что согласованности в работе не было.  

    Кроме того, существовала токсичность локаций в адрес друг друга. Например, эксперты в Томске были в ярости от того, что их коллеги заводят ненормированное количество багов, которые за ними надо перепроверять и закрывать. А новички злились на то, что какие-то распальцованные ребята в Томске закрывают их задачи без объяснения причин.

    Как тушить все это, было непонятно.

    Шаг 3: Остудить, еще раз перемешать

    Было решено собрать группу экспертов, которые бы занялись решением следующих задач:

    • Выработать единый подход к регрессу;

    • Найти способы ускорить регресс;

    • Восстановить качество релизов;

    • Делиться друг с другом экспертизой в продукте.

    Все QA в команде Денежных Переводов Online находятся в своих фича-командах. В каждом спринте у них есть собственные sprint goal. Но понимания, зачем QA-инженеры из этих обособленных фиче-команд раз в две недели собираются все вместе в трех локациях, чтобы кому-то помогать, ни у кого не было. Надежда решила начать сначала, и собрать всех очно в одной локации.

    Это предпринималось для того, чтобы за аватарками в сети все увидели реальные лица, поняли, что все одинаково болеют за продукт, но из-за отсутствия настроенных процессов тянут в разные стороны, как лебедь, рак и щука.

    А еще ей хотелось сформулировать цель совместной работы. 

    Летом 2019 года все собрались и познакомились, после чего родилась цель: выпускать качественный продукт быстро, чтобы заказчик и пользователи были довольны.

    Качественно и быстро — это отсылки к желаемому сокращению ТТМ и к восстановлению уровня качества.

    После того, как цель была сформулирована, Надежда предложила коллегам провести мозговой штурм на тему «Что мешает нам достичь желаемого» и начать строить сообщество вокруг общей цели.

    Мозговой штурм был построен на базе книги «5 пороков команды» Патрика Ленсиони. И на него было потрачено около 8 часов. 

    Когда он шел, Надежда поняла, что в команде наступил переломный момент в коммуникациях. Когда цель была не навязана извне, а сформулирована самостоятельно, степень мотивации оказалась совершенно иной. 

    Когда участники встречи разъезжались, заряд community был такой мощный, что все говорили: «Эге-гей! Да мы следующий регресс вообще за день бахнем!».

    Подобная встреча может дать ощутимый толчок в нужном направлении. Но если появившийся настрой не подогревать регулярными действиями,  мотивации у людей хватит в лучшем случае на месяц.

    Шаг 4: Выпекать до готовности

    В команде Денежных Переводов Online договорились проводить регулярные встречи гильдии раз в 2 недели. 

    Так как главной целью было систематизировать процесс регресса, первые полчаса встречи участники обсуждали прошедший регресс: чтобы по горячим следам разобрать, что можно улучшить.

    Но не релизами едиными живет ДП Online. В течение обычных двухнедельных спринтов сотрудники пишут тест-кейсы, занимаются ревью кода автотестов, тестируют требования. И в этом производственном цикле возникают вопросы, по которым хочется посоветоваться с коллегами или набросить optimise на какой-то процесс. Обсуждению таких инициатив, вопросов, болей решили посвятить вторую часть регулярных встреч гильдии. 

    В результате удалось увидеть интересные аспекты работы и новые боли, о которых не все знали раньше. Например, релиз-инженеры рассказали о том, что для них неочевидно распределение исполнителей во время регресса, и поэтому они не могут оперативно управлять его балансировкой.

    После того, как существующие проблемы начали обсуждать во время встреч, потребовалось меньше, чем полгода, чтобы процесс регрессионного тестирования тотально изменился и ускорился в два раза. 

    Канал коммуникации очень простой: QA-инженеры раз в две недели встречаются онлайн в Microsoft Teams. 

    За счет таких встреч им удалось выработать единый подход к регрессу и найти способы ускорить его.

    Осторожно! Горячо!

    Так как речь идет о коммуникациях людей, нужно понимать, что регулярные встречи инженеров не всегда будут конструктивны

    Если вы захотите строить свое профессиональное сообщество на базе животрепещущего процесса,  вы должны быть готовыми к тому, что после различных форс-мажоров в этом процессе участники встречи вряд ли будут доброжелательными. 

    Они могут начать выяснять отношения друг с другом очень эмоционально и жестко. Поэтому в вашей команде обязательно должен быть хороший медиатор конфликтов.

    Шаг 5: Сбрызнуть соком лимона

    Сообщество — это не всегда только про решение проблем. Это неизбежно история про обучение и QA-сообщество ДП Online не исключение. Например, кто-то хочет научиться пользоваться снифферами, а кто-то мечтает, чтобы ему объяснили, как безболезненно протестировать пуши на интеграции. Такие запросы есть всегда. Самое главное, что по востребованным темам есть эксперты, и нужно лишь решить вопрос формата подачи информации. 

    Надежда решила устроить получасовые обучающие митапы во время созвонов гильдии. 

    В команде появился такой wishlist:

    В Confluence сотрудники компании сами вписывают темы, которые они хотят послушать, или о которых готовы рассказать. Коллеги лайкают, и если тема популярна, она попадает в анонс. Казалось бы, что может быть проще и работоспособнее? 

    Но проблемы начались с самого первого митапа.  

    Первые грабли заключались в невнятных анонсах с вышеописанными болящими пушами. Нашелся человек, который пообещал рассказать, как решать эту проблему быстро и просто. Сотрудники пришли на митап в надежде, что им покажут, как нужно селектить и апдейтить данные в БД для того, чтобы система вообще решила отправить пуш. А докладчик полчаса рассказывал о самых азах, которые были для всех очевидны.  

    С тех пор в команде договорились, что все на 100% должны четко понимать, что именно будет обсуждаться.

    А на другом митапе, где должны были говорить на интересную всем тему, докладчицы неожиданно засмущались и начали читать с листа, чем усыпили всех уже через пять минут. Теперь существует правило и на этот счет: должна быть прямая речь.

    И последние грабли: через несколько встреч участники взмолились о том, чтобы митапы проводились в начале, а не после часа обсуждений актуальных для команды тем.

    Шаг 6: Дать отдохнуть

    В ДП Online решили отправлять сотрудников в командировки для того, чтобы они начали встречаться не только онлайн, но и лично. Когда появилась страничка графика поездок, очередь туда выстроилась до конца 2020 года. И все, естественно, хотели в Питер, ведь две другие локации находились в Сибири. 

    Пришлось жестко проредить табличку. Поехать можно было только тем, кто мог принести какую-то пользу выбранной локации, или наоборот: привезти нужные знания в свой филиал. 

    Польза от таких командировок чаще всего прослеживается на новых сложных фичах. В команде появляется новая фича, QA становится экспертом, и для него уже заранее куплены билеты в соседнюю локацию, для того, чтобы при личном общении он показал все нюансы настройки окружения и тестирования этой фичи.

    Но это не единственная возможность. В командировку могут отправиться и те, кто хочет создать обучающий курс.  Например, есть инженер в Питере, который хотел ввести своих коллег в проект автотестирования. Он на несколько месяцев приезжал в Томск, где находятся эксперты по автотестам, и все вместе они подготовили программу обучения.

    Профиты командировок:

    • Для продукта: быстрый шаринг экспертизы;

    • Для инженеров: сменить обстановку, пообщаться с иногородними коллегами.

    За счет командировок сотрудникам QA-сообщества ДП Online удалось выработать единый подход к регрессу и найти способы ускорить его, восстановить качество релизов и делиться друг с другом экспертизой в продукте.

    Что дальше?

    В 2020 году в ЦФТ появились новые цели саморазвития гильдии.

    • Коммуникация с QA-гильдиями других платформ продукта;

    Если в 2019 году сотрудники команды притирались и учились друг с другом общаться, то сейчас внутри Android community очень теплая и уютная атмосфера. Но там готовы раздвинуть границы и подсмотреть, что происходит у других сообществ. Уже запланированы встречи кросс-платформенного community.

    • Ежемесячные публикации блога с обзором новостей платформы и сообщества.

    Обо всех нововведениях и текущих изменениях хочется рассказывать, поэтому в QA-сообществе начали выпускать блог с обзором новостей. 

    Есть и продуктовые цели.

    Если раньше в ДП Online существовал басфактор в виде единой выпускающей команды, то теперь он исчез.  Тем не менее, процесс релиза непрозрачный, очень тяжело онбордить в него людей. Поэтому стоит цель однозначно работать над его упрощением и над снижением порога входа в проект автотестирования. А еще могут потребоваться новые hard skills, ведь продукт компании динамичный.

    Выводы в цифрах и фактах

    На картинках активности, которые пробовали применять в QA-сообществе ДП Online. 

    Рост качества, произошедший на почве работы сообщества, напрямую отразился на количестве hot fix’ов на число выпущенных версий.

    И немного статистики релизов продукта за 2018-2019 годы. Внизу красным подсвечены hot fix’ы. В 2018 году в ДП Online было нормой раз в 3-4 релиза выпустить hot fix. С 2019 года, когда начала собираться гильдия экспертов, hot fix’ов почти нет. За весь 2019 год выпустили всего 4. Причем речь не о клиентских, а о технических hotfix’ах, например, когда какое-то событие было потеряно в Google Analytics.

    Кроме того, активности, которые были направлены на решение продуктовых проблем, принесли несколько положительных сайд-эффектов:

    • Тюнинг soft skills;

    • Единое информационное поле;

    • Здоровая конкуренция;

    • Новые лиды.

    Но самое главное — в команде исчезли токсичная обстановка и поиски виновных. Более того, появились инициативные люди, новые лиды, которые стали брать на себя ответственность. А за ними тянутся и джуниоры.

    Программный комитет Saint TeamLead Conf 2021 ждет ваши доклады.

    Эта конференция для тех, кто не желает управлять командой наугад, проводить сомнительные эксперименты на людях и изобретать велосипеды. Но хочет выполнять роль тимлида грамотно, получать отдачу от команды и приносить пользу бизнесу. И вы можете стать одним из ее героев.

    Присоединяйтесь!

    Конференции Олега Бунина (Онтико)
    Конференции Олега Бунина

    Комментарии 9

      +1
      Про зоны ответственности. В тексте этого не написано, как у вас устроены команды? Это 30 равноправных команд, каждая из которых занимается разработкой определенной части продукта? Или у вас есть инфраструктурные команды, которые не взаимодействуют с заказчиками, не решают проблемы бизнеса, не релизят продуктовые сервисы и сайты? Почему было выбрано такое решение? Или его никто не выбирал, оно сложилось, как получилось?

      Про обучение. Судя по тексту, обмен опытом у вас происходит в основном через митапы (не суть важно, удаленные или очные). Но это же огромное дублирование усилий — невозможно попасть на прошедший митап второй раз, невозможно попасть на митап, на котором меня не было. Можно проводить запись митапов, но видеоинформацию очень дорого анализировать, искать по ней, копипастить и т.п. Почему вы не систематизируете информацию на внутренней вики или в ином текстовом виде? Были какие-то организационные проблемы, почему так не сделано?
        +1

        По поводу организации производства. Да, у нас есть core и infra-тимы, которые решают сугубо технические задачи. Но их от общей массы всех команд примерно 5%. Остальные команды — это feature teams. Мы работаем в эджайл-фреймворке LeSS. Именно по этой причине и пришлось создавать сообщество, т.к. каждый отдельный QA инкапсулирован в свою команду. Разные команды работают в разных доменах требований, а процессы нужно было настроить одинаковые для всех.
        По поводу обучения. Действительно, митапы — это затратно. Я предложила их проводить больше с целью понять истинные потребности сообщества. Не всегда через опросники можно получить честную картину интересов людей, а на митапе можно увидеть тренд популярных вопросов. Плюс, на тот момент мне хотелось всевозможными способами добавить живого общения. В действительности же у нас есть база знаний, мы стараемся ее поддерживать и реорганизовывать по мере необходимости. Но и митапы всё еще проводим, чтобы голосом что-то обсудить. Как правило, они бывают не чаще раза в месяц и самые полезные мы тоже сохраняем в базу.

        0
        Сколько денег заработали/сэкономили/потратили на это?
          0

          Сколько заработали в рублях, не скажу, но регресс сократили с 4 дней до 1. ТТМ короче стал, стали релизить раз в 2 недели, а не как получится. В общем, посчитать экономию нетрудно, если взять количество инженеров, умножить на среднюю з/п по рынку и на 3 высвободившихся дня их работы.
          Также сэкономили на этом через год, когда надо было еще 2 раза отмасштабироваться, прицепив к себе соседнюю команду с ненастроенными процессами и выделив в продукте еще один домен. Это вообще нам ничего не стоило. Ни дня простоя производства не было. В этом году нужно снова отмасштабироваться: сильно надеюсь, что и в этот раз решим все процессные проблемы через сообщество.
          А что касается затрат, тут скажу так. Это очень долгосрочная инвестиция. Та ситуация, которую описывает статья, была уже в далеком 2019 году. Тогда на запуск этого комьюнити реально пришлось потратиться: на физический сбор всей команды и несколько командировок. Получается, что инвестировали весь 2019 год. Командировки, конечно, очень дорогое удовольствие. Однако они показали пользу только в фазе запуска. Экспертиза быстро расшарилась, и в них пропала острая необходимость, а потом и пандемия подоспела. Окупилась эта затея примерно в середине 2020. Плюс, за эти 2 года в другие команды перевелось порядка 8 человек, потому что такое количество людей было уже не нужно. Профит очевидный. Вопрос больше в том, насколько вы готовы потратиться на запуске.

            0
            Итого. Сухие факты, чистые потери.
            • Вы не стали зарабатывать больше денег. Да вы сократили ТТМ, но это не принесло вам увеличение дохода.
            • Вы не сократили накладные расходы. Вы делаете регрес быстрее, но вы уменьшили команду. Да вы высвободили 3 дня работы, но не превратили это в деньги.


            Теперь домыслы. То что вы от масштабировались без простоев, ну это хорошо конечно, но я не знаю, может простои и никак не сказываться на доходах вашей компании.

            Я пока не вижу окупаемости…

            Вам в плюс, вы смогли наладить крос взаимодействие, но это можно сделать все дешевле.
              0

              Возможно, вы правы.
              Мне сложно обозначить какие-либо показатели в деньгах по той причине, что доступа к этой информации у меня нет. Безусловно, в компании есть менеджмент, который умеет получать и анализировать такие цифры. И когда после приведения длительности ТТМ к желаемому виду он ко мне с запросами на изменение больше не пришел, я сделала выводы о том, что, по крайней мере, проблем релизный цикл больше не приносит. Раньше приносил, т.к. запросы на изменение процесса были регулярно.
              Сконвертировался ли этот ТТМ в чистые деньги, можно сказать, только имея на руках все цифры продукта. Это ведь зависит от многих факторов. В частности, от успешности самих фич, запускаемых бизнесом.
              Мы не совсем уменьшили команду. Эти же люди плавно перетекли в тестирование нашего же бэкенда. Тишейпились-тишейптлись и в итоге остались там, потому что там сформировалась большая потребность. Не пришлось нанимать и тратиться на онбординг. За счет того, что эти же люди высвободили время от регресса, они как минимум, сделали больший импакт в разработку автотестов.

                0
                а вы не хотите поделиться рецептом «как сделать всё дешевле» на следующей конференции?
                0
                Sergey-Titkov, а вы не хотите присоединиться и продемонстрировать свой подход? И так ли важна окупаемость на каждом этапе? Ведь инвестиции в развитие вовсе не должны мгновенно доводить до окупаемости? И уж тем более в явном виде

          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

          Самое читаемое