Предлагаем вашему вниманию проектную работу Романа Прудкогляда, выпускника курса «Delivery Manager«.

• LinkedIn: linkedin.com/in/roman-prudkogliad-7526a44

• Telegram: @RomanPrudkogliad

Устроившись в компанию N, я первым делом провожу аудит доверенного мне отдела разработки. Оказывается, что отдел находится в неработоспособном состоянии: процессов нет;  что команды делают и как именно – никто не знает; тимлиды между собой никак не коммуницируют, а топ-менеджеры не понимают, что происходит в отделе. 

Все эти проблемы мне предстоит решить. Здесь вы узнаете о том, как я это делаю.

Девять проблем отдела разработки

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

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

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

Частые кризисы в отделе разработки. Это сигнал о том, что продукт работает нестабильно, снижается NPS (индекс потребительской лояльности), падают доходы самой компании

Бэкенд разрабатывается на Java 8, БД – на PostgreSQL 9.2, Spring 4.3, Spring Boot 1.5. Многие из этих версий уже не поддерживаются, при серьёзных уязвимостях – будет сложно починить. При попытках создать микросервисы, получается распределенный монолит. Релиз новых версий монолита требует участия всех QA, попавших в этот деплой. Каждый деплой отнимает полдня. 

Фронтенд разрабатывается на Angular 11 и TypeScript 4.1. Эти версии библиотек необходимо обновить. В одном репозитории – огромное количество кода, на сборку уходит много времени. После каждого исправления разработчик ждёт сборки по 10-20 минут в зависимости от мощности компьютера.  

QA пишут автотесты на Selenium v3.141.5. Старая и медленная версия Selenium. Прогон тестов занимает от двух до четырёх часов. Много случайно «упавших» тестов (flaky tests). Разработчики практически не пишут юнит-тестов, а если пишут, то такие тесты – низкого качества.

Система виртуализации – старая, «виртуалки» постоянно ломаются. Внедрены система контейнеризации Docker и система управления контейнерами Kubernetes, но разработчики не придерживаются требований к разработке сервисов для контейнеров. Поэтому возникает много проблем с поддержкой и обновлением. Тестовые среды постоянно ломаются, а их починкой не занимается никто. Проблемы с production-окружением часто игнорируются. Проблемы пользователей не доходят до отдела разработки. 

Следствие проблем

Многие сотрудники выгорели, отдел теряет специалистов.

Решения

Проекты

• Я согласую зону ответственности и мои цели на квартал, полгода, год.  

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

• метрики PMBOK
• набор других подходящих метрик для Scrum или Kanban
• метрики для waterfall-проектов.

Горизонтальные связи

Предлагаю сформировать:

• проектные команды разработки
• сервисную команду с DevOps (у каждого члена сервисной команды – своя зона ответственности)

Состав команд разработки:

• 1 тимлид
• 6 разработчиков: три бэкенд- и три фронтенд-разработчика
• 2 QA

Структура отдела

Также считаю необходимым организовать работу сообществ бэкенд- и фронтенд-разработчиков, тестировщиков, DevOps.

Функции и устройство сообществ

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

• Раз в месяц сообщества рассказывают о реализованных технические инициативах, делятся дальнейшими планами. 
• Сообщества собираются раз в неделю и ведут бэклоги с инициативами и техническим долгом. 
• У каждого сообщества есть лидер (председатель), который отвечает за сообщество и помогает формировать бэклог. 

Вертикальные связи

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

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

Инструменты и практики

• Три проектные команды будут работать над внутренним продуктом. Эти команды внедряют гибкие методологии разработки (Scrum).
• Две другие проектные команды работают над проектами для заказчиков и работают по методологии Waterfall.
• Команда DevOps работает с входящим потоком запросов от проектных команд; внутри команды действует Kanban.
• Каждая команда сама должна решить, сколько времени выделять на технический долг или на технические инициативы. Я бы предложил выделять на это 15-20% от времени спринта или каждый пятый спринт целиком. 
• Внедрить ревью кода и архитектурных решений на стадии дизайна и анализа будущих изменений. Костяк из лидеров, способных проводить такой анализ, будет формироваться в профессиональных сообществах.
• Внедрить новую стадию проверки кода, статический анализатор кода и библиотек на уязвимости. 
• Закрепить за каждым сервисом ответственную команду. 
• Показывать технический долг, задачи и приоритет задач из саппорта на спринт-ревью команды
• Внедрить практику технических чтений: команды будут делиться новыми техническими решениями, решениями архитектурных задач, создавать записи архитектурных решений (ADR, architectural decision records)
• Создать карту компетенций для каждой специализации: бэкенд, фронтенд, QA, DevOps: для каждого отдела создаётся матрица скилов и разрабатывается карьерный путь; расписываются уровни для каждого отдела: Intern, Junior, Middle, Senior, Lead. Лиды в командах и профсообществах отвечают за развитие сотрудников. 
• Разработать и внедрить процесс эскалации. Также внедрить автоматические инструменты мониторинга и эскалации ошибок в ответственные команды. 
• Привлечь HRBP. Необходимо оценивать мотивацию сотрудников отдела разработки, слаживать команду; организовывать проверки для работников с низкой производительностью, и, если нужно, увольнять.

План действий

1. Встретиться с командами и руководителями команд. Обучить лидов и команды гибким методологиям. 
2. Обучить лидов проводить встречи «один на один», составлять карьерные пути и ставить цели. 
3. Сформировать бэклог команд со стейкхолдерами и лидами, упорядочить бэклог по степени важности задач, спланировать спринты. Постепенно запустить гибкие методологии. Организовать регулярные встречи в командах: планирование, «daily», упорядочивание бэклога, организацию «демо» и «ретро» в командах. 
4. Установить коммуникацию с стейкхолдерами. Организовать ежемесячные встречи, отчетчитываться о проекте в системе трекинга задач, чтобы стейкхолдеры всегда могли узнать состояние проекта и прогнозы.
5. Создать процесс, который поможет передать командам и стейкхолдерам сведения о дефектах из «продакшена». Распределить ответственность за сервисы между командами, закрепить границы ответственности. У каждой команды должен быть свой канал, куда пользователи и автоматические системы мониторинга смогут сообщать о проблемах с сервисом. Также каналы команд можно будет использовать и для ChatOps.
6. Постепенно запустить профсообщества бэкенд- и фронтенд-разработчиков, тестировщиков, DevOps. 

Расчёт ROI для инженерных инициатив сообществ

Пример расчета ROI 1:  Обновление библиотек бэкенда. Риски: уязвимости в старых библиотеках могут вызвать отказ или утечку персональных данных клиентов. Затраты на обновление библиотек: один человеко-месяц на одну библиотеку. Потери в случае утечки данных: 10-20% годового дохода компании в качестве штрафа. ROI = (2 000 0000 — 5000) ÷  5000 = 400%.

Пример расчета ROI 2: Обновление библиотек фронтенда для уменьшения времени сборки для каждого разработчика. Стоимость обновления: 0,5 человеко-месяца за библиотеку. Потери при сборке: 

15 человек производят 4-6 сборок в день.
15 x 6 x 20(мин) = 1800 x 20 (рабочих дней) = 36000 мин/мес = 600 ч/мес = 3.75 человеко-месяца х 5000 = 18750＄. ROI = (18750 — 2500) ÷ 2500 = 6.5%

Такие расчёты помогут встроить технические задачи в общий бэклог с продуктовыми задачами. 

7. Улучшить релизный процесс по результатам аудита в командах, внедрить и улучшить метрики DORA (DevOps Research and Assessment), провести оценку релизного процесса по DORA.
8. Совместно со стейкхолдерами разработать систему метрик для оценки работы команд. В командах с лидами разработать KPI для участников команд, согласовать метрики и KPI со всем отделом, внедрить регулярные отчеты по KPI и метрикам команд: «capacity», «performance», «review iterations»

Ожидаемый результат

Когда мера становится целью, она перестаёт быть хорошей мерой

Чарльз Гудхарт

• Команды обучены; работают, используя гибкие методологии. Каждая команда проводит встречи, чтобы поддерживать процесс разработки: daily, «груминг», планирование, спринт, демо, ретро. 
• Руководители регулярно проводят встречи один на один: раз в месяц или в квартал. Команды оперируют метриками для оценки собственной работы: метриками по дефектам (информация о дефектах поступает от пользователей) и метриками по объему технического долга. Метрики презентуются на каждом демо команд. Регулярные отчёты по метрикам позволяют быстро реагировать на изменения [в метриках] и принимать соответствующие решения.
• Профсообщества проводят встречи раз в неделю, чтобы расставить приоритеты в работе над техническими задачами и организовать технические инициативы в командах.
• Стейкхолдеры всегда в курсе деятельности и планов команд. Регулярные встречи со стейкхолдерами для расстановки приоритетов в бэклоге и для разбора задач позволяют установить двустороннюю коммуникацию. 
• Чёткие планы позволяют инвестировать в будущую разработку продуктов. Повышается NPS, компания увеличивает доход от своих продуктов, получает инвестиции для новых проектов. 
• Улучшается eNPS, уменьшается текучка кадров. Стабилизируется работа команд. Сотрудники учатся презентовать внутренние технические решения, выступать на встречах. Таким образом повышается публичный рейтинг компании внутри сообщества разработчиков.

Новая структура отдела 

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