Большому кораблю — большие проблемы, или куда уходит эффективность компаний

Вводная статья серии о скрытых издержках роста

По моим наблюдениям, у любой растущей IT-компании есть момент, когда она начинает работать тяжелее, чем должна.

Это не какой-то конкретный квартал или событие, не точка, в которой всё пошло не так. Нет события, которое разделило бы всё на «до» и «после». Просто в какой-то момент проблема стала очевидной.

Однажды основатель или кто-то из C-level команды приходит на работу и видит: всё вроде бы хорошо. Людей много, решений ещё больше, процессов накручено прилично, метрики есть на всё, что движется (а что не двигалось уже давно расшевелили). Вот только ощущение управляемости куда-то испарилось, хотя вроде бы раньше оно было. Да и скорость явно ниже, чем была, когда в команде сидело пятнадцать человек и все кричали друг другу через стол.

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

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

Всё, что написано дальше — моё видение ситуации, а не истина в последней инстанции. Если видите иначе, буду рад подискутировать в комментариях.

С ростом компания начинает платить налоги. Я не о тех, что государству. С этими налогами как раз прекрасно справляется бухгалтерия. Я о других. Корпоративных. Поддержка внутренней системы начинает требовать оплаты нематериальным образом: временем, вниманием, способностью договариваться, удержанием контекста. И самое неприятное свойство этих налогов в том, что они возникают не из-за чьих-то ошибок, а из-за решений, которые в моменте были абсолютно правильными.

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

Именно об этом и пойдёт речь в этом цикле. А в этой статье разберём:

Разбирать всё это на абстракциях очень скучно, поэтому я возьму одну вымышленную компанию. Почему вымышленную? Объясню сразу.

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

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

Licipan Nestworks — продуктовая IT-компания. Она строит облачную платформу для управления всем жизненным циклом гнездовых самолётов: от регистрации семени до мониторинга полёта в реальном времени. Внутри — полный джентльменский набор: команды, интеграции, конфиг-хранилища, адаптеры для систем клиентов с разной степенью технической зрелости. Снаружи — несколько десятков B2B-заказчиков и собственное легаси, которое надо уважать, даже когда очень не хочется.

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

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

Прежде чем продолжить повествование, я должен сделать небольшое отступление о природе решений. Без него всё дальнейшее будет выглядеть как... Да не важно, как оно будет выглядеть, просто чтобы говорить с читателем на одном языке, нужно определить базу. И этим мы сейчас и займемся.

Компания — это, конечно, система, но решения в ней принимают люди. А у человеческого мышления есть баги. Причём не случайные ошибки, а вполне предсказуемые и воспроизводимые. Давайте разберёмся, как они появляются.

У нашего мозга есть два принципиально разных режима работы. Это не метафора. Разные научные школы пришли к этому выводу независимо, просто каждая со своим словарём: нейробиологи говорят про рептильный мозг и префронтальную кору, психологи (последователи Фрейда) — про сознательное и бессознательное, поведенческие экономисты — про быстрые и медленные системы принятия решений. Названия разные, суть одна:

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

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

А компании, как правило, живут чуточку дольше: лет так от ста, при хорошем раскладе.

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

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

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

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

Но план — это не просто договорённость. Это ещё и обязательство перед системой. Соседние команды строят свои планы, опираясь на ваш. Интеграции привязываются к срокам. Клиенты ждут релиза в конкретную дату.

И вот в какой-то момент оказывается, что «подвинуть задачу» — это уже не просто сказать «я не успеваю, сделаю в четверг», а изменение, которое нужно согласовать с системой. Не потому, что кто-то специально всё усложнил, а потому, что система стала связанной.

Чтобы не допускать дорогих отклонений, планы начинают строить детальнее. С большим числом зависимостей. Что делает их менее гибкими. И, что ещё важнее, — менее точными. (звучит парадоксально, но это математика: каждая оценка — это вероятность, а вероятности при сложении подчиняются своим законам)

Что мы имеем?

Вот вам и петля, которая усиливает саму себя.

Посмотрим на еще один пример из жизни Nestworks.

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

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

Акт второй. Проходит год. Алиса — единственный человек в компании, кто понимает модуль совместимости. Не потому, что она присвоила знание, а потому, что система сама отучила всех остальных в него погружаться. Когда Алиса в отпуске — модуль лучше не трогать. Когда она говорит «это делать нельзя» — никто не может возразить. Да и не хочет, если честно.

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

Акт третий. Руководство замечает: компания зависит от конкретных людей, это риск. Автоматический режим снова узнаёт паттерн: «риск — нужно митигировать». Появляются регламенты, чтобы переложить знания на бумагу, и снизить пресловутый гнездо фактор (bus factor на нашем). Архитектурные решения должны документироваться. Создаются шаблоны, вводятся процедуры согласования. Месяц-два всё идёт хорошо, люди начинают больше понимать в том, как им строить работу.

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

Что мы имеем?

Ещё одна петля. И заметьте, ни на одном шаге никто не ошибался. Система деградирует не потому, что люди принимают плохие решения, а потому, что хорошие решения имеют скрытую цену, и цена эта отложена во времени.

Вот ещё одна петля, но она запускается не из-за сложности, а из-за роста ставок.

Представьте: вам надо бросить монетку. Орёл дает вам гарантированный доход 10 миллионов долларов в месяц до конца жизни. Решка — ампутация конечностей без наркоза и какого-либо ожидания.

У вас нет выбора «делать или не делать» — от вас это не зависит. Вопрос простой: насколько быстро вы решитесь сделать бросок?

Именно это происходит с компанией по мере роста. Гнездовые самолёты Nestworks начинают использоваться в реальных операционных процессах клиентов. Ошибка — это уже не «поправили и забыли», а остановленный конвейер, штраф и репутационный удар. Цена решки сильно выросла. Есть хорошая фраза на эту тему:

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

Контроль реально снижает риск. Но у него есть цена, которая проявляется чуть позже.

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

Что мы имеем?

И опять: ни на одном шаге нет ошибки. Есть только монетка с очень высокими ставками, и совершенно понятное нежелание бросать её быстро.

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

Продакшн. Гнездовой самолёт крупного клиента теряет управление в воздухе. Четыре часа простоя. Инцидент уровня «срочно всем на мостик».

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

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

Это не все проявления, но думаю, общий механизм понятен.

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

Важно понимать: все эти налоги — не ошибки. Это неизбежная цена нормального развития — только выставляется она без счёта и без предупреждения. Именно поэтому их так сложно заметить и ещё сложнее признать.

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

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

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

Если упростить этот текст до одной мысли:

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

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

Продолжение следует.