Перестройка команды: от конфликтов к слаженной работе

Выступление Марии Щекочихиной, нашего руководителя продуктовых команд, на TeamLead Conf (Москва, 11 февраля 2020).

Transcript

1. Перестройка команды: от конфликтов к слаженной работе Мария Щекочихина, CUSTIS
2. Ситуация
3. Моя роль • Архитектор • Руководитель команды (с марта 2019) Состав и особенности • Заказная разработка: автоматизация пополнения магазинов крупного ритейлера • 10 человек: аналитики, разработчики, тестировщики • Сформировалась из двух разных групп • Новый руководитель проекта Команда
4. Триггеры Смена трех ведущих разработчиков за короткий промежуток времени Внедрение системы несколько раз переносится на короткий срок (от одного дня до недели) Непонимание между участниками, ведущее к конфликтам Нет четких критериев готовности системы
5. Где мы оказались? Формирование Бурление Нормирование Функционирование Расставание
6. Решение проблем
7. Проблемы • Нет четких критериев готовности системы • Сдвиг внедрения на короткий срок (от дня до недели) • Заказчик хочет тестировать систему в неожиданные моменты Решение • Единый приоритизированный список задач от заказчика • Введение релизного цикла: длительность итерации — 2,5 недели, частота поставок — неделя • Неделя — компромисс между нашими возможностями и сроками сдвигов внедрения Частота поставки версии
8. Решение • Еженедельные конфколлы с заказчиком • Договоренности о работе с техдолгом: сначала под него выделили каждый 4–5-й релиз, затем — до 20 % каждого релиза Взаимодействие с заказчиком Проблемы • Неотлаженная и непостоянная коммуникация с заказчиком • Большой объем техдолга из-за быстро меняющихся требований
9. Проблемы • Разобщенность команды • Противоречия в правилах работы • Не закреплены границы ролей • Отсутствие правил ведения задач в таск-трекере Решение • Договоренности о правилах работы: закрепили границы ролей, установили правила ведения задач в таск-трекере • Переход на Jira Договоренности в команде
10. Договоренности в команде Формирование Бурление Нормирование Функционирование Расставание
11. Решение • Два блока планирования: отдельно — аналитика, отдельно — разработка • Переход к разработке только после согласования аналитики Проблемы • Рассинхронизация работ аналитиков и разработчиков • Необходимость постоянно переделывать функционал Планирование
12. Решение • Наведение порядка в wiki: создали страницу команды и портал с документацией Работа с документацией Проблемы • Неструктурированная и неактуальная документация в wiki • Сложности в поиске нужной документации
16. Решение • Введение должности руководителя команды • Разделение обязанностей: фокус руководителя команды — на внутренних процессах, фокус руководителя проекта — на внешних взаимодействиях и обязательствах Проблемы • За команду отвечал руководитель проекта, который курировал еще несколько проектов • У команды не было тимлида Организационная структура
17. Решение • Ротация специалистов ◦ Привлекли младшего специалиста «на вырост» ◦ Взяли разработчика, который хотел развиваться во фронтенд-разработке ◦ Расширили обязанности одного из членов команды Проблемы • Нехватка сотрудников с нужными компетенциями из-за ухода ведущих специалистов • Невозможность быстро ввести в проект новых специалистов с рынка Состав команды
18. Результаты
19. Результаты для команды Четкое распределение обязанностей, повышение прозрачности работы Слаженная работа, взаимовыручка участников Стабильный состав команды Налаженное взаимодействие с заказчиком
20. Формирование Бурление Нормирование Функционирование Расставание Результаты для команды
21. Внешние результаты Предсказуемое время попадания задачи на прод: 2,5 недели после включения в релиз Успешное внедрение системы Внедрение новых практик в других командах внутри компании
22. Что можно было сделать по-другому? Сначала наладить отношения с заказчиком Не брать слишком много новичков Раньше переезжать в удобный таск-трекер
23. Оценка результатов Опросы команд: январь 2019 и лето 2019 Сравнение результатов ретро: осень 2018 и лето 2019
24. Результаты ретро До После Постановки аналитиков вызывают много вопросов Сформировалась команда, налажены коммуникации Разработчики не уточняют задачи Есть понятный процесс, как внутри, так и с заказчиком Тестирование работает, как «черный ящик» Тестирование стало более прозрачным
25. Появилось ли чувство командности? Команда 1 Команда 2 Моя команда Команда 4 Команда 5 Да Нет
26. Бывает ли непонятна приоритизация задач? Никогда Редко Иногда Часто Всегда
27. Часто ли вы не понимаете, входит ли задача в вашу зону ответственности? Никогда Редко Иногда Часто Всегда
28. Что дальше? Внедрение мониторинга Завершение перехода к полностью автоматизированному регрессионному тестированию
29. Рекомендации и полезные материалы
30. Как • Обратная связь от участников: ретроспектива, опросы, личные обсуждения • Чек-листы • Метрики Когда • Слияние нескольких команд или реорганизация команды • Появление новых участников в команде • Внешние изменения (организационные изменения в компании, новый формат работы с заказчиком) Когда и как пересматривать процессы?
31. Чек-лист: что поможет слаженной работе? • Зафиксированный в документах состав с ролями и функциями • Договоренности о правилах работы • Общее пространство команды ◦ Чат, групповой почтовый адрес ◦ Страница команды • Состав и роли • Ссылки на самое важное • Статусы в командах: общий регулярный статус, короткие ситуативные • Таск-трекер ◦ Общая доска и доски по специализациям • Расписание работ/релизов
32. Опросник: удовлетворенность работой в команде
33. Как внедрить изменения Не ждите действий сверху: предложить изменения может любой инициативный участник Ищите поддержку как внутри команды, так и за ее пределами Проговаривайте свои планы, объясняйте смысл нововведений Не рассчитывайте на быстрые результаты
34. Спасибо за внимание! Мария Щекочихина maria.schekochikhina@outlook.com