Ключевые подходы
Многим теоретическая часть кажется скучной, но я считаю важным разобраться с инструментами, которые могут помочь в формировании команды. Выделил самые основные, которыми сам постоянно пользуюсь:
Backcasting, или ретроспективный прогноз, — это подход, который помогает планировать деятельность. Суть в том, что сначала вы обозначаете точку, в которую хотите прийти, а потом разматываете всю историю в обратном направлении.
Проектный менеджмент — это процесс управления проектами, который предполагает их организацию, планирование и достижение результата за определённое время и бюджет. С моей точки зрения, этот инструмент отошёл на второй план, причём незаслуженно. Проектный менеджмент полезен для запуска новых инициатив, особенно если у команды ограничены средства или ресурсы.
Канбан — это подход, в котором задачи внутри проекта визуализируются на доске, что помогает эффективнее следить за ходом работы и избегать задержек. Этот подход помогает команде осознать свою системность, а ещё — увидеть бутылочные горлышки, где застревают все проекты, и постараться от этого избавиться. Канбан также полезен, когда команду пытаются перегрузить задачами. Благодаря визуализации люди понимают, что будет перегруз.
Закон Конвея и обратный манёвр Конвея — этот подход придумал разработчик Мелвин Конвей около 50 лет назад. Он заметил, что команды, которые проектируют системы, повторяют структуру своих коммуникаций в дизайне этих систем.
Из этого закона родился вывод, что перед тем, как трансформировать свой продукт или бизнес, нужно обратить внимание на взаимодействие команд. И начать изменения с них.
Teаm Topologies — это подход, который основан на трёх принципах: чёткие цели, простая организация команд и гибкая структура внутри, которую легко приспособить к изменениям.
Менеджмент изменений — подход, который помогает примирить людей в команде с изменениями. Люди часто сопротивляются тому, чего не понимают, поэтому важно помочь им сориентироваться в новой структуре, объяснить, как изменения помогут в будущем.
Алгоритм формирования команды
Теоретически алгоритм выглядит так:
- Поставить долговременную цель с помощью подхода Backcasting и продумать шаги на пути к ней.
- Понять целевую структуру систем, за которые придётся отвечать.
- Применить инструмент «Обратный манёвр Конвея» для проектирования структуры будущих команд.
- Использовать паттерны из Teаm Topologies и подогнать под них структуру команд, которая у вас получилась.
- Использовать менеджмент изменений, чтобы всё спланировать и воплотить.
Часто, если в команде и так всё хорошо, никто даже не задумается о том, чтобы обращаться за помощью. А вот если специалиста по формированию команд уже пригласили, можно не сомневаться: где-то уже что-то горит. Сначала нужно всё потушить, а потом уже думать, как справляться с вызовами. Поэтому на практике алгоритм работает совсем по-другому.
Примеры применения алгоритма
Расскажу несколько случаев из моего опыта в Тинькофф, которые подходят для того, чтобы проиллюстрировать мою работу на разных этапах.
Проектное управление
Задача: переехать на новую версию сайта tinkoff.ru.
К моменту, когда я взялся формировать команду для решения этой задачи, разработка проекта велась больше года. За общее решение отвечала команда из более чем 50 человек. Я вместе с тремя инженерами должен был отвечать за привлечение клиентов через формы и лендинги.
До полноценного переезда оставалось три месяца, при этом до сих пор не работали SSR, аналитика, механики в формах привлечения. А релизы занимали около трёх недель из-за ручного регресса. Если бы мы не переехали на новую версию сайта вовремя, банк потерял бы миллионы рублей.
Решение: проектный менеджмент.
Я составил план: что нужно доделать и кто в этом участвует. Решил, что в команде важно работать короткими итерациями с частыми релизами по два раза в неделю. Это было важно для того, чтобы успеть выкатить все обновления. Для привлечения пользователей через приложение мы создали отдельную инфраструктуру, а также использовали собственный подход к работе с кодом — делали релизы из замороженной ветки и проводили редкий мердж всех изменений.
Аналитику мы запустили через костыль, чтобы проводить хоть какие-то эксперименты и решать проблемы в моменте. Механики в срочном порядке перенесли со старых форм, а проблемы с SEO пришлось принять как данность.
Итог: к переезду мы успели перенести основные формы и страницы почти без потери эффективности. Ребята в команде научились решать проблемы, которые раньше мешали им работать. В конце проекта у нас получился продукт, который можно масштабировать как угодно.
Планомерное развитие
Задача: перейти к планомерному развитию онлайн-привлечения.
Мы потушили пожары, успешно переехали на новую платформу, где всё работало. Появились долговременные цели, которые звучали так:
- Перенести оставшиеся страницы и формы на новые рельсы
- Построить систему server-driven UI
- Разработать внутреннюю систему для проведения экспериментов
- Создать систему для склейки продуктовых и рекламных страниц
Покажу примерную схему взаимодействия систем между собой.
Вот что на ней происходит: когда пользователь хочет открыть наш сайт, он вводит адрес, запрос попадает на фронт. Он не знает, что нужно рендерить, идёт на наш server-driven UI за контентом. Тот, в свою очередь, идёт в нашу систему тестов и подбирает альтернативную страницу для пользователя. Дальше система отдаёт экспериментальную версию с пометкой в описании контента. Фронт получает данные, отрисовывает и показывает пользователю.
Нам нужно было реализовать целевой вариант, с которым пользователь будет взаимодействовать. При этом сделать так, чтобы он был не костыльным, а нормальным.
Решение: продуктовый подход.
Чтобы работать вдолгую, нужно было выстроить понятный продуктовый конвейер. Вот что я сделал:
- Определил ответственность команд — у нас была фронтовая, команда контент-сервисов для server-driven UI и команда, которая отвечала за A/B-тесты.
- Состыковал команды через точки интеграции. В нашем случае такой точкой стал API.
- Организовал работу по Канбану — визуализировал процессы, чтобы людям было проще в них вникнуть.
Итог: получилась структура, в которой команды понимают свои зоны ответственности, а между ними выстроены процессы. Это значит, что у каждой команды предсказуемая пропускная способность и её можно легко улучшить. С помощью таких изменений удалось получить продукт, который готов к масштабированию.
Масштабирование
Задача: масштабировать фронтовые продуктовые команды.
К следующему этапу у нас было три сложившиеся команды при следующих долговременных целях:
- Научиться масштабировать фронтовую разработку за счёт отдельных автономных продуктовых команд
- Делать общие компоненты централизованно, чтобы сэкономить на масштабах и стандартизации
Решение: Team Topologies.
У нас было четыре типа команд и три типа взаимодействий между ними. Для удобства отобразил это на схеме.
Эти команды занимаются реальными задачами бизнеса, при этом продуктовые команды сначала взаимодействуют с платформенными в формате коллаборации. По мере развития команды и продукта взаимодействие перерастает в сервисную историю и так далее.
Мы сделали так, чтобы развести продуктовые и платформенные команды. Таким образом продуктовые освободились и стали пилить бизнесовые фичи, например каско, ОСАГО, формы для привлечения ИП или клиентов по дебетовым картам. Процесс стал понятен не только команде, но и заказчику. Платформенные команды стали заниматься общими инструментами.
Итог: благодаря масштабированию продуктовых команд удалось создать свой фреймворк поверх React с DI, реализовать общие компоненты, например движок форм, трекинг событий и SDK для server-driven UI. Всю команду удалось перевести на микрофронты и передать им весь неавторизованный tinkoff.ru.
Платформизация
Задача: сделать так, чтобы мобильный банк стал платформой.
Покажу схему его развития.
При этом суперапп, к которому мы стремились, — это не монолитная структура. Внутри него есть ряд сервисов, например банковские продукты, платежи и переводы, нефинансовые сервисы и много других. Всё это нужно развивать параллельно, поэтому команду снова пришлось менять.
Решение: использовать сразу несколько инструментов — закон Конвея, обратный манёвр Конвея, Team Topologies и менеджмент изменений.
Такой набор инструментов помог представить, как будет выглядеть приложение, потом подогнать структуру команд так, чтобы они не мешали друг другу работать, а потом помочь всем адаптироваться в новых условиях.
Изначально у нас была слоёная архитектура команды: из супербольшой команды выделялись отдельные слои, каждый из которых работал над своим направлением. Это выглядело так.
Проблема такой структуры в том, что что-то где-то постоянно отваливается и нужно постоянно тушить пожары. Нужно было виртуально разделить людей на отдельные автономные команды со своими задачами и бизнес-доменами. Так и получилось, при этом мы стремились к модульной архитектуре команд.
Автономность каждой команды оказалась ограничена только кодом — можно что-то изменить в нём и сломать работу соседней команде. Поэтому понадобилось внедрить инструменты инженерной культуры. Вот из чего она состояла:
- Формализация процессов разработки через Канбан и внедрение в Delivery Managers
- Обязательное автоматизированное тестирование для новых фич
- Автоматизация регресса и сокращение времени на него
- Контроль архитектуры с помощью fitness functions и Danger в шагах CI/CD-пайплайна
- Улучшение инфраструктуры для сборок приложения и тестов
Итог: релизы стали выпускаться в три раза быстрее за счёт того, что мы описали процессы работы и дали командам возможность их улучшать. Благодаря инженерной культуре удалось сделать приложение надёжнее и производительнее.
Сквозная архитектура
Задача: улучшить сквозную постановку ценности.
Временами работа команд напоминала игру в горячую картошку: сложные задачи каждый передавал другому. Появлялись костыли, которые со временем приходилось пересобирать и настраивать процессы без ошибок.
Чтобы наладить сквозную работу, нужно было сделать так, чтобы продуктовые и платформенные команды могли общаться через stream-aligned команды.
Решение: использовать те же инструменты, что и на предыдущем этапе, — закон Конвея, обратный манёвр Конвея, Team Topologies и менеджмент изменений.
Чтобы выделить stream-aligned команды, понадобилась схема. Она выглядела так.
В каждой stream-aligned команде есть руководители, аналитики, разработчики и тестировщики. Аналитики занимаются проектированием и прописывают требования к работе по всему стеку. Delivery Manager помогает строить сквозные процессы, а благодаря сквозной архитектуре мы постепенно отходим от API к BFF для мобильных приложений. А ещё планируем перейти к сборке read-моделей на основе потока событий.
Итог: в Тинькофф теперь много сквозных команд, которыми можно управлять на основе следующих принципов:
- Для команд супераппа есть определённые правила, которые дают представление о сути команды, процессах разработки, эксплуатации и проверки.
- Руководители отслеживают метрики и получают представление о влиянии изменений на производительность людей, команд и качество продукта.