Признак №1: Ваш рабочий день длится 10-14 часов, но бизнес не растёт

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

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

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

Признак №2: Вы не можете уехать в отпуск даже на неделю

Последний раз вы были в отпуске... когда? Три года назад? Пять лет назад? И то провели его с ноутбуком, отвечая на сообщения и проводя созвоны. Вы боитесь отключить телефон даже на день, потому что "всё развалится без меня".

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

• Что происходит дальше: Ваше здоровье сдаёт. Сначала это хроническая усталость. Потом - бессонница, головные боли, проблемы с давлением. Врач говорит: "Ещё год в таком темпе - и инфаркт". Но вы не можете остановиться, потому что "дело не ждёт".

Признак №3: Каждая делегированная задача возвращается к вам

Вы пытались делегировать. Честно пытались. Отдали задачу сотруднику - он сделал не так. Исправили. Отдали снова - опять мимо. В итоге проще сделать самому за 2 часа, чем объяснять и переделывать.

• Истинные причины:

  • Перфекционизм: "Никто не сделает так хорошо, как я". Ваши стандарты настолько высоки, что соответствовать им может только вы сам - в идеальный день, после трёх чашек кофе.

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

  • Страх потерять контроль: Что если сотрудник испортит отношения с важным клиентом? Что если допустит ошибку на миллион? Страх парализует сильнее, чем любая реальная угроза.

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

Признак №4: У вас нет времени на семью, здоровье и себя

Партнёр говорит: "Ты выбираешь между мной и бизнесом". Дети спрашивают: "Пап, а когда ты поиграешь со мной?" - и вы отвечаете "завтра" уже третий месяц подряд. Друзья перестали звать, потому что вы всё равно откажетесь или отмените в последний момент.

• Статистика безжалостна: Отсутствие границ между работой и личной жизнью - одна из главных причин выгорания. Компании экономят, перераспределяя обязанности на оставшихся сотрудников, что приводит к хроническому переутомлению. Для предпринимателя это ещё критичнее - он сам себе перераспределяет ВСЁ.

• Во что это превращается:

  • Вы забыли, когда последний раз были в спортзале

  • Питаетесь на бегу - кофе, сэндвич, кофе, доставка в офис

  • Спите 5-6 часов, просыпаетесь разбитым

  • Секс? Хобби? Путешествия? Всё это "когда-нибудь потом"

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

Признак №5: Вы микроменеджите всё и всех

Вы контролируете каждую запятую в коммерческом предложении. Проверяете каждый счёт перед отправкой. Читаете всю переписку с клиентами. Утверждаете дизайн каждого поста в соцсетях.

• Что на самом деле происходит: Микроменеджмент - это не забота о качестве. Это страх и недоверие. Страх, что без вашего контроля всё рухнет. Недоверие к способностям команды. И знаете что? Вы сами создаёте эту реальность.

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

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

Признак №6: Вы потеряли радость от работы

Помните, как всё начиналось? Горящие глаза, энтузиазм, драйв. Каждый новый клиент был победой. Каждая сделка - праздником. А теперь? Открываете утром ноутбук с чувством тоски. Работа превратилась в рутину, в обязанность, в бремя.

Это классическое выгорание достигатора. По данным 2025 года, около трети россиян страдают от профессионального выгорания, причём более 35% из них не нашли решения за пять лет. Выгорание становится скрытой эпидемией на рынке труда. Особенно в IT-секторе, маркетинге, PR - там, где более 60% работников сталкиваются с чрезмерной нагрузкой и хроническим стрессом.

• Признаки выгорания:

  • Эмоциональное истощение - вы чувствуете себя опустошённым

  • Цинизм и отстранённость - клиенты раздражают, сотрудники бесят

  • Снижение продуктивности - делаете в два раза медленнее, чем раньше

  • Потеря смысла - каждое утро спрашиваете себя "Зачем?"

Выгорание - это не слабость, а системный сбой в управлении. Не вы виноваты - виновата система, которую вы построили (или не построили).

Признак №7: Бизнес зависит от вас на 100%

Самый страшный вопрос: "Что будет с бизнесом, если с вами что-то случится?" И вы не знаете ответа. Потому что без вас бизнес остановится через неделю, максимум через две.

• Это не бизнес. Это самозанятость с сотрудниками. Настоящий бизнес - это система, которая работает без владельца. Макдональдс работает без Рэя Крока. Apple работает без Стива Джобса. А ваша компания не проживёт без вас и месяца.

• Диагностика на честность:

  • Можете ли вы не появляться в бизнесе неделю, и всё будет работать?

  • Знают ли сотрудники, что делать в критических ситуациях без вас?

  • Есть ли у вас описанные процессы и регламенты?

  • Может ли кто-то заменить вас хотя бы на 50%?

Если на большинство вопросов ответ "нет" - вы не владелец бизнеса. Вы самый незаменимый (и самый измотанный) сотрудник.

Цена бездействия: что будет через 5 лет

Давайте честно. Если ничего не изменится, что произойдёт через год? Через три? Через пять?

• Сценарий №1: Выгорание и крах
  Организм не выдерживает темпа. Сначала тревожные звоночки - панические атаки, бессонница, депрессия. Потом серьёзные диагнозы - инфаркт, инсульт, диабет. Исследования показывают: каждый второй, кто столкнулся с выгоранием, в итоге увольняется. Для предпринимателя это означает - закрывает бизнес.

• Сценарий №2: Потеря семьи
  Партнёр устал ждать. Дети выросли, но вас не было рядом в важные моменты. Развод. Алименты. Чувство вины, которое не купишь ни за какие деньги. Вы построили успешный бизнес и разрушили всё, что действительно важно.

• Сценарий №3: Застой и деградация
  Пять лет одна и та же выручка. Конкуренты обогнали. Рынок изменился. Вы устарели. Бизнес превратился в жалкое подобие того, чем мог бы стать. Вы работаете в два раза больше за половину возможного результата.

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

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

Хорошая новость: из этой ловушки есть выход. Плохая новость: выход требует работы на трёх уровнях одновременно.

• Уровень 1: Стратегический (Бизнес-трекинг)
  Нужен внешний взгляд - трекер, который поможет найти точки роста, выстроить систему, создать процессы. Кто-то, кто задаст правильные вопросы и поможет увидеть лес за деревьями.

• Уровень 2: Операционный (Бизнес-коучинг)
  Нужно научиться делегировать, выстроить команду, создать управленческую систему. Коуч поможет преодолеть внутренние барьеры и развить навыки, которых не хватает.

• Уровень 3: Психологический (EMDR-терапия)
  Нужно проработать глубинные страхи, токсичный перфекционизм, установки из детства. EMDR-терапия помогает за 6-8 сессий переработать травматические убеждения "я недостоин", "всё должно быть идеально", "никому нельзя доверять".

Первый шаг к свободе

2026 год станет определяющим для компаний и предпринимателей в плане выстраивания грамотной стратегии против выгорания. Только изменив подход к работе, бизнес сможет справиться с этим вызовом. Выгорание - это не слабость, а системный сбой в управлении.

ЧТО УЗНАЕТЕ:

👉этапы, построения работающей воронки

👉ошибки, которые влияют на конверсию воронки

👉с чего начать и чем закончить -разложили всё по полочкам

До 23.05 доступны АУДИОРАЗБОРЫ, чтобы ещё круче разобраться в системных продажах🔥

👉ОТ ВАС:

-в тексте или голосом обозначьте свою самую актуальную задачу

-скиньте ссылку на свой тг/инсту/чат бот и тд (что есть)

👉ОТ МЕНЯ - разбор в голосовых, где вы получите:

-что можно улучшить в проекте уже сейчас

-на что обратить внимание, чтобы повысить продажи

-триггерные действие, которое увеличит/запустит продажи

Круто?

Круто😎

ссыль на тг канал в профиле

Данный прием я продолжаю использовать и внутри IT, изучая разные части проектов и направлений. Например, коммуницируя с инженерами SRE и DevOps (такие ребята, которые делают так, чтобы разрабатываемая система была стабильна, а ее новые версии поставлялись быстро и исправно), я подчеркнул для себя, как можно организовать управление инцидентами в исполнении рабочих процессов, хотя изначально эта штука была направлена на управление стабильностью систем строго в рамках DevOps/SRE, но она просто крайне универсальна.

Или другой пример, в рамках разных секторов рынка IT - если ты набрал опыта по игрострою, то ты можешь использовать такие приемы, как «геймификация» в продуктах, не являющихся играми (вспомните Duolingo - штука для обучения, но цикл ее использования построен как игра).

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

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

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

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

Но мы рассмотрим еще более простой способ - это искать вдохновение, новые идеи и концепции совсем не в IT, но при этом подходящие под применение в IT, на стороне, как, например, делал Алан Кэй, один из разработчиков концепции ООП (объектно-ориентированное программирование), который вдохновлялся клеточной биологией, перенося поведение клеток на объекты в программировании, и при этом у него не было образования биолога - это было просто ему интересно.

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

Про наше масштабирование

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

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

Это, конечно, типовая проблема ("стартапы vs корпорации и проблема того, как одному перерасти в другое"), но есть хоть и эмпирическое, но четкое ощущение того, что у нас эта проблема выражена значительно сильнее.

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

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

В-третьих, специфика самого IT такова, что забуксовка на этапе стартапа в виде отсутствия роста компании не является тем, что ее уничтожит быстро и однозначно - у вас команда в 10 человек, 1 продукт в линейке, рост прекратился уже давно и риски потерять рынок все ближе, но вы все еще зарабатываете миллионы, хоть и стоите на месте.

Пример кривого масштабирования

Для конкретики давайте рассмотрим известный мне случай:

Условная фирма «Есть кибертемка». Условные 8 программистов под прямым управлением Овнера (owner, владелец компании) за пару лет создают на костылях продукт (что нормально для выхода на рынок), который выстреливает и очень быстро завоевывает часть аудитории, подтверждает гипотезы и обеспечивает первый поток прибыли. Точно ясно - надо точно копать дальше, дело стоящее.

Дальше стоят две задачи - обеспечить дальнейший рост, чтобы получить больше клиентов (соответственно, оставить меньше конкурентам, которые уже начали делать аналог и дышат в затылок) и, главное, заранее обеспечить конкурентное преимущество продукта - чтобы он работал стабильно (мы ведь помним, что первая версия была сделана на костылях, которое имеет технические ограничения?), имел много фич и просто не давал шанса конкурентам догнать продукт, когда их аналоги будут готовы.

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

Овнер - крайне крутой мужик, который умеет в выход на рынок, знает и потребности клиентов, и может руководить небольшой командой просто на скиллах операционного контроля, но программистов уже 60, а скоростным методом поставленных замов уже под 10 человек, а скорость разработки все падает, падает, а фич, которые нужно было выпустить уже вчера, уже не сосчитать.

И при этом из изначальных 8 программистов ушли 4, 1 ушел к конкуренту, 1 судится за авторство идеи и оставшиеся 2 борются за то, кто будет тимлидом, подставляя друг друга и не успевая рассказывать новым программистам, как этот код вообще был написан.

Потому что управление бизнесом, финансами, командой и проектами - это абсолютно разные вещи, разные направления и особенно - на разной глубине применения.

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

В данном случае основной орган управления в команде, когда она была из 8 программистов, - это ежедневные летучки на 15-20 минут, где Овнер давал новые задачи и получал отчеты о старых, сразу получал информацию о проблемах и разрешал их «на месте». Все слажено, все просто, все понятно.

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

Проектная модель и роли

Что пошло не так?

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

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

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

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

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

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

Для этого, собственно, и есть куча описанных проектных моделей в прожект-менеджменте.

А при чем тут дрожжи?

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

Но есть вещи, которым нельзя обучить, их можно только впитать - это ценности и культура.

Ценности соучастия, являющиеся фактором облегчения развития и внедрения процессов как фактора выживаемости компании, или понимание продуктовой ценности и взаимосвязи между положением компании на рынке и объемом личной зарплаты.

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

Нельзя написать список из пунктов «1. Будь честным. 2. Будь соучастным. 3. Будь крутым» и надеяться, что после прочтения данной инструкции человек станет честным, соучастным и крутым - это просто так не работает, а вот кринжа вызовет достаточно, если кто натыкался на такое.

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

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

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

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

На решение меня подтолкнуло то, как устроено производство сыра среди ремесленного бизнеса.

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

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

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

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

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

Выводы

Думаю, читателю уже очевидно, к чему я вел.

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

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

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

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

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

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

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

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

Через время убирайте арбитражное управление и подсоединяйте команду к общему органу управления, чтобы этого у вас не было — команды должны быть равными и иметь прямые линии управления из одной точки.

Поздравляю, у вас две команды.

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

Тем более, что касается скорости масштабирования — как правильно, это не история того, что масштабирование шло медленно, это история того, что масштабирование **было начато поздно**, а все остальные негативные случаи — это как раз то, когда масштабирование происходило слишком быстро, и команда просто не успевала адаптироваться.

Можно делать медленнее, последовательно, через зиро-команду, если этот процесс налажен и дает нужные результаты. Более медленную историю интеграции процессов проще контролировать.

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