Почему мы заставляем программистов менеджерить
Запускали один жирный релиз. Команда разрослась до пятнадцати человек, фичей — десятки, задач — сотни. Работа шла параллельно: авторизация, интеграции, доработки по разделам, багфиксы. И всё это надо было как-то стабилизировать перед релизом.
Тут нас начало штормить. Дейли-встречи превратились в опрос без ощущения прогресса: кто что делал, кто что делает сегодня. Контекст одной фичи размазывался по нескольким людям, а менеджер не успевал следить за прогрессом по фичам.
Стало очевидно: так жить больше нельзя. Мы пересобрали процесс и внедрили практику фича-лидов.
Теперь за каждую user story, которая представляет собой законченный результат, отвечает тот, кто лучше всех владеет контекстом именно по этой истории. Если в задаче больше фронта — лидом становится фронтендер. Если логики и интеграций — берём аналитика. Если нужно просто вычистить UX и добить баги перед релизом — фича уходит под ответственность тестировщика.
Теперь не менеджер бегает и собирает воедино статусы по куче задач в рамках разных стримов, а фича-лид сам знает, кто кого ждёт, у кого затык, и как вытянуть всю фичу до конца спринта. Он не просто делает свою часть, а следит за всей историей: фронт, бэк, тесты — всё в одном фокусе.
Под новый процесс пересобрали дейли. Вместо прохода по людям — теперь проходимся по фичам. Каждый фича-лид рассказывает, что с его частью, где мы, успеваем ли в спринт, кому надо напомнить, кого подтолкнуть. Это резко повысило эффективность. Менеджер перестает быть диспетчером и начинает быть стратегом. Появляется то самое пространство для мысли: что можно выкинуть, где срезать углы, на чём сфокусироваться, чтобы принести максимум пользы.
Эта практика уже работает в нескольких проектах, и мы будем её масштабировать. Она не про контроль — она про результат. Про то, чтобы мозги были заняты не напоминаниями, а решением задач, которые реально двигают продукт вперёд.
