Home | Blog | Guide

Скрытые издержки операционных расходов стартапа

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

By Ellis Keane · 2026-04-02

16:47 в четверг, и ваш ведущий инженер только что разослал всем сообщение в канал Slack с вопросом: была ли когда-нибудь окончательно согласована спецификация API с понедельничной встречи? Потому что он три дня разрабатывал продукт, опираясь на предположения, и никто не сообщил ему, что руководитель по продукту изменила структуру payload во вторник днём в документе Notion, на который (с любовью говоря) не был подписан ни один человек. Руководитель по продукту, со своей стороны, была искренне убеждена, что упомянула об этом на стендапе. Скорее всего, действительно упомянула – но тот стендап был восемнадцать часов и сорок семь Slack-тредов тому назад, а инженер опоздал в то утро на пять минут, потому что его ребёнок устроил истерику из-за носков.

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

Вот как это происходит, этап за этапом.

Этап первый: Рай для троих (месяцы 1–6)

Когда вас трое в одной комнате – или, реалистичнее в 2026 году, трое в постоянном видеозвонке и одном канале Slack – операционные накладные расходы стартапа едва существуют как концепция. Вы слышите всё. Если кто-то меняет решение, вы знаете об этом, потому что, скорее всего, были в разговоре или хотя бы рядом. Нет никаких процессов, потому что они и не нужны. Контекст существует в воздухе.

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

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

Этап второй: Неловкая середина (месяцы 7–14, сотрудники 4–8)

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

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

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

Этап третий: Паника с процессами (месяцы 15–22, сотрудники 9–15)

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

stat: "25–45%" headline: "Рабочего времени теряется на координационные накладные расходы в командах из 10–20 человек" source: "Asana Anatomy of Work 2023; Microsoft Work Trend Index 2023; инженерные данные Clockwise"

Цифры действительно хуже, чем ожидает большинство основателей. Отчёт Asana Anatomy of Work (n=9,615 в шести странах) показал, что 58% рабочего дня среднестатистического работника умственного труда уходит на «работу о работе» – координацию, погоню за статусами, поиск информации, переключение между инструментами. Work Trend Index от Microsoft дал практически идентичные 57%. Даже данные Clockwise по инженерным командам – которые смещены в сторону более компактных и бережливых компаний – показали, что инженеры тратят 9,7 часов в неделю только на встречи, и это до того, как вы посчитаете переписку в Slack, поиск документов и повторные объяснения.

Для стартапа в диапазоне 10–20 человек консервативная оценка – 25–45% рабочего времени уходит на чистые координационные накладные расходы. Сколько это стоит в реальных деньгах, полностью зависит от того, где сидит ваша команда:

| Локация | Смешанная почасовая ставка | Годовые накладные расходы на человека (при 30%) | |---|---|---| | San Francisco | ~$134/hr | ~$72,000 | | Manhattan, NY | ~$116/hr | ~$63,000 | | Baden-Württemberg | ~€54/hr (~$59) | ~€29,000 (~$32,000) | | Tokyo | ~¥5,056/hr (~$34) | ~¥2.7M (~$18,000) | | Shenzhen | ~¥289/hr (~$40) | ~¥155K (~$21,000) |

Эти смешанные ставки включают льготы и налоги работодателя поверх базовой зарплаты. Столбец «30%» – это середина диапазона 25–45%, и если вы честны с собой, ваша команда, вероятно, ближе к верхней границе. Даже по консервативной оценке, стартап из двенадцати человек в Сан-Франциско сжигает примерно $860,000 в год на координацию, которая не строит продукт. В Штутгарте – около €350,000. В Токио – порядка ¥33 миллионов. Абсолютные числа различаются, но доля вашего burn rate, уходящая на людей, рассказывающих другим людям, что они делают, вместо того чтобы делать, – удивительно стабильна по географиям.

И вот что происходит дальше – потому что это происходит каждый раз: кто-то (обычно основатель, иногда недавно нанятый специалист по операциям) объявляет, что команде нужны Процессы. С большой буквы П. Вводится инструмент управления проектами, или второй инструмент управления проектами, или еженедельная встреча по планированию, или ежедневный письменный чекин, или сложная система шаблонов Notion с семнадцатью свойствами на страницу. Намерение хорошее! Исполнение иногда тоже хорошее! Но фундаментальная проблема в том, что добавление процессов в команду, которая восемнадцать месяцев строила идентичность вокруг принципа не нуждаться в процессах, – это как установить систему пожаротушения в доме, где все убеждены, что они несгораемые.

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

Сложная математика операционных расходов стартапа

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

Предположим, что у вас восемь человек и ваши координационные накладные расходы составляют умеренные 20% – около 32 часов на человека в месяц в сумме, или 256 человеко-часов по всей команде. Раздражает, но терпимо – вы стартап, работаете упорно, поглощаете это.

Теперь вы нанимаете ещё четырёх за квартал. Вас двенадцать. Но координационные накладные расходы не масштабируются линейно с численностью – они масштабируются с количеством коммуникационных путей, которое примерно равно n(n-1)/2. Переход с 8 до 12 человек увеличивает коммуникационные пути с 28 до 66, более чем удваивая их. Накладные расходы на человека не остаются на 20%; исследования последовательно показывают, что они растут до 30–35% при таком размере, потому что просто больше людей для координации, больше каналов для мониторинга, больше встреч для посещения и больше возможностей для того самого безобидного информационного провала, который мы видели в хронике вторника выше.

Итого: 12 человек × примерно 50 часов координационных накладных расходов в месяц на каждого = 600 человеко-часов – более чем вдвое больше, чем было при восьми, хотя команда выросла лишь на 50%. Эти 600 часов в месяц – это примерно три с половиной штатных инженера, которые, по сути, работают на поддержание координации команды, а не на создание того, что команда должна строить. Исследование Роба Кросса в UVA, опубликованное в Harvard Business Review, показало, что объём совместной работы вырос и поглощает 80% и более рабочего времени сотрудников во многих компаниях – и хотя эта цифра смещена в сторону крупных организаций, траектория начинается именно здесь, на этом перегибе.

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

Что на самом деле помогает (а что нет)

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

То, что действительно сдвигает иглу, – это снижение стоимости фонового осознания. Если люди могут без усилий оставаться в курсе происходящего во всех инструментах, которые они уже используют – не проверяя вручную Linear, потом GitHub, потом Slack, потом Notion, потом календарь, потом снова Slack – огромная часть этих накладных расходов на координацию просто испарится, потому что коренная причина большинства упущенных задач не в том, что людям всё равно, а в том, что они не знали.

Это, если говорить открыто, проблема, для решения которой был создан Sugarbug. Он подключается к инструментам, которые ваша команда уже использует, через API и строит граф знаний из всех сигналов, которые эти инструменты генерируют. Так что когда инженер разрабатывает продукт на основе устаревшей спецификации, факт того, что спецификация изменилась в документе Notion во вторник, – это то, что система действительно выводит на поверхность, а не то, что зависит от того, вспомнит ли кто-то упомянуть об этом на стендапе. Мы не заменяем ваши инструменты или процессы (честно говоря, хорошие процессы всё равно нужны), но мы стараемся сделать поток информации между всеми этими инструментами менее зависимым от чьей-то памяти и внимания.

При этом позвольте быть честным насчёт того, что не помогает, хотя экосистема советов по операциям стартапов это обожает рекомендовать. Нанимать «chief of staff» или «head of ops» при двенадцати людях – это, по нашему опыту, преждевременно: вы добавляете ещё один коммуникационный узел к уже перегруженной сети, и вся работа этого человека сводится к тому, чтобы вручную делать то, что программное обеспечение должно делать автоматически. Аналогично, добавление еженедельного общего собрания, где пятнадцать человек сидят в комнате и по очереди зачитывают свои обновления вслух, является – что ж, если быть справедливым – одним из наименее эффективных способов использования коллективного времени из когда-либо придуманных. Говорю это как человек, просидевший примерно на четырёхстах таких встречах.

Настоящий злодей – это вы (конкретно, ваши привычки)

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

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

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

Если этот материал отозвался в вас и вы хотите увидеть, как граф знаний Sugarbug может снизить налог координации в вашей команде, зарегистрируйтесь для раннего доступа – мы ведём развёртывание для команд в диапазоне 5–30 человек и будем рады показать, как выглядит фоновое осознание на практике.

Часто задаваемые вопросы

Q: Что такое операционные накладные расходы стартапа? A: Операционные накладные расходы стартапа – это совокупное время, энергия и деньги, которые ваша команда тратит на координацию вместо создания продукта: встречи по статусам, отслеживание обновлений в разных инструментах, повторное объяснение контекста, который кто-то пропустил, поиск актуальной версии документа и сверка противоречивой информации, разбросанной по шести разным местам. Это налог, который вы платите за то, что над одним делом работает больше одного человека, – и он растёт быстрее, чем ожидает большинство основателей по мере масштабирования команды.

Q: Как Sugarbug помогает снизить операционные накладные расходы стартапа? A: Sugarbug подключается через API к инструментам, которые ваша команда уже использует: Linear, GitHub, Slack, Notion, Google Calendar, Figma и другим – и строит живой граф знаний из всех сигналов, которые эти инструменты производят. Когда спецификация меняется в Notion, PR появляется в GitHub или встреча переносится в Календаре, Sugarbug выводит эти обновления в контексте, чтобы вашей команде не нужно было вручную отслеживать информацию в десятках вкладок. Он не заменяет ваши инструменты; он следит за тем, чтобы важные сигналы, текущие через них, не терялись.

Q: При каком размере команды операционные накладные расходы становятся серьёзной проблемой? A: Большинство команд начинают ощущать настоящую боль при 8–12 людях – это момент, когда неформальная координация (случайно услышать, быть во всех тех же каналах, держать контекст в голове) разрушается, а формальные процессы либо ещё не существуют, либо не применяются последовательно. Накладные расходы накапливались ещё до этого порога – просто это не было достаточно болезненным, чтобы замечать.

Q: Может ли Sugarbug заменить инструменты управления проектами, такие как Linear или Asana? A: Нет – и это намеренно. Sugarbug работает рядом с вашим существующим стеком и считывает из него данные, строя граф знаний, который связывает информацию между инструментами. Ваш трекер проектов по-прежнему является местом, где вы планируете и отслеживаете работу; Sugarbug – это слой, который гарантирует, что решение, принятое в Slack, изменение объёма в Notion и заблокированный PR в GitHub окажутся связаны между собой, чтобы ничто не ускользнуло. Думайте о нём как о соединительной ткани между вашими инструментами, а не как о замене любого из них.