Когда кажется, что дело в процессах
В какой-то момент почти каждая продуктовая IT-команда приходит к одной и той же мысли: «Нам нужно навести порядок в процессах».
Это обычно происходит не из-за моды на менеджмент, а из-за вполне конкретных ощущений:
задач много и все срочные
задачи делаются дольше, чем хотелось бы
ожидания у команды и бизнеса не совпадают
обсуждений много, а ясности нет.
В такие моменты «описание процессов» начинает казаться логичным решением. Если всё расписать, разложить по шагам, назначить роли и ответственных - вот тогда заживем!
По крайней мере, так кажется. Ну и это выглядит рабочим и простым решением.
Я работаю PM’ом в продуктовой IT-компании, в команде разработки из 16 человек. И за последний год у меня сложилось довольно устойчивое ощущение:
процессы часто не работают не потому, что они плохие или их нет, а потому что от них ждут слишком многого.
Как обычно начинается «наведение порядка»
Сценарий довольно типичный.
Так как проблему мы вроде как поняли, надо ее визуализировать. Поэтому появляются:
схемы
регламенты
статусы
этапы
чек-листы
Формально всё действительно становится аккуратнее. Но спустя время приходит странное чувство: внутри команды мало что изменилось. Стало только больше документации - записали и забыли, и продолжаем работать как и работали раньше.
Почему так происходит:
регламенты прочитали и забыли, никто не хочет работать по новой инструкции
нет времени вникать в новые процессы, без конца продолжают сыпаться задачи и надо работать
сопротивление чему-то новому.
Иллюзия №1. Процесс как универсальное решение
Одна из самых устойчивых иллюзий- это вера в то, что процесс может заменить собой договорённости.
Процесс может описать:
порядок шагов
роли
точки контроля
Но он не отвечает на ключевые вопросы:
зачем мы делаем эту задачу
какой результат считаем хорошим
что важнее - скорость или качество (не бывает и быстро, и качественно)
кто принимает финальное решение
Если на эти вопросы нет общего ответа, процесс начинает жить сам по себе, а работа - сама по себе.
Задач сыпется столько, что ты даже не успеваешь их проанализировать. Никто не хочет слушать разработку, что сроки поставлены невыполнимые, ведь клиенту уже продали услугу и пообещали сделать вовремя.
Иллюзия №2. Если не работает - значит, недостаточно детально
Когда процесс не даёт ожидаемого эффекта, следующая логичная мысль - его нужно доработать:
добавить ещё один шаг
ещё одно согласование
ещё одну роль
еще один инструмент
еще один звонок для обсуждения
Процесс усложняется, но при этом:
решения принимаются не быстрее
ответственность не становится яснее
результат не улучшается
задач не уменьшается
В какой-то момент процесс превращается в фон: он вроде есть, но на реальные решения влияет слабо.
Иллюзия №3. Процессы как способ контроля
Иногда процессы внедряются не столько для команды, сколько для ощущения управляемости.
Это понятное желание, когда информации много, неопределённости ещё больше, хочется за что-то зацепиться. Получается некий мнимый контроль.
Но процессы, построенные как инструмент контроля, довольно быстро начинают:
снижать инициативу
поощрять формальное выполнение для галочки
ответственность перекладывать «в систему»
И команда начинает делать не то, что нужно продукту, а то, что требуется процессу.
Когда становится понятно, что дело не только в процессах
В нашей команде в какой-то момент стало очевидно, что даже при наличии описанных процессов мы всё равно возвращаемся к одним и тем же вопросам.
Например:
разные ожидания от качества
разное понимание приоритетов
неочевидно, где заканчивается обсуждение и начинается решение
кто за что отвечает
И в этот момент становится ясно — сам по себе «голый», хоть и описанный процесс не может заменить разговоры, договорённости и ответственность, понимание и вовлеченность.
К примеру, пришло 3 задачи, срочные, даты релиза пересекаются, ресурсов разработки для выполнения недостаточно. Есть чек‑лист «критичности» задач, но на деле каждая сторона (маркетинг, продажи, бухгалтерия) просто продавливает свою задачу и никто не собирается вникать в эти ваши процессы и чек‑листы.
Потому что все привыкли уже ТАК работать, кому-то удобно, кому-то просто не хочется лишний раз напрягаться и менять то, что и так работает.
Важное наблюдение
Со временем у меня сформировался довольно простой, но неочевидный вывод:
процессы — это следствие зрелости команды или компании в целом, а не её причина.
Они начинают работать там, где уже есть:
общее понимание цели (масштаб, качество, скорость)
что такое качественный результат (минимум багов, быстрая работа сервисов, скорость выполнения услуги)
принятие ответственности (четкое распределение кто за что отвечает)
доверие (не ставится под сомнение оценка задачи сотрудником другого отдела “а почему так много времени нужно потратить на бэк, здесь же все просто”)
право на ошибку (вес этой ошибки и частотность)
Без этого процесс остаётся формальностью, даже если он красиво описан.
Почему эта история только начинается
На этом этапе возникает логичный вопрос: если процессы сами по себе не решают проблему, что делать дальше?
В нашем случае следующим шагом стало усиление:
мы привлекли внешнего бизнес-эксперта для работы с процессами
усилили команду.
Если внутри не получается договориться и навести порядок, возможно, поможет внешний взгляд и дополнительные ресурсы.
Зачем мы привлекли внешнего бизнес-эксперта
Основная идея была довольно простой. Мы ожидали, что внешний эксперт:
посмотрит на наши процессы со стороны
поможет выявить узкие места
задаст правильные вопросы
предложит более устойчивую и масштабируемую модель работы
Важно: мы не ждали "волшебной таблетки", но рассчитывали, что человек без внутреннего контекста и эмоциональной вовлечённости сможет:
структурировать хаос
зафиксировать договорённости (внутри команды и отделов)
помочь команде прийти к общему пониманию
Кроме того, это был способ подтвердить или опровергнуть наши собственные гипотезы: проблема действительно в процессах или мы просто плохо их описали и внедрили.
Зачем мы усилили команду
Параллельно с этим у нас было ещё одно устойчивое ощущение: команде не хватает ресурсов.
Задач становилось больше, продукт рос, ожидания бизнеса увеличивались. Логика была простой:
больше людей → быстрее делаем
больше ролей → меньше размытости
больше экспертизы → выше качество решений
Мы рассчитывали, что расширение команды:
снизит нагрузку на ключевых людей
ускорит выполнение задач
сделает ответственность более явной
позволит разделить зоны принятия решений
Какие ожидания у нас были
Если говорить откровенно, ожидания были примерно такие:
процессы станут "работать сами"
решения будут приниматься быстрее
приоритеты станут понятнее (среди отделов и внутри команды)
команда будет меньше возвращаться к одним и тем же вопросам
уровень напряжения снизится
Что действительно изменилось
Изменения, конечно, были. Но не совсем те и не совсем так, как мы ожидали.
Внешний эксперт нам действительно:
помог структурировать текущую картину
подсветил слабые места (нужен проектный офис, который будет просеивать задачи, коих много, а приоритет у всех наивысший)
задал неудобные, но полезные вопросы (на этом этапе было множество звонков)
предложил провести ротацию кадров
Усиление команды дало:
больше рук
больше точек зрения
больше параллельной работы
Но вместе с этим стало заметно и другое.
Количество коммуникаций выросло. Количество договорённостей - тоже.
А вот ясности автоматически больше не стало.
Новые люди приносили:
свои ожидания
свой опыт
своё понимание "как правильно"
И если эти вещи не проговорены и не согласованы, команда начинает тратить всё больше времени не на работу, а на синхронизацию.
Главное что стало понятно на этом этапе
Этот опыт дал довольно трезвое понимание. Ни внешний эксперт, ни расширение команды:
не снимают необходимость договариваться
не берут на себя ответственность за решения
не делают команду зрелой автоматически
Они лишь усиливают то, что уже есть.
Если в команде есть общее понимание и доверие - это начинает работать лучше. Если нет, то проблемы просто масштабируются.
Работа с процессами оказалась длинной дистанцией: прошло около восьми месяцев с начала изменений, мы ещё не вышли на полностью стабильный ритм, но уже движемся в эту сторону достаточно уверенно.
Комментарии (33)
IVNSTN
02.02.2026 15:47# Было
У царя 3 сына:
старший (умный детина);
средний (так и сяк);
младший → вовсе дурак.
---
Просто же список за списком! Ровно как вы в статье рассуждаете о том, что голый процесс, вброшенный в хаос/вакуум, ничего не решает и нуждается в "мясе" вокруг него: культуре практиках, ритуалах - ровно так же и статья поверх структуры и тезисов нуждается в мясе из рассказа, составленного из предложений, содержащих подлежащее, сказуемое и прочую светотень. Будто чей-то рабочий блокнот на экране открыл, где что ни страница, то чек-листы и буллиты, имеющие отношение к какой-то объёмной задаче, оставшейся за пределами этой исчёрканной бумаги.
bosco
02.02.2026 15:47Что не так со списками? Лично я их люблю, они же помогают читать.
Или вы любите предложения абзацы как у Льва Николаевича? Вижу по тексту, что любите. Не вкусовщина ли это?
svetashchegoleva Автор
02.02.2026 15:47Не поняла тезиса в Вашем комментарии, посему не возразить, не согласиться не могу)
palmin90
02.02.2026 15:47Нечитабельно. Слишком много ии?
svetashchegoleva Автор
02.02.2026 15:47Так не читайте) ИИ тут нет, все написано на основе реальных событий
Akon32
02.02.2026 15:47Пфф... Перегруженными процессами и их схемками увлекаются только незрелые люди, которым нечего делать. Если у управленца есть некоторый опыт, он берёт минимальный работающий процесс, тюнит его под ситуацию, и команда "просто работает". Ну а потом можно и схему нарисовать (а можно и не рисовать - всем и так всё ясно).
P.S. в статье слишком много списков!
svetashchegoleva Автор
02.02.2026 15:47Что значит "просто работает"? Не думали ли Вы, что у команды из 16 человек мозги работают по-разному, как и у остальных сотрудников компании? Чтобы каждый не работал так, как он видит (из разряда "я- художник, я так вижу"), нужен общий регламент, как и в любом бизнес-процессе. Нужна структура, рамки заданные.
Увы, не всем все ясно, ясно может быть только в голове у того, кто это придумал.
sergey_prokofiev
02.02.2026 15:47процессы часто не работают не потому, что они плохие или их нет, а потому что
.... а потому что вы их не умеете готовить.
Пример буквально абзацем ниже:
регламенты прочитали и забыли, никто не хочет работать по новой инструкции
Естественно никто не хочет формализации и все будут саботировать. Но если у вас процесс заканчивается на хоровом чтении регламента "за все хорошее и против всего плохого" то вот он, плохо приготовленый процесс.
svetashchegoleva Автор
02.02.2026 15:47"Но если у вас процесс заканчивается на хоровом чтении регламента" - здесь он только начинается. Закончится тогда, когда будет работать слаженно и приведет к желаемому результату. У нас пока идет движение в сторону отладки
sergey_prokofiev
02.02.2026 15:47У нас пока идет движение в сторону отладки
Удачи в движении.
Из стандартных косяков у вас вроде итальянской забастовки еще не было - скорей всего будет :)
VGoudkov
02.02.2026 15:47Тут сто пятьсот причин может быть...
нон-стоп-дедлайн, это когда продавать ключевому клиенту успевают быстрее, чем команда пилит фичи
для каждого следующего шага по процессу нужно по пол-дня бегать за человеком, без которого он не делается
комплиментарная к предыдущей - свои задачи висят, и по двадцать отвлечений на дню на шаги процессов у других людей (обычно когда RACI матрица забита буковками до верху)
больше отчётов богу отчётов
В общем пока у команды производительность минимум на четверть не превышает поток задач - никакие процессы ввести не удастся. Плавали, знаем.
svetashchegoleva Автор
02.02.2026 15:47Спасибо за комментарий! Безусловно, причины есть и другие, с теми же дедлайнами, нескончаемым потоком задач и еще не будем забывать про личные факторы, все-таки с людьми работаем). Хочется верить, что проблем станет меньше.
garregusev
02.02.2026 15:47ну если исходить из Теории Ограничений, то производительность практически никогда невозможно натянуть на бизнес требования. именно поэтому более реалистично сперва скомпенсировать бизнес требования под текущие ресурсы потому что "скорость всего процесса равна скорости самого узкого места", а когда узкое место найдено и оценено, то уже зная это ограничение работать с задачами заказчиков и возвращать им реалистичные сроки
svetashchegoleva Автор
02.02.2026 15:47да, узкое место найдено, к решению этого вопроса подошли другим путем: 1) усилили команду (не хватало рук) 2)увеличили покрытие автотестами 3)ну и еще ряд действий. Может подробнее напишу об этом в другой статье
Twizard
02.02.2026 15:47Процессы работают тогда, когда направлены на результаты. А для этого надо сначала выяснить на каком этапе и какая проблема формируется. И только потом внедрять шаги, позволяющие их решить или компенсировать вред. Четко понимая как конкретные шаги смогут это решить.
В текущем повествовании ощущение, что пытаемся решить проблемы в финальной точке, не разобравшись откуда они появляются. Просто внедряя обобщенные правильные процессы как у всех, для решения неправильных проблем. Приглашение внешнего эксперта не знающего внутренней кухни и оценивающего всё по верхам (общая температура по больнице) в ту же степь.
"В соседней компании поют гимн по утрам и у них продажи выше на 20%. Начнем тоже петь гимн и продажи подскочат"
Вы сами пишете, что ваши топы продают сроки клиентам даже без консультации с профильными экспертами отвечающими за эти сроки. С одним этим никакие процессы в команде не позволят успевать.
Далее команда, у которой мотивация на таком уровне, что они не хотят уже никакие регламенты и процессы. Или логически не понимают как это способно помочь решить те самые проблемы.
И расписывать можно долго. Ну реально, всего 16 человек. Вы не можете собраться и поговорить открыто, выслушав каждого?
Могу только предположить что руководству, которому не интересно мнение команды по срокам, скорее всего и по всему остальному их мнение не учитывает и не пытается слушать.
svetashchegoleva Автор
02.02.2026 15:47Вы так хорошо все говорите)) Не могу не согласиться. Со стороны все кажется просто, а на деле, если погрузиться, там стооооолько всего еще).
Twizard
02.02.2026 15:47Да я и не говорил что это просто) Уходят месяцы, а иногда и годы. И чаще всего основное сопротивление исходит сверху. Когда нужно найти виноватых и все исправить, но это все должно быть найдено обязательно в низших эшелонах. А в итоге, как в том анекдоте - в любом расследовании главное не выйти на самих себя. И вот это исправить уже самое сложное.
AlexanderNB
02.02.2026 15:47Процессы в продуктовой команде очень хорошо работают, просто есть одно ограничение - ваш PO должен понимать куда движется ваш продукт/ы и иметь виденье куда вых хотите придти. Если этого нет, никакие процессы в этом не помогут.
garregusev
02.02.2026 15:47ну ещё PO должен иметь защиту от влетов за счёт того, что стратегия продукта согласована всеми, и он сам, или кто-то выше по иерархии может (вежливо, но твердо) слать нахрен тех кто лезет невпопад
AlexanderNB
02.02.2026 15:47Тут и да и нет. В зависимости от типа управления, я могу выделить примерно 6 типов:
Команда → процессная / функциональная
Инициатива → проектная
Продукт → продуктовая
Организация → матричная
Бизнес в целом → портфельная (если >1 проекта)
В зависимости от типа управления, и структуры CLVL: видение, стратегия, а также риски будут по-разному разделены между управляющим составом.
Но в любом случае PO/ CPO будет нести основную ответственность.
bosco
02.02.2026 15:47Спасибо, хорошая статья и глубокие мысли, переживание за результат.
Я бы добавил к смыслу процессов ещё возможность уравновешивания влияния конкретных личностей на результат.
Возможно эта мысль помогла бы и выстроить процессы получше. Поясню. Берём успешного человека, который тянет команду и решает задачи, который когда уходит в отпуск - все замирает.
Раскладываем его деятельность на процесс и шаги. Выбираем оптимальных исполнителей для каждого шага.
Вуаля.
svetashchegoleva Автор
02.02.2026 15:47Спасибо за комментарий!
Про влияние конкретных личностей на результат и уход в отпуск - точно! Периодически такое бывает, особенно летом, меня это жутко расстраивает.
DaryaBufenko
02.02.2026 15:47Классная статья, содержательная. Спасибо, что поделились своим опытом и сложностями, с которыми столкнулись. Ждем следующий этап и его итоги. Желаю успешно прийти к нужной цели!
kogemrka
Хочется не согласиться.
Выше по тексту сформулирована проблема - "никто не слушает, что разработка не успевает" и "три источника - маркетинг, продажи, бухгалтерия" - каждый продавливает свою задачу.
Когда мы говорим, что для того, чтобы процессы заработали нужно "общее понимание" и "доверие" мы как будто бы ждём, что три источника задач (на самом деле - даже четыре - разработка в описанных условиях наверняка генерирует техдолг, который рано или поздно надо начинать "выплачивать") - договорятся и выровнятся друг с другом по приоритетам.
Но ведь, если бы источники задач могли бы между собой договориться - нам не нужны были бы никакие формальные процессы!) Они бы просто договорились)
В описанной ситуации непонятно, а было ли что-то, что МЕШАЕТ и ЗАПРЕЩАЕТ условному самому-главному руководителю маркетинга/продаж/бухгалтерии прийти и принести +1 задачу?
svetashchegoleva Автор
"Просто договориться", увы, не выходит, так как каждый педалирует свои интересы, для этого и хочется наладить процессы, некие правила создать, чтобы упорядочить хаос)
garregusev
мне помогало прямо очную ставку делать. я описывал свое видение в какой последовательности надо делать задачи и почему. дальше приглашал всех заказчиков из разных департаментов и объяснял им, что ресурсов есть только на одну задачу за раз, поэтому придется выстроить очередь, поэтому чтобы сохранялось доверие и прозрачность, предлагал им между собой согласовать порядок выполнения задач
в целом в матричной структуре команд разработки, когда у меня в какой-то момент не было инженеров под мой продукт я так же ходил к другим продуктам и просил их уступить инженерные слоты под мои задачи
мне кажется, что такое может сработать и здесь
svetashchegoleva Автор
у нас создан проектный офис, в котором менеджер как раз призван фильтрован задачи, которые поступают из других отделов на разработку, договариваться с ними о приоритетах. Когда это задумывалось, все выглядело радужно, но на деле пока не так
garregusev
ну по моему опыту в таких ситуациях "специально выделенный человек" может добавлять неопределенности и лучше чтобы такие встречи вел продакт или проджект команды которая будет все реализовывать - чтобы на лету отвечать на вопросы и возвращать к основному вопросу. сторонний человек может упустить либо технические особенности проекта, либо его связи с бизнес-заказчиками.
был опыт когда специально нанятый руководитель проектного офиса пыталась разруливать поток задач и это вылилось как раз в то, что она просто выдала каждому заказчику тонну форм для подготовки ко встречам на которых она не понимала толком ни о бизнесе, ни о технической реализации. в итоге часть команд просто между собой обо всем договаривалась и на такие встречи приходила с решенным вопросами. а другие просто сказали, что для них это не сработало
svetashchegoleva Автор
ну раньше мы сами (я, в частности,) решали все вопросы приоритезации с непосредственно иницааторами, сейчас менеджер из проектного офиса все равно приходит ко мне или БА с миллионом лишних вопросов "а что да как, а почему работает так, а не этак, а накатим ли скрипт и пр.". Либо это было неверным решением, либо еще не до конца обкатали новый процесс.