Спасение проблемной команды разработки видеосервиса

Реанимация проблемной команды: диагностика и план спасения

1. Выявление дисфункций команды

Признаки проблем в команде видеосервиса

Признак 1: Пропуск дедлайнов (100% вероятность)

• Предоставляемые сроки регулярно срываются на 30-50%
• Пример: обещали 2 недели, в итоге 3 недели
• Причины: плохая оценка времени, перфекционизм, недостаток ресурсов, блокеры

Признак 2: Деградация качества кода (95% вероятность)

• Увеличение количества багов в production
• Растущее количество code review комментариев
• Технический долг accumulates
• Причины: спешка, усталость, низкое тестовое покрытие

Признак 3: Демотивация и текучка (80% вероятность)

• Разговоры по поводу ухода сотрудников
• Активность в чате упала, ответы вяло
• Нет инициативы, люди делают только то, что просили
• Причины: перегруженность, бесперспективность, плохая коммуникация

Признак 4: Отсутствие координации (90% вероятность)

• На стендапах либо рассинхрон, либо никто ничего не говорит
• Люди занимаются своим, не знают, что делают коллеги
• Блокеры остаются нерешёнными неделями
• Причины: плохой PM, отсутствие планирования

Признак 5: Отсутствие видения (75% вероятность)

• Люди не понимают, зачем этот сервис нужен
• Нет связи между спринтом и большей стратегией
• Каждый спринт - новые требования
• Причины: плохая коммуникация целей

Какие данные нужно собрать для диагностики

Данные #1: Метрики спринта за последние 3 месяца

• Velocity: был ли тренд вверх или вниз?
• Burn-down: как часто люди не успевают до дедлайна?
• Количество переносимых задач из спринта в спринт

Данные #2: Анализ вакансий и уходов

• Сколько человек ушло за последние 6 месяцев?
• Причины ухода: выгорание, низкая зарплата, смена профессии?
• Сколько вакансий не можно заполнить на рынке?

Данные #3: Опрос команды (анонимный)

• Шкала 1-10: как часто ты чувствуешь себя перегруженным?
• Шкала 1-10: понимаешь ли ты цели проекта?
• Шкала 1-10: доверяешь ли ты PM/лиду команды?
• Открытый вопрос: что главное разочарование в проекте?

Данные #4: Анализ production issues

• Сколько критических багов в неделю?
• Среднее время исправления
• Частые разделы: backend, frontend, infrastructure?

Данные #5: Структура команды и компетенции

• Кто лидер технический? Авторитет ли он?
• Есть ли PM? Какой уровень опыта?
• Возрастное распределение
• Есть ли конфликты между людьми?

Данные #6: История требований и изменений

• Сколько раз менялись приоритеты в текущем квартале?
• Сколько раз задачи переходили из "в разработке" в "отменено"?

Данные #7: Техдолг и код-смеллы

• SonarQube оценка качества кода
• Процент покрытия unit-тестами (целевое: >= 80%)
• Количество FIXME/TODO комментариев в коде

2. Предложенные решения для каждой проблемы

Проблема 1: Срывающиеся дедлайны

Решение 1a: Улучшить оценку (Planning Poker)

• Каждая задача - оценка в story points
• Обсуждение: почему одни говорят 5, другие 13?
• История estimate vs actual: после завершения учимся
• Ожидаемый результат: accuracy оценок +25% через месяц

Решение 1b: Добавить 30% буфера

• Спринт = 10 дней, но планируем только на 7
• Остальные 3 дня = непредвиденные блокеры, code review, рефакторинг
• Ожидаемый результат: 90%+ спринтов завершаются в срок

Решение 1c: Максимум 70% capacity на новые фичи

• 30% на техдолг, баги, code review, документацию
• Ожидаемый результат: техдолг не растёт

Решение 1d: Выявление и удаление блокеров еженедельно

• На стендапе: кто забокирован и на сколько дней?
• PM немедленно решает блокеры
• Ожидаемый результат: время на блокеры -50%

Проблема 2: Деградация качества кода

Решение 2a: Обязательный code review

• Никакой PR не мёрджится без review от 2 человек
• SLA на review: максимум 24 часа
• Автоматизированные проверки ПЕРЕД review
• Ожидаемый результат: количество багов в production -40%

Решение 2b: Повышение test coverage

• Текущее покрытие: допустим, 40%, целевое: 80%
• План: +10% в спринт
• Для новых фич: 100% покрытие обязательно
• Ожидаемый результат: баги в production -50%

Решение 2c: Code style guide и автоматизация

• Создать style guide
• Настроить pre-commit hooks: форматирование, linting, unit тесты
• IDE templates
• Ожидаемый результат: дни code review -30%

Решение 2d: Техдолг-спринт один раз в 3 спринта

• Один спринт = 100% на техдолг, рефакторинг, баги
• Это не обсуждается, это правило
• Ожидаемый результат: техдолг не растёт

Проблема 3: Демотивация и текучка

Решение 3a: Демонстрация результатов (еженедельно)

• Каждую пятницу: демонстрация фич реальным пользователям
• Люди видят: я делал, это работает, люди это используют
• Ожидаемый результат: engagement в работе +40%

Решение 3b: Развитие компетенций (1 день в спринт)

• Каждый выбирает learning goal на квартал
• 1 день в спринт на обучение
• Ожидаемый результат: люди чувствуют карьерный рост, retention +25%

Решение 3c: Психологическая безопасность

• Позволить людям говорить: это невозможно
• Не критиковать за bad estimates
• Отмечать effort
• Ожидаемый результат: люди говорят правду

Решение 3d: Зарплата (если позволяет бюджет)

• Анализ рынка: какая средняя зарплата?
• Если отставание > 10% - это проблема
• Пересмотр зарплаты для key людей
• Ожидаемый результат: retention ключевых спецов +40%

Проблема 4: Отсутствие координации

Решение 4a: Переделать стендап

• УТРОМ, максимум 15 мин
• Вопросы: что сделал, что делаю, есть ли блокеры?
• Блокеры = сразу встреча PM + зависимый человек
• Ожидаемый результат: люди знают, кто что делает

Решение 4b: Планирование спринта (лучше)

• Подготовка: PM готовит backlog
• День 1 спринта: все оценивают и планируют
• Все говорят: понял ли я, что нужно делать?
• Ожидаемый результат: clarity +60%

Решение 4c: Board (Jira/Linear) как источник истины

• Все задачи ОБЯЗАТЕЛЬНО в board-е
• Статусы: Backlog, To Do, In Progress, Review, Done
• Люди обновляют статус каждый день
• Ожидаемый результат: visibility +80%

Проблема 5: Отсутствие видения

Решение 5a: Разработать видение на квартал

• Какая цель? (увеличить DAU на 50%)
• Какие 3-5 эпик? (улучшить качество видео, социальные фичи)
• Почему это важно?
• Каким будет успех? (DAU +50%, retention +30%)
• Ожидаемый результат: motivation +50%

Решение 5b: Planning документ

• Одна страница: видение, roadmap на 6 месяцев, метрики
• Обновляется раз в месяц
• Доступно всей команде
• Ожидаемый результат: люди объясняют, зачем это делают

Решение 5c: Демонстрация результатов заинтересованным сторонам

• Раз в месяц: показываем CEO/руководству результаты
• Люди видят: их работа влияет на бизнес
• Ожидаемый результат: большее понимание важности

3. План действий на 30 дней

НЕДЕЛЯ 1: ДИАГНОСТИКА

День 1: Вступительная встреча с командой (30 мин)

• Представиться, объяснить мандат
• Я тут, чтобы помочь, не чтобы судить
• Мне нужна ваша помощь

День 1-2: Индивидуальные 1-1-беседы с инженерами

• Как дела? Что вас разочаровывает?
• Какие ваши сильные стороны?
• Что бы вы изменили в процессе?
• Планируете ли остаться в команде?

День 2-3: Анализ данных

• Velocity за 3 месяца
• Production issues анализ
• Review recent PRs
• Check технических стандартов

День 3-4: Встреча с техническим лидом

• Какие главные технические проблемы?
• Какие зависимости блокируют развитие?
• Что нужно для улучшения архитектуры?

День 4: Встреча с руководством

• Предварительные выводы
• Мне нужна поддержка: буфер времени, возможно найм
• Дедлайны: реалистичные ли?

День 5: Итоговый доклад команде

• Вот что я вижу (проблемы)
• Вот что мы будем менять
• Я беру ответственность за результаты

НЕДЕЛЯ 2-3: ВНЕДРЕНИЕ

Неделя 2: Процесс и коммуникация

День 6-7: Переделать стендап

• Новый формат: максимум 15 мин, утром
• Вопросы: что сделал, что делаю, есть ли блокеры?
• Обсудить формат, скорректировать

День 8: Планирование спринта

• Подготовка: PM готовит backlog
• 3 часа на оценку и планирование
• Все говорят: поняли ли требования

День 9: Встреча по техдолгу

• Какой % спринта на улучшение? (30%)
• Приоритет: test coverage +10%

День 10: Встреча по зарплатам

• Анализ рынка
• Raise для key людей

Неделя 3: Люди и мотивация

День 11: Демонстрация фич (Demo day)

• Каждый показывает, что сделал
• Реальный пользователь смотрит и даёт feedback

День 12: Встреча по learning goals

• Каждый выбирает, в чём развиваться
• 1 день в спринт на обучение

День 13: Обновить vision документ

• Цель на квартал
• 3-5 эпик
• Метрики успеха

День 14: 1-1 встреча с каждым

• Видишь ли изменения?
• Что ещё не так?
• Готов ли остаться?

День 15: Анонимный опрос

• Улучшилась ли ситуация?
• Какие проблемы остались?

НЕДЕЛЯ 4: ОЦЕНКА РЕЗУЛЬТАТОВ

День 16-20: Отслеживание прогресса

• Velocity спринта
• Переносимые задачи
• Баги в production
• Текучка в команде
• Morale

День 20: Промежуточный доклад руководству

• Что сделали
• Текущие метрики
• Следующие 30 дней: план B

День 21-30: Корректировка и масштабирование

• Если velocity улучшилась +15%: продолжаем
• Если нет: анализируем почему

День 30: Финальный доклад команде

• Что достигли
• Что улучшилось: метрики
• Новое видение на следующие 30 дней

4. Метрики для отслеживания прогресса команды

Метрики производительности

Метрики качества

Метрики людей и культуры

Метрики коммуникации

5. Коммуникация с руководством о статусе проекта

Принцип: "Правда, надежда, план"

Первый доклад (День 4) - Диагностика

СЛАЙД 1: ПРОБЛЕМА

• Velocity падает на 30% в месяц
• 3 человека ушло за последние 6 месяцев
• Техдолг критический: D по SonarQube
• Production bugs: 5-7 в неделю
• Morale: 3.2/10

СЛАЙД 2: ПРИЧИНЫ

• Амбициозные дедлайны без буфера
• Отсутствие стандартов качества
• Плохая коммуникация видения
• Отсутствие развития
• Перегруженность: 100% capacity на фичи

СЛАЙД 3: РИСК

• Ещё 2-3 человека уйдут в месяц
• Velocity упадет ещё на 30%
• Качество проекта упадет
• Проект может быть заморожен

СЛАЙД 4: ЧТО БУДУ ДЕЛАТЬ

1. Переделать стендапы и планирование
2. Ввести code review и test coverage
3. 70% фичи, 30% улучшения
4. Коммуницировать видение
5. Развивать компетенции
6. Пересмотр зарплат

СЛАЙД 5: ЧТО НУЖНО ОТ ВАС

• Буфер на 3 недели на дедлайне
• Найм разработчиков
• Поддержка: честная коммуникация

СЛАЙД 6: МЕТРИКИ УСПЕХА

• Velocity +15%
• Bugs -50%
• Morale +40%
• 0 уходов

Второй доклад (День 15) - Промежуточные результаты

Velocity: 35 pts (было 28) +25% Bugs: 2 за неделю (было 5) -60% Morale: 6.8/10 (было 3.2) +110% Attrition: 0

ПРОБЛЕМЫ:

• Code review время: 24h (нужно 12h)
• Test coverage: 55% (нужно 80%)
• Один человек подумывает об уходе

ПЛАН:

• Усилить pressure на code review
• Спринт-тестирование
• 1-1 встреча с "thinking of quitting"

Третий доклад (День 30) - Финальные результаты

НАЧАЛО МЕСЯЦА:

• Velocity: 28 pts
• Bugs/week: 5
• Morale: 3.2/10
• Attrition: 3 за 6 месяцев
• Code quality: D

КОНЕЦ МЕСЯЦА:

• Velocity: 38 pts (+36%)
• Bugs/week: 1.2 (-76%)
• Morale: 7.5/10 (+134%)
• Attrition: 0
• Code quality: B

ЧТО СРАБОТАЛО:

1. Переделка планирования
2. Code review + тесты
3. Демонстрация результатов
4. Learning goals
5. Честная коммуникация

ДЕМОНСТРАЦИЯ (команда показывает фичи)

РИСКИ НА БУДУЩЕЕ:

• Если люди уйдут: velocity упадет
• Если авральные дедлайны: вернется chaos
• Если техдолг не сжигать: качество упадет

ПРАВИЛА КОММУНИКАЦИИ С РУКОВОДСТВОМ

1. Всегда начинай с проблемы

   • Плохо: "Я внедрил новые стандарты"
   • Хорошо: "Было 5 багов потому что нет code review"

2. Цифры, цифры, цифры

   • Плохо: "Команда демотивирована"
   • Хорошо: "Morale 3.2/10, 3 человека ушло"

3. Связь между действием и результатом

   • Плохо: "Я переделал планирование"
   • Хорошо: "Новое планирование → clarity +80% → velocity +25%"

4. Риск, если ничего не делать

   • Плохо: "Команда может развалиться"
   • Хорошо: "По темпу текучки, к концу года 7 человек вместо 10"

5. Просить конкретную поддержку

   • Плохо: "Нужна помощь"
   • Хорошо: "Буфер на 3 недели и 2 разработчика"

6. Еженедельный email

Зелёные (успехи):

• Velocity: 38 pts (target: 40)
• Bugs: 1 за неделю (target: < 2)
• Code review: 16h (было 24h)

Жёлтые (внимание):

• Test coverage: 62% (нужно 80%)
• Один человек думает об уходе

Красные:

• Нет

Нужна помощь: Нет

Следующая встреча: через неделю