Всем привет!

В рамках этой статьи мы бы хотели рассказать про разные способы организации команд разработки, которые онлайн-кинотеатр Национальной Медиа Группы more.tv прошел за три года: цели изменений, их плюсы и минусы и допущенные ошибки. Уверены, что для многих такой формат может быть более полезен, чем изучение теории по учебникам.

Меня зовут Алексей Дмитриев, я руководитель проектного офиса М3.

Начало

Итак, всё началось в конце 2018 года с принятия управленческого решения о создании нового онлайн-кинотеатра more.tv на базе существующего продукта Videomore. До этого в Национальной Медиа Группе не было больших проектов inhouse-разработки, поэтому для запуска more.tv было решено создать М3 — отдельную компанию с цифровой экспертизой. Перед компанией была поставлена амбициозная цель: за полгода запустить новый продукт.

Но результаты первого полугода оказались довольно скромными: была нанята команда разработки в ~50 человек, развернуты базовые инструменты и продемонстрированы несколько рабочих прототипов. Давайте посмотрим, как была организована работа команды v1.0, чтобы стало понятнее, почему так произошло.

• Продукт: деление по витринам доступа (web, mobile, Smart TV).

• Архитектура: не структурирована, ситуативные решения.

• Разработка: компонентная (деление по стекам PHP, C++, React, Swift, Java) + несколько подрядчиков, работающих по fix price.

• Тестирование: внутри и только ручное.

• DevOps: системный администратор + тимлиды разработки.

• Управление: не структурировано, процессы настраиваются ситуативно, за сроки отвечает команда целиком.

• Agile framework: несвязные островки скрама.

Атмосферу тех времён хорошо передаёт следующая схема:

У этой структуры был ряд проблем:

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

2. ВЕ нужно было выкатывать много и часто, а ручное тестирование не справлялось. Зачастую ранее принятый функционал забывался в новых релизах.

3. Не понимая архитектуру будущего решения в деталях, на подряд был отдан критически важный функционал с непроработанным ТЗ. Уточняющие вопросы сильно отвлекали, а fix price не позволял внести существенные изменения. Итоговый результат пришлось на 70% переписать собственными силами.

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

5. Одновременный найм сотрудников с разным опытом усложнял их возможность быстро договориться. Без людей, ответственных за синхронизацию всех со всеми, возникала ситуация лебедя, рака и щуки.

Команда 2.0

После осознания системных проблем были проведены следующие организационные изменения:

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

Организован проектный офис, который систематизировал процессы в командах, ввёл ежедневный Scrum of Scrum, поставил на поток ретроспективы, перевёл подрядчиков на Time and material и сделал их частью большой команды. Это позволило увеличить гибкость, ускорить реакцию на возникающие проблемы, синхронизировать усилия разных команд и добавить прозрачности для ТОП-менеджмента.

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

Наняты QA-автоматизаторы, которые смогли существенно увеличить скорость прогона регулярных тестов всё больше разрастающегося функционала ВЕ.

Создан отдел DevOps, который занялся системной организацией CI/CD, настройкой мониторинга и отказоустойчивости.

Все эти организационные изменения позволили не только успешно запустить more.tv, но и оперативно реализовать изначально отложенный функционал.

Овертаймы для команды стали редкостью, удовлетворённость сотрудников росла, техдолг уменьшался, на ретроспективах люди чаще стали приносить позитивные кейсы.

В то же время появились проблемы другого характера.

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

Тогда мы решили сфокусироваться на улучшении параметра среднего Time to market (TTM).

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

Сфокусировались на трёх направлениях:

1. уменьшение интервала между релизами,

2. ликвидация бутылочных горлышек,

3. увеличение объема автотестирования.

Тизер: значительный эффект дал только первый пункт, и то для не очень крупных изменений (до четырёх дней разработки). 

Мы внедрили индивидуальные тестовые окружения, пофичный выпуск, канареечные релизы, запретили брать новые задачи, пока не выпущены предыдущие, и многое другое. Это позволило уменьшить средний интервал между релизами нового функционала FE и BE с 23 до 9 рабочих дней.

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

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

Команда 3.0

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

Мы решили попробовать собрать полноценные кросс-функциональные продуктовые команды или feature teams. Благо вся необходимая инфраструктурная подготовка для независимого выката команд была уже готова.

Чтобы не наломать дров, мы решили поставить эксперимент на одной такой команде, собрав ее из добровольцев.

В итоге команда состояла из шести человек каждый со своей ролью:

1. Product owner

2. Business analytic

3. Scrum master

4. Dev BE

5. Dev FE

6. QA manual

По результатам двух кварталов работы feature team было отмечено значительное улучшение среднего ТТМ.

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

Плюсы и минусы

К плюсам такой организации мы отнесли независимость поставки от других команд и большую вовлеченность команды

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

Решение

Первоначальная идея была перевести в кросс-функциональные команды всю разработку.

Но мы столкнулись с несколькими проблемами:

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

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

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

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

В результате сейчас у нас работают восемь команд: шесть продуктовых команд, техническая и компонентная Core-team.

Продуктовые команды отвечают за прокачку определённых метрик. Большинство из них отвечают за свои AARRR-метрики.

Техническая команда распиливает легаси и делает жизнь разработчиков, тестировщиков и DevOps лучше.

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

В командах раз в квартал проводится Health check. Это позволяет участникам четче сформулировать возможные точки роста, а менеджменту увидеть, что и где плохо работает или где требуется помощь.

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

Выводы

Как сейчас видно, за три года мы опробовали три разных подхода к организации разработки. Велик соблазн заявить: «Почему же сразу нельзя было сделать хорошо, чтобы потом не переделывать?».

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

В стадии, когда есть рабочий продукт, устоявшийся штат разработки и продвинутый CI/CD, гораздо эффективней оказываются продуктовые кросс-функциональные команды. 

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

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

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

Автор статьи:

Алексей Дмитриев

Руководитель проектного офиса ООО М3