Технический директор ivi Евгений Россинский (eross) хорошо знаком участникам наших конференций по докладам о технической стороне стриминга. Но сегодня пред вами расшифровка доклада Евгения на TeamLead Conf о том, как отражается Agile-трансформация на лидерах команд.
Не так давно в ivi прошли Agile-трансформацию и получили от неё хороший профит в плане:
Но последствия этого креативного решения довольно серьёзно ударили по лидерам команд. Доклад как раз о том, как с этим справляться, и какие применять инструменты.
До трансформации
Для того чтобы понять, о чём я буду говорить, надо немножко познакомиться с нашим продуктом. Затем разберём, почему у нас такой формат команд и почему мы выбрали такой путь.
Разработка в ivi идет под пять крупных платформ:
И, конечно же, бэкенд, без которого никуда. До того, как мы решили провести трансформацию, наши команды формировались по компетенциям.
Ребята, которые знают, к примеру, Swift или Objective C:
Вроде бы все хорошо, но есть одна проблема — платформы очень серьёзно отличаются с точки зрения продукта и потребления пользователем контента.
Это значит, что в каждой команде стал появляться свой backlog и свои приоритеты. Например, пользователи web-приложения не очень любят платить, и потребление контента осуществляется посредством рекламной модели. Фичи, которые нужны для этой платформы, естественно появляются в backlog. Smart TV характеризуются тем, что на них хорошо покупают, и проявляются особенности платной модели.
Получается следующая ситуация: кто-то придумал гениальную идею, как улучшить продукт; написал множество тикетов, которые попадают к менеджерам продуктов, отвечающим каждый за свою платформу. Менеджеры пропускают идеи через призму своего восприятия, возможно, что-то модернизируют и вставляют в свой план работ. Проблема здесь заключается в том, что одна фича может релизиться на всех платформах больше года, потому что «я считаю, что она для моей платформы совсем не приоритетна». А за год, полгода или всего несколько месяцев с продуктом может произойти всё что угодно — например, случится редизайн или изменение концепции, и эту фичу уже надо выкатывать, а она совсем непохожа на все остальные платформы.
В результате, через какое-то время получилось, что на разных платформах у нас абсолютно разные продукты с разными коммуникационными сообщениями и бизнес-логикой. Пользователь в такой ситуации начинает путаться, потому что у него нет единого пространства, в котором он чувствует себя уверенно. К тому же очень сложно строить гипотезы, так как не всегда понятно, на какой платформе какая функциональность лучше выстрелит. Всё зависит от размера экрана, от того, как люди потребляют контент. А выглядело это всё примерно так:
Гениальный продуктовик приносит идею, а разработчики на разных платформах воспринимают её довольно недружественно, за исключением бекенда, которому в целом не принципиально, что писать.
Итак, поскольку в компании было достаточно компетенций относительно того, что такое гибкие методологии, мы договорились с бизнесом, что нам нужно убрать барьер между:
продуктивно взаимодействовать, и делать одно общее дело.
После трансформации
Это вылилось в архитектуру с выделенными Value Stream, в которой каждая команда занимается конкретным бизнес-направлением.
Чтобы сформировать новую структуру мы:
Правда перед этим мы сделали одну такую команду, на примере которой провели показательные выступления, запилив одну фичу на всех платформах с отличным time-to-market.
К тому же фича была выбрана очень удачно и оказалась успешной на всех платформах. Таким образом у нас был пример, который показывал, что всё можно делать быстрее и лучше. Это позволило всей команде разработки из 130–140 человек понять, что можно работать по-другому.
Когда мы определили value stream, встал вопрос, что делать с тимлидами. Раньше они были основой всему в своём направлении, а теперь появись value stream и большее влияние бизнеса. Что мы сделали? Мы в каждый value stream собрали людей разных компетенций, как минимум по одному:
Получилась как бы независимая команда, но независимая она на словах и на красивых слайдах Agile-коучей. На деле все забывают про то, что остаётся что-то общее между людьми, умеющими писать на одном языке программирования, — это их программный код, посредством которого они должны каким-то образом общаться. Об этом почему-то многие умалчивают, но это действительно довольно большая проблема, о которой нужно помнить.
Допустим, вы рассадили людей по разным этажам или комнатам, а код-то они пишут один и тот же. Есть релизный цикл и фичи, которые не должны мешать друг другу. Возникает множество проблем.
Концепции
Мы приняли несколько базовых концепций:
У нас появились команды value stream и команды платформ. В value stream ребята реализуют конкретную фичу, а в платформах находится тимлид — центр компетенций. Внутри платформ тоже могут разрабатывать какие-то фичи, но это больше архитектурный взгляд на разработку программного обеспечения.
Мы ввели понятие «Гильдии». Разместив тех же самых iOS-разработчиков по разным комнатам, нам нужно было дать им формальный признак и даже неформальный, что они остались теми самыми iOS-разработчиками, а не только участниками value stream рекламного продукта, например. А дальше с этой гильдией нужно что-то делать и как-то учить людей общаться внутри.
Следующий вопрос состоял в том, что делать с релизными циклами. На тех платформах, где можно выкатываться по мере того, как фича готова, вопросов никаких нет. А в случае с iOS или Android, когда в силу специфики получения approve от Apple, невозможно два раза в день отправлять приложение на релиз, приходится накапливать некоторые пачки.
Мы приняли решение, что каждую платформу, которую нельзя релизить сразу же, будем релизить раз в две недели. Завели специальный доступный всем календарик, где команда публикует дату feature freeze и дату релиза. Если, находясь в value stream, ты хочешь, чтоб твоя задачка стала доступна реальному пользователю, ты должен успеть до feature freeze. Успел — хорошо, не успел — ждёшь следующего поезда.
Тимлид в новой схеме
Что же стало у нас с тимлидами? Они прошли по классической схеме осознания проблем, которые невозможно решить.
Сначала мы натолкнулись на отрицание. Потому что тимлид несколько лет собирал классную команду, каждого сотрудника взращивал, кого-то переманил у конкурентов. И этих специалистов теперь распределили на работы, которые не всегда соответствуют их ожиданиям.
Конечно, после отрицания был гнев.
Было много скандалов, после которых начался торг. Каждый приходил с вопросом: «Давайте у всех будет по-вашему, а у меня — как раньше, но я возьму маркер, напишу у себя „Agile“, буду ходить в футболке с этой надписью, но всё будет по-старому». Не получилось.
Но в итоге случилось то, чего я очень ждал, — люди поняли, для чего мы это делаем. Я надеюсь, что поняли, хотя может, они и соврали. Тот самый первый успешный кейс показал действительное разительное отличие того, что было раньше, от того, как можно делать по-другому. Вдвое уменьшенный time-to-market позволил определить ориентир для всех. Произошёл следующий шаг, который в классической модели психологии называется «стокгольмский синдром». Люди, принявшие новые правила, научились в них существовать и начали потихоньку пропагандировать эту «религию». Не могу сказать за всех тимлидов, но примерно 30% из них сейчас являются активными «проповедниками» этого направления.
Проблемы и трудности
Теперь постараюсь более структурно перечислить сложности, с которыми мы столкнулись:
Из-за того, что сотрудников рассадили в разные кабинеты, пропало вербальное общение. На месяц стало очень тяжело, потому что раньше была возможность быстренько спросить соседа, например, от чего нужно наследоваться, и тут же получить ответ. А теперь ты сидишь в отдельный комнате, вокруг тебя люди, технологии которых тебе могут не нравиться, и посоветоваться не с кем. Чтобы задать кому-то вопрос, нужно написать в чате, а человек, который может ответить, ушёл — всё, ты предоставлен сам себе.
У нас тут же начались проблемы с Code Review, которые я считаю не проблемами, а большим открытием. Мы выяснили, что большое количество сотрудников не являются самостоятельными. Допустим, был сотрудник, у которого по статистике review задачек проходил максимум со второго раза, обычно с первого раза всё было хорошо. А когда он ушёл работать в value stream, почему-то стало 5-6 итераций.
Начали разбираться, и выяснилось, что авторитетное мнение знаковой фигуры тимлида, который контролирует, централизует относительно себя все потоки информации, не очень хорошо влияет на развитие разработчиков. Люди ленятся, по всем вопросам обращаются за помощью и получают компетентные ответы. И поэтому review проходит быстро и классно. Оказавшись наедине с собой, многим разработчикам пришлось довольно существенно вырасти над собой, чтобы принимать те же самые архитектурные решения. Никому не нравится пять раз подряд слышать, что твой код не очень хорош. Это расстраивает, заставляет считать себя недостаточно квалифицированным сотрудником, может даже приводить к депрессии или убеждению, что, может быть, работа плохая. Но смысл в том, что нужно посмотреть на себя, понять, что в прежнем режиме работы ты не думал об этих вещах, а теперь развиваешься и должен начать о них думать.
С другой стороны, у нас были некоторые очень интересные вещи, которые, на мой взгляд, избыточны относительно Code Review. В одной из команд существовало правило: для того, чтобы задачка прошла review, все члены команды должны принять её решение. Когда они сидели все вместе, у них это более-менее получалось, а теперь все расселись — у одних daily stand-up meeting в одно время, у других какие-то другие дела — и review задач стало узким бутылочным горлышком. Они раз за разом на ретроспективе узнавали, что некоторые задачи висят в review по две недели, и были вынуждены что-то менять.
Дальше начались: сепаратизм, дискриминация и зависть.
Ранее человек думал, что знает, чем он хочет заниматься. А с разделением на value stream и платформы стало возникать подозрение, что «у соседа вкуснее»: задачки интересней и рост быстрее. Вторая проблема заключается в том, что, когда все становятся фича-центрированные, очень сильно ухудшается качество кода. Вокруг тебя сидят люди, которые хотят быстро получить результат, и не их задача подумать о том, что его нужно будет каким-то образом поддерживать, модернизировать, да и у коллег ничего не должно сломаться от новой фичи.
Стали возникать ситуации, в которых высокая скорость разработки имела свою обратную сторону — некачественный код, который начал плодиться в нечеловеческих количествах. Когда ответственный тимлид берётся за исправление этих ошибок и рефакторинг, получается, что его жизнь превращается в подметание мусора за нерадивыми сотрудниками. У разработчиков всё быстро получается, все довольны, и не замечают титаническую работу тимлида, благодаря которому на самом деле все работает. Примерно через два месяца каждый тимлид высказал недовольство сложившейся ситуацией.
Чтобы решить эти проблемы мы провели несколько встреч сначала с тимлидами, а потом и со всеми гильдиями для того, чтобы объяснить людям, что можно работать по-другому. Если ты хочешь попробовать что-то другое, то с этим нужно прийти к тимлиду, и совершенно спокойно можно поменяться местами. Главное договориться между собой.
Это с одной стороны. С другой стороны, чтобы была справедливость относительно того, кто занимается рефакторингом, а кто делает новые фичи, тимлиды начали работать с backlog’ами, я вернусь к этому чуть позже.
А дальше начались сложности с Release Management. В value stream свои тестировщики, в платформах свои тестировщики, что-то автоматизировано, что-то не автоматизировано, нужно продумать, как сделать общую регрессию. А ещё есть сроки. Мы волюнтаристски решили релизиться раз в две недели, и что же, если придет партнёр с просьбой сделать все к завтрашнему дню (и мешочком денег, например), велеть ему подождать следующего цикла? Все-таки нужно искать компромисс. И тогда красивая схема с релизами может сильно измениться.
Наглядный пример — закон ФЗ-54, по которому все покупки в интернете должны сопровождаться отправкой электронных чеков пользователям и в налоговую. Можно сколько угодно выступать на конференциях и говорить про гибкие методологии и про то, что есть регламенты и прочее, но как только возникает риск получения штрафа на 70% твоей выручки, ты переходишь в совершенно иной режим и делаешь так, чтобы твою компанию не оштрафовали. Такие случаи нечастые, но бывают. В частности, нам пришлось сделать второй уровень коммуникации на случай изменений в схеме. Это непросто, но возможно.
Следующая проблема, с который мы столкнулись в следствие трансформации связана с новыми сотрудниками. На мой взгляд, новичков нужно погружать в среду, максимально близкую к той, в которой он будет работать. А там за счёт окружения он максимально быстро получит нужные знания. А мы же растащили специалистов, которые составляли эту среду, по разным этажам и комнатам. Жизнь новичка в компании становится довольно серьёзной менеджерской задачей, решение которой должно быть продумано.
Инструменты
Вот, какие инструменты мы используем.
Начну рассказ с маршрутной карты для нового сотрудника. К сожалению, это то, что мы пока не научились полностью автоматизировать и, по сути, продумываем для каждого сотрудника отдельно в зависимости от того, чем он будет заниматься.
Был довольно интересный пример: нам нужно было вырастить универсального тестировщика, который бы для рекламного стрима умел бы тестировать абсолютно все продукты. В них есть очень много общего, но имеется и своя специфика. Не секрет, что тестировщик, который классно умеет тестировать веб-приложение, первое время будет теряться при работе с инструментарием, допустим, для iOS. Для этого тестировщика наш директор по контролю качества выстроил специальную маршрутную карту. По этой карте новый сотрудник в каждой компетенции набирался знаний по две недели, участвовал в регрессиях и прочем. С разработчиками ситуация с внедрением примерно такая же. Таким образом, еще на собеседовании мы выясняем, к чему тяготеет кандида и что ему интересно, и пытаемся подобрать, в какое направление его отправить.
Безусловно первое время новый сотрудник прокачивает компетенции, то есть, в наших терминах, находится в команде платформы, а потом уже может мигрировать в необходимый нам value stream. Кстати, маршрутные карты — хорошо, но их адаптивность тоже не нужно исключать.
Дальше мы ввели Guild Sync — синхронизацию действий гильдии.
Зачем это нужно? Все слушали лекции по Scrum, в которых говорилось о необходимости daily stand-up meeting, позволяющем узнавать, что происходит вокруг. Но наш специалист, например, с одной стороны разработчик под Android, а с другой стороны — участник продуктовой команды. Если он будет должен два раза в день ходить и общаться — получится какой-то Карго-культ. Такими темпами можно потратить всю жизнь на совещания. Однозначно, людей это будет раздражать.
Если мы говорим, что мы основываемся на фича-центрической модели, то daily stand-up meeting более важен в своём value stream. Но при этом можно оторваться от того, что происходит в гильдии. Для этого какие-то гильдии устраивают совещания раз в неделю, какие-то — два раза в неделю. И тут тимлид методично продумывает, о чём стоит поговорить. Это не должно переводиться в пустой разговор, это — стратегия развития технологической команды, которой является гильдия. Встречи Guild Sync нужны, чтобы все понимали, какие технологии будет использовать компания, какие стратегические решения приняты относительно этой платформы. На нём же происходит частичное review архитектурных решений.
В некоторых командах у нас не один тимлид. Вообще, определение тимлида очень неоднозначно. Есть лидеры мнений, которые могут быть тимлидами и нести на себе решение каких-то организационных вопросов. Лидеров мнений со скиллами менеджмента в команде может быть несколько. И дальше они могут сами организоваться, кто за что отвечает. Например, один из лидеров мнений может уйти в value stream. В таком случае нужно синхронизировать свои архитектурные решения, которые в дальнейшем будут определять стратегию развития всей технологической платформы.
Затем мы начали проводить внутренние и внешние митапы по определённым направлениям. В целом это достаточно стандартный отчасти HR кейс, отчасти кейс по тимбилдингу. Для внутренних митапов, иногда проводится голосование о том, какая тема интереснее всего, ищутся докладчики либо внутри компании, либо мы приглашаем кого-то со стороны, снимаем специальное помещение и обсуждаем разные важные моменты. В среднем в месяц у нас проходит два внутренних митапа, но бывает и четыре. На эти митапы могут приходить люди из других компетенций, чтобы послушать, как живут соседи, и посмотреть, не хотят ли они поменять свою специализацию. Такое тоже бывает.
Сейчас на рынке труда в вопросах разработчиков всё не очень просто. А переучить хорошего, толкового парня с одного языка программирования на другой иногда бывает намного дешевле, чем взять подобного специалиста с рынка. Поэтому, если человек заскучал, мы приветствуем практику по переводу его в другое направление, которое ему интересно. И внутренние митапы очень помогают, чтобы понять, а что из себя представляет это направление.
Расскажу об еще одном интересном моменте. Я собрал небольшую статистику, на основе которой выяснилась, что при Agile-трансформации курящие люди оказались более осведомлены, а курящим и пьющим практически не нужны Guild Sync и другие совещания.
Люди, работающие вместе, не часто обсуждают общебытовые темы, так или иначе всё сводится к работе. У команд, в которых многие курят, Guild Sync нужен реже, потому что они и так всё обсуждают на перекурах.
Конечно, есть некурящие тимлиды, тогда они, например, практикуют совместные обеды, на которых все собираются вместе за одним большим столом. Правда в команде больше 10 человек такое уже не провернешь.
Следующий инструмент для создания комфортной среды — это ротация. Изначально самая большая проблема при всех трансформациях в том, что люди боятся спросить, а можно ли по-другому. Почему-то считается, что, если руководство сказало делать так, то надо делать так. И только самые смелые и отважные идут и что-то меняют, а остальные задумываются о смене рабочего места, считая, что здесь их не ценят. Хотя они даже не сказали, что им что-то не нравится. Поэтому мы проводили ряд встреч и маленьких тренингов на тему того, что компании неважно, кто именно работает на том или ином месте, ей важно, чтобы и там, и там кто-то работал.
А дальше мы начали применять различные мотивационные методы для привлечения исполнителей в непопулярные задачи. Есть задачи, которые очень сложно автоматизировать. Их никто не любит делать, но делать их надо, потому что это, допустим, сверка данных с одним из наших партнёров. Этот партнёр постоянно присылает данные, много данных, которые нам нужно обрабатывать, в разном формате. Получается, что раз в месяц ты должен очень сильно расстраивать кого-то из разработчиков, потому что нужно не просто запустить скрипт, а понять, что там не так, поправить скрипт, запустить снова и т.д. Автоматизации такой процесс поддается плохо. В этом случае прекрасно выручают небольшие бонусы, этакая надбавка «за вредность». И желающих сделать непопулярную задачку, стало больше, и цена вопроса невысока.
Guild Чате стал сильно востребован после того, как люди расселись. Некоторые команды договорились фиксировать результаты каких-то договорённостей в общих чатах, чтобы не перегружать тикеты, регламенты и прочее.
Самое интересное, наши тимлиды научились продуктивно общаться с product owner’ами в value stream. Они стали методично им объяснять, что если те сделали 10 фич, и в определённом куске кода нужно будет что-то поменять, то это займет полгода, потому что изначально следовало бы учесть ряд особенностей. Положительным фактором является то, что product owner’ы восприняли подобные обращения нормально. И в backlog’ах стали появляться задачи на рефакторинг и исправление своих собственных костылей. И тимлиды довольно серьёзно выдохнули, так как они поняли, что их команды остались их командами. Они убедились, что точно так же управляют этим процессом (не в плане менеджмента, а, скорее, в плане донесения до всех, как нужно сделать правильно).
Teamlead — клей
Основной вывод, который мы для себя почерпнули, что по-хорошему провал или успех любой гениальной трансформации зависит от поверивших в неё людей.
Если вы затеете нечто подобное, то фокус вашего воздействия должен быть прежде всего на тимлидах. Потому что придумать красивую картинку, с которой выступить на конференции очень легко, а сделать так, чтобы это работало, люди не разбежались и понимали, что это рабочая схема, — это непросто.
Я, например, для себя уяснил, что после трансформации многие тимлиды избавились от большого количества «внутреннего бега». Если раньше по всем, даже незначительным и не связанным с менеджментов или кодом, вопросам виноват был тимлид, то теперь при подобной схеме масштабирования по целому ряду вопросов к нему просто не приходят. Тимлиду теперь не нужно отвечать на глупые вопросы, потому что их задают тому, кто разрабатывал эту фичу, к тому, кто отвечает за нужный value stream. У тимлида стало меньше входящих, отвлекающих факторов, и это здорово. Тимлиды стали спокойнее, у них перестали дёргаться глаза, и в целом их уверенность в себе стала выше.
Не так давно в ivi прошли Agile-трансформацию и получили от неё хороший профит в плане:
- бизнеса,
- скорости разработки,
- time to market;
- других интересных метрик.
Но последствия этого креативного решения довольно серьёзно ударили по лидерам команд. Доклад как раз о том, как с этим справляться, и какие применять инструменты.
До трансформации
Для того чтобы понять, о чём я буду говорить, надо немножко познакомиться с нашим продуктом. Затем разберём, почему у нас такой формат команд и почему мы выбрали такой путь.
Разработка в ivi идет под пять крупных платформ:
- iOS,
- Android,
- Web,
- Smart TV,
- Windows + Xbox.
И, конечно же, бэкенд, без которого никуда. До того, как мы решили провести трансформацию, наши команды формировались по компетенциям.
Ребята, которые знают, к примеру, Swift или Objective C:
- сидят в одном помещении;
- получают задачи от менеджеров продукта;
- работают над ними и производят результат.
Вроде бы все хорошо, но есть одна проблема — платформы очень серьёзно отличаются с точки зрения продукта и потребления пользователем контента.
Это значит, что в каждой команде стал появляться свой backlog и свои приоритеты. Например, пользователи web-приложения не очень любят платить, и потребление контента осуществляется посредством рекламной модели. Фичи, которые нужны для этой платформы, естественно появляются в backlog. Smart TV характеризуются тем, что на них хорошо покупают, и проявляются особенности платной модели.
Получается следующая ситуация: кто-то придумал гениальную идею, как улучшить продукт; написал множество тикетов, которые попадают к менеджерам продуктов, отвечающим каждый за свою платформу. Менеджеры пропускают идеи через призму своего восприятия, возможно, что-то модернизируют и вставляют в свой план работ. Проблема здесь заключается в том, что одна фича может релизиться на всех платформах больше года, потому что «я считаю, что она для моей платформы совсем не приоритетна». А за год, полгода или всего несколько месяцев с продуктом может произойти всё что угодно — например, случится редизайн или изменение концепции, и эту фичу уже надо выкатывать, а она совсем непохожа на все остальные платформы.
В результате, через какое-то время получилось, что на разных платформах у нас абсолютно разные продукты с разными коммуникационными сообщениями и бизнес-логикой. Пользователь в такой ситуации начинает путаться, потому что у него нет единого пространства, в котором он чувствует себя уверенно. К тому же очень сложно строить гипотезы, так как не всегда понятно, на какой платформе какая функциональность лучше выстрелит. Всё зависит от размера экрана, от того, как люди потребляют контент. А выглядело это всё примерно так:
Гениальный продуктовик приносит идею, а разработчики на разных платформах воспринимают её довольно недружественно, за исключением бекенда, которому в целом не принципиально, что писать.
Итак, поскольку в компании было достаточно компетенций относительно того, что такое гибкие методологии, мы договорились с бизнесом, что нам нужно убрать барьер между:
- продуктом,
- бизнесом,
- технологиями,
продуктивно взаимодействовать, и делать одно общее дело.
После трансформации
Это вылилось в архитектуру с выделенными Value Stream, в которой каждая команда занимается конкретным бизнес-направлением.
Чтобы сформировать новую структуру мы:
- провели несколько тренингов;
- определили, какие для нашего бизнеса главные направления;
- в добровольно-принудительном разбили людей на value stream;
- приступили к внедрению.
Правда перед этим мы сделали одну такую команду, на примере которой провели показательные выступления, запилив одну фичу на всех платформах с отличным time-to-market.
К тому же фича была выбрана очень удачно и оказалась успешной на всех платформах. Таким образом у нас был пример, который показывал, что всё можно делать быстрее и лучше. Это позволило всей команде разработки из 130–140 человек понять, что можно работать по-другому.
Когда мы определили value stream, встал вопрос, что делать с тимлидами. Раньше они были основой всему в своём направлении, а теперь появись value stream и большее влияние бизнеса. Что мы сделали? Мы в каждый value stream собрали людей разных компетенций, как минимум по одному:
- iOS-разработчику,
- Android-разработчику,
- JavaScript-разработчику,
- специалисту по Smart TV,
- верстальщику,
- тестировщику.
Получилась как бы независимая команда, но независимая она на словах и на красивых слайдах Agile-коучей. На деле все забывают про то, что остаётся что-то общее между людьми, умеющими писать на одном языке программирования, — это их программный код, посредством которого они должны каким-то образом общаться. Об этом почему-то многие умалчивают, но это действительно довольно большая проблема, о которой нужно помнить.
Допустим, вы рассадили людей по разным этажам или комнатам, а код-то они пишут один и тот же. Есть релизный цикл и фичи, которые не должны мешать друг другу. Возникает множество проблем.
Концепции
Мы приняли несколько базовых концепций:
У нас появились команды value stream и команды платформ. В value stream ребята реализуют конкретную фичу, а в платформах находится тимлид — центр компетенций. Внутри платформ тоже могут разрабатывать какие-то фичи, но это больше архитектурный взгляд на разработку программного обеспечения.
Мы ввели понятие «Гильдии». Разместив тех же самых iOS-разработчиков по разным комнатам, нам нужно было дать им формальный признак и даже неформальный, что они остались теми самыми iOS-разработчиками, а не только участниками value stream рекламного продукта, например. А дальше с этой гильдией нужно что-то делать и как-то учить людей общаться внутри.
Следующий вопрос состоял в том, что делать с релизными циклами. На тех платформах, где можно выкатываться по мере того, как фича готова, вопросов никаких нет. А в случае с iOS или Android, когда в силу специфики получения approve от Apple, невозможно два раза в день отправлять приложение на релиз, приходится накапливать некоторые пачки.
Мы приняли решение, что каждую платформу, которую нельзя релизить сразу же, будем релизить раз в две недели. Завели специальный доступный всем календарик, где команда публикует дату feature freeze и дату релиза. Если, находясь в value stream, ты хочешь, чтоб твоя задачка стала доступна реальному пользователю, ты должен успеть до feature freeze. Успел — хорошо, не успел — ждёшь следующего поезда.
Тимлид в новой схеме
Что же стало у нас с тимлидами? Они прошли по классической схеме осознания проблем, которые невозможно решить.
Сначала мы натолкнулись на отрицание. Потому что тимлид несколько лет собирал классную команду, каждого сотрудника взращивал, кого-то переманил у конкурентов. И этих специалистов теперь распределили на работы, которые не всегда соответствуют их ожиданиям.
Конечно, после отрицания был гнев.
Было много скандалов, после которых начался торг. Каждый приходил с вопросом: «Давайте у всех будет по-вашему, а у меня — как раньше, но я возьму маркер, напишу у себя „Agile“, буду ходить в футболке с этой надписью, но всё будет по-старому». Не получилось.
Но в итоге случилось то, чего я очень ждал, — люди поняли, для чего мы это делаем. Я надеюсь, что поняли, хотя может, они и соврали. Тот самый первый успешный кейс показал действительное разительное отличие того, что было раньше, от того, как можно делать по-другому. Вдвое уменьшенный time-to-market позволил определить ориентир для всех. Произошёл следующий шаг, который в классической модели психологии называется «стокгольмский синдром». Люди, принявшие новые правила, научились в них существовать и начали потихоньку пропагандировать эту «религию». Не могу сказать за всех тимлидов, но примерно 30% из них сейчас являются активными «проповедниками» этого направления.
Проблемы и трудности
Теперь постараюсь более структурно перечислить сложности, с которыми мы столкнулись:
Из-за того, что сотрудников рассадили в разные кабинеты, пропало вербальное общение. На месяц стало очень тяжело, потому что раньше была возможность быстренько спросить соседа, например, от чего нужно наследоваться, и тут же получить ответ. А теперь ты сидишь в отдельный комнате, вокруг тебя люди, технологии которых тебе могут не нравиться, и посоветоваться не с кем. Чтобы задать кому-то вопрос, нужно написать в чате, а человек, который может ответить, ушёл — всё, ты предоставлен сам себе.
У нас тут же начались проблемы с Code Review, которые я считаю не проблемами, а большим открытием. Мы выяснили, что большое количество сотрудников не являются самостоятельными. Допустим, был сотрудник, у которого по статистике review задачек проходил максимум со второго раза, обычно с первого раза всё было хорошо. А когда он ушёл работать в value stream, почему-то стало 5-6 итераций.
Начали разбираться, и выяснилось, что авторитетное мнение знаковой фигуры тимлида, который контролирует, централизует относительно себя все потоки информации, не очень хорошо влияет на развитие разработчиков. Люди ленятся, по всем вопросам обращаются за помощью и получают компетентные ответы. И поэтому review проходит быстро и классно. Оказавшись наедине с собой, многим разработчикам пришлось довольно существенно вырасти над собой, чтобы принимать те же самые архитектурные решения. Никому не нравится пять раз подряд слышать, что твой код не очень хорош. Это расстраивает, заставляет считать себя недостаточно квалифицированным сотрудником, может даже приводить к депрессии или убеждению, что, может быть, работа плохая. Но смысл в том, что нужно посмотреть на себя, понять, что в прежнем режиме работы ты не думал об этих вещах, а теперь развиваешься и должен начать о них думать.
С другой стороны, у нас были некоторые очень интересные вещи, которые, на мой взгляд, избыточны относительно Code Review. В одной из команд существовало правило: для того, чтобы задачка прошла review, все члены команды должны принять её решение. Когда они сидели все вместе, у них это более-менее получалось, а теперь все расселись — у одних daily stand-up meeting в одно время, у других какие-то другие дела — и review задач стало узким бутылочным горлышком. Они раз за разом на ретроспективе узнавали, что некоторые задачи висят в review по две недели, и были вынуждены что-то менять.
Дальше начались: сепаратизм, дискриминация и зависть.
Ранее человек думал, что знает, чем он хочет заниматься. А с разделением на value stream и платформы стало возникать подозрение, что «у соседа вкуснее»: задачки интересней и рост быстрее. Вторая проблема заключается в том, что, когда все становятся фича-центрированные, очень сильно ухудшается качество кода. Вокруг тебя сидят люди, которые хотят быстро получить результат, и не их задача подумать о том, что его нужно будет каким-то образом поддерживать, модернизировать, да и у коллег ничего не должно сломаться от новой фичи.
Стали возникать ситуации, в которых высокая скорость разработки имела свою обратную сторону — некачественный код, который начал плодиться в нечеловеческих количествах. Когда ответственный тимлид берётся за исправление этих ошибок и рефакторинг, получается, что его жизнь превращается в подметание мусора за нерадивыми сотрудниками. У разработчиков всё быстро получается, все довольны, и не замечают титаническую работу тимлида, благодаря которому на самом деле все работает. Примерно через два месяца каждый тимлид высказал недовольство сложившейся ситуацией.
Чтобы решить эти проблемы мы провели несколько встреч сначала с тимлидами, а потом и со всеми гильдиями для того, чтобы объяснить людям, что можно работать по-другому. Если ты хочешь попробовать что-то другое, то с этим нужно прийти к тимлиду, и совершенно спокойно можно поменяться местами. Главное договориться между собой.
Сила гибких методологий в том, что всем неважно, как всё происходит, главное, чтобы люди договорились и были довольны.
Это с одной стороны. С другой стороны, чтобы была справедливость относительно того, кто занимается рефакторингом, а кто делает новые фичи, тимлиды начали работать с backlog’ами, я вернусь к этому чуть позже.
А дальше начались сложности с Release Management. В value stream свои тестировщики, в платформах свои тестировщики, что-то автоматизировано, что-то не автоматизировано, нужно продумать, как сделать общую регрессию. А ещё есть сроки. Мы волюнтаристски решили релизиться раз в две недели, и что же, если придет партнёр с просьбой сделать все к завтрашнему дню (и мешочком денег, например), велеть ему подождать следующего цикла? Все-таки нужно искать компромисс. И тогда красивая схема с релизами может сильно измениться.
Наглядный пример — закон ФЗ-54, по которому все покупки в интернете должны сопровождаться отправкой электронных чеков пользователям и в налоговую. Можно сколько угодно выступать на конференциях и говорить про гибкие методологии и про то, что есть регламенты и прочее, но как только возникает риск получения штрафа на 70% твоей выручки, ты переходишь в совершенно иной режим и делаешь так, чтобы твою компанию не оштрафовали. Такие случаи нечастые, но бывают. В частности, нам пришлось сделать второй уровень коммуникации на случай изменений в схеме. Это непросто, но возможно.
Следующая проблема, с который мы столкнулись в следствие трансформации связана с новыми сотрудниками. На мой взгляд, новичков нужно погружать в среду, максимально близкую к той, в которой он будет работать. А там за счёт окружения он максимально быстро получит нужные знания. А мы же растащили специалистов, которые составляли эту среду, по разным этажам и комнатам. Жизнь новичка в компании становится довольно серьёзной менеджерской задачей, решение которой должно быть продумано.
Инструменты
Вот, какие инструменты мы используем.
Начну рассказ с маршрутной карты для нового сотрудника. К сожалению, это то, что мы пока не научились полностью автоматизировать и, по сути, продумываем для каждого сотрудника отдельно в зависимости от того, чем он будет заниматься.
Был довольно интересный пример: нам нужно было вырастить универсального тестировщика, который бы для рекламного стрима умел бы тестировать абсолютно все продукты. В них есть очень много общего, но имеется и своя специфика. Не секрет, что тестировщик, который классно умеет тестировать веб-приложение, первое время будет теряться при работе с инструментарием, допустим, для iOS. Для этого тестировщика наш директор по контролю качества выстроил специальную маршрутную карту. По этой карте новый сотрудник в каждой компетенции набирался знаний по две недели, участвовал в регрессиях и прочем. С разработчиками ситуация с внедрением примерно такая же. Таким образом, еще на собеседовании мы выясняем, к чему тяготеет кандида и что ему интересно, и пытаемся подобрать, в какое направление его отправить.
Безусловно первое время новый сотрудник прокачивает компетенции, то есть, в наших терминах, находится в команде платформы, а потом уже может мигрировать в необходимый нам value stream. Кстати, маршрутные карты — хорошо, но их адаптивность тоже не нужно исключать.
Дальше мы ввели Guild Sync — синхронизацию действий гильдии.
Зачем это нужно? Все слушали лекции по Scrum, в которых говорилось о необходимости daily stand-up meeting, позволяющем узнавать, что происходит вокруг. Но наш специалист, например, с одной стороны разработчик под Android, а с другой стороны — участник продуктовой команды. Если он будет должен два раза в день ходить и общаться — получится какой-то Карго-культ. Такими темпами можно потратить всю жизнь на совещания. Однозначно, людей это будет раздражать.
Если мы говорим, что мы основываемся на фича-центрической модели, то daily stand-up meeting более важен в своём value stream. Но при этом можно оторваться от того, что происходит в гильдии. Для этого какие-то гильдии устраивают совещания раз в неделю, какие-то — два раза в неделю. И тут тимлид методично продумывает, о чём стоит поговорить. Это не должно переводиться в пустой разговор, это — стратегия развития технологической команды, которой является гильдия. Встречи Guild Sync нужны, чтобы все понимали, какие технологии будет использовать компания, какие стратегические решения приняты относительно этой платформы. На нём же происходит частичное review архитектурных решений.
В некоторых командах у нас не один тимлид. Вообще, определение тимлида очень неоднозначно. Есть лидеры мнений, которые могут быть тимлидами и нести на себе решение каких-то организационных вопросов. Лидеров мнений со скиллами менеджмента в команде может быть несколько. И дальше они могут сами организоваться, кто за что отвечает. Например, один из лидеров мнений может уйти в value stream. В таком случае нужно синхронизировать свои архитектурные решения, которые в дальнейшем будут определять стратегию развития всей технологической платформы.
Затем мы начали проводить внутренние и внешние митапы по определённым направлениям. В целом это достаточно стандартный отчасти HR кейс, отчасти кейс по тимбилдингу. Для внутренних митапов, иногда проводится голосование о том, какая тема интереснее всего, ищутся докладчики либо внутри компании, либо мы приглашаем кого-то со стороны, снимаем специальное помещение и обсуждаем разные важные моменты. В среднем в месяц у нас проходит два внутренних митапа, но бывает и четыре. На эти митапы могут приходить люди из других компетенций, чтобы послушать, как живут соседи, и посмотреть, не хотят ли они поменять свою специализацию. Такое тоже бывает.
Сейчас на рынке труда в вопросах разработчиков всё не очень просто. А переучить хорошего, толкового парня с одного языка программирования на другой иногда бывает намного дешевле, чем взять подобного специалиста с рынка. Поэтому, если человек заскучал, мы приветствуем практику по переводу его в другое направление, которое ему интересно. И внутренние митапы очень помогают, чтобы понять, а что из себя представляет это направление.
Расскажу об еще одном интересном моменте. Я собрал небольшую статистику, на основе которой выяснилась, что при 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 августа.
