Привет! Меня зовут Игорь Федорчук, я руковожу разработкой в направлении «Монобренды» в GRI.

За последний год компания заметно выросла: команд стало больше, изменений и интеграций — тоже. А процессы в разработке долго оставались такими же, какими были пару лет назад. В какой-то момент это перестало «склеиваться» само собой: ответственность размылась, централизованной точки входа в команды не было, а коммуникация стала слишком неэффективной.

Это первая статья о том, как мы пересобирали процесс разработки в GRI — от получения запроса от заказчиков до выкатки в прод. В этой части я разберу роли (тимлиды, техлиды, TPM), зоны ответственности и общий флоу. Во второй части покажем, как мы приземлили это в Jira и метрики, а в третьей — как масштабировали поставку: релизы, код-ревью и инциденты.

Начали мы не с Jira и не с попытки «ускорить релизы», а с зоны ответственности. При росте она ломается первой: задачи начинают зависать на стыках ролей, статусы приходится собирать вручную и дублировать в несколько каналов коммуникаций, а «владелец результата» меняется по ходу движения.

Как было устроено «до»

Организационно мы жили в логике функциональных направлений. CTO репортили лиды функций (техлиды): бэкенд, фронтенд, мобильная разработка, DevOps. Руководителю мобильной разработки репортили функциональные лиды iOS и Android.

При этом продуктовые команды, которые непосредственно пилили фичи, были кроссфункциональными: бэкендеры, мобильщики, тестировщики и так далее. Внутри таких команд не было выделенного человека, который нёс бы  ответственность за результат со стороны разработки.

Проблемы, которые проявились при росте

Когда команда небольшая, многое работает за счёт личных договоренностей. Но по мере роста мы столкнулись со следующими проблемами:

• Размытая ответственность. В кроссфункциональной команде нет одного ответственного за работу и результат команды.

• Нет человека, который агрегирует статус, даёт оценки, снимает блокеры и управляет обработкой багов.

• Коммуникации начинают ломать доставку. За задачами разработчиков фактически следили продакты и проджекты. Это плохо работало: возникали проблемы взаимодействия, в результате никто со стороны разработки системно не управлял реализацией, и это приводило к срыву сроков и снижению качества.

• Неочевидные зоны ответственности бьют по результату. При отсутствии явного владельца задачи затягиваются, решения принимаются ситуативно, контроль размывается.

В связи с этим, мы выделили для себя ряд задач: определить роли, ответственность и правила движения задач от задумки до прода.

Внедрение изменений

Первое изменение: в продуктовых командах ввели кроссфункциональных тимлидов и отделили функцию техлида. Команды у нас уже были кроссфункциональными — фичи делали силами бэкендеров, фронтендеров, мобильных разработчиков и QA. Проблема была в другом: в такой команде не было одного понятного человека со стороны разработки, который целиком отслеживает всю работу.

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

Мы решили сделать структуру проще и прямее:

• тимлид — непосредственный руководитель и владелец команды (статусы, риски, помехи, организация работы, техническая проработка фич, верхнеуровневые оценки для бизнеса);

• техлид — отвечает за технические решения и качество, но не руководит людьми.

Дальше мы отталкивались не от оргсхем, а от текущей парадигмы: в каждой команде было несколько бэкендеров, и почти всегда уже существовал неформальный лидер — зачастую им был ведущий бэкендер команды. Мы поговорили с такими ребятами и предложили им роль тимлида продуктовой команды, но с важным отличием: теперь в его ответственности были не только бэкендеры, а вся команда, которая делает фичу.

У многих кандидатов в тимлиды был большой инженерный опыт, но управленческие практики приходилось осваивать в процессе. Кроме того, роль тимлида заметно расширяет ответственность: помимо технических решений появляется регулярная операционная работа — проработка задач на входе, синхронизации и статусы, организация взаимодействия внутри команды и доведение инициатив до результата.

Поэтому мы переходили постепенно и роль предлагали тем, кому она действительно подходит по мотивации и готовности брать на себя такую ответственность. Тем, кто предпочитал оставаться в инженерами, сохраняли возможность развиваться без ухода в менеджмент. А тем, кто взял на себя роль, помогали точечно: объясняли ожидания, делились практиками, поддерживали в выстраивании процесса доставки, параллельно усиливая команды наймом.

В итоге управление на уровне команд стало понятнее, появились устойчивые точки входа, а ответственность и коммуникации — более собранными и предсказуемыми.

Второе изменение: убрали узкое горлышко: объединили часть функций аналитика и управления проектом в роль TPM. Раньше аналитики описывали бизнес-задачи и технические подробности, и на них держалась большая часть проработки. Если такой человек внезапно уходил, то это сразу било по системе: долго искать замену, много времени уходит на адаптацию, команда становится нестабильной из-за завязки на одного человека.

Мы хотели сделать команды устойчивее и уменьшить зависимость от конкретный ролей. Поэтому сдвинули контур «описания и ведения» задач ближе к командам: объединили часть функций аналитика и проджект-менеджера в одну и назвали её TPM (Technical Project Manager). Этот человек не принимает продуктовых решений, но обеспечивает их качественную реализацию.

Далее мы выстроили процесс перехода к новой роли:

• Сначала описали, что именно входит в зону ответственности TPM, и вместе с командой посмотрели, какие текущие задачи аналитика и проджект-менеджера логично собрать в один контур. 

• Определили несколько траекторий: кто-то из текущих коллег перешёл в роль TPM, кто-то остался в своей специализации, но перешёл на другой проект, а недостающие компетенции закрыли наймом.

• После этого распределили TPM по командам так, чтобы они работали рядом с тимлидом и были включены в ежедневный контур доставки, а не существовали отдельной «прослойкой».

Переход потребовал около двух месяцев на выравнивание ожиданий и навыков: объединённая роль по определению шире, чем каждая из исходных, поэтому по ходу дела мы уточняли границы ответственности и адаптировали процессы под новую модель.

В результате команда стала устойчивее: снизилась зависимость от конкретных людей, появился понятный операционный центр, который системно доводит инициативы до результата.

Третье изменение: зафиксировали правила игры: роли, RACI и жизненный цикл инициативы. Когда в командах появились тимлиды и TPM, следующий логичный шаг — сделать ожидания и ответственность явными, иначе система продолжает ехать по старым рельсам: всё держится на личных договорённостях, только теперь между новыми ролями.

Нам нужно было избавиться от разрозненности в самых частых вопросах, которые всплывали при каждой передаче задачи: кто принимает решение, что задача действительно готова к разработке; кто отвечает за качество входных данных и полноту контекста; кто владелец результата; кто должен поднимать и проталкивать задачу, если она зависла. Это важно не только для сроков. Когда ответственность плавает, команда идёт по одному из двух путей: либо люди выгорают, потому что постоянно «подхватывают чужое», либо, наоборот, возникает пассивность: «это не моё, пусть решит кто-нибудь».

Поэтому мы вместе с руководителями разработки, СТО и руководителем TPM зафиксировали в документации базовые договорённости. Начали с простого: кто и за что отвечает. Затем разложили зоны ответственности по ролям (тимлид, TPM и другие), описали матрицу RACI (Responsible, Accountable, Consulted, Informed) и жизненный цикл инициативы — как она появляется, чем должна быть наполнена и в какой момент считается готовой к следующему шагу.

Параллельно описали ключевые процессы продуктовых команд, в том числе груминг — что это и кто его ведёт — и работу с техдолгом, который теперь формируется системно через функциональных руководителей, а не «как получится».

В итоге договорённости на входе стали проще и быстрее, уменьшилось количество конфликтов ожиданий между ролями, а сам процесс выполнения задачи стал воспроизводимым: меньше зависел от личных договорённостей и конкретных людей.

Выводы

Когда роли, зоны ответственности и правила передачи стали явными, у команд появилась устойчивая точка входа со стороны разработки, а ответственность за следующий шаг стала понятна заранее, а не выяснялась по факту. Коммуникации стали короче: меньше кругов согласования и меньше ситуаций. Роль TPM добавила устойчивости: контур проработки и сопровождения задач перестал держаться на единичных людях и стал встроенной частью командного процесса.

В следующей статье мы разберём, как «приземлили» всё это в Jira и добились прогнозируемости: рабочий процесс и статусы, правила задач, критерии попадания в спринт, продуктивность, сходимость спринта, обнаружение узкого места в QA, а также метрики, которые начали использовать.