Всех приветствую! Меня зовут Мухаммад, я 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 по учебнику не решает проблемы. Работают только те практики, которые осознанно адаптированы под реальные условия проекта.

Такие дела.