Во имя нового продукта
Когда в статьях и докладах говорят о кейсах в управлении командами, часто ограничиваются тем, что рассказывают, что было не так и как изменили ситуацию. Но в этот раз у нас есть уникальная возможность узнать, как команда жила дальше и чем все закончилось — на самом деле не закончилось, а продолжается.
Перед вами продолжение истории под названием «Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода» об Agile-трансформации в ivi. На TeamLead Conf технический директор компании Евгений Российский (eross) рассказал, почему может понадобиться откатить всю реорганизацию команды, как при этом не переругаться и помочь разработчикам, а еще и сохранить и приумножить бизнес-эффективность.
Контекст компании
ivi — крупнейший легальный интернет-кинотеатр с аудиторией в 48 млн пользователей, которые все вместе ежемесячно проводят на ресурсе 70 млн часов. У ivi 62 тысячи единиц контента, который доступен с разных устройств и всегда в отличном качестве.
Так совпало, что в тот самый день, когда Евгений выступал на TeamLead Conf с этим докладом, был день рождения компании. 9 лет назад состоялся первый релиз веб-версии проекта, а через 2 дня сила Первого канала привела большое число пользователей на ivi. В компании даже подумали, что это DDoS, но смогли достойно выстоять.
В этой статье речь о запуске нового продукта — полном перезапуске всех приложений.
Смотрите видео, чтобы услышать нецензурированную версию или читайте расшифровку доклада от первого лица.
Сначала поговорим об используемых технологиях и компетенциях, чтобы понять масштаб разрушений.
Компетенции:
- Backend (Python, Golan, Java);
- Web (JavaScript, Node.js);
- Android (Java);
- iOS (Objective-C, Swift);
- SmartTV (JavaScript);
- Windows/XBox (C#);
- Sony PS (JavaScript).
По каждую из этих компетенций в 2016 году у нас была своя команда, т.е. команда iOS, команда Android и т.д. Также была команда бэкенда и отдельно — команда продуктовых менеджеров, которые придумывали новые фичи.
Основная проблема, из-за которой понадобилось трансформироваться, была в том, что все платформы разные, и в том числе у них были разные бэклоги и приоритеты. А нам очень хотелось построить единое инфопространство в рамках наших приложений.
Часто бывало так, что сложная фича на всех платформах появлялась через 4 месяца после того, как она была задумана. При этом на одной платформе она появлялась через 3 дня, а потом, в зависимости от приоритизации бэклогов, на разных платформах выкатывалась с разной скоростью. Получалось чудовищно по следующим причинам:
- За 4 месяца фича уже могла приобрести совсем другой смысл и потребность в ней могла отпасть.
- Из-за проблем в коммуникации, которые в данном случае очевидны, люди реализовывали фичи по-разному.
Так как у продукта есть три модели монетизации, которые с разной эффективностью работают на разных платформах, приоритезация бэклога на каждой платформе была своя. Некоторые фичи могли в принципе никогда не быть реализованы на отдельных платформах.
Краткий пересказ трансформации
В 2017 году мы ввели понятие Value Stream — это кросс-функциональные команды, которые отвечают за конкретные задачи бизнеса. Чтобы понять, какие у нашего бизнеса конкретные задачи, мы собрали примерно 25–30 человек из всей компании, позвали коучей, которые занимаются гибкими методологиями, и за 2 дня сформулировали, какие же у нас должны быть Value — направления развития.
Получили 5–6 Value Streams. Посадили этих ребят вместе, выдали каждому по Product Owner, который будет топить именно за это направление (подробнее тут).
Мы познали боль, кровь, слезы и радость и вышли на очень хорошие показатели:
- Синхронная выгрузка одинаковых фич на разных платформах.
- Кратное уменьшение time-to-market. Релиз многих фич уперся только в цикл релизного менеджмента на каждой из платформ, так как, например Apple не позволяет выгружать каждую фичу отдельно. Поэтому фичи группируются и в среднем мы релизимся раз в две недели.
- Ликвидация «бутылочных горлышек», которыми были как Product Owners, так и технические менеджеры и тимлиды.
- Разработчики начали понимать, зачем они «пилят» новую функциональность.
Год мы просуществовали очень неплохо — в 2017 году практически удвоилась выручка.
Но этого оказалось недостаточно, и жизнь в конце 2017 — начале 2018 преподнесла нам сюрприз.
Почему понадобился новый продукт
Бизнес обозначил новые цели. Сюрприз заключался в том, что разработка любого программного обеспечения существует ради чего-то. Немногие пишут код из альтруистических соображений. Для того, чтобы компания оправдывала свое существование, ее владельцы и акционеры ставят определённые цели, которые команда должна выполнять.
Наши акционеры не говорят, как нам делать, они говорят, чего они хотят добиться. Как — должна решить команда.
Перед командой встала задача придумать, как зарабатывать больше. Мы провели брейншторм, и продуктовый отдел вместе с техническим пришли к выводу, что для того, чтобы реализовать амбициозные цели (условно, удвоить размер платящей аудитории), надо в принципе сместить весь акцент с бесплатного просмотра кино к платному.
Практически все выдвинутые гипотезы очень плохо вписывались в концепцию старого продукта. Точнее, вообще не вписывалось — любые мотивационные flow по переходам пользователей упирались в то, что на каких-то платформах это реализуется, на каких-то нет, здесь одни ограничения, там другие. Нашей команде 9 лет, и у нас накопилось много такого, что тащило нас на дно. По-хорошему надо было все переписывать.
Несколько качественных и количественных исследований показали проблемы старого продукта. Оказалось, что мы находимся на 2–3 года позади того, до чего додумалось мудрое человечество. Например, если лет 5 назад на мобильных устройствах было модно и современно ставить в левом верхнем углу бургерное меню, то с появлением больших экранов люди перестали туда дотягиваться. У нас до 2018 года действительно было бургерное меню, и люди как-то с ним справлялись.
Бедный пользователь привыкает ко всему, но это не значит, что нужно оставлять все, как есть.
Многие фреймворки нуждались в рефакторинге. Мы нашли логические недоработки и, как в любом долгоживущем коде, у нас было много старого не очень хорошего кода. Это очень не нравилось разработчикам.
Например, очень сложно нанимать разработчиков, которые хотят писать на Objective-C. Все мы подвержены влиянию моды, да еще и ленивы — если появляется какой-то инструмент, который позволяет делать примерно то же самое, но быстрее и эффективнее, мы хотим его использовать. А ситуация на рынке труда такая, что можно написать в резюме: «Хочу писать на Swift», и даже если не умеешь писать на Swift, куда-то точно устроишься.
С этим надо было что-то делать, и это одна из проблем, мешающая развитию. Поэтому нам надо было переписать устаревшие компоненты и внедрить современные фреймворки.
Цели
Мы хотели:
- Создать новый продукт с единым дизайном.
- Сделать, чтобы наша хорошая рекомендательная система стала отвечать за выдачу всех блоков в рамках нашего продукта.
- Исправить логические ошибки интерфейса.
- Навести порядок в коде.
- Мигрировать на новую систему статистики.
- Внедрить дизайн-систему.
Все вызовы довольно амбициозные, особенно дизайн-система, потому что крайне мало дизайн-систем, которые работают кроссплатформенно и оторваны от программного кода. В основном выпускают JS-движок, который используют в разных платформах. По сути, механизм передачи информации о том, как должен выглядеть продукт, находится внутри кода.
У нас такое провернуть не очень получается, потому что мы работаем с видео, а работа с видео требует использования более-менее нативных инструментов. Плюс ко всему, если не использовать нативные инструменты, всегда будет отставание на 1–2 шага от релизов операционной системы. Все универсальные фреймворки типа Xamarin все равно приходится догонять после релизов. А мы очень алчные до того, чтобы нас фичерили — и Google, и Apple рекомендуют нас как раз за то, что мы используем нативные инструменты.
Нативные инструменты помогают делать качественные, хорошие, быстрые приложения. В случае с видео это просто необходимо.
Поиск решений по организации управления
Обозначив цели, мы настроились на их быстрое достижение. Напомню, что мы разделились на Value Stream’ы, разные разработчики сидели в разных командах, и мы столкнулись с суровой реальностью —, а что делать?
Вроде бы у нас была система, к которой мы довольно долго приучали людей, а теперь правила игры поменялись.
Конечно, сначала мы попробовали работать как раньше, используя Value Stream’ы, приняв следующие логические выкладки: «Пусть Value Stream, который занимается таким-то направлением бизнеса, и будет рефакторить все компоненты, связанные с этими направлениями».
О, как мы ошибались! Примерно через месяц выяснилось, что для того, чтобы переписать ядро каждого из приложений, по сути нужно залезть во все сферы деятельности бизнес-правил.
Очень сложно было разграничить зону ответственности Value Stream’ов, кто какую часть на себя берет, когда люди сидят на разных этажах, в разных комнатах.
Что самое печальное, из-за разных языков и особенностей платформ для разработки полностью пропал эффект коллаборации.
В рамках Value Stream разработчики iOS и Android пилят одну и ту же фичу, и им есть, о чем поговорить, они обсуждают бизнес-логику. А когда каждый из них пилит низкоуровневый фреймворк, который слабо соотносится с тем, что потом будет в итоговом продукте, синхронизация пропадает полностью.
Появились люди, которые в принципе оторвались от смысла происходящего. Первыми впали в уныние тимлиды, потому что им, как людям ответственным, нужно было оступившихся и разуверившихся в человечестве сотрудников вернуть в лоно истинной церкви, чтобы они писали адекватный код в правильную сторону. Получалось это очень плохо.
Через месяц-полтора пришло осознание, что Value Stream’ы прекрасно работают для готовых продуктов, но вообще неэффективны, когда продукт нужно написать с нуля.
Как и все простые истины понимаешь их только после того, как сам пройдешь по граблям босиком, да еще и по граблям пустишь ток.
Все новое — это хорошо забытое старое.
Вернем все как было
После триумфальной Agile-трансформации решили сделать все, как было в 2016 году, потому что право на демократию нужно заслужить.
Чтобы каждый имел право голоса, и это право было востребовано и использовано, нужно сформировать правила и экосистему, в которой это будет работать.
Когда нет экосистемы, приходится некоторые вещи делать авторитарно, чтобы правила как-то сформировались.
Сделали следующее:
- Вернули людей обратно под крыло тимлидам, перефокусировали их с фича-ориентированного программирования на просто нормальное программирование.
- Продуктовых менеджеров распределили по flow пользователей. В нашем случае это скачивание, авторизация и пр.
- Постарались формализовать все требования к новому продукту, о которых мы договорились в начале разработки.
Вроде бы все логично, но как и два года назад мы уперлись в те же самые проблемы.
Так не пойдет, снова проблемы в организации
Главными проблемами два года назад были: централизация и принятие решений.
Авторитаризм приводит к тому, что появляются «бутылочные горлышки» — тимлиды, технические менеджеры и продуктовые менеджеры, которые не успевают донести фичи до разработки. Продукт, который до этого пилился 8 лет, сложно весь переосмыслить за несколько месяцев. Не круто, когда 80% концепции готово, а 20% (как раз где самая мякотка) еще нет. Это сильно раздражало и расстраивало команду.
Когда разработчики формально вернулись под управление тимлидов, живого общения с продуктовыми менеджерами стало сильно меньше, и появилась потребность в формализации ТЗ. То, что прекрасным образом было заменено вербальным общением, опять обернулось формализмом — он сам вернулся, никто его не возвращал. Но инженеры устроены таким образом, их в институте учат: есть постановка задачи — ее нужно решить, постановки задачи нет — мир рушится, алгоритм работать не будет.
По ходу дела обнаружились ошибки и просчеты, как логические, так и архитектурные. Представьте, несколько лет делаешь код, и все это время мечтаешь его отрефакторить, а когда появляется возможность, выясняется, что все идеи и концепции не очень-то хорошие или совсем не работают. Мечта оказывается ложной.
При этом, как это обычно бывает при оценке сроков, бизнес слышит одно, разработка — другое. Причем бизнес еще делит на два, и тут же начинает давить со сроками и хотеть получить новый продукт вчера. В час Х, выясняется, что разработка думает, что еще есть 3–4 месяца, а бизнес ждал релиз еще вчера. Все расстраиваются, в команда наступает раздрай.
Что предприняли
Мы провели масштабную ретроспективу относительно того, как мы живем, и выявили, что больше всего беспокоит разработчиков и тимлидов.
Необходимость переделывать функциональность, и часто по 3 раза. Если быть честными, ровно половина проблем была на стороне постановки задачи, вторая половина — на стороне реализации. Однако разработчиков, конечно, твердо были уверены, что вся проблема в постановке задачи. На стороне постановщиков задач было то же самое. Никто не хочет считать себя неправым или виноватым, все говорят, что проблема на другой стороне.
Поддержка старого приложения. Сервис с многомиллионной аудиторией нельзя просто так забросить. Параллельно с написанием нового продукта, что-то нужно делать со старым. Это ужасно раздражает!
Внедрение дизайн-системы. Мы очень гордимся этим направлением: оно действительно позволяет быстро делать очень сложные вещи, и продукт выглядит единообразно. Но пришлось обучать дизайнеров тому, что такое JSON, а дизайнерам—- доносить до разработчиков, что внешний вид — это тоже очень важно. Было сломано очень много копий по этому поводу.
Отсутствие информации и ответов на вопрос «Зачем?». Без Value Stream’ов некоторые разработчики перестали понимать, зачем они что-то делают. Произошел разрыв передачи информации, и причинно-следственные связи частично ушли. Те, кто находили в себе силы спросить, почему мы так делаем, были счастливы. Не очень коммуникативные люди считали, что где-то наверху сидят идиоты, которые придумывают вещи, которые невозможно спроектировать.
Недостаток документации по новым бизнес-правилам. По причине отсутствия информации проявился недостаток документации, в которой было бы прописано, как правильно должно работать приложение.
Каждый примерил на себя роль архитектора, и не всем она понравилась. Для меня это было самое большое открытие. Первый раз тимлиды оценили сроки на переработку приложений примерно в полтора года, что никуда не годится. Это произошло потому, что каждый тимлид захотел через себя пропустить все куски системы, то есть очень не хотел делегировать и заниматься декомпозицией архитектуры приложения, а хотел все оставить на себе.
При таком подходе действительно нужно полтора года на переработку архитектуры. Но с такими сроками в этом мире делать нечего. Поэтому после долгих обсуждений пришли к выводу, что архитектурные функции тимлида нужно по определенным ключевым направлениям делегировать опытным бойцам из разработки, которые, в том числе, хотели поучаствовать и почувствовать себя архитектором.
Выяснился интересный факт — оказывается, брать на себя ответственность неприятно.
Называть себя архитектором или тимлидом и быть тимлидом — это две большие разницы. Не каждый оказался готов принять, что если облажаешься и просадишь конверсию, то это будет только твоя ответственность.
Я был наивен и почему-то думал, что подобной смелостью обладают все в нашей команде. Я забыл, что до тимлида нужно созреть и немножко повзрослеть. За год у нас многие прошли через это направление, и некоторые осознали, что хотят расти не вверх, а вширь, и не хотят быть тимлидами.
Как исправляли ситуацию
Помимо декомпозиции и разграничения ролей тимлида на различные архитектурные направления, мы сформировали так называемые Летучие Отряды Возмездия (ЛОВ) и привлекли к ним специалистов по контролю качества (QA). Во-первых, они были свободнее всех — нового продукта еще нет, а писать test case и test suite для последующих регрессов можно уже сейчас.
Тогда выяснилось, что бизнес-правила еще не совсем сформулированы, и в компании не так много людей, которые знают, как должно работать новое приложение.
Мы поставили перед QA следующие задачи:
- Нужна актуальная документация по бизнес-правилам и логике, в которой работает приложение.
- Нужны адепты новой бизнес-логики, причем не только менеджеры и техлиды.
Раз у нас новое приложение, и нужно сделать все заново, нужны люди, к которым можно прийти с вопросами типа: как обработать такую ошибку, как приложение должно вести себя в такой ситуации. Повторюсь, основные кейсы были описаны, но дьявол кроется в деталях — те самые 20% нужно было закрыть.
Мы начали создавать динамические микрокоманды. При том что людей никуда не пересаживали, а прикрепили к продукту конкретного направления человека из QA, который методично занимался проектной работой, а именно, отвечал за:
- сбор вопросов от разработчиков, создание опросников;
- организацию и протоколирование встреч;
- формализацию документации;
- написание заранее test cases и test suites.
Когда мы уже вышли на финишную прямую, это позволило подключать аутсорсеров, аутстафферов для тестирования, чтобы увеличить скорость подготовки к релизу. У нас огромное количество платформ, то, что я перечислил, это только инструменты, с помощью которых мы работаем. Например, в SmartTV 6–7 платформ, на каждую из которых отдельно нужно релизить, проводить отдельный регресс и пр. Если у вас есть заранее прописанные бизнес-кейсы, здесь можно совершенно спокойно подключать аутсорсеров и аутстафферов.
Внедрение ЛОВ очень сильно разгрузило тимлидов. У них появилась возможность не отвлекаться на менеджерские задачи, а уже по проработанному материалу принимать стратегические решения относительно развития кода.
Проект «Летучие Отряды Возмездия» оправдал надежды, и мы вышли на релизную прямую, не поубивав друг друга.
А что дальше?
В октябре 2018 мы зарелизили большую часть приложений, и даже я немножко приуныл — вот мы построили новую платформу, только что переколбасили всю команду, она снова работает эффективно и классно. Но мы же уже через это проходили. Дальше, чтобы снова работать быстро и эффективно, нужно опять этот кубик Рубика разбирать и собирать заново. «Тяжело, но надо,» — подумал я.
Во второй раз уже пошло полегче, потому что трудно было только тем, кто пришел в компанию уже во время возврата к конфигурации 2016 года и не работал в Value Stream. Меньшему числу людей из компании пришлось объяснять, что это такое. Мы уже знали все особенности, как нужно обучать персонал, у нас были подобраны все лекции и пр. Но при этом этот процесс все равно занял месяцы.
Мы начали процесс создания нового приложения в апреле, в октябре пошли первые релизы, на нормальный производственный уровень мы вышли только в середине января.
Вы не представляете, как я был рад, когда в январе релизы пошли по планам годовалой давности. Но при этом мы получили новый продукт, нам удалось, несмотря на все наши страдания, за 2018 год удвоить выручку и довести ее до 4 млрд. Да, команде было тяжело, но при этом нам удалось добиться фантастических результатов, которыми сейчас каждый из нас гордится по праву.
Не бойтесь возвращаться к уже пройденным этапам и переосмысливать их.
Для каждой конкретной ситуации подходит своя модель управления и передачи информации.
Главное — не зашориваться и не ограничиваться шаблонами. Если вы считаете, что сейчас модно, стильно и современно использовать гибкие методологии, это не значит, что нужно работать, принимая во внимание только это направление. Работать можно по-всякому, но важно объяснить команде, почему правила игры меняются.
Открою еще один секрет: со взрослыми людьми, которые не хотят друг другу ничего доказывать, можно работать по любой методологии, потому что они профессионалы. Для каждого этапа развития компании есть свой стиль управления. Не бойтесь показаться смешным.
Программа питерской TeamLead Conf почти готова. Проведем несколько прогонов, добавим последние штрихи, чтобы раскрыть все запланированные темы, и начну рассказывать о докладах по блокам. Пока вы можете самостоятельно оценить список докладов и зарезервировать 23 и 24 сентября под прокачку скиллов тимлида.
