Как выпускать больше изменений в продукте? Или команда разработки как продукт
У проектного менеджера, или деливери менеджера – иногда, возникает такая специализация, основная задача: выпустить в срок запрос на изменение продукта.
Давайте посмотрим, как эволюционно мы развивали наши процессы в командах и пришли к выводу, что главная метрика работы сотрудника – время работы над запросом на изменения – Заказом в нашей терминологии.
В статье рассматривается отдел внутренней разработки в крупной компании.
Для приготовления по нашему рецепту вам потребуется.
Список ингредиентов:
- Проекты на обслуживании – у нас это интернет-магазины на платформе 1С-Битрикс 🧱
- Команды разработки – аналитики, дизайнеры, фронт и бэкенд разработчики, тестировщики и devops инженеры 🤗
- Система подачи заявок на изменения сайтов – Битрикс24, бизнес-процесс для согласования стейкхолдерами 📨
- Система ведения задач командами – Youtrack ✍
- Система сбора данных по процессу разработки (Hand Made KPI) 📊
- Система обучения и адаптации сотрудников (Hand Made HRM) 🧑🏫
Мы развиваем 18 проектов на базе 1С-Битрикс, которые обслуживают свыше 1300 доменных имен – сайтов. Копоративный портал с CRM на основе коробочной версии 1С-Битрикс24. PIM систему на Laravel и систему СДО (на базе **** 🤬) . Про «блеск и боль» разработки на Битрикс можно будет написать отдельный пост, но все наши сайты отвечают быстрее 2 секунд при любых раскладах, а это кое чего стоит.
Если мы будем смотреть на команду, как на продукт, то у нее будут метрики продукта и метрики роста:
Метрика команды-продукта – доля времени сотрудников, которое уходит на добавление фич.
Метрика роста – количество выпущенных фич.
Ядро команд разработки состоит из аналитиков и программистов PHP, остальные сотрудники присоединяются к ним при возникновения потребности, для реализации того или иного запроса на изменения сайта.
Все запросы на изменения сайтов, которые обслуживают наши команды, оформляются в виде документов – Заказов. Заказы содержат от 1 до нескольких требований на изменение функционала интернет-магазинов или корпоративного портала.
В этот момент возникает одна из главных неопределённостей – как долго будет выполняться заказ? Когда его сможет получить заказчик-инициатор?
Для уменьшения неопределённости на этом этапе надо классифицировать заказы на категории трудоёмкости:
- D – простое изменение 1-2 рабочих дня.
- С – обычное изменение 3-5 рабочих дней.
- В – сложное изменение 6-10 рабочих дней.
- А – трудоёмкое изменение 11-20 рабочих дней.
- А+ – эпическое изменение, требует более 20 дней работы команды.
Вы можете попробовать создать другую систему классификации, но 100% точности всё равно не получить – запросы разные и нам их надо «примерно разложить на кучки», чтобы было от чего отталкиваться при сборе данных.
Категория трудоёмкости пересчитывается в момент релиза, на основе фактических затрат команды. Мы регулярно анализировали причины переоценок и улучшали процесс будущих оценок, чтобы уменьшить погрешность в первоначальной оценке.
В результате мы получили 2х кратное улучшение оценок – сократили ошибки первоначальной оценки трудоёмкости с 60% до 30%.
Предварительная оценка трудоёмкости позволила выявить средние календарные сроки для каждой категории и взять их в качестве отправной точки, чтобы улучшать процессы и сокращать сроки реализации.
В 2020 году, когда более менее выстроилась система и мы начали собирать данные мы получили следующую таблицу в календарных днях:
- D – изменение 1-2 рабочих дня: реализация 11 календарных дней. 🤔
- С – изменение 3-5 рабочих дней: реализация 42 календарных дня. 😩
- В – изменение 6-10 рабочих дней: реализация 100 календарных дней. 😱
- А – изменение 11-20 рабочих дней: реализация 127 календарных дней. 😬
Так как эпические изменения А+ выполнялись от полугода до 2 лет, то смысла сравнивать их друг с другом нет, но к этому выводу мы пришли немного позднее.
Основные способы разработки выглядели следующим образом:
- Любое число заказов в работе – нет WIP лимитов
- Заказ разрабатывается последовательно – передаётся сотрудниками с этапа на этап 🚰
- Синхронизация коллег на утренней планёрке и в чатах
Любая работа ведётся по тикету в Ютреке, причём он «включается сотрудником в работу» на время, когда ты реально делаешь эту задачу и выключается, если занят другим делом. Это позволяет собирать данные и оптимизировать процессы опираясь именно на данные и факты, а не мнения.
Чтобы облегчить себе процедуры включения и выключения задач, и вообще работу с ними – запилили микроприложение Pixapp которое обеспечивает дружелюбный UI для основных сценариев работы с Youtrack.
Безусловно такие длительные сроки разработки не устраивали заказчиков, да и нам самим они не очень нравились. Чётко понять причины такого сложно – все работают работу ежедневно, она делается и выпускаются релизы.
Ключевое изменение № 1 – переход к реальным командам разработки
Мы начали собирать полную команду разработки сразу, как только заказ был приоритизирован и передан в работу. В неё включались все виды сотрудников, а если для конкретной реализации не требовался дизайн, пересборка фронта или перенастройка инфраструктуры, то эти специалисты «отключались от команды» и могли прийти только на внутренее тестирование.
Преимущество 👍 – команда вовлекалась сразу, если придумывала как, то могла начать и параллельную разработку.
Недостаток 👎 – техническое задание могло быть готовым уже после реализации, и его согласование задерживало выпуск релиза из-за соблюдения согласованных процедур.
Результаты № 1:
– Календарные сроки сократились на 20-30%.
Уже не плохо, но это не то, чего мы хотели – календарные сроки хотелось сократить в 2 раза минимум.
Ключевое изменение № 2 – постмортем отчет по каждому выпущенному заказу
Мы создали форму и начали заполнять отчеты по тому, что в процессе работы пошло не так, что можно улучшить. Однако, неструктурированная форма отчета в свободной форме вызывала длительное время на их осмысление. Пришлось проанализировать отчеты и выделить типовые причины, по которым происходят задержки с выпуском релиза.
Постмортем отчёт разделили на два блока ответственности – свою и заказчика. Список получился такой:
Проблемы внутри команд разработки:
- Вовремя не приняты решения по заказу: разбиение, сокращение функционала
- Новые для исполнителей технологии, сервисы или их части
- Сценарии взаимодействия были не проработаны
- Техническая реализация была не проработана
- Возврат на исполнителя: не проверено за собой
- Проблемы с внутренними сервисами и технологиями: ранее написанный код, вёрстка, дизайн или документация
- Проблемы с внешними сервисами и технологиями
- Ожидание выпуска: зависимость от других заказов ИНТ
- Проблемы с коммуникациями, взаимодействием внутри команды или регламентами
- Предложенное решение усложнило изначально поставленную задачу
- Недостаточно времени у исполнителей на выполнение задачи: дежурства или другие приоритетные задачи
- Отсутствие исполнителей на рабочем месте: отпуск, больничный или другое отсутствие
Проблемы на стороне заказчика:
- Бизнес-цель или проблема не определена
- Инициатор заказа не являлся конечным заказчиком: проблема передачи требований или видения реализации
- Заказчик плохо понимал особенности имеющегося или добавляемого функционала: проект или работу веб-технологий
- Заказ не проработанный: изложены не все требования, есть неточности и противоречия
- Добавлены необоснованные требования на этапе тестирования
- Задержки для синхронизации с релизом внешней системы: связанный заказ ЕРП, 1С, Астор, Антор и прочее
- Заказчик несвоевременно предоставил контент: данные для тестирования, фото или тексты
- Заказчик приостановил выпуск
- Недостаточно времени у заказчика на коммуникации и тестирование: больничные, отпуска или другая более приоритетная работа
Каждая из причин срабатывала в той или иной степени, причём возникали заказы, в которых они срабатывали, но не приводили к последствиям – заказ выпускался с нормальным календарным сроком.
Результаты № 2:
– Структуризация проблем в процессе с классификацией по степени влияния на календарные сроки.
Наибольшее влияние около 30% оказывают внутренние факторы:
- Новые для исполнителей технологии, сервисы или их части
- Проблемы с внутренними сервисами и технологиями: ранее написанный код, вёрстка, дизайн или документация
- Недостаточно времени у исполнителей на выполнение задачи: дежурства или другие приоритетные задачи
И порядка 15% создают проблемы с календарными сроками на стороне заказчика следующий причины:
- Заказ не проработанный: изложены не все требования, есть неточности и противоречия
- Недостаточно времени у заказчика на коммуникации и тестирование: больничные, отпуска или другая более приоритетная работа
Для устранения каждой из причин были намечены следующие действия:
- Недостаточно времени у исполнителей – ввели лимит 1 заказ в работе у одного аналитика, и он и команда перестали «распыляться» и начали фокусировано выпускать релизы.
- Проблемы с легаси кодом и технологиями – начали переписывать части кода на основе принципов «чистой архитектуры» и внедрять ТДД.
- Новые сервисы – определили специализацию для команд, теперь одна команда вносит изменения только в определённый части сайта, а не любую часть проекта. Программисты начали иногда встречать ранее знакомы код.
Сложнее оказалось с заказчиками, они не всегда готовы принимать ответственность за свои требования, всегда можно срыв сроков свалить на разработку.
- Заказ не проработанный – начали глубоко прорабатывать начальные требования, выяснять их обоснованность и необходимость. Выискивать МЗР – минимально затратное решение, для реальной клиентской проблемы. Создали «комитеты» – команда собирается на раннем этапе написания заказа, анализирует требования и его потенциальную ценность и сложность.
- Недостаточно времени у заказчика – пока ничего хорошего не придумали, для устранения этой причины.
Наибольшее недовольство вызвали проработки заказов – уточнения требований и их обоснованность, это всё буквально воспринималось в штыки. Однако, принесло свои плоды – заказов стало меньше, они стали более обдуманными и содержали минимум требований, которые были полезны клиенту.
Что же произошло со сроками реализации?
Они сократились на 30-50%.
- D – трудоёмкость 1-2 рабочих дня: реализация 6 календарных дней.
- С – трудоёмкость 3-5 рабочих дней: реализация 19 календарных дня.
- В – трудоёмкость 6-10 рабочих дней: реализация 57 календарных дней.
- А – трудоёмкость 11-20 рабочих дней: реализация 90 календарных дней.
Из данных видно, что 2х кратного сокращения удалось добиться для заказов D и C. Для В и А чуть меньше, но тоже не плохой результат для начала.
Какие инструменты у нас остались в запасе, чтобы еще больше нарастить производительность:
- Выстроенная декомпозиция и улучшенная параллельность работ
- Улучшение методик сбора требований
Это позволит оптимизировать добавление фич, но может не улучшить их ценность для клиентов – для этого потребуется перейти на продуктовый подход. А это тема уже следующей истории.
Кроме того, было выявлено, что у нас может наблюдаться существенная утечка времени на исправление ошибок, которые возникают, в том числе, из-за погони за сроками реализации. И тут возникает тот самый противовес, который надо сбалансировать.
Надеюсь, что статья была полезна. Не буду рекламировать никаких тг каналов, но если захотите уточнить что-то или потребуется помощь в улучшении работы вашей команды, то пишите @tatonimus.