Я — Антон Марунько, руководитель в продуктовых компаниях уже более шести лет, помогаю строить и обучать команды в сфере IT.

Давайте начнём с простого вопроса. Как вы думаете, сколько мелких ошибок нужно, чтобы сложная система рухнула? 10? 100? или 1 — но в очень нужном месте?

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

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

Давайте же разберем, что такое прирожденная простота подробнее. 

Прирожденная простота — это идея о том, что в любой системе есть всего несколько факторов, которые реально определяют ее поведение.

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

Где-то в центре всей путаницы есть:

• одна точка,

• один человек,

• один процесс,

• один шаг,

который и определяет поведение всей системы.

С этого момента управление перестаёт быть магией.

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

Кейс 1. Нужно ли делегировать?

Если ты об этом думаешь, то да, нужно! Если вы сомневаетесь, делегировать ли задачу, в большинстве случаев её стоит делегировать. Почему?

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

И оно даёт сразу несколько эффектов:

• развивает людей,

• растит доверие,

• освобождает ваше внимание,

• позволяет вам заниматься тем, что действительно важно прямо сейчас.

Кейс 2. Масштабирование: где и зачем

Масштабирование почти всегда начинают неправильно.

Обычно его начинают там, где:

• проще,

• быстрее,

• красивее,

• или понятнее на цифрах.

Но масштабироваться имеет смысл сначала в узком месте или в бутылочном горлышке. Бутылочное горлышко — это самое узкое место в системе, которое ограничивает скорость работы всего остального.

Если вы увеличиваете всё, кроме бутылочного горлышка, система не вырастет.

Она просто перегреется. Бутылочное горлышко определяет максимум того, сколько система вообще может произвести. 

Пока оно не расширено:

• всё, что вы усиливаете вокруг, будет простаивать,

• ресурсы будут тратиться впустую,

• рост будет выглядеть как хаос, а не как прогресс.

Можно нанять больше людей, купить больше оборудования, ускорить процессы — но всё это упрётся в одно место и остановится там.

Поэтому логика простая:

Сначала увеличиваешь то, что ограничивает весь поток. Потом — всё остальное. Именно так рост становится перевариваемым, а не разрушительным.

Пример: IT-команда и один этап релиза

Есть продуктовая IT-команда. Продукт растёт, пользователей становится больше, задач — всё больше. Руководство решает: надо масштабироваться.

Что делают:

• нанимают ещё разработчиков,

• увеличивают backlog задач,

• ускоряют дизайн,

• заводят больше фич в работу одновременно.

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

Что происходит после масштабирования:

• разработчики пишут код быстрее,

• задач «готово» становится больше,

• очередь на релиз растёт,

• фичи неделями лежат «почти готовые»,

• баги копятся,

• бизнес не видит эффекта,

• люди злятся: «Мы же работаем больше!»

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

Как выглядит правильное масштабирование

1. Сначала честно признать: узкое место — релиз / проверка / финальное согласование.

2. Масштабироваться именно там:

• автоматизировать проверки,

• убрать ручные шаги,

• распределить ответственность,

• сократить согласования,

• уменьшить размер поставок (меньше, но чаще).

3. И только после этого:

• нанимать разработчиков,

• брать больше задач,

• ускоряться.

Если ты ускоряешь всё до бутылочного горлышка, ты создаёшь очередь. Если ты ускоряешь бутылочное горлышко — ты создаёшь рост.

Кейс 3. Как мотивировать команду?

Для начала, стоит отметить, что мы работаем с людьми, которые НЕ ВЫЖИВАЮТ. У них базово закрыты потребности, вы платите им рыночную зарплату, которой достаточно, чтобы не сводить концы с концами.

Чтобы мотивировать людей, объясни людям, зачем они работают. Покажи им. Приведи на производство, дай цифры, покажи влияние и вложение команды. 

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

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

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

Как же с этим жить в реальности

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

Если обобщить, принцип очень простой:

1. Формулируй простой тезис.

2. Ставь его под сомнение.

3. Исследуй дальше.

4. Пока не дойдёшь до 1–2 коренных причин.

И избегай замкнутых кругов.

Пример замкнутого круга

Мы не успеваем → нужно точнее планировать → добавляем отчёты → тратим больше времени → ещё сильнее не успеваем. Прирождённая простота — это не про то, что всё легко. И не про то, что сложных систем не существует.  Она про другое.

Про то, что в любой момент времени система упирается в очень конкретное место. И именно оно определяет:

• скорость,

• результат,

• ощущение хаоса или порядка.

Пока мы пытаемся улучшать всё сразу, мы распыляем внимание, усилия и ответственность. Мы создаём активность, но не создаём прогресс. Настоящее управление начинается там, где появляется фокус. Фокус — это честно ответить себе:

• где сейчас узкое место,

• что именно через него не проходит,

• и почему.

И дальше действовать предельно просто:

• улучшить это место,

• проверить, сместилось ли ограничение,

• повторить.

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

Заключение

Пока мы пытаемся улучшить всё сразу, мы создаём активность, но не прогресс. Настоящее управление начинается с фокуса: найти настоящее ограничение и понять, как его улучшить/расширить/изменить. Когда внимание сосредоточено на одном ограничении, решения становятся простыми, ясными и выполнимыми — а сложность перестаёт управлять нами.

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