Как поступишь если заказчик скажет что команда плохо работает

Как реагировать на критику заказчика о работе команды

Это сложная ситуация, требующая баланса между защитой интересов команды и удовлетворением заказчика. Вот как я бы поступил:

Шаг 1: Слушать и собирать информацию

Первое — не защищаться и не спорить. Нужно понять, в чём именно проблема:

"Спасибо за обратную связь. Можете быть конкретнее? 
Что именно не устраивает вас в работе команды?
Какие проблемы вы наблюдаете?"

Соберу конкретные примеры:

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

Шаг 2: Анализ и поиск корня проблемы

После сбора информации не сразу брать на себя вину, а анализировать:

• Объективные факты: сроки, количество багов, покрытие тестами
• Технические ограничения: сложность задачи, требования были реалистичны?
• Коммуникация: понимала ли команда все требования?
• Ресурсы: достаточно ли опыта и времени выделено?

Шаг 3: Признать проблемы и взять ответственность

Если критика справедлива:

"Я согласен, что есть проблемы. Вот что я вижу...
Это происходит потому что...
Вот что я буду делать:"

Не искать виноватого в команде — как лидер я несу ответственность.

Шаг 4: Предложить конкретный план улучшений

Критика без решения бесполезна. Предложу:

Краткосрочные меры (1-2 недели):

• Ежедневные статус-синки с заказчиком
• Код-ревью всех PR до мержа
• Увеличение покрытия тестами
• Четкие критерии качества

Среднесрочные меры (1-3 месяца):

• Обучение команды если нужно
• Пересмотр архитектуры если есть проблемы
• Увеличение прозрачности процесса
• Улучшение документации

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

1. Провожу ретроспективу с командой
2. Выявляю узкие места в процессе
3. Внедряю метрики отслеживания
4. Переделаю план спринта
5. Еженедельно отчитываюсь заказчику

Шаг 5: Защитить команду если критика несправедлива

Если проблемы вызваны нереалистичными требованиями:

"Я понимаю вашу фрустрацию. Однако посмотрите на факты:
- Мы доставляем 40 story points в спринт (выше плана на 20%)
- Качество кода выше среднего по индустрии
- Но требования изменились 5 раз за месяц

Чтобы улучшить скорость, нужно:
- Заморозить требования на спринт
- Четко определить приоритеты
- Выделить больше людей если нужно"

Шаг 6: Следить за результатами

• Отслеживать метрики: velocity, баги, код-ревью время
• Еженедельные демо заказчику с выполненными задачами
• Собирать обратную связь на каждой демо
• Быстро реагировать на новые проблемы

Что НЕЛЬЗЯ делать

• ❌ Сразу защищать команду и спорить с заказчиком
• ❌ Искать виноватого в членах команды
• ❌ Игнорировать критику
• ❌ Обещать что-то нереалистичное
• ❌ Молчать и надеяться что пройдет

Ключ к успеху

Прозрачность + ответственность + конкретные действия

Если я ясно покажу, что понимаю проблему, беру ответственность и имею план действий — доверие восстановится. Главное — не обещать, а делать.

Это покажет заказчику, что я професионал, который не только может написать код, но и управлять процессом и людьми.