Меня зовут Сергей, и в Домклик я отвечаю за операционное управление в IT. 

Взросление компании существенно отличается от взросления человека. Одно из различий заключается в росте бюрократии.

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

Эта история о том, как выжить и остаться собой, когда ваша компания из гаража превращается в серьёзный бизнес.

Акт первый: раньше было лучше

Помните то время, когда можно было в три часа ночи, поймав внезапное озарение, быстро добавить опцию, которую утром обсуждали в курилке; когда падение сервиса было не катастрофой, а поводом сказать: «Сейчас быстро починю» — ведь пользователей всего пятеро, и те — коллеги; когда не было Agile, спринтов и «Программ и методик испытания релиза». Было лишь желание сделать что-то крутое.

А теперь откройте Jira (или его аналог). Чтобы исправить опечатку, нужно пять согласований. PR может висеть три дня, потому что тимлид в отпуске. А после каждого сбоя базы данных вас заставляют заполнять «постинцидентный разбор». Где же мы свернули не туда, позволив себе потерять это золотое время?

Ответ прост и циничен: мы выжили.

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

Хотели ли руководители и те, кто внедрял эти процессы, такого исхода? По моему опыту, нет. Это чистый инстинкт самосохранения.

Акт второй: первые звоночки

Сначала это были едва уловимые признаки: незначительные сбои (но «быстро поднятое упавшим не считается»), недовольные отзывы, на которые отвечали: «Пользователь не разобрался». Но этих сигналов становится больше. И в какой-то момент вашему тимлиду приходит мысль: «Нужно это как-то систематизировать…». Это происходит не в моменте, а, как в фильме «Начало» Кристофера Нолана - в голове поселяется Идея. С каждым отзывом, с каждой ошибкой эта Идея крепнет и набирает силу. 

А потом наступает Тот Самый День.

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

Команда впервые столкнулась с финансовыми потерями из-за технических сбоев. Это не абстрактные «баги», а реальные деньги, которые могли уйти к конкурентам.

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

В Confluence скромно обосновались первые страницы с инструкциями. Пока ещё робкие и несовершенные, они несли в себе обещание: «Такого больше не повторится».

Акт третий: между Сциллой и Харибдой

Можно выдохнуть: первые процессы заработали. Заинтересованные стороны спрашивают: «А что произошло? Почему клиенты теперь меньше страдают?»

Им рассказали про code review и тестовые стенды, и родилась простая, но элегантная формула: «процессы = стабильность». А раз так, то почему не добавить ещё процессов? И ещё? И ещё?

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

Знакомьтесь — Михаил, наш Одиссей. Пути появления таких специалистов в компаниях разные: кого-то нанимают специально для того, чтобы он занимался подобными задачами, кто-то появляется эволюционно, а иногда это просто самый громкий разработчик, который больше всех хочет что-то поменять. Так или иначе, Михаил внедрил первые процессы, и теперь заинтересованные лица требуют «больше контроля». Но вместо того, чтобы слепо подчиниться, он садится с ними и рисует на доске простую диаграмму: «Видишь эту кривую? Следующие 20% процессов дадут нам лишь 5% стабильности, но отнимут 40% скорости. Готовы ли вы заплатить такую цену?»

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

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

И что же происходит? Бизнес обретает стабильность. Разработчики сохраняют скорость. А Михаил получает заслуженное повышение, потому что отыскал тот самый Святой Грааль: баланс между контролем и свободой. Но как удержать это хрупкое равновесие, когда компания вырастет втрое, когда появятся новые продукты, новые команды, новые вызовы?

Акт четвертый: скрытая угроза

Знаете, какое заблуждение в управлении процессами является самым опасным? Думать, что вы защищены, настроив ревизию кода, автоматизировав развёртывание и внедрив инцидент-менеджмент. Михаил и его команда долго жили этой иллюзией. Пока снова не наступил Тот Самый День.

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

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

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

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

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

Масштаб. То, что работало на десять человек, не работает на 50. То, что спасало при 1 тысяче пользователей, губит при 100 тысячах. Каждый новый рост — это новая болезнь, требующая нового лекарства. 

Что же делать

На этом этапе развития выбор не так велик: адаптироваться или умереть.

Ваше развитие и рост вашей компании влекут за собой увеличение рисков, которыми приходится управлять: юридическими, кадровыми, финансовыми и многими другими. Что может убить нас завтра или через полгода? Где наши слабые места? Какие знания мы не зафиксировали? Как сохранить скорость разработки при постоянной оптимизации штата? Пока мы выстраиваем идеальную защиту от вчерашних угроз, завтрашние уже готовы посмеяться над нашими решениями.

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

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

Бюрократия? Она никуда не делась. Но теперь она работает как система фильтров: не мешает двигаться вперёд, но не даёт утонуть при первой же пробоине. 

Акт пятый, заключительный: как дальше жить

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

Мы всё ещё рассказываем счастливую историю, поэтому Михаил собрал команду и сказал: «Признаем честно: мы подменили цели средствами. Мы не управляем рисками, мы создали новую религию процессов. Пора вернуться к здравому смыслу». (Тут стоит вставить ремарку: для достижения этого этапа эволюции может потребоваться много лет, возможно даже десятилетий, поэтому не все доживут до момента, когда результат станет очевиден).

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

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

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

Главный урок, который усвоил Михаил: бюрократия подобна тени — чем больше вы от неë убегаете, тем быстрее она вас настигает. Но стоит повернуться к ней лицом, понять её природу, и она превращается из врага в союзника. Идеальный процесс — это тот, о котором никто не знает, но который работает.

Эпилог

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

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

P.S. Эта статья прошла ревизию пяти человек, написана по двум регламентам.