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

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

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

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

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

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

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

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

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

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

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


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

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

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

  • схемы

  • регламенты

  • статусы

  • этапы

  • чек-листы

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

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

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

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

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


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

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

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

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

  • роли

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

Например:

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • больше рук

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

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

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

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

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

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

  • свой опыт

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

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


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

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

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

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

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

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

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

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