На «Ура, мы запустили процесс!» работа не заканчивается. Здесь как с деревьями: мало посадить, важно присматривать и ухаживать, иначе процесс зачахнет и не даст ожидаемых плодов. В этой статье по мотивам выступления с TeamLeadConf Александр Бондаренко из Garage Eight поделится своим опытом, как сделать так, чтобы процессы жили и приносили результаты. Передаём ему слово.
Привет, Хабр! Я — Саша, и работаю в продуктовой разработке больше 17 лет. В Garage Eight я отвечаю за весь портфель продуктов — много раз заводил и убивал процессы в разных масштабах.
Когда я работал в одной компании, у меня был гениальный продакт‑менеджер. Но из‑за его гиперответственности у этого бедолаги было 23 ежедневных процесса — от дневных стендапов до вечерних отчетов с Slack. В итоге, как вы понимаете, он непосредственно на свою работу тратил меньше 10% времени и часто выполнял её в нерабочее время.
Мы вместе с ним сели, потратили полтора часа времени и попробовали проанализировать, что же такого он делает, что вся работа — это одни процессы. Оказалось, что из 23 процессов восемь дублировали друг друга, шесть никто не читал (они достались от предыдущих периодов и никто не решился их отменить), ещё три можно было легко автоматизировать прямо сейчас. В итоге мы оставили ему всего лишь шесть процессов и он начал спать по восемь часов в сутки, а не по пять.
Разные исследования, которые проводят, в том числе, McKinsey, Deloitte и другие агентства, говорят, что 70% процессов не достигают своих целей, потому что процессы умирают, когда перестают быть полезными. Сегодня мы как раз научимся управлять этим жизненным циклом на разных этапах.
Что такое процесс
Процесс — это набор регулярно повторяемых действий, которые обеспечивают предсказуемый результат.
Сегодня будем говорить о трёх уровнях:
Командный — то, что внутри сами для себя определяем.
Межкомандный — то, как мы живём в среде с другими командами.
Уровень компании, когда процесс затрагивает все подразделения, например перформанс ревью, бюджетные циклы.
Попробуем определить, что является процессом. Например, код ревью, стендапы, дейлики — это процессы, потому что они проводятся на регулярной основе, по определённым правилам и имеют некую ценность. Также это может быть формат письма клиенту, онбординг новичков — что угодно. Даже заказ кофе в офис тоже может быть процессом, если мы делаем это регулярно.
Границы процесса начинаются от момента, когда появляется триггер (проблема или задача) до момента получения конечного результата.
Парадокс: часто мы вводим процессы для того, чтобы уменьшить хаос, а его становится только хаоса. Почему? Здесь важно понимать, что процессы нужны всего лишь в двух случаях: когда они решают реальную проблему команды/продукта или когда снижают риски. Важно этот баланс учитывать.
Пример — история с компанией, где хороший мотив превращался в бессмысленный ритуал. В коллективе из пяти человек решили внедрить строгий Scrum. Кто знаком с этим фреймворком, понимает, что там есть обязательные элементы. В итоге команда начала дополнительно тратить по три часа в день, а доставка фичей упала в несколько раз. Здесь важно учитывать контекст и проблемы, которые мы решаем.
Поэтому первый принцип:
Процессы должны решать проблемы, а не создавать новые.
Если процесс хорошо описан, он становится частью архитектуры знаний вашей команды и вы быстрее онбордите в него людей.
Нулевая фаза — это рождение процесса. Здесь как раз возникает много ошибок, когда мы делаем то, что не нужно.
Когда процесс не нужен?
Для начала поймем, когда процесс не нужен:
Когда проблема возникает редко или единожды
Для этого не надо заводить регламент или описывать процесс. Добавьте себе напоминание в календарь, этого достаточно.
Когда команда маленькая и можно договориться устно
Это самая лучшая форма взаимодействия для 3−5 человек. Любые правила и процессы будут только мешать.
Когда издержки процесса превышают пользу
Часто при внедрении процессов снижается наша эффективность и скорость. Поэтому здесь важно следить за этим показателем. Процесс должен приносить пользу, а не добавлять дополнительную нагрузку.
Когда нет чёткой проблемы для решения
«Так делают все» или «так должно быть» — это не аргументы.
Что можно с этим со всем сделать? Во‑первых, договоритесь устно, без формализации — для стабильных команд. Во‑вторых, ограничьтесь разовой инструкцией, карточкой, стикером в Notion. Наконец, в‑третьих — создайте шаблон или чек‑лист без обязательного контроля
Когда я работал в Сбертехе, начались частые релизы в продакшене — в каждом мы получали баги. Выяснилось, что необходимо внедрить код‑ревью. Чёткая проблема — чёткий результат. Это нам позволило повысить нашу эффективность.
Но бывают ситуации, когда процесс действительно необходим.
Когда процесс нужен
Процесс однозначно нужен, если:
Проблема повторяется регулярно и имеет высокую цену ошибки
Примеры: релизы cross‑production, интеграция с критической инфраструктурой.
Команда выросла, устные договорённости неэффективны
Обычно устные договоренности перестают работать для 20+ человек. Здесь как раз уже нужно какие‑то правила описывать.
Требуются прослеживаемость и аудит действий
Примеры: финансовые операции, работа персональными данными, требования по безопасности.
Нужна предсказуемость результата для смежных команд
Например, есть команда разработки, рядом команды маркетинга и сопровождения, которые так или иначе объединены общим контекстом.
В таком случае достаточно будет ответить на три вопроса, когда у вас появилась идея:
Какую проблему решает процесс, и существует ли она на самом деле?
Что изменится в работе команды после внедрения процесса?
Какие метрики покажут, что процесс работает?
Если однозначного ответа нет, значит, либо процесс не нужен, либо его нужно переосмыслить.
Предположим, вы доказали, что процесс всё‑таки нужен — возникает фаза проектирования.
Как спроектировать процесс
Предлагаю простой фреймворк. Во‑первых, начинайте с MVP‑подхода. Не нужно описывать все сразу — начните с базовой версии, которая покажет решение конкретной проблемы, а потом уже будете её донасыщать.
Во‑вторых, командная разработка — это самое важное. На всех этапах вовлекайте участников и исполнителей процесса.
В‑третьих, простота. В науке есть принцип Бритва Оккама: «Не приумножай сущего без необходимости». Здесь он тоже применяется: чем проще процесс, тем быстрее и легче он приживается.
И наконец, измеримость: закладывайте метрики в самом начале.
Структура проектирования состоит из трёх шагов:
Опишите проблему: что конкретно идет не так, как часто это происходит и сколько стоит (время, деньги, репутация)?
Придумайте решение с командой: проведите мозговой штурм (можно какие‑то идеи набрать на рынке у конкурентов), выберите самое простое решение и опишите в паре абзацев. Это позволяет одинаково понимать и проблему, и суть решения.
Заложите метрики: как поймёте, что процесс работает или что пора его менять.
Следом наступает фаза внедрения.
Внедрение процесса: почему это непросто объявить
Внедрение — это не чек‑лист. Объявить внедрение процесса непросто, потому что здесь начинается сопротивление изменениям. По статистике 70% процессов не приживаются из‑за человеческого фактора. Предлагается использовать различные модели. Наиболее популярные — модель Джона Коттера и модель ADKAR. Не буду их описывать — об этом уже было много сказано в других статьях и докладах, а мы поговорим немного о другом.
Антипаттерны внедрения
Даже обладая теоретической и практической базой, мы неосознанно в это скатываемся.
Например, это может быть внедрение через негативную мотивацию, итальянская забастовка. То есть мы наказываем тех, кто не следует правилам, которые мы выработали.
Внедрение сразу на всех — высокий риск провала. Если у вас 10 человек — этим ещё можно управлять, а если 100−1000 — представьте, какая нагрузка будет на команду сопровождения! Всех обучить, адаптировать, учитывать разный контекст. Как следствие — очень высокий риск провала. Начинайте с маленьких групп, с пилотов.
Отсутствие объяснения «зачем» — тоже частая причина неудачи. Когда сверху впустили: «Нам так сказали, давайте так делать», а зачем и почему — не объясняем. Это тоже вызывает некоторую демотивацию.
Мы не любим работать с бессмысленными вещами, мы как раз их челленджим.
Начинайте с осознания и желания
Что делать? Ваши задачи:
Объясните ценность процесса через проблемы: зачем, почему, что это нам даст?
Вовлеките команду в разработку процесса. Это ваши агенты изменений, через них это проще будет делать.
Проведите пилот перед полным внедрением. Возьмите маленькую группу, на которой обкатаете решение и выявите факторы, которые никогда бы не смогли учесть на этапе планирования. Это позволит адаптировать процесс и снизить страхи у людей перед тем, как он начнет происходить.
Отмечайте первые успехи публично. Это самое важное: вам покажет, что вы двигаетесь в правильном направлении, а у участников закрепит положительный результат.
После внедрения начинается жизнь процесса.
Жизнь процесса: как не дать ему умереть
Первые три месяца — критичный период, когда умирают 80% процессов. Здесь мы часто думаем, что всё сделали, бросаем работу и переключаемся на что‑нибудь другое. Но важно понимать, что после внедрения главная задача — не дать процессу превратиться в бессмысленный ритуал.
Почему это происходит именно в первые три месяца?
Избыточная сложность
Это когда мы описываем все возможные кейсы. Например, упадёт метеорит или где‑нибудь воду перекроют. Нам нужно всё это правильно документировать.
Приведу реальный кейс. В одной из компаний процесс релиза занимал 32 шага и требовал девять подписей. Это была интеграция с критической инфраструктурой, но команды перемудрили и все делали хот‑фиксы, потому что они не требовали такого согласования. В итоге 80% изменений шли в обход процесса.
Решение: упрощайте процессы до минимально необходимого. Как говорят в Amazon, хороший процесс тот, который незаметен.
Отсутствие владельца
Помните, процесс — это продукт, потому что у него есть свои клиенты и задачи. Обязательно у каждого процесса должен быть владелец продукта (хранитель процесса), который регулярно проверяет работу, адаптирует процесс под изменившуюся реальность и собирает обратную связь от команды.
Позже поговорим про то, как он будет выводить процесс при утрате эффективности — важная история, потому что если нет владельца, то процесс просто медленно умирает.
Игнорирование контекста
Это очевидная история, когда мы просто копируем чужие процессы как есть или процесс конфликтует с культурой команды.
Опять пример из моей практики. В одной компании команда маркетинга решила усилить качество креативов, и они просто скопировали воркфлоу разработки один в один. Теперь каждый баннер, каждая картинка — обязательно PR и ревью дизайн‑лида и бренд‑менеджера. В итоге время создания креативов увеличилось 2.5 раза. При этом 35% креативов в срок выходят. Когда мы нырнули внутрь, увидели, что там вся работа идет в обход процесса через личные договорённости.
Помните, что в процессе важно учитывать скорость канала и цену ошибки. То, что хорошо для одних, для других может быть смертью.
Чек‑лист здоровья процесса
Предлагаю простой чек‑лист здоровья процесса, который можно регулярно использовать:
Проводите регулярные ретро
Не обязательно каждый спринт — можно раз в квартал/полгода/год. Но так вы будете хотя бы некоторые ревью проводить.
Упрощайте, если люди начинают искать обходные пути
Не пытайтесь с ними соперничать. Сделайте их своими сторонниками и вместе найдите оптимально лучшее решение.
Анализируйте метрики процесса
Пересматривайте, когда меняется контекст команды или бизнеса
Это может быть изменение архитектуры, бизнес‑стратегии, выход на новые рынки и так далее. Например, у вас команда расширилась или стало 2−3 команды — это тоже нужно адаптировать.
При изменениях адаптируйте процесс под новую реальность.
Метрики для оценки «здоровья» процесса
Здесь важно учитывать контекст: каждый процесс уникален, и у каждого будут свои определенные метрики. Я выделил четыре наиболее универсальные:
Cycle Time — как долго задача находится в процессе от момента, когда она вошла в процесс, до момента, когда мы получили результат. Хороший показатель: снижение на 20–30% после оптимизации.
Количество переходов от одного человека к другому. Хороший показатель: не более 3–4 переходов на типовую задачу. Добавление нового человека увеличивает стоимость процесса (время и деньги), потому что он будет тратить свое время в рабочий день на то, чтобы участвовать в этом процессе.
Вовлечённость команды в процесс. Хороший показатель: 80%+ команды считают процесс полезным.
Количество процессов на человека. Хороший показатель: не более 10, иначе вы в зоне перегруза.
Приведу пример. В одной компании у нас был процесс командировок. Когда человек хотел, например, поехать на конференцию, он скачивал шаблоны, выбирал из них нужный, заполнял, отправлял своему менеджеру. Тот его согласовывал, отдавал бухгалтеру, бухгалтер — в HR, HR тоже согласовывал, передавал бухгалтеру, и потом бухгалтер покупал билет и отдавал сотруднику. Итого пять переходов. Минимальный cycle time был 14 дней при условии, что мы ещё эскалировали вопросы, так в среднем было больше. Удовлетворённость процессом была ниже 50% — 2,5 по 5-балльной шкале.
Мы нашли простое решение. Во‑первых, отказались от шаблонов и сделали простую онлайн форму. Когда сотрудник её заполняет, она сразу уходит его менеджеру. По мере согласования включается автоматическая цепочка уведомлений одновременно HR и бухгалтеру. Также сделали простого чат‑бота, где отслеживается текущий статус. Так мы получили cycle time до 6 дней (среднее значение), удовлетворенность процессом 4,5, а количество переходов всего 3 (сотрудник, менеджер, автоматическая цепочка). Бонусом мы ещё высвободили 3 дополнительных дня в неделю у HR за счёт того, что убрали у них эту рутину.
Мы уже перевалили экватор, осталось чуть‑чуть! Вы — классные менеджеры, правильно придумали хорошие процессы. Благодаря им компания и команда растут, и наступает фаза масштабирования.
Как масштабировать процессы, не создавая бюрократию
Часто при масштабировании берут старое и сверху обкладывают настройками. Но зачастую процессы, которые работали в маленькой группе, начинают ломаться, когда команда или компания растёт. Среди триггеров — команда выросла до 20+ человек, появление зависимостей между командами и возникновение одинаковых проблем в разных местах.
Подходы к масштабированию
Моя задача — дать инструмент, а вы, исходя из своего контекста, примените те или иные фреймворки.
Правило двух пицц от Amazon. Команда должна быть достаточно маленькой, чтобы её можно было накормить двумя пиццами.
Правило предложил Джефф Безос в 1997 году. Важно, чтобы команды были маленькими, потому что такие команды сохраняют гибкость и адаптивность. Но при этом зоны ответственности и процессы между командами должны быть чётко определены, иначе начинается хаос. Люди не понимают, что нужно делать, и начинают толкаться.
Правило 150 (число Данбара). Создавайте новый офис или подразделение, как только в текущем накапливается 150 человек.
Это психологический барьер. Если людей больше, они перестают понимать, кто чем занимается, и начинается коммуникационный сбой. Например, компания W.L. Gore and Associates принципиально создаёт новый офис, когда численность подразделения или офиса достигает числа Данбара.
Иерархия процессов. В больших компаниях различают «тяжёлые» и «лёгкие» процессы.
Например, в компании Google есть правило: «тяжёлые» процессы для инфраструктурных команд. Это команды, которые работают с клиентскими решениями. «Лёгкие» процессы — для продуктовых команд, где важны инновации и гибкость. Это позволяет им оставаться лидерами за счет этого баланса.
Главный принцип при масштабировании заключается в том, что процессы должны помогать людям взаимодействовать, а не заменять взаимодействие бюрократией.
Принцип трёх корзинок
Я в своей работе применяю при масштабировании принцип трёх корзинок и раскладываю задачи:
Что масштабируется «как есть». Техпроцессы, стандарты кодирования — они в основе имеют фрактальную структуру.
Что требует адаптации. Код‑ревью, коммуникационные ритуалы, процессы принятия решений — их нужно переработать, но качественно, а не просто сделать какие‑то дополнительные надстройки.
Что НЕ масштабируется. Личные отношения, устные договорённости или, например, какой‑то фреймворк, который перестал работать, и нужно критически пересмотреть эту работу в новом ключе.
Смерть процесса — это нормально
«Убийство» устаревших процессов — признак здоровой организации. Финальная фаза, про которую почему‑то многие забывают, и в итоге имеют традиции, которые передаются по наследству от одного руководителя к другому. А потом уже не помнят, какую задачу решают.
Это психологически трудно: люди привыкли работать в прежних условиях, а в новом ключе они не знают, что будет — вдруг всё поломается и рухнет? Но помните, что процессы должны умирать на любом этапе. Даже если вы только что внедрили процесс, но что‑то пошло не так — незамедлительно убивайте его и возвращаетесь на фазу 0.
Как понять, что процесс устарел?
Я выделяю качественные и количественные признаки.
Качественные признаки:
Формализм ради формализма — делаем для галочки. Это как раз наши традиции и ритуалы, которые передаются испокон веков.
Рост цинизма и шутки про «бессмысленную бюрократию». Обычно эта история хорошо выявляется в курилках и на тимбилдингах. Здесь триггером является уже не один процесс, а совокупность, когда мы обросли операционной работой, непонятными ритуалами, и люди начинают об этом шутить.
Люди ищут обходные пути и регулярно избегают выполнения задач, а лучшие сотрудники недовольны или уходят. Пожалуй, самый негативный триггер, до которого лучше не доходить.
Количественные метрики:
Compliance Rate < 60%, то есть время нахождения задачи в цикле увеличилось.
Lead Time > 30%, тем самым снизилась скорость доставки фичей до клиентов.
Employee satisfaction с процессом < 3/5 говорит о том, что все страдают, но делают.
Количество эскалаций по процессу выросло.
Метрики можно наблюдать через Exit интервью, например. Какие процессы мешали вашей работе? Если в 30%+ интервью упоминается один процесс — это красная зона. Также сюда можно отнести сопоставление затраченного времени на процесс с пользой. Если процесс занимает > 20% времени команды, а проблемы все равно есть — пересматривайте. И, наконец, опросы команды — пусть сотрудники оценят полезность процесса и расскажут, сколько времени тратят на него в неделю.
Как остановить процесс
Есть много практик остановки процесса. Выделю любимые, которые применяю сам:
“Kill a Stupid Rule Day”
Практику предложила компания Henkel, а в дальнейшем её переняли другие компании.
Раз в квартал команды выбирают несколько раздражающих процессов или правил и официально их отменяют. Можно, конечно, отменить то, что должно не отменяться пока. Жёстко — да, но это позволяет поддерживать культуру эффективности и результативности.
“Stop Doing List”
Практика предложена Джимом Коллинзом. Она полезна не только для процессного менеджмента, но и для руководителей в операционной работе. Например, тимлиды помимо операционки должны проводить регулярные 1:1, участвовать в бюджетных циклах, подтверждать цели, планировать и проводить синки, выступать. В рутине и не замечаешь, что 85% времени уходит на неё и только 10% времени на полезную работу. Когда наступает следующий квартал, мы обычно пишем список задач, что будем делать полезного, чтобы наш руководитель нас оценил.
Джим Коллинз предлагает вместо этого создавать список того, что вы прекращаете делать. Это заставляет критически посмотреть на работу и убрать ненужную рутину.
«Давайте месяц без этого»
Временная отмена с последующей оценкой результатов — пилот на отмену. Это позволяет оценить эффект отмены и понять, ничего ли не поломалось. Если всё хорошо, то продолжаем дальше так существовать.
Чек‑лист безопасной отмены
Измерьте проблему
Соберите данные о времени и сложностях, потому что субъективные факторы могут исказить картинку.
Найдите альтернативу
Не отменяйте в пустоту, потому что если что‑то было придумано, значит, оно какую‑то задачу решало. Нужно посмотреть, в каком новом качестве это выродится.
Протестируйте отмену (пилот на месяц — см. выше)
Объясните команде, почему отмена полезна
Помните, мы на этапе создания процесса шли через форму почему и зачем, какую проблему решаем? Тут тоже самое. Мы должны объяснить команде, какую проблему мы решаем отменой процесса.
Проведите ретроспективу, что изменилось через месяц в вашей работе.
Кейс из моей практики. Мы сделали в одной компании команду R&D, но упустили момент и полностью интегрировали в производственную цепочку. Там уже были свои практики. В итоге они начали тратить много времени на бессмысленную работу, а для R&D важна скорость инноваций. Что мы сделали? Мы просто отменили им планирование, ежедневные стендапы и дали больше свободы работать асинхронно через Slack. В итоге удовлетворённость ребят выросла на 40%, а скорость изменений, которые они предлагали — на 20−25%.
Когда не стоит отменять процессы?
Процесс связан с безопасностью или compliance
Если вы на своём уровне его отмените, то создадите для компании риски другого уровня. Обязательно нужно производить отмену вместе с представителями этих подразделений.
Отмена создаст проблемы для других команд
Например, команда разработки, у которой релизный цикл две недели, решила релизить не раз в две недели, а раз в полгода. А рядышком маркетинг уже завёл федеральную компанию, саппорт вывел 10 человек для на поддержку. Начинают возникать некоторые сложности. Важно вместе со всеми участниками этого процесса отменять эту историю.
Нет измеримых проблем, только субъективное недовольство
Это не является триггером.
Мой личный топ-5 ошибок
Уверен, что у каждого тоже такой сформирован. Надеюсь, мой опыт поможет вам понять, как выстроить свою работу.
Процесс ради процессов
Моя любимая ошибка, когда мы начинаем внедрять процессы везде — по каждому чиху, по каждому поводу процесс. Нужно учитывать контекст и проблему, которые решаем, а не просто создавать видимость деятельности.
Игнорирование человеческого фактора
Тоже реальный пример. В компании, где я работал, была проблема между фронтендером и бэкендером. «Эффективные» менеджеры нашли техническое решение: чтобы свести их, предложили ввести в Jira 15 обязательных полей, которые ребята будут заполнять каждый на своем уровне. И ещё обязательно 30-минутные ежедневные синки. Позже эту практику предложили распространить на всю производственную группу. В итоге начали страдать все команды — по два часа в день уходило на бессмысленную и ненужную работу. При этом проблема между фронтендером и бэкендером никуда не делась.
Такие вопросы нужно решать в другом ключе. Это вообще межличностный конфликт — нужно выбирать медиатора и пытаться между сторонами проблему решить. Не используйте технические решения для проблем, которые решаются другими способами.
Нет владельца
Мы часто забываем, что если кто‑то предложил процесс, то обязательно должен быть его хранитель. Нет хранителя — не идите в процесс, не тратьте на это время.
Слепое копирование процессов
Например, мы видим практику у Google, Яндекса, Сбера и перенимаем её. Мой любимый пример — это модель Spotify с трайбами и складами, которую в конце 2010-го практически все компании в мире хотели переиспользовать у себя. Но мало кто знает, что в 2020 году сам Spotify признал, что их модель никогда не работала в чистом виде. А всё почему? Потому что такие модели нельзя копировать. Их нужно адаптировать под свою работу. Это ещё один способ убить мотивацию команды, когда мы просто перенимаем практики, которые хорошо работают в одном месте, а в другом месте не работают.
Метрики ради метрик: начинаем измерять процессы по непонятным критериям
У нас были проблемы в релизном цикле. Что мы сделали? Внедрили чек‑бокс, который нужно заполнить, и метрикой процесса взяли, что все 20 пунктов этого чек‑бокса должны быть заполнены. Метрика не отражает решение — мы не знаем, ушла ли проблема, но зато у нас все команды начали классно отчитываться с точки зрения выполнения этого процесса.
Наше решение
Помните, что принцип «Докажи, что нужно» — это бремя ответственности того, кто хочет предложить его.
Расскажу, как сейчас у нас в Garage Eight построена работа. Мы быстро растём, увеличивается число сотрудников и подразделений. Примерно год назад на одного сотрудника приходились куча изменений и процессов. Мы собрались вместе с лидами команд и предложили простое решение. Открыли Excel, выписали все процессы подряд. Рядом с процессом описали, какую проблему он решает, на что он нанимался, какую задачу делает, поставили метрику процесса и указали владельца. Причём часть процессов были без владельца — потенциально мы должны их убрать. Начали дальше раскапывать, и неактуальные процессы официально выводили. Кроме того, мы туда добавили участников процесса и сделали этот файл открытым.
Что это дало? Мне, как руководителю, стало проще в целом управлять операционной нагрузкой. Я вижу реальную картину и понимаю, где мы неэффективны. Для сотрудника это тоже полезно — он открывает этот файл, выбирает по фильтрам свою фамилию и видит, когда и какие задачи на него будут падать. Это позволяет управлять своей нагрузкой и давать нам обратную связь, что мы делаем какую‑то несуразицу. А Scrum‑мастерам это в целом помогает выстраивать нашу культуру эффективности. Мы регулярно с этим файликом каждый квартал работаем для того, чтобы актуализировать его.
Это одно из решений, которое вы можете перенять очень эффективно и быстро. Буквально 2−3 часа мы потратили на эту историю.
Заключение
Помните, что процесс — это не самоцель. Он помогает. Пока помогает — живет, перестал помогать — должен уйти.
Лучший процесс тот, которому следуешь, не задумываясь.
Я всех призываю оглянуться вокруг на своём рабочем месте: какие процессы и ритуалы вас окружают? Помогают ли они? Если да — хорошо, если нет — наберитесь смелости, попробуйте либо изменить, либо отменить ненужные процессы. Ведь вы управляете своей работой, а не работа управляет вами. Вы настраиваете контекст, в котором вам будет комфортно работать.
А узнать ещё больше полезного вы сможете на Saint TeamLead 2026! В этом году «Онтико» кардинально меняет подход к IT‑мероприятиям. В частности, SHL пройдёт в этом году в формате конференции развития. Она станет инструментом решения задач, а не потребления контента; практикумом, а не лекциями.
Новая программа режиссируется с учётом пути участника и состоит не только из докладов, но и из стримов развития, фасилитируемого нетворкинга, интерактивных и игровых форматов. Подробнее — на официальном сайте. Ждём тебя!