Почему процессы в продуктовой IT-команде не работают

Когда кажется, что дело в процессах

В какой-то момент почти каждая продуктовая IT-команда приходит к одной и той же мысли: «Нам нужно навести порядок в процессах».

Это обычно происходит не из-за моды на менеджмент, а из-за вполне конкретных ощущений:

• задач много и все срочные

• задачи делаются дольше, чем хотелось бы

• ожидания у команды и бизнеса не совпадают

• обсуждений много, а ясности нет.

В такие моменты «описание процессов» начинает казаться логичным решением. Если всё расписать, разложить по шагам, назначить роли и ответственных - вот тогда заживем!

По крайней мере, так кажется. Ну и это выглядит рабочим и простым решением.

Я работаю PM’ом в продуктовой IT-компании, в команде разработки из 16 человек. И за последний год у меня сложилось довольно устойчивое ощущение:

процессы часто не работают не потому, что они плохие или их нет, а потому что от них ждут слишком многого.

Как обычно начинается «наведение порядка»

Сценарий довольно типичный.

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

• схемы

• регламенты

• статусы

• этапы

• чек-листы

Формально всё действительно становится аккуратнее. Но спустя время приходит странное чувство: внутри команды мало что изменилось. Стало только больше документации - записали и забыли, и продолжаем работать как и работали раньше.

Почему так происходит: 

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

• нет времени вникать в новые процессы, без конца продолжают сыпаться задачи и надо работать

• сопротивление чему-то новому.

Иллюзия №1. Процесс как универсальное решение

Одна из самых устойчивых иллюзий- это вера в то, что процесс может заменить собой договорённости.

Процесс может описать:

• порядок шагов

• роли

• точки контроля

Но он н�� отвечает на ключевые вопросы:

• зачем мы делаем эту задачу

• какой результат считаем хорошим

• что важнее - скорость или качество (не бывает и быстро, и качественно)

• кто принимает финальное решение

Если на эти вопросы нет общего ответа, процесс начинает жить сам по себе, а работа - сама по себе.

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

Иллюзия №2. Если не работает - значит, недостаточно детально

Когда процесс не даёт ожидаемого эффекта, следующая логичная мысль  - его нужно доработать:

• добавить ещё один шаг

• ещё одно согласование

• ещё одну роль

• еще один инструмент

• еще один звонок для обсуждения

Процесс усложняется, но при этом:

• решения принимаются не быстрее

• ответственность не становится яснее

• результат не улучшается

• задач не уменьшается

В какой-то момент процесс превращается в фон: он вроде есть, но на реальные решения влияет слабо.

Иллюзия №3. Процессы как способ контроля

Иногда процессы внедряются не столько для команды, сколько для ощущения управляемости.

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

Но процессы, построенные как инструмент контроля, довольно быстро начинают:

• снижать инициативу

• поощрять формальное выполнение для галочки

• ответственность перекладывать «в систему»

И команда начинает делать не то, что нужно продукту, а то, что требуется процессу.

Когда становится понятно, что дело не только в процессах

В нашей команде в какой-то момент стало очевидно, что даже при наличии описанных процессов мы всё равно возвращаемся к одним и тем же вопросам.

Например:

• разные ожидания от качества

• разное понимание приоритетов

• неочевидно, где заканчивается обсуждение и начинается решение

• кто за что отвечает

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

К примеру, пришло 3 задачи, срочные, даты релиза пересекаются, ресурсов разработки для выполнения недостаточно. Есть чек‑лист «критичности» задач, но на деле каждая сторона (маркетинг, продажи, бухгалтерия) просто продавливает свою задачу и никто не собирается вникать в эти ваши процессы и чек‑листы. 

Потому что все привыкли уже ТАК работать, кому-то удобно, кому-то просто не хочется лишний раз напрягаться и менять то, что и так работает.

Важное наблюдение

Со временем у меня сформировался довольно простой, но неочевидный вывод:

процессы — это следствие зрелости команды или компании в целом, а не её причина.

Они начинают работать там, где уже есть:

• общее понимание цели (масштаб, качество, скорость)

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

• принятие ответственности (четкое распределение кто за что отвечает)

• доверие (не ставится под сомнение оценка задачи сотрудником другого отдела “а почему так много времени нужно потратить на бэк, здесь же все просто”)

• право на ошибку (вес этой ошибки и частотность)

Без этого процесс остаётся формальностью, даже если он красиво описан.

Почему эта история только начинается

На этом этапе возникает логичный вопрос: если процессы сами по себе не решают проблему, что делать дальше?

В нашем случае следующим шагом стало усиление:

• мы привлекли внешнего бизнес-эксперта для работы с процессами

• усилили команду.

Если внутри не получается договориться и навести порядок, возможно, поможет внешний взгляд и дополнительные ресурсы.

Зачем мы привлекли внешнего бизнес-эксперта

Основная идея была довольно простой. Мы ожидали, что внешний эксперт:

• посмотрит на наши процессы со стороны

• поможет выявить узкие места

• задаст правильные вопросы

• предложит более устойчивую и масштабируемую модель работы

Важно: мы не ждали "волшебной таблетки", но рассчитывали, что человек без внутреннего контекста и эмоциональной вовлечённости сможет:

• структурировать хаос

• зафиксировать договорённости (внутри команды и отделов)

• помочь команде прийти к общему пониманию

Кроме того, это был способ подтвердить или опровергнуть наши собственные гипотезы: проблема действительно в процессах или мы просто плохо их описали и внедрили.

Зачем мы усилили команду

Параллельно с этим у нас было ещё одно устойчивое ощущение: команде не хватает ресурсов.

Задач становилось больше, продукт рос, ожидания бизнеса увеличивались. Логика была простой:

• больше людей → быстрее делаем

• больше ролей → меньше размытости

• больше экспертизы → выше качество решений

Мы рассчитывали, что расширение команды:

• снизит нагрузку на ключевых людей

• ускорит выполнение задач

• сделает ответственность более явной

• позволит разделить зоны принятия решений

Какие ожидания у нас были

Если говорить откровенно, ожидания были примерно такие:

• процессы станут "работать сами"

• решения будут приниматься быстрее

• приоритеты станут понятнее (среди отделов и внутри команды)

• команда будет меньше возвращаться к одним и тем же вопросам

• уровень напряжения снизится

Что действительно изменилось

Изменения, конечно, были. Но не совсем те и не совсем так, как мы ожидали.

Внешний эксперт нам действительно:

• помог структурировать текущую картину

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

• задал неудобные, но полезные вопросы (на этом этапе было множество звонков)

• предложил провести ротацию кадров

Усиление команды дало:

• больше рук

• больше точек зрения

• больше параллельной работы

Но вместе с этим стало заметно и другое.

Количество коммуникаций выросло. Количество договорённостей - тоже.
А вот ясности автоматически больше не стало.

Новые люди приносили:

• свои ожидания

• свой опыт

• своё понимание "как правильно"

И если эти вещи не проговорены и не согласованы, команда начинает тратить всё больше времени не на работу, а на синхронизацию.

Главное что стало понятно на этом этапе

Этот опыт дал довольно трезвое понимание. Ни внешний эксперт, ни расширение команды:

• не снимают необходимость договариваться

• не берут на себя ответственность за решения

• не делают команду зрелой автоматически

Они лишь усиливают то, что уже есть.

Если в команде есть общее понимание и доверие - это начинает работать лучше. Если нет, то проблемы просто масштабируются.

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