Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

CUSTIS
February 11, 2020

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

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

CUSTIS

February 11, 2020
Tweet

More Decks by CUSTIS

Other Decks in Business

Transcript

  1. Моя роль • Архитектор • Руководитель команды (с марта 2019)

    Состав и особенности • Заказная разработка: автоматизация пополнения магазинов крупного ритейлера • 10 человек: аналитики, разработчики, тестировщики • Сформировалась из двух разных групп • Новый руководитель проекта Команда
  2. Триггеры Смена трех ведущих разработчиков за короткий промежуток времени Внедрение

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

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

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

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

    разработка • Переход к разработке только после согласования аналитики Проблемы • Рассинхронизация работ аналитиков и разработчиков • Необходимость постоянно переделывать функционал Планирование
  7. Решение • Наведение порядка в wiki: создали страницу команды и

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

    руководителя команды — на внутренних процессах, фокус руководителя проекта — на внешних взаимодействиях и обязательствах Проблемы • За команду отвечал руководитель проекта, который курировал еще несколько проектов • У команды не было тимлида Организационная структура
  9. Решение • Ротация специалистов ◦ Привлекли младшего специалиста «на вырост»

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

    работа, взаимовыручка участников Стабильный состав команды Налаженное взаимодействие с заказчиком
  11. Внешние результаты Предсказуемое время попадания задачи на прод: 2,5 недели

    после включения в релиз Успешное внедрение системы Внедрение новых практик в других командах внутри компании
  12. Что можно было сделать по-другому? Сначала наладить отношения с заказчиком

    Не брать слишком много новичков Раньше переезжать в удобный таск-трекер
  13. Результаты ретро До После Постановки аналитиков вызывают много вопросов Сформировалась

    команда, налажены коммуникации Разработчики не уточняют задачи Есть понятный процесс, как внутри, так и с заказчиком Тестирование работает, как «черный ящик» Тестирование стало более прозрачным
  14. Часто ли вы не понимаете, входит ли задача в вашу

    зону ответственности? Никогда Редко Иногда Часто Всегда
  15. Как • Обратная связь от участников: ретроспектива, опросы, личные обсуждения

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

    с ролями и функциями • Договоренности о правилах работы • Общее пространство команды ◦ Чат, групповой почтовый адрес ◦ Страница команды • Состав и роли • Ссылки на самое важное • Статусы в командах: общий регулярный статус, короткие ситуативные • Таск-трекер ◦ Общая доска и доски по специализациям • Расписание работ/релизов
  17. Как внедрить изменения Не ждите действий сверху: предложить изменения может

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