Как понять, что пора что-то менять в команде
Почему часто численность персонала вырастает независимо от того, становится работы больше или меньше? – Общая эффективность команды со временем начинает падать. Как правило, первые симптомы не очень заметны:
🔹Начинают ухудшаться метрики проекта: например, снижается скорость релизов.
🔹Некоторые процессы перестают выполняться: код-ревью, ретроспективы и т.д.
🔹Растет время на проектирование и разработку фич. Специалисты переходят к избыточному перфекционизму: ищут изящные и красивые решения – кодят «в своё удовольствие».
🔹Снижается мотивация команды.
Черты запущенных случаев, конечно, более явные:
🔹срывы сроков запланированных релизов;
🔹жалобы пользователей на работу приложения и многочисленные ошибки в нём;
🔹большой технический долг и бэклог – список задач в приоритетном порядке;
🔹конфликты.
Причины
Сформировать и поддерживать эффективную команду в принципе непросто. А на проекте сложно вовремя признаться, что есть проблемы и команда не вытягивает – мы до последнего верим в позитив. Среди основных причин провала (которых множество) можно выделить:
🔹отсутствие требуемых компетенций у специалистов и руководителей;
🔹отсутствие требуемого процесса/этапа в проекте;
🔹неверно определённые ожидания;
🔹ошибки в оценке проекта;
🔹отсутствие системы работы с рисками;
🔹отсутствие контроля.
Рекомендации
1️⃣Измерять работу над проектом с самого начала. При этом необходимо выстроить непрерывный процесс сбора метрик: количества фич в бэклоге, оценок пользователей, быстродействия продукта и т.д. Анализируя данные, вы сможете предотвратить угрожающие «пожары» и далее скорректировать работу команды.
2️⃣Выстроить нужный процесс работы и обеспечивать его: например, заранее проработать вопросы доступа к стендам, чтобы не возникало простоя и перегорания специалистов на этом фоне.
3️⃣От «замыливания» помогает периодический взгляд со стороны – аудит. Например, один клиент пригласил нас для оценки работы своего постоянного подрядчика. В итоге мы предложили улучшения, о которых не задумывались до этого ни клиент, ни команда разработки – свежий взгляд помог развитию проекта.
4️⃣Работать с проверенным партнёром.
Последний пункт раскроем в следующих постах, так как коротким комментарием тут не обойдёшься) В видео разбираем примеры реальных кейсов и их источники проблем (ссылка с привязкой к нужному моменту).
Post #252
315