Компания развивалась как стартап около 5 лет, все фичи делали итерационно в сжатые сроки без планирования. В какой-то момент проект стал большим, неповоротливым и с большим техдологом (нет понимание его объема). Любые фичи начинаются с нескольких дней на понимание куда вносить правки в код. Бизнес винит слабую команду разработки, разработка винит бизнес который давит со сроками. Если бы оказались руководителем разработки в этой компании какие шаги вы бы сделали для решения проблем?

Вопрос прямо как с собеса 😉
Если бы я оказалась у руля, то сделала бы так:

1️⃣ Выясняем, что реально важно

Встречаемся с бизнесом, выясняем, что приносит деньги, что должно начать приносить деньги, а что можно пока отложить. Возможны попытки продавить подход «всё важно», но мы не продавливаемся и договариваемся о реальных приоритетах.

2️⃣ Рисуем карту кодовой базы

Созываем лидов, рисуем архитектурную схему:
🔵 какие микросервисы/модули есть
🟣 за что отвечают
🟢 как общаются
🟡 где какие базы и что в них лежит
🟣 какие есть проблемы (техдолг можно собирать постепенно)

3️⃣ Делаем star map

Это табличка, в которой отмечаем, кто насколько шарит в каком сервисе (0 – никогда не сталкивался, 3 – кодил с закрытыми глазами).

Видим пробелы, понимаем, кто в чем эксперт 😎

4️⃣ Режем слона на части

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

5️⃣ Фокусируемся на приоритетах

Берем самые важные для бизнеса области, которые выявили на первом шаге. Смотрим по star map, кто в них эксперт и качаем по ним остальных людей: созвоны, разборы кода, митапы с разбором бизнес-процессов, ответы на вопросы.

6️⃣ Чиним процессы

Если задачи сначала берутся на реализацию, а потом разработчик пытается понять, что и где надо делать, значит упущен этап проработки задач. От этого первичные оценки занижены, постоянная спешка, все равно не успеваем, и бизнес недоволен ❌

Выделяем этап анализа/проектирования для всех фичей перед разработкой (тут и документация сама собой формируется). Появляется понимание, как делать задачу, сроки становятся реалистичными, стресс снижается ✔️

7️⃣ Разбираемся с техдолгом

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

8️⃣ Автоматизируем, что можно

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

9️⃣ Проводим регулярные демо для бизнеса

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

Растёт прозрачность -> растёт доверие. Жизнь налаживается 😊

Все перечисленные приемы в разное время проверяла на практике.

Задать вопрос можно тут: https://forms.gle/SPE6NEALG9vcnF3s7

Ребят, что бы вы предложили для такой ситуации?

#женя_есть_вопрос