Перестройка команды: от конфликтов к слаженной работе Мария Щекочихина, CUSTIS

Ситуация

Моя роль ● Архитектор ● Руководитель команды (с марта 2019) Состав и особенности ● Заказная разработка: автоматизация пополнения магазинов крупного ритейлера ● 10 человек: аналитики, разработчики, тестировщики ● Сформировалась из двух разных групп ● Новый руководитель проекта Команда

Триггеры Смена трех ведущих разработчиков за короткий промежуток времени Внедрение системы несколько раз переносится на короткий срок (от одного дня до недели) Непонимание между участниками, ведущее к конфликтам Нет четких критериев готовности системы

Где мы оказались? Формирование Бурление Нормирование Функционирование Расставание

Решение проблем

Проблемы ● Нет четких критериев готовности системы ● Сдвиг внедрения на короткий срок (от дня до недели) ● Заказчик хочет тестировать систему в неожиданные моменты Решение ● Единый приоритизированный список задач от заказчика ● Введение релизного цикла: длительность итерации — 2,5 недели, частота поставок — неделя ● Неделя — компромисс между нашими возможностями и сроками сдвигов внедрения Частота поставки версии

Решение ● Еженедельные конфколлы с заказчиком ● Договоренности о работе с техдолгом: сначала под него выделили каждый 4–5-й релиз, затем — до 20 % каждого релиза Взаимодействие с заказчиком Проблемы ● Неотлаженная и непостоянная коммуникация с заказчиком ● Большой объем техдолга из-за быстро меняющихся требований

Проблемы ● Разобщенность команды ● Противоречия в правилах работы ● Не закреплены границы ролей ● Отсутствие правил ведения задач в таск-трекере Решение ● Договоренности о правилах работы: закрепили границы ролей, установили правила ведения задач в таск-трекере ● Переход на Jira Договоренности в команде

Договоренности в команде Формирование Бурление Нормирование Функционирование Расставание

Решение ● Два блока планирования: отдельно — аналитика, отдельно — разработка ● Переход к разработке только после согласования аналитики Проблемы ● Рассинхронизация работ аналитиков и разработчиков ● Необходимость постоянно переделывать функционал Планирование

Решение ● Наведение порядка в wiki: создали страницу команды и портал с документацией Работа с документацией Проблемы ● Неструктурированная и неактуальная документация в wiki ● Сложности в поиске нужной документации

No content

No content

No content

Решение ● Введение должности руководителя команды ● Разделение обязанностей: фокус руководителя команды — на внутренних процессах, фокус руководителя проекта — на внешних взаимодействиях и обязательствах Проблемы ● За команду отвечал руководитель проекта, который курировал еще несколько проектов ● У команды не было тимлида Организационная структура

Решение ● Ротация специалистов ○ Привлекли младшего специалиста «на вырост» ○ Взяли разработчика, который хотел развиваться во фронтенд-разработке ○ Расширили обязанности одного из членов команды Проблемы ● Нехватка сотрудников с нужными компетенциями из-за ухода ведущих специалистов ● Невозможность быстро ввести в проект новых специалистов с рынка Состав команды

Результаты

Результаты для команды Четкое распределение обязанностей, повышение прозрачности работы Слаженная работа, взаимовыручка участников Стабильный состав команды Налаженное взаимодействие с заказчиком

Формирование Бурление Нормирование Функционирование Расставание Результаты для команды

Внешние результаты Предсказуемое время попадания задачи на прод: 2,5 недели после включения в релиз Успешное внедрение системы Внедрение новых практик в других командах внутри компании

Что можно было сделать по-другому? Сначала наладить отношения с заказчиком Не брать слишком много новичков Раньше переезжать в удобный таск-трекер

Оценка результатов Опросы команд: январь 2019 и лето 2019 Сравнение результатов ретро: осень 2018 и лето 2019

Результаты ретро До После Постановки аналитиков вызывают много вопросов Сформировалась команда, налажены коммуникации Разработчики не уточняют задачи Есть понятный процесс, как внутри, так и с заказчиком Тестирование работает, как «черный ящик» Тестирование стало более прозрачным

Появилось ли чувство командности? Команда 1 Команда 2 Моя команда Команда 4 Команда 5 Да Нет

Бывает ли непонятна приоритизация задач? Никогда Редко Иногда Часто Всегда

Часто ли вы не понимаете, входит ли задача в вашу зону ответственности? Никогда Редко Иногда Часто Всегда

Что дальше? Внедрение мониторинга Завершение перехода к полностью автоматизированному регрессионному тестированию

Рекомендации и полезные материалы

Как ● Обратная связь от участников: ретроспектива, опросы, личные обсуждения ● Чек-листы ● Метрики Когда ● Слияние нескольких команд или реорганизация команды ● Появление новых участников в команде ● Внешние изменения (организационные изменения в компании, новый формат работы с заказчиком) Когда и как пересматривать процессы?

Чек-лист: что поможет слаженной работе? ● Зафиксированный в документах состав с ролями и функциями ● Договоренности о правилах работы ● Общее пространство команды ○ Чат, групповой почтовый адрес ○ Страница команды • Состав и роли • Ссылки на самое важное ● Статусы в командах: общий регулярный статус, короткие ситуативные ● Таск-трекер ○ Общая доска и доски по специализациям ● Расписание работ/релизов

Опросник: удовлетворенность работой в команде

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

Спасибо за внимание! Мария Щекочихина maria.schekochikhina@outlook.com