Вспомните корпоративный регламент, который все соблюдают, но никто не знает, зачем он нужен. Подумайте о регулярных встречах, которые все считают бесполезными, но никто их не отменяет. Это примеры процессов, которые должны умереть. Но их некому убить — менеджмент не понимает, как это сделать.
В статье я расскажу об искусстве помогать процессам жить и умирать в нужное время. Поделюсь пошаговым планом, чек-листами и примерами из моего опыта, чтобы ритуалы не отнимали у вас по 5–10 часов в неделю
Всем привет! На связи Александр Бондаренко, CPO Garage Eight. Недавно на конференции Saint TeamLead Conf я рассказал о подходе к построению процессов в продуктовой разработке (видеозапись выступления можно посмотреть здесь). Почему я выбрал эту тему?
Поделюсь реальной историей:
Мой знакомый продакт-менеджер в российском e-commerce-стартапе вел 23 регулярных процесса: от дейли-стендапа до пяти отчетов в Slack. В рабочем дне у него оставалось меньше 10% времени на продукт. Мы с ним сели и за 1,5 часа посмотрели, что он делает каждый день.
Выяснилось:
8 процессов дублировали друг друга.
6 процессов стали традицией компанией, операционным легаси.
3 процесса можно было автоматизировать.
Результат: оставили всего 6 процессов. PM получил возможность сосредоточиться на приоритетных задачах, начал спать по 8 часов вместо 5, а качество решений выросло.
Метрика | До | После |
Количество регулярных процессов | 23 | 6 |
Повторяющиеся/дублирующие процессы | 8 | 0 (устранены) |
Устаревшие, “традиционные” процессы | 6 | 0 (удалены) |
Процессы, подлежащие автоматизации | 3 | 3 (автоматизированы) |
Время на работу с продуктом | < 10% рабочего дня | > 50% рабочего дня |
Кол-во часов сна в сутки | 5 | 8 |
Качество принимаемых решений | Среднее | Высокое |
По исследованиям McKinsey, 70% процессов и изменений в организациях либо не достигают целей, либо превращаются в бессмысленные ритуалы.
Поэтому процессы должны умирать тогда, когда перестают приносить пользу. И ими нужно управлять на каждом этапе жизненного цикла. Об этом мой материал.
Поехали!
Что такое процесс, когда он нужен и не нужен
Процесс — это набор повторяемых действий, которые обеспечивают предсказуемый результат. Они бывают трех уровней:
Командные
Межкомандные
Корпоративные
Процессы — везде. Даже то, как мы заказываем кофе в офис, может быть процессом, если мы делаем это по определенным правилам. У каждого процесса есть границы: от момента, когда появился триггер, до получения результата.
Пример: «Хочется кофе»/Триггер → «Подойти к роботу, приложить карту»/Действие → «Латте в руке за 40 секунд»/Результат
Но часто мы создаем процессы, чтобы снизить хаос, а получаем еще больше хаоса. Это связано с тем, что некоторые процессы вообще не нужны.
Процесс стоит внедрять только в двух случаях
Он решает проблему. Например, команда регулярно забывает фиксировать договоренности — процесс с чек-листом и логированием может это решить.
Он снижает риски, которые мы не можем себе позволить. Например, процесс код-ревью для релиза предотвращает критические ошибки в проде.
Пример: в одной компании стали появляться частые баги в проде. С каждым релизом возникали новые проблемы на стороне клиентов. Проблема повторяющаяся. Решение: внедрить code review для команд разработки API. Мы четко зафиксировали цель: сократить количество критичных багов на 80% за три месяца. И получили «здоровый» процесс — он появился из конкретной боли и его эффективность можно измерить.
Когда процессы точно не нужны
Огромное количество управленческих ошибок возникает на нулевом этапе — когда процесса нет и появляется мысль его создать.
Этого точно не стоит делать, если:
Проблема возникает редко или единожды. Не нужно создавать регламент для ситуации, которая случается раз в год. Ограничьтесь разовой инструкцией, карточкой, стикером в Notion.
Можно договориться устно. Для команды из 3–5 человек достаточно договоренностей. Устные договоренности снижают издержки и повышают гибкость.
Издержки процесса превышают пользу. Если процесс занимает больше времени, чем экономит. Когда появляется процесс, снижается эффективность и скорость. Если эти показатели критичны, стоит отказаться от формальностей. Например, создать шаблон без обязательного контроля.
Нет четкой проблемы для решения. «Так делают все» или «Так должно быть» — не аргументы. Если вы не можете объяснить, зачем существует процесс, скорее всего, он вам не нужен.
Пример: Команда из пяти человек внедрила строгий фреймворк Scrum. Но вместо решения проблем разработчики проводили по 3 часа в день на созвонах, а скорость доставки фич упала в два раза. В итоге хороший мотив превратился в лишний ритуал.
Если процесс хорошо описан — вы быстрее онбордите в него людей. Он становится частью архитектуры знаний команды.
Как понять, что без процесса уже нельзя
Процесс нужен, если выполняется хотя бы одно из условий:
Проблема повторяется или связана с высокой ценой ошибки — например, баги в продакшене, сбои при интеграции с банковскими системами, работа с критической инфраструктурой, финансовыми операциями, персональными данными или в условиях строгих требований к безопасности.
Команда выросла, и устные договорённости больше не работают. Когда над похожими задачами трудится более 20 человек — разработчики, маркетологи, саппорт — важно описывать правила.
Пример: в моей предыдущей компании команда Data-платформы выросла с 7 до 20 человек, и устная передача задач перестала работать. Решение: мы ввели легкий pull-request-шаблон и check-list из трех пунктов. Результат: доля баг-фиксов в релизах упала с 12% до 2%.
______
Мини-чек-лист: стоит ли документировать процесс?
Повторяется одна и та же боль?
Цена ошибки высокая?
В задачи вовлечено много участников?
Есть конфликты из-за недопонимания?
Один и тот же вопрос задают снова и снова?
Когда появляется мысль запустить новый процесс, отвечайте на три вопроса:
Какую конкретную проблему он решает? Эта проблема вообще существует?
Что изменится в работе команды после внедрения?
Какие метрики покажут, что процесс работает?
Если на эти вопросы нет измеримых ответов — либо вам не нужен процесс, либо вы не поняли, зачем он вам.
Как спроектировать процесс
Допустим, тест пройден, и процесс действительно нужен. Чтобы его спроектировать, я рекомендую использовать простой алгоритм, который работает у меня уже много лет:
MVP-подход — начинайте с минимальной версии, не описывайте все сразу.
Командная разработка процесса — вовлекайте исполнителей.
Простота — чем проще, тем лучше приживется.
Измеримость — заложите метрики с самого начала.
И самое главное: процесс не должен быть надстройкой сверху. Важно, чтобы он органично встраивался в повседневную работу.
Для запуска процесса нужно пройти три шага:
Шаг 1: Опишите проблему, ее частоту и стоимость.
Шаг 2: Придумайте простое решение с командой, опишите его в 1–2 абзацах.
Шаг 3: Заложите метрики. Обязательно подумайте о двух типах метрик: для оценки процесса и для понимания того, что его пора менять.
Пример: в другой компании команда сама разработала процесс синхронизации между фронтендом и бэкендом. Проблема: 40% времени уходило на исправление несовместимостей API. Решение: еженедельные 30-минутные sync-встречи. Метрика: снижение времени на фиксы до 10%. Работает уже 2 года.
Как внедрить процесс и пережить сопротивление изменениям
Допустим, вы спроектировали процесс и нашли подходящие метрики. Но просто объявить команде:«Теперь работаем вот так!» — недостаточно. Самое сложное — пережить сопротивление изменениям. По статистике, 70% процессов не приживаются.
Как нельзя внедрять процесс
Чтобы избежать проблем, полезно применять разные модели, например, ADKAR или модель Джона Коттера. Подробно их рассматривать не будем.
Но даже обладая теоретической и практической базой, мы неосознанно ошибаемся при внедрении. Есть антипаттерны, которые встречаются даже у опытных команд.
С этим я сталкивался сам:
Лучше начать с пилотной группы, проверить процесс, адаптировать его, и только потом масштабировать. Я подготовил несколько лайфхаков для внедрения.
Как лучше внедрять процесс, чтобы он заработал
В ИТ-компаниях особенно важно начинать с осознания и желания. Поэтому:
Объясните ценность процесса через проблемы, с которыми сталкивается команда.
Вовлеките команду в разработку и внедрение процесса. То, что придумано вместе, воспринимается как «наше», а не «навязанное сверху».
Пример: когда мы внедряли код-ревью в одной из команд, получили сопротивление. Ошибка: мы объяснили необходимость, но команда все равно сопротивлялась. Если бы пошли по силовому сценарию, это бы переросло в конфликт. Решение: попросили команду самих разработать процесс ревью. И команда сама придумала легкую, удобную версию, которая прижилась быстрее и была лучше изначальной идеи.
Проведите пилот перед полным внедрением. В маленькой группе адаптация проходит быстрее, а рисков — меньше.
Фиксируйте первые успехи публично. Если вы покажете, что процесс сработал, у других команд тоже появится мотивация его внедрить.
Почему большинство процессов умирает
Если процесс внедрен, не значит, что ваша задача закрыта. 80% процессов умирает в первые 3 месяца после запуска.
Ваша задача после внедрения — не позволить процессу превратиться в ритуал. Для этого нужно понимать три основные причины, по которым процессы ломаются.
Причина 1. Избыточная сложность. Если процессу сложно следовать, он отнимает время и силы — его нужно менять. Что делать: упрощайте процессы до минимально необходимого.
Причина 2. Отсутствие владельца. Если за процессом никто не следит и не обновляет его — он медленно умирает. Что делать: каждый процесс должен иметь «хранителя», который:
Регулярно проверяет, работает ли процесс.
Адаптирует его под изменившуюся реальность.
Собирает обратную связь от команды.
Причина 3. Игнорирование контекста. Если вы скопируете чей-то процесс «как есть», например, позаимствуете готовый подход у Google или топового банка, у вас он не заработает. Что делать: процесс должен учитывать скорость канала и цену ошибки.
Healthcheck процессов: что делать, чтобы процесс работал
Каждый процесс уникален, и у каждого будут свои метрики для оценки его «здоровья». Мне чаще всего полезно смотреть на:
Cycle Time.
Число точек передачи задачи между людьми.
Вовлеченность команды в процесс.
Количество процессов на человека.
Как масштабировать процессы, не создавая бюрократию
Представим, вы уже придумали рабочие процессы и они помогли расти команде и бизнесу. Когда внутри одной команды метрики «зеленые», следующим шагом становится масштабирование.
Когда процесс нужно масштабировать:
Команда выросла с 10 до 20+ человек.
Появились зависимости между командами.
Одинаковые проблемы возникают в разных местах.
Тут главное — не скатиться в бюрократию. Частая ошибка: брать старую схему, и вместо адаптации добавлять избыточные уровни согласований, правил и отчетности.
Есть несколько подходов к масштабированию:
Принцип «двух пицц» от Amazon. Его предложил Джефф Безос в 1997 году. Он считал, что команда должна быть настолько маленькой, чтобы ее можно было накормить двумя пиццами — 6–12 человек. Такие команды сохраняют автономность и эффективность, но процессы между командами и зоны ответственности нужно определять четко.
Правило 150 (число Данбара). Компания W.L. Gore принципиально создает новый офис или подразделение, как только в текущем собирается 150 человек. Это психологический предел, после которого люди перестают знать, кто чем занимается, и начинаются коммуникационные сбои.
Иерархия процессов. В больших компаниях различают «тяжелые» процессы для критичных областей (безопасность, работа с клиентами) и «легкие» процессы для задач, где важны скорость и инновации. Например, в Google инфраструктурные и продуктовые команды работают по разным правилам.
Принцип трех корзинок. Раскладывать процессы на три группы:
Что масштабируется «as is»: техпроцессы, стандарты кодирования.
Что требует адаптации: принятия решений, согласование, код-ревью.
Что не масштабируется: личные отношения, устные договоренности.
Пример: команда инженеров резко выросла с 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)