Что делать, когда компания проходит этап взрывного роста? Очевидно, что с увеличением количества сотрудников нужно менять не только структуру отделов, но и все процессы, которые до того казались наиболее удачными. За 15 лет опыта в IT я прошел путь от разработчика интернет-решений для банковской сферы до технического директора. Поэтому на личном опыте знаю, насколько важны правильно выстроенные процессы и четко поставленные задачи с точки зрения разработки и насколько благоприятным может быть грамотно настроенное взаимодействие с бизнес-юнитом.
В компании мы создаем сразу несколько продуктов одновременно, поэтому используем большой стек технологий, что в итоге накладывает отпечаток на то, какие шаги нужно пройти команде, чтобы выкатить готовую версию приложения или новую функциональность. Эффективное управление сразу 12 командами разработки — трудоемкий процесс, к которому нужно подходить с четким пониманием целей и вниманием к деталям.
Восемь лет назад мы были заняты жизненно важными, с точки зрения разработки, задачами: строили свою инфраструктуру, создавали сайт megogo.net и писали приложения для Smart TV. И всем этим занимались около 20 человек, поэтому структура всего отдела разработки была максимально простой и плоской. Нам не нужны были проджекты и тимлиды, сложные процессы взаимодействия были бы избыточными.
Сейчас все иначе. Нас почти 120, и это только люди, задействованные в разработке продуктов. Поэтому сегодня бизнес-процессы сильно отличаются от того, что было в 2011–2012 годах. Первые несколько лет существования компании не все было гладко и не все принятые нами решения и установленные процессы были оптимальными.
Сначала у нас не было деления на команды, а задачи передавались «первому свободному разработчику». Мы ввели Road map, а директор разработки, по сути, выполнял функции главного project manager: самостоятельно распределял задачи и следил за ходом всей разработки. Тем не менее до идеала было далеко: у нас не существовало процесса передачи задач, техническую документацию готовили условные product owners в лучшем случае в Google Docs. Кроме того, что этот подход сильно замедлял всю разработку, project manager тратил огромное количество времени, чтобы из такого документа вычленить и организовать только важную для разработки информацию. В итоге из-за отсутствия согласованности выполнение даже «маленьких» задач в разы затягивалось по срокам.
В процессе развития стало понятно, что используемые методы перестают работать, замедляют рост и ход разработки платформы и, в принципе, давно устарели. Так мы пришли к тому, что пора скорректировать устоявшиеся процессы.
В итоге мы составили для себя план отстройки: запустили ретроспективу своих процессов и на некоторых этапах даже задействовали внешних консультантов.
Первый шаг — общение с командами. Мы собирали «боль» разработчиков во время работы над задачами с точки зрения процессов. Именно обратная связь от команд стала важнейшим рычагом для внедрения изменений.
Основная «боль» не стала для нас новостью. Отсутствие согласованности разработки и готовых требований, которые сразу можно брать в работу, разделили вершину пьедестала худших процессов.
Так у нас появилась команда системных аналитиков. Они превращали документацию от бизнес-юнита в реальные требования для разработки. Параллельно с аналитиками в «бизнесе» создали департамент продуктологов, которые собирали требования, организовывали их в onepagers для аналитиков, следили за целостностью документации и тесно сотрудничали в процессе подготовки требований к разработке.
Следующим шагом было проведение масштабного воркшопа по методологии Agile. Рассказали менеджменту и командам, зачем это нужно в нашем случае и как внедрение поможет упростить работу всей разработки.
Воркшоп помог нам оценить часть существующих процессов и распределения команд, что привело к одновременному использованию Kanban и Scrum как наиболее оптимальному для нас варианту. Более того, мы разделили команды разработки на продуктовые и сервисные. Scrum лучше решает проблемы продуктовых команд, потому что они в рамках спринтов работают над новыми функциональностями одного целостного с точки зрения пользователя продукта. А Kanban наиболее оптимален для сервисных команд, которые не связаны рамками одной функциональности и должны эффективно работать в многопоточном режиме.
Еще одним слабым звеном в процессе взаимодействия отдела разработки и бизнес-юнита было отсутствие порядка и стадий задач, то есть не существовало прозрачности. Без понятных всем участникам ступеней, по которым нужно пройти, чтобы выполнить задачи, слишком много времени тратилось на согласование, всевозможные встречи и проверки статусов. Поэтому мы ввели воронку требований, которая строго определяет стадии: первичный анализ, определение бизнес-метрик, определение MVP, параметры конфигурации, дизайн и Team Review. Вместе с определением приоритетов в Road map, основанном на оценке ожидаемых результатов по каждой задаче, это позволило сделать ход разработки прозрачным для всех участников процесса.
Тестирование продуктовых идей
В том же временном промежутке у нас проводилась оценка перспективных технологий, которые способны упростить разработку и расширить возможности нашей платформы. За их исследование отвечали архитекторы и тимлиды, затем тестировали команды. Самые перспективные технологии взяли в работу. Так мы начали использовать Scala и React.
Структура отдела разработки
За каждой из продуктовых команд закреплен системный аналитик, который является своего рода связующим звеном между бизнесом и разработкой. Его задача — формирование backlog и подготовка формализованных требований для реализации фич.
Отдел системных аналитиков получает бизнес-задачи, каждая из которых проходит через воронку требований. Воронка включает идеи, Road Map с приоритетами и улучшения. Мы получаем некий обозримый набор задач, поэтому важно определить приоритеты и оценить, что улучшит пользовательский опыт и что сможет улучшить сервис. Затем аналитики описывают задачи детальнее, идет подготовка дизайнов и полной спецификации для команд Smart TV, Mobile (Android, iOS, Android TV и Apple TV), Web (desktop и mobile). Далее продуктовые команды передают задачу сервисным командам, которые разрабатывают логику на Back-end. Именно в таком взаимодействии актуально выбранное нами разделение — большее число продуктовых команд создает условную конкуренцию за ресурсы сервисных команд. Эта проблема решается выбором разных методологий (Scrum и Kanban) и однозначным Road Map, явно указывающим на новые функции или особенности, которые необходимо реализовать каждой из команд.
Еще один важный этап в нашем flow — MVP-анализ для тестирования объемных функций и неочевидных идей. Часто он позволяет существенно сократить Time to market для новых продуктов, что, в свою очередь, дает нам существенную фору по сравнению с конкурентами. Когда появляется гипотеза, мы формируем минимальный scope задач, достаточных для релиза и тестирования.
Вот один из последних примеров. У нас была классическая на медиарынке задача — увеличить Retention пользователей на мобильных устройствах. Мы предположили, что популярный в мобильном сегменте формат Stories может нам помочь. В качестве гипотезы для тестирования мы решили использовать наиболее интересные фрагменты из телепередач, сериалов и фильмов. Создавались короткие ролики до 10 минут с возможностью перехода к полной версии. Суммарно над задачей работало около 20 специалистов в течение 3 месяцев. Мы разработали новый инструмент для iOS и Android, настроили метаданные и создали новые профили транскодинга.
На этапе брейнсторминга мы придумали этой функции множество дополнительных фишек. Там был и ускоренный просмотр, и дополнительная перемотка, и воспроизведение субтитров на нескольких языках. Но все они появились со временем: чтобы протестировать гипотезу и ее жизнеспособность, хватало неполной функциональности.
На эффективность процессов влияют не системы трекинга, а сами люди. И конечно, нам приятно, когда сотрудники самомотивированны. К счастью, у нас есть интересные проекты и амбициозные задачи. Медиарынок постоянно развивается. Чтобы успевать за изменениями, мы раз в две недели организовываем неформальные презентации, на которых разбираем новые технологии либо делимся перспективными решениями, над которыми работаем сами. К примеру, на одной из встреч мы разбирались во Flutter, а на другой — рассказывали, как работает система рекомендаций.
Мы четко видим, куда нам двигаться, чтобы и далее улучшать свой flow. Во-первых, следует принимать решения на основании данных, A/B-тестов и строгих метрик — здесь нам не обойтись без алгоритмов Data Science. Во-вторых, построить масштабный Idea Backlog, в основе которого будет глубокая статистика, чтобы убрать субъективные метрики и руководствоваться цифрами.
В итоге мы довольны своим flow и процессами, которые за ним стоят. Разработка функционирует, с нашей точки зрения, оптимально и эффективно. А это единственный важный показатель.
dou.ua
В компании мы создаем сразу несколько продуктов одновременно, поэтому используем большой стек технологий, что в итоге накладывает отпечаток на то, какие шаги нужно пройти команде, чтобы выкатить готовую версию приложения или новую функциональность. Эффективное управление сразу 12 командами разработки — трудоемкий процесс, к которому нужно подходить с четким пониманием целей и вниманием к деталям.
Что-то здесь не так
Когда есть крутая идея и желание плюс возможность для ее реализации, продумывание процессов в компании с заделом на будущее — последнее, что приходит в голову. По многим причинам.Восемь лет назад мы были заняты жизненно важными, с точки зрения разработки, задачами: строили свою инфраструктуру, создавали сайт megogo.net и писали приложения для Smart TV. И всем этим занимались около 20 человек, поэтому структура всего отдела разработки была максимально простой и плоской. Нам не нужны были проджекты и тимлиды, сложные процессы взаимодействия были бы избыточными.
Сейчас все иначе. Нас почти 120, и это только люди, задействованные в разработке продуктов. Поэтому сегодня бизнес-процессы сильно отличаются от того, что было в 2011–2012 годах. Первые несколько лет существования компании не все было гладко и не все принятые нами решения и установленные процессы были оптимальными.
Сначала у нас не было деления на команды, а задачи передавались «первому свободному разработчику». Мы ввели Road map, а директор разработки, по сути, выполнял функции главного project manager: самостоятельно распределял задачи и следил за ходом всей разработки. Тем не менее до идеала было далеко: у нас не существовало процесса передачи задач, техническую документацию готовили условные product owners в лучшем случае в Google Docs. Кроме того, что этот подход сильно замедлял всю разработку, project manager тратил огромное количество времени, чтобы из такого документа вычленить и организовать только важную для разработки информацию. В итоге из-за отсутствия согласованности выполнение даже «маленьких» задач в разы затягивалось по срокам.
В процессе развития стало понятно, что используемые методы перестают работать, замедляют рост и ход разработки платформы и, в принципе, давно устарели. Так мы пришли к тому, что пора скорректировать устоявшиеся процессы.
А с чего начать?
Мы хотели понять, каких целей нужно добиться и какие процессы нужно исправить. С целями было проще: оптимизировать работу команд разработки и упростить взаимодействие с бизнес-юнитом компании. С процессами было сложнее: здесь нужно было разбираться, что работает, а что не очень, в каком месте можно масштабировать и где есть узкие места.В итоге мы составили для себя план отстройки: запустили ретроспективу своих процессов и на некоторых этапах даже задействовали внешних консультантов.
Первый шаг — общение с командами. Мы собирали «боль» разработчиков во время работы над задачами с точки зрения процессов. Именно обратная связь от команд стала важнейшим рычагом для внедрения изменений.
Основная «боль» не стала для нас новостью. Отсутствие согласованности разработки и готовых требований, которые сразу можно брать в работу, разделили вершину пьедестала худших процессов.
Так у нас появилась команда системных аналитиков. Они превращали документацию от бизнес-юнита в реальные требования для разработки. Параллельно с аналитиками в «бизнесе» создали департамент продуктологов, которые собирали требования, организовывали их в onepagers для аналитиков, следили за целостностью документации и тесно сотрудничали в процессе подготовки требований к разработке.
Следующим шагом было проведение масштабного воркшопа по методологии Agile. Рассказали менеджменту и командам, зачем это нужно в нашем случае и как внедрение поможет упростить работу всей разработки.
Воркшоп помог нам оценить часть существующих процессов и распределения команд, что привело к одновременному использованию Kanban и Scrum как наиболее оптимальному для нас варианту. Более того, мы разделили команды разработки на продуктовые и сервисные. Scrum лучше решает проблемы продуктовых команд, потому что они в рамках спринтов работают над новыми функциональностями одного целостного с точки зрения пользователя продукта. А Kanban наиболее оптимален для сервисных команд, которые не связаны рамками одной функциональности и должны эффективно работать в многопоточном режиме.
Еще одним слабым звеном в процессе взаимодействия отдела разработки и бизнес-юнита было отсутствие порядка и стадий задач, то есть не существовало прозрачности. Без понятных всем участникам ступеней, по которым нужно пройти, чтобы выполнить задачи, слишком много времени тратилось на согласование, всевозможные встречи и проверки статусов. Поэтому мы ввели воронку требований, которая строго определяет стадии: первичный анализ, определение бизнес-метрик, определение MVP, параметры конфигурации, дизайн и Team Review. Вместе с определением приоритетов в Road map, основанном на оценке ожидаемых результатов по каждой задаче, это позволило сделать ход разработки прозрачным для всех участников процесса.
В том же временном промежутке у нас проводилась оценка перспективных технологий, которые способны упростить разработку и расширить возможности нашей платформы. За их исследование отвечали архитекторы и тимлиды, затем тестировали команды. Самые перспективные технологии взяли в работу. Так мы начали использовать Scala и React.
Новые принципы работают
Естественно, мы не остановились на внедрении Agile. Например, мы усложнили структуру команд, но смогли упростить взаимодействие между различными отделами. Теперь в каждой из команд кроме разработчиков и QA-инженеров есть project manager, который занимается планированием и обсуждением требований к функциональностям, управляет релизами и их развертыванием, следит за выполнением задач. И обязательно есть team lead, отвечающий за распределение задач, code review, выбор технологий и архитектурные решения.
За каждой из продуктовых команд закреплен системный аналитик, который является своего рода связующим звеном между бизнесом и разработкой. Его задача — формирование backlog и подготовка формализованных требований для реализации фич.
Отдел системных аналитиков получает бизнес-задачи, каждая из которых проходит через воронку требований. Воронка включает идеи, Road Map с приоритетами и улучшения. Мы получаем некий обозримый набор задач, поэтому важно определить приоритеты и оценить, что улучшит пользовательский опыт и что сможет улучшить сервис. Затем аналитики описывают задачи детальнее, идет подготовка дизайнов и полной спецификации для команд Smart TV, Mobile (Android, iOS, Android TV и Apple TV), Web (desktop и mobile). Далее продуктовые команды передают задачу сервисным командам, которые разрабатывают логику на Back-end. Именно в таком взаимодействии актуально выбранное нами разделение — большее число продуктовых команд создает условную конкуренцию за ресурсы сервисных команд. Эта проблема решается выбором разных методологий (Scrum и Kanban) и однозначным Road Map, явно указывающим на новые функции или особенности, которые необходимо реализовать каждой из команд.
Еще один важный этап в нашем flow — MVP-анализ для тестирования объемных функций и неочевидных идей. Часто он позволяет существенно сократить Time to market для новых продуктов, что, в свою очередь, дает нам существенную фору по сравнению с конкурентами. Когда появляется гипотеза, мы формируем минимальный scope задач, достаточных для релиза и тестирования.
Вот один из последних примеров. У нас была классическая на медиарынке задача — увеличить Retention пользователей на мобильных устройствах. Мы предположили, что популярный в мобильном сегменте формат Stories может нам помочь. В качестве гипотезы для тестирования мы решили использовать наиболее интересные фрагменты из телепередач, сериалов и фильмов. Создавались короткие ролики до 10 минут с возможностью перехода к полной версии. Суммарно над задачей работало около 20 специалистов в течение 3 месяцев. Мы разработали новый инструмент для iOS и Android, настроили метаданные и создали новые профили транскодинга.
На этапе брейнсторминга мы придумали этой функции множество дополнительных фишек. Там был и ускоренный просмотр, и дополнительная перемотка, и воспроизведение субтитров на нескольких языках. Но все они появились со временем: чтобы протестировать гипотезу и ее жизнеспособность, хватало неполной функциональности.
Время важных вопросов
После всех оптимизаций и ретроспектив мы поставили себе вполне логичный вопрос: как понять, что процессы работают? Объективно это сделать сложно. У нас нет классических KPI. Мы выбрали для себя главный показатель — выдача готового проекта в кратчайшие сроки с допустимым минимумом багов и максимумом функциональности. На каждом члене команды лежит ответственность за процесс. Для большой задачи мы оцениваем, сколько на нее уйдет времени и ресурсов. Но если в итоге не попали в цель, разбираем на ретроспективах, что пошло не так. Во многих случаях Jira наглядно показывает, почему и на каком этапе зависла задача. Ко всему прочему для оценки серьезных проблем в команде есть Incident Manager.На эффективность процессов влияют не системы трекинга, а сами люди. И конечно, нам приятно, когда сотрудники самомотивированны. К счастью, у нас есть интересные проекты и амбициозные задачи. Медиарынок постоянно развивается. Чтобы успевать за изменениями, мы раз в две недели организовываем неформальные презентации, на которых разбираем новые технологии либо делимся перспективными решениями, над которыми работаем сами. К примеру, на одной из встреч мы разбирались во Flutter, а на другой — рассказывали, как работает система рекомендаций.
Мы четко видим, куда нам двигаться, чтобы и далее улучшать свой flow. Во-первых, следует принимать решения на основании данных, A/B-тестов и строгих метрик — здесь нам не обойтись без алгоритмов Data Science. Во-вторых, построить масштабный Idea Backlog, в основе которого будет глубокая статистика, чтобы убрать субъективные метрики и руководствоваться цифрами.
В итоге мы довольны своим flow и процессами, которые за ним стоят. Разработка функционирует, с нашей точки зрения, оптимально и эффективно. А это единственный важный показатель.
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua