Всех приветствую! Меня зовут Мухаммад, я Delivery Manager в «05.ру». В августе 2024 года руководитель проектного офиса, предложил мне возглавить один из крупных проектов компании. Для меня это был большой вызов, потому что на тот момент не было большого опыта, а проект был классической «проблемной зоной». Чтобы вы понимали: за год там сменилось три проект-менеджера, я стал бы четвёртым.
Через три дня я решил: возьмусь.
Постепенно передал все свои текущие проекты и начал принимать новый. Наконец, переходный этап завершился и я оказался один на один с командой, которая привыкла, что менеджеры здесь долго не задерживаются xD.
Ключевые экшены
Управленческая зрелости в проекте. Процессы должны начинаться с договорённостей и прозрачных «правил игры», а не с настройки статусов в таск-трекере;
Борьба с инфантильность. Менеджер, который двигает задачи за разработчиков, легализует их безответственность и убивает проект;
Системный подход к изменениям. Реорганизация команд должна опираться на глубокий аудит компетенций и ролей, а не на случайное распределение людей.
План захвата. Как эффективно зайти в «проблемный» проект
Чтобы не стать очередной статистической жертвой этого проекта, я сразу составил план входа. Если вы заходите в «проблемную зону», не пытайтесь сразу чинить код — чините доверие и контекст. Вот чек-лист, который помог мне закрепиться:
Найти неформальных лидеров. В любой команде есть люди, чей авторитет выше формальных должностей. Я нашёл их и начал «продавать» свои идеи через них. Пока у тебя нет авторитета в проекте, работа через лидеров мнений — единственный способ избежать саботажа;
Аудит «договорённостей», а не кнопок. Выстроенные процессы начинаются не с Jira, а с понимания: кто за что отвечает, как принимаются решения и что мы считаем «готовым»;
Стабилизация поставки. Прежде чем начинать революцию, нужно начать стабильно выпускать фичи. Мы с техлидом Сашей за первые три месяца наладили релизный план и упаковали всю документацию в Wiki;
Работа с ожиданиями заинтересованных лиц. Нужно чётко зафиксировать проблемные для бизнеса задачи и показать первые быстрые победы.
Новая структура: фундамент трансформации
Спустя три месяца я успешно прошёл испытательный срок. Мне удалось стабилизировать базовые процессы и вместе с техлидом составить релизный план. Позже, когда я вплотную начал анализировать метрики, выявил и другие проблемы:
TTM (Time-to-Market) всё еще слишком высокий;
Функциональные колодцы. Команды были жёстко поделены на бэкенд, фронтенд, QA, дизайн. У каждой команды свои руководители, расписание встреч и планы;
Протухание ТЗ. Из-за разрозненности и долгого пути задачи до прода требования часто теряли актуальность.
Наш процесс разработки напоминал строительство какого-то реактора, с бесконечной цепочкой согласований: архитектурный комитет, продуктовый комитет, системный комитет… Чтобы системно решить эти проблемы, руководство решило привлечь внешних консультантов.
Особую роль здесь сыграл наш СТО - Мусали Генжеханов. Именно он инициировал этот процесс и проделал подготовительную работу: нашел компанию и долго погружал их в наш контекст (от существующих архитектурных проблем и «бас-факторов» до специфики взаимодействия наших команд).
Первое, с чего мы начали практическую фазу — обновление структуры команд. Трое консультантов провели аудит: проанализировали текущие роли, оценили компетенции каждого сотрудника и подготовили новую структуру кроссфунциональных команд, в которых собрали все необходимые функции для поставки пользовательской ценности от идеи до прода.
Прыжок веры и ошибка «недельных спринтов»
Спустя ещё несколько созвонов, синхронизаций и доработок, мы совершили тот самый «прыжок веры».
Собрали две кроссфункциональные команды и внедрили все церемонии: daily, PBR, planning, retro, review. Консультанты ещё настаивали на недельных спринтах, но наш регламент релизов и сложность задач в это уже не укладывались. Мы спорили, что сейчас нужно оставить двухнедельные спринты, иначе на этом этапе могут быть плохие последствия. Команды тоже негодовали, что при недельных спринтах у них просто не останется времени писать код.
В результате мы отстояли свою точку зрения. Хотя ещё оставались некоторые нерешённые вопросы, основная часть процессов была готова, и мы, нарезав первые UserStory, запустили спринт.
На протяжении всего периода трансформации отслеживали «температуру по больнице». Спустя два спринта начали замечать недовольство команды. Даже с учетом того что мы отстояли двухнедельные спринты у команд было обилие созвонов и меньше времени оставалось на решение конкретных задач. Я решил собрать отзывы и составил опросник: в нём нужно было оценивать успешность разных изменений по 10-бальной шкале, а в конце я просил написать, что, по мнению отвечающего, не работает и на чём нужно сосредоточиться. Все подробности, конечно, я раскрыть не могу, но, в целом, я получил такую картину:
Было много комментариев в стиле «у нас не завелось то-то и то-то, в таком-то созвоне на данный момент мы ценности не видим», и т. д. и они были по факту. Мы по порядку начали обрабатывать все возражения, также раз в 2 недели мы все еще виделись с консультантами и они также накидывали варианты решения.
Как вы, наверное, уже поняли одной из проблем от которой, казалось бы, мы планировали уйти «большое количество созвонов, согласований», не оставила нас и в новых процессах. Особенно страшно было смотреть на мой календарь и календарь техлида. Примерно так выглядели наши календари первый месяц изменений.
Вам сейчас больно смотреть на понедельник, а мы с техлидом эти понедельники проживали)
Конечно, по мимо этих созвонов есть и другие задачи, которые поступают от проектного офиса, которые тоже нужно выполнять. В общем это было жестко.
Спустя какое-то время нам удалось стабилизировать вопрос с созвонами. Те созвоны, от которых мы действительно не получали должного выхлопа мы со временем убрали и некоторые созвоны команды уже проводят автономно без моего участия и участия техлида.
Отработав и другие проблемные зоны я решил снова собрать удовлетворенность разработки и в результате получил более положительную картину.
Консультанты ещё какое-то время подсказывали, что можно улучшить, делились с нами наработками. Но как говорится нет предела совершенству и мы не намерены останавливаться на этом.
С тех пор мы с командой продолжаем улучшать наши процессы:
Убрали лишние созвоны, оставив только те, на которых реально рождалась ценность;
Внедрили DoR и DoD;
Начали анализировать инциденты не сразу же и на эмоциях, а через postmortem.
Ещё остались проблемные места, которые нужно решить, но, в целом, итоговым результатом довольны.
Ловушка для менеджера. Не будьте «секретарём»
Еще немного времени выделить для наболевшей темы проджектов. Некоторые думают, что «выстроить процессы» — это накидать стандартные статусы в планировщике задач и следить, чтобы разработчики их двигали. Это не так. Под этим словосочетанием скрывается огромная работа с ожиданиями заинтересованных лиц, приоритезацией и рисками.
Худшее, что может сделать менеджер — начать двигать задачи за разработчиков, потому что те «забывают» или «не успевают». И даже сами разработчики порой говорят, что это работа менеджера двигать задачи. Я пару раз слышал подобное и от своих ребят в новом проекте. Когда менеджер начинает работать «руками» за команду, он тем самым поощряет инфантильность. В этот момент система ломается: ответственность размывается, данные в трекере теряют смысл, а вы превращаетесь в секретаря. Зрелый процесс предполагает, что обновление статуса — это часть работы программиста, а не дополнительная нагрузка.
Если кто-то из команды говорил мне, что я должен двигать статусы, то я объяснял, почему такая позиция ошибочна. Некоторые даже после нескольких объяснений стояли на своём. При дополнительном анализе у таких сотрудников были проблемы и в других аспектах их работы, и тогда я поднимал вопрос о прекращении сотрудничества.
Итоги
За полгода работы мы:
снизили TTM проекта на 50% за счёт уменьшения зависимостей и передач управления;
ускорили принятие решений внутри команды;
повысили предсказуемость сроков поставки;
сместили фокус с «выполнения задач» на достижение продуктового результата;
самостоятельно запустили третью кроссфункциональную команду, и продолжаем улучшать процессы каждый день.
Я пришёл в проект как «четвёртый за год», и выжил. Избавился от внутреннего ограничения «нельзя менять систему так кардинально». Работа над проектом помогла мне вырасти до Middle+ и получить реальное влияние на бизнес-метрики.
Выводы для тех, кто хочет перемен:
Выходите из зоны комфорта. Как говорил мне CTO “человек не развивается в покое и самые большие результаты человек достигает, когда выходит из зоны комфорта”.
Менеджер — не секретарь. Не двигайте задачи за разработчиков, создавайте среду, где они сами несут ответственность.
Слушайте тех, кто «варится» в процессе. Обратная связь от команды ценнее любых методичек.
Проводите изменения через внутренних «авторитетов». Находите и вовлекайте внутренних лидеров с реальным авторитетом в команде. Так будет меньше всего потерь, сопротивления и саботажа. Работа только через формальные роли и верхнее руководство не поможет принять изменения на уровне исполнения.
Scrum — не «панацея». Внедрение Scrum по учебнику не решает проблемы. Работают только те практики, которые осознанно адаптированы под реальные условия проекта.
Такие дела.
