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

В статье я расскажу об искусстве помогать процессам жить и умирать в нужное время. Поделюсь пошаговым планом, чек-листами и примерами из моего опыта, чтобы ритуалы не отнимали у вас по 5–10 часов в неделю

Всем привет! На связи Александр Бондаренко, CPO Garage Eight. Недавно на конференции Saint TeamLead Conf я рассказал о подходе к построению процессов в продуктовой разработке (видеозапись выступления можно посмотреть здесь). Почему я выбрал эту тему? 

Поделюсь реальной историей: 

Мой знакомый продакт-менеджер в российском e-commerce-стартапе вел 23 регулярных процесса: от дейли-стендапа до пяти отчетов в Slack. В рабочем дне у него оставалось меньше 10% времени на продукт. Мы с ним сели и за 1,5 часа посмотрели, что он делает каждый день. 

Выяснилось:

• 8 процессов дублировали друг друга.

• 6 процессов стали традицией компанией, операционным легаси.

• 3 процесса можно было автоматизировать.

Результат: оставили всего 6 процессов. PM получил возможность сосредоточиться на приоритетных задачах, начал спать по 8 часов вместо 5, а качество решений выросло.

По исследованиям McKinsey, 70% процессов и изменений в организациях либо не достигают целей, либо превращаются в бессмысленные ритуалы.

Поэтому процессы должны умирать тогда, когда перестают приносить пользу. И ими нужно управлять на каждом этапе жизненного цикла. Об этом мой материал.

Поехали!

Что такое процесс, когда он нужен и не нужен

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

• Командные

• Межкомандные

• Корпоративные

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

Пример: «Хочется кофе»/Триггер → «Подойти к роботу, приложить карту»/Действие → «Латте в руке за 40 секунд»/Результат

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

Процесс стоит внедрять только в двух случаях

1. Он решает проблему. Например, команда регулярно забывает фиксировать договоренности — процесс с чек-листом и логированием может это решить.

2. Он снижает риски, которые мы не можем себе позволить. Например, процесс код-ревью для релиза предотвращает критические ошибки в проде.

Пример: в одной компании стали появляться частые баги в проде. С каждым релизом возникали новые проблемы на стороне клиентов. Проблема повторяющаяся. Решение: внедрить code review для команд разработки API. Мы четко зафиксировали цель: сократить количество критичных багов на 80% за три месяца. И получили «здоровый» процесс — он появился из конкретной боли и его эффективность можно измерить.

Когда процессы точно не нужны

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

Этого точно не стоит делать, если:

1. Проблема возникает редко или единожды. Не нужно создавать регламент для ситуации, которая случается раз в год. Ограничьтесь разовой инструкцией, карточкой, стикером в Notion.

2. Можно договориться устно. Для команды из 3–5 человек достаточно договоренностей. Устные договоренности снижают издержки и повышают гибкость.

3. Издержки процесса превышают пользу. Если процесс занимает больше времени, чем экономит. Когда появляется процесс, снижается эффективность и скорость. Если эти показатели критичны, стоит отказаться от формальностей. Например, создать шаблон без обязательного контроля.

4. Нет четкой проблемы для решения. «Так делают все» или «Так должно быть» — не аргументы. Если вы не можете объяснить, зачем существует процесс, скорее всего, он вам не нужен.

Пример: Команда из пяти человек внедрила строгий фреймворк Scrum. Но вместо решения проблем разработчики проводили по 3 часа в день на созвонах, а скорость доставки фич упала в два раза. В итоге хороший мотив превратился в лишний ритуал.

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

Как понять, что без процесса уже нельзя

Процесс нужен, если выполняется хотя бы одно из условий:

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

• Команда выросла, и устные договорённости больше не работают. Когда над похожими задачами трудится более 20 человек — разработчики, маркетологи, саппорт — важно описывать правила.

Пример: в моей предыдущей компании команда Data-платформы выросла с 7 до 20 человек, и устная передача задач перестала работать. Решение: мы ввели легкий pull-request-шаблон и check-list из трех пунктов. Результат: доля баг-фиксов в релизах упала с 12% до 2%.

______

Мини-чек-лист: стоит ли документировать процесс?

• Повторяется одна и та же боль?

• Цена ошибки высокая?

• В задачи вовлечено много участников?

• Есть конфликты из-за недопонимания?

• Один и тот же вопрос задают снова и снова?

Когда появляется мысль запустить новый процесс, отвечайте на три вопроса: 

1. Какую конкретную проблему он решает? Эта проблема вообще существует?

2. Что изменится в работе команды после внедрения?

3. Какие метрики покажут, что процесс работает?

Если на эти вопросы нет измеримых ответов — либо вам не нужен процесс, либо вы не поняли, зачем он вам.

Как спроектировать процесс

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

• MVP-подход — начинайте с минимальной версии, не описывайте все сразу.

• Командная разработка процесса — вовлекайте исполнителей. 

• Простота — чем проще, тем лучше приживется.

• Измеримость — заложите метрики с самого начала.

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

Для запуска процесса нужно пройти три шага: 

Шаг 1: Опишите проблему, ее частоту и стоимость.

Шаг 2: Придумайте простое решение с командой, опишите его в 1–2 абзацах.

Шаг 3: Заложите метрики. Обязательно подумайте о двух типах метрик: для оценки процесса и для понимания того, что его пора менять.

Пример: в другой компании команда сама разработала процесс синхронизации между фронтендом и бэкендом. Проблема: 40% времени уходило на исправление несовместимостей API. Решение: еженедельные 30-минутные sync-встречи. Метрика: снижение времени на фиксы до 10%. Работает уже 2 года.

Как внедрить процесс и пережить сопротивление изменениям

Допустим, вы спроектировали процесс и нашли подходящие метрики. Но просто объявить команде:«Теперь работаем вот так!» — недостаточно. Самое сложное — пережить сопротивление изменениям. По статистике, 70% процессов не приживаются. 

Как нельзя внедрять процесс

Чтобы избежать проблем, полезно применять разные модели, например, ADKAR или модель Джона Коттера. Подробно их рассматривать не будем.

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

С этим я сталкивался сам:

Лучше начать с пилотной группы, проверить процесс, адаптировать его, и только потом масштабировать. Я подготовил несколько лайфхаков для внедрения.

Как лучше внедрять процесс, чтобы он заработал

В ИТ-компаниях особенно важно начинать с осознания и желания. Поэтому:

1. Объясните ценность процесса через проблемы, с которыми сталкивается команда.

2. Вовлеките команду в разработку и внедрение процесса. То, что придумано вместе, воспринимается как «наше», а не «навязанное сверху».

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

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

4. Фиксируйте первые успехи публично. Если вы покажете, что процесс сработал, у других команд тоже появится мотивация его внедрить.

Почему большинство процессов умирает

Если процесс внедрен, не значит, что ваша задача закрыта. 80% процессов умирает в первые 3 месяца после запуска.

Ваша задача после внедрения — не позволить процессу превратиться в ритуал. Для этого нужно понимать три основные причины, по которым процессы ломаются.

Причина 1. Избыточная сложность. Если процессу сложно следовать, он отнимает время и силы — его нужно менять. Что делать: упрощайте процессы до минимально необходимого.

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

• Регулярно проверяет, работает ли процесс.

• Адаптирует его под изменившуюся реальность.

• Собирает обратную связь от команды.

Причина 3. Игнорирование контекста. Если вы скопируете чей-то процесс «как есть», например, позаимствуете готовый подход у Google или топового банка, у вас он не заработает. Что делать: процесс должен учитывать скорость канала и цену ошибки.

Healthcheck процессов: что делать, чтобы процесс работал

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

• Cycle Time.

• Число точек передачи задачи между людьми.

• Вовлеченность команды в процесс.

• Количество процессов на человека.

Как масштабировать процессы, не создавая бюрократию

Представим, вы уже придумали рабочие процессы и они помогли расти команде и бизнесу. Когда внутри одной команды метрики «зеленые», следующим шагом становится масштабирование.

Когда процесс нужно масштабировать:

• Команда выросла с 10 до 20+ человек.

• Появились зависимости между командами.

• Одинаковые проблемы возникают в разных местах.

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

Есть несколько подходов к масштабированию:

1. Принцип «двух пицц» от Amazon. Его предложил Джефф Безос в 1997 году. Он считал, что команда должна быть настолько маленькой, чтобы ее можно было накормить двумя пиццами — 6–12 человек. Такие команды сохраняют автономность и эффективность, но процессы между командами и зоны ответственности нужно определять четко.

2. Правило 150 (число Данбара). Компания W.L. Gore принципиально создает новый офис или подразделение, как только в текущем собирается 150 человек. Это психологический предел, после которого люди перестают знать, кто чем занимается, и начинаются коммуникационные сбои.

3. Иерархия процессов. В больших компаниях различают «тяжелые» процессы для критичных областей (безопасность, работа с клиентами) и «легкие» процессы для задач, где важны скорость и инновации. Например, в Google инфраструктурные и продуктовые команды работают по разным правилам.

4. Принцип трех корзинок. Раскладывать процессы на три группы:

   1. Что масштабируется «as is»: техпроцессы, стандарты кодирования.

   2. Что требует адаптации: принятия решений, согласование, код-ревью.

   3. Что не масштабируется: личные отношения, устные договоренности.

Пример: команда инженеров резко выросла с 30 до 120 человек. Ошибка: мы продолжали работать по Scrum, который хорошо масштабируется примерно до 50 человек. Решение: мы перешли на фреймворк LeSS (Large Scale Scrum). Несколько команд стало работать с единым бэклогом и совместным планированием. За 4 спринта скорость поставки выровнялась, процент зависших задач сократился в 2 раза. 

Смерть процесса — это нормально

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

Почему так происходит? Психологически тяжело отказаться от привычного. Люди не знают, что будет после отмены.

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

Что подсказывает, что процесс пора «убить»

Есть два типа сигналов, которые помогают понять, что пора расставаться с операционным легаси: качественные и количественные.

Качественные сигналы:

• Процессы соблюдаются для галочки.

• Появляются шутки про бессмысленную бюрократию.

• Сотрудники регулярно избегают выполнения.

• Лучшие сотрудники недовольны и уходят.

Количественные сигналы:

• Время нахождения задачи в цикле увеличилось, compliance rate упал ниже 60%.

• Скорость доставки фичи до клиента снизилась, lead time вырос на 30%.

• Удовлетворенность сотрудников снизилась, показатель упал ниже 60%.

• Количество эскалаций по процессу выросло.

Чтобы узнать метрики проблем, проведите exit interviews, посчитайте время на процесс и оцените его полезность. Раз в квартал просите команды дать процессам оценку.

Чтобы посчитать метрики и поймать триггеры изменений, говорите с командами

Чек-лист безопасной отмены процесса

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

Пример: в одной из компаний мы собрали R&D-команду. Ошибка: мы встроили ее в производственную цепочку с дейликами. На ежедневных стендапах 8 человек выступало по 30 минут — суммарно уходило 4 часа в день. Ребята больше синкались, чем занимались инновациями. Решение: мы ввели асинхронные апдейты в Slack (по 2 минуты на человека). Результат: производительность выросла на 20–25%, удовлетворенность команды — на 40%.

Когда не стоит отменять процессы

Процессы существуют не только ради удобства. Часто они защищают от юридических, операционных и репутационных рисков. Я не советую резко отменять процессы, если:

• Процесс связан с безопасностью или compliance.

• Отмена создаст проблемы для других команд.

• Нет измеримых проблем, только субъективное недовольство.

Отмена процесса — это управленческое решение, и оно должно быть не менее обоснованным, чем его запуск.

Из личного архива: пять типичных ошибок в управлении процессами

Уверен, у каждого менеджера или руководителя есть список факапов. Делюсь своим — возможно, он поможет посмотреть на свои процессы под новым углом.

Ошибка 1. Процессы ради процессов. Ставить процесс на планирование, стендапы и ретро, потому что в Scrum Guide так написано. Важно не следовать моде, а отвечать на простой вопрос: какую проблему мы решаем?

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

Ошибка 3. Нет владельца процесса. Руководитель создает процесс, описывает его и не управляет им. Если кто-то предложил процесс, то он обязательно должен быть его хранителем. Нет хранителя — не заводите процесс и не тратьте на это время.

Ошибка 4. Слепое копирование чужого опыта. Вдохновиться чужим кейсом и перенести его к себе без адаптации. Увидеть, что работает в Google и Сбере, и скопировать. Процессы нужно адаптировать под свою культуру, задачи и зрелость команды. То, что работает у большой продуктовой компании, может не взлететь у вас.

Ошибка 5. Метрики ради метрик. Измерять все подряд, не понимая, зачем. Если метрика есть — значит, работа идет. Не отслеживайте показатели, которые не влияют на результат. Используйте принцип «Докажи, что нужно».

Выводы: процесс — не самоцель, а инструмент

Процесс помогает решать задачу. Пока помогает — живет. Перестал — должен уйти.

Пример: Garage Eight быстро растет. В какой-то момент на каждого сотрудника навалилось по десятку процессов. Люди начали путаться, выгорать, жаловаться. Решение: мы открыли Excel, выписали все процессы, какие проблемы они решают, кто владелец, как измеряем эффективность. Увидели, что часть процессов неактуальны — удалили их. Сделали таблицу открытой для всех, актуализируем ее раз в квартал. Результат: я вижу реальную картину нагрузки, а команда понимает, что и зачем делает.

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

Спросите себя: «Помогает ли он нам?» И если он мешает —- наберитесь смелости и попробуйте изменить или отменить его. Вы управляете своей работой, а не она вами. Вы настраиваете тот контекст, в котором вам будет комфортно работать.

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

---

Полезные ресурсы

Common pitfalls in transformations (McKinsey)

The Prosci ADKAR Model

The 8 Steps for Leading Change — Dr. John Kotter

Мой LinkedIn: Александр Бондаренко