В компаниях часто ищут агента изменений: «сильного менеджера», который возьмёт весь хаос на себя и решит проблемы, накопленные годами. Но когда менеджер выходит на работу, оказывается, что нет ни целей, ни ответственности, ни бюджета. Зато слышит фразу: «Мы тебя наняли — ты и решай». Вместо изменений менеджер тушит пожары, берёт на себя чужие задачи и пытается доказать, что перемены вообще нужны. В итоге его увольняют за то, что тот «не оправдал ожиданий», а ситуация в компании остаётся прежней.

Меня зовут Степан Сорокин, я Delivery-менеджер в Outlines Tech и руководитель проектов с опытом более 10 лет. Запускал процессы в стартапах и корпорациях. Почти в каждом проекте сталкивался с одной и той же проблемой: компания хочет внедрить Agile или другую методологию, но не готова действительно менять процессы и вкладывать в это ресурсы. От менеджера ждут, что он изменит всё сам, без поддержки сверху.

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

Как выглядит работа, когда в компании ждут волшебника

В компаниях часто мечтают, что придёт «сильный менеджер» и всё наладится. Он внедрит Agile, расставит задачи, выстроит процессы и команда начнёт стабильно выполнять планы. При этом руководство не хочет вникать в детали. Им нужен агент изменений, который «возьмёт хаос на себя», желательно без затрат и без их участия. На встречах говорят: «Вас наняли, вы и решайте». При этом они ждут быстрых результатов, а в любой неудаче винят менеджера. 

Вот как это обычно выглядит:

Руководство не формулирует задачи. Менеджера нанимают «наладить процессы», но не объясняют, что именно не работает. Нет целей, зоны ответственности, KPI. Непонятно, на какой результат компания рассчитывает, кто принимает решения и как будет измеряться прогресс. Менеджер тратит время на выяснение базовых вещей, но по факту работает вслепую.

Изменения идут снизу вверх. Это когда руководство нанимает менеджера и даёт ему задачу: «Наладь процессы как-нибудь сам». Ему не дают административного ресурса на изменения и не представляют его как человека, которого надо слушать. Из-за этого он не может достучаться до людей, поменять правила и внедрять новые подходы. Команда не понимает, зачем это нужно: никто сверху не объяснил пользу. В итоге все продолжают работать как раньше, менеджер остаётся один и не может улучшать процессы, потому что у него нет полномочий и поддержки.

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

Начальство хочет изменений, но не закладывает на это бюджет. Например, отказывается привлекать внешнюю команду, когда текущая не справляется с объёмом. Или не готова платить за нужный для ускорения работы софт. На любые предложения отвечают: «Давай без затрат, у нас бюджет уже свёрстан». В итоге сроки срываются, команда работает на износ и выгорает, а менеджер остаётся крайним.

Я устроился в ИТ-компанию, где надо было внедрять процессы, связанные с масштабированием. Руководство хотело внедрить фреймворки (SAFe), но никто не понимал, зачем они нужны и как работают. Все надеялись, что я решу проблему заклинанием — без ресурсов, без поддержки и без чёткого запроса.

Я принёс технико-экономическое обоснование, показал, что сколько стоит. На это я получил от фаундера такой вопрос: «Слушай, Степан, а мы можем сейчас нанять команду ровно на один месяц? За это время они как-то быстренько все наши проблемы решат, а мы потом как маленькая, быстроходная яхта под лёгким парусом, поплывём в стабильное, финансовое будущее с небольшой смелой командой матросов из пяти человек?». После этого я понял, что сработаться здесь не получится и ушёл через месяц после трудоустройства.

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

Инструменты, которые помогают изменить процессы

Разберу три подхода, которые помогали мне запускать изменения: аудит, приоритет и OKR.

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

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

В одном проекте аудит показал, что команда каждую неделю тратит десятки часов на ручную подготовку технических заданий. Это не считалось проблемой, пока я не посчитали затраты. Я подготовил ТЭО и после этого мне стало проще обосновать автоматизацию и привлечь нужных специалистов. В результате компания сэкономила больше $100 000, а я после этого успешно провёл финансовое планирование проекта с бюджетом в $17 млн.

2. Расстановка приоритетов: люди → процесс → инструменты.

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

Объясню метафорой. У нас 50 соток, куда нужно посадить картошку. Вроде всё просто: взяли лопаты и вперёд. Но если собрать людей и выдать им инструмент без плана и мотивации — поле никто не вспашет, а инвентарь останется в сарае. Сначала стоит договориться: кто копает, зачем это нужно, какая выгода. Потом обсудить, когда сажаем, как ухаживаем, кто собирает урожай. И только после этого можно идти закупать инвентарь. Причём не абы какой, может, вообще не лопаты нужны, а трактор.

Так и в работе. Меня позвали автоматизировать работу команды. Руководство сразу попросило подобрать подходящий инструмент, не разбираясь в текущем процессе. Но команда не понимала, зачем всё это нужно, и была не готова к изменениям.

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

3. Внедрение целей и ключевых результатов (OKR). Это инструмент, с помощью которого команда формулирует, что стоит улучшить, и по каким признакам измерить результат. Для этого ставят цель и записывают 2–3 измеримых результата. 

Пример, как выглядит сформированные OKR

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

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

Как обозначить границы своей ответственности и не утонуть в чужих задачах

Если в компании не проговорить роли заранее, менеджеру могут навесить всё подряд. Он и задачи поставит, и договоры согласует, и с клиентами пообщается, и на митингах вместо всех поучаствует. Руководители это объясняют просто: «Ты же хорош в коммуникации, справишься».

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

Я столкнулся с непониманием: руководитель считал, что раз у меня «сильные софтскиллы», то могу потянуть общение с клиентами и коммерческую часть. А я рассчитывал заняться именно технической стороной проекта. Начальник сам до конца не понимал, что входит в мою зону ответственности и мы быстро разошлись.

Чтобы определить границы, я делаю матрицу ответственности (RACIS). Это простая таблица в Excel, где я по каждому направлению указываю, кто за что отвечает. 

В матрицу входит пять типов ответственности:

• R (Responsible): исполнитель задачи.

• A (Accountable): ответственный за результат.

• C (Consulted): консультант по задаче.

• I (Informed): информированный участник, которого важно держать в курсе событий.

• S (Support): помощник.

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

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

Скачать шаблоны матрицы и таблицы для распределения задач — можно тут.

Как на этапе собеседования понять, что руководству нужны изменения, а не «человек-оркестр»

Самый надёжный способ договориться — обсудить всё до того, как вышел в компанию. Я больше не надеюсь на ответы в духе «разберёмся по ходу дела», а сразу пытаюсь понять: мне тут дадут рулить или просто бросят на амбразуру. Ниже — вопросы, которые я рекомендую задавать на собеседовании. Они помогут сразу вычислить компании, которые верят в волшебство, а не факты.

Если хотя бы на один из этих вопросов нет чёткого ответа — ясности у вас не будет. Например, если бюджет не закладывается на изменения и всё «должно само случиться», готовьтесь к постоянной нехватке ресурсов. А если на вопрос: «Из чего будет состоять мой рабочий день?» вам не могут ответить — значит, зону ответственности ещё даже не пытались сформулировать.

Может звучать банально, но лучше узнать все детали до выхода на работу, чем через три недели, когда на вас уже повесили пять чужих задач. Но если вас устраивает роль «всё в одном» — вопросы можно не задавать. Только потом не стоит удивляться, что вы отвечаете за всё, но не управляете ничем. 

Коротко о главном

• Убедитесь на собеседовании, что изменения действительно нужны компании. Иначе вместо выстраивания процессов придётся выполнять чужие задачи без права влиять на результат.

• Согласуйте матрицу ответственности с руководством, чтобы не превратиться в «человека-оркестра».

• Используйте аудит процессов и технико-экономическое обоснование. Когда у вас есть цифры и факты, проще убедить топ-менеджмент и получить поддержку.

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

• Используйте OKR как инструмент вовлечения, а не контроля.

Чек-лист аудита процессов и пример ТЭО — тут.
Шаблоны матрицы ответственности и таблицы для распределения задач — тут.

Поделитесь в комментариях, какие вопросы вы задаёте на собеседовании, чтобы понять, есть ли у компании реальный запрос на изменения?