# Планы повышения эффективности инженерной команды должны соответствовать модели финансирования > Планы повышения эффективности инженерной команды должны учитывать финансирование, запас времени, обещания по росту, нагрузку поддержки и риски, которые стартап действительно может принять. У компании, которая финансируется за счёт собственной выручки, и компании с венчурным финансированием могут быть одинаковые расходы на инженеров, один и тот же бэклог продукта и одна и та же жалоба совета директоров или основателей: расходы слишком высокие. Но план повышения эффективности им нужен разный. Компания, которая живёт за счёт выручки, должна постоянно подтверждать право на существование деньгами клиентов. Компания с венчурным финансированием купила время для реализации гипотезы роста, но вместе с этим взяла на себя обещания по скорости, захвату рынка и будущему финансированию. Первая обычно может отложить экспериментальную интеграцию. Второй она может понадобиться, чтобы закрыть стратегического клиента или подтвердить историю для следующего раунда. Поэтому общие советы вроде «сократите 20%», «замените команду ИИ» или «нанимайте только опытных инженеров» приносят вред. Это действия, а не планы. Рабочий план начинается с ограничений, которые действуют сегодня: насколько хватит денег, чего ждут клиенты, какой рост уже обещан и какие сбои компания действительно может пережить. ## Одна и та же цель по расходам может требовать противоположных решений Сокращение на 30% может означать закрытие неиспользуемой продуктовой линии в одной компании и отмену найма для расширения в другой. Сам процент ничего не говорит о том, сохранила ли компания способность продавать, поставлять продукт и восстанавливаться после плохой недели. Я видел, как основатели превращали эффективность в спор между инженерией и финансами. Финансы видят, как зарплаты каждый месяц уходят из банка. Инженеры видят очередь задач, которая не исчезла только потому, что людей стало меньше. Оба взгляда неполны, пока кто-то не определит, какие обязательства можно перенести, а какие нельзя. Прежде чем обсуждать роли или инструменты, определите четыре ограничения: - Запас денежных средств: количество месяцев до момента, когда компании понадобятся новая выручка, новое финансирование или меньший расход средств. - Обязательства по росту: релизы, контракты клиентов, обещания отдела продаж и рыночные возможности, которые руководство уже выбрало. - Обязательства по поддержке: доступность, время ответа, интеграции, миграции, исправления безопасности и прежнее поведение продукта, на которое всё ещё рассчитывают платящие клиенты. - Допустимый риск: уровень задержек, оттока клиентов, риска инцидентов и технического долга, который компания может принять. У бизнеса, который живёт за счёт собственной выручки, обычно мало возможностей долго работать с отрицательным денежным потоком, но ему проще отказаться от поспешного расширения. У компании с венчурным финансированием может быть больше денег, но меньше свободы пропустить релиз, подтверждающий модель роста. Если считать обе компании просто «стартапами», главное решение останется скрытым. Сначала сформулируйте ограничения простым языком. Если руководители не могут договориться о них, никто не должен начинать перестраивать инженерную организацию. ```text Ограничения компании Запас денежных средств: 11 месяцев при текущем уровне расходов Зависимость от выручки: 62% ежемесячной выручки зависит от существующего продукта Обязательство по росту: запустить самостоятельную регистрацию для подписавшего контракт партнёра по продажам в этом квартале Обязательство по поддержке: ответ платным клиентам в рабочие дни, инженерная команда отвечает за производственные инциденты Допустимый риск: можно отложить экспериментальные функции; нельзя допустить повторяющиеся инциденты с потерей данных или очередь поддержки дольше двух рабочих дней ``` Этот документ заставляет провести важное различие: желаемый результат не равен обязательству. «Мы хотели бы выйти в Европу» относится к другой категории, чем «мы подписали клиента, и дата запуска указана в контракте». ## Запас времени меняет смысл эффективности Для компании, которая финансируется самостоятельно, эффективность означает превращать время инженеров в сохранённую выручку, новую выручку или заметное снижение операционных расходов до того, как деньги закончатся. У работы, которая может принести пользу через восемнадцать месяцев, должна быть веская причина, если зарплаты нужно покрыть поступлениями от клиентов уже в следующем месяце. Для компании с венчурным финансированием запас времени тоже важен, но вопрос звучит иначе: сохраняют ли текущие расходы шанс достичь следующей точки подтверждения до того, как закончатся деньги? Это может быть удержание клиентов, дополнительная выручка от существующих клиентов, готовность к работе с крупным бизнесом, новый канал распространения или возможность продукта, которую конкуренты не смогут быстро скопировать. Основатели часто совершают одну из двух ошибок. Они либо сохраняют каждый проект, потому что в него уже вложено время, либо сокращают всё, что не принесёт выручку на этой неделе. Первое это мышление невозвратных затрат. Второе может уничтожить работу, которая создаёт условия для выручки через полгода. Распределите все активные инженерные инициативы по четырём категориям: 1. Защита выручки: снижение числа инцидентов, корректность биллинга, исправления безопасности, выполнение договорных обязательств и работа, необходимая для продления контрактов. 2. Создание выручки: чётко определённая возможность для сегмента клиентов, подписанной сделки или подтверждённого сигнала спроса. 3. Снижение расходов: автоматизация, упрощение инфраструктуры, вывод дублирующихся систем из эксплуатации и повторяющаяся ручная работа. 4. Создание возможностей: эксперименты, платформенная работа, исследовательские интеграции и функции, которые могут открыть путь в будущем. Эти категории не отражают моральную иерархию. Создание возможностей может быть правильным использованием времени в компании с венчурным финансированием. Опасность возникает, когда руководство называет возможностью любой спекулятивный проект и отказывается назначать ему дату окончания. Для компании, которая финансируется самостоятельно, у проекта по созданию возможностей должны быть низкая стоимость, короткий срок принятия решения и конкретный клиент или гипотеза о выручке. Если для его оценки нужна отдельная команда на два квартала, это, скорее всего, уже не эксперимент. Это ставка, которой нужно выделить отдельное финансирование. Для компании с венчурным финансированием проверка состоит в том, поддерживает ли такая возможность план финансирования и роста. Если компания собирается завоевать рынок за счёт более быстрой реализации, работа над повторно используемым процессом подключения клиентов может заслуживать финансирования. Если связь объяснить нельзя, это накладные расходы под стратегическим названием. Простой расчёт запаса времени помогает, но не позволяйте ему создавать ложную уверенность: ```text Ежемесячный чистый расход = ежемесячные операционные выплаты - ежемесячные поступления Запас времени в месяцах = неограниченные денежные средства / ежемесячный чистый расход Сценарий A: убрать ежемесячные расходы проекта в размере $45 000 Сценарий B: сохранить проект, но сократить $45 000 за счёт лишней работы поддержки и инфраструктуры Сравните оба сценария с риском для выручки, сроками поставки и стоимостью отмены решения. ``` Именно разница между сценариями A и B обычно показывает, с чего начинается работа руководства. Удаление проекта быстро улучшает таблицу, но повышает риск оттока клиентов. Удаление повторяющейся ручной работы может проявиться позже, зато снижает расход, который иначе будет возвращаться каждый месяц. ## Обещания по росту задают минимальную мощность Компания с венчурным финансированием не обязана сохранять каждого инженера только потому, что инвесторы ждут роста. Ей нужно сохранить достаточно мощности, чтобы выполнить обязательства по росту, которые она осознанно взяла на себя. Это более узкое и конкретное утверждение. Начните с обязательств, которые нельзя молча перенести. Учтите даты запуска, зафиксированные с клиентами, миграции продукта, нормативные сроки, риски продления, важные интеграции и обещания отдела продаж, где участие инженеров было частью сделки. Затем оцените минимальную мощность, необходимую для их выполнения с обычными сбоями, а не при идеальном сценарии. Большинство дорожных карт предполагает спокойный квартал. В них нет производственных инцидентов, неожиданных миграций клиентов, сложного партнёра по интеграции, отсутствия сотрудников и поздних изменений со стороны продаж. Это не план, а оптимистичный прогноз, выданный за модель численности. Минимальная мощность состоит из трёх частей: - Мощность поставки для обязательств, которые создают или защищают выручку. - Сервисная мощность для инцидентов, эскалаций поддержки, операционного обслуживания и работы над безопасностью. - Мощность восстановления для задач, которые займут больше времени, чем ожидалось, или не сработают с первого раза. Третья часть вызывает споры, потому что похожа на резерв. Но это не простой, если бизнес регулярно сталкивается с проблемами в продакшене, эскалациями клиентов и изменениями требований. Команда без мощности восстановления не становится эффективнее. Она начинает забирать время у запланированной работы, а затем каждую сорванную дату называют проблемой исполнения со стороны инженерии. Не оценивайте мощность только по числу людей. Считайте навыки и ответственность. Если только один инженер понимает биллинг, развёртывание, хранение данных или важную интеграцию с клиентом, компания зависит от одной точки отказа, даже если численность выглядит комфортной. Сокращение универсального специалиста может быть проще исправить, чем потерю единственного человека, который способен диагностировать сбой биллинга ночью. Перед любым сокращением составьте карту покрытия: ```text Область: развёртывание в продакшен Основной владелец: инженер A Резервный владелец: инженер C Документированный регламент действий: да Недавняя практика резервного владельца: нет Переживёт ли область уход сотрудника в этом месяце: нет Область: устаревший мобильный клиент Основной владелец: инженер B Резервный владелец: нет Документированный регламент действий: частично Затронутая выручка: 8% активных клиентов Переживёт ли область уход сотрудника в этом месяце: только если продукт вывести из эксплуатации или передать поддержку по контракту ``` Именно такой документ выявляет символические программы повышения эффективности. Если руководитель хочет убрать владельца области, план должен указать, кто возьмёт работу, что будет остановлено и как изменится время ответа. Если ничего этого нет, перед нами цель по численности, которая притворяется операционным планом. ## Поддержка клиентов это инженерное обязательство, а не фоновый шум Поддержка становится невидимым налогом, когда основатели называют её перебоями вместо запланированной работы. Инженеры расследуют дефекты в продакшене, исправляют данные, объясняют интеграции, помогают продажам отвечать на технические вопросы и поддерживают поведение, которое текущая дорожная карта никогда бы не выбрала. Эти часы входят в стоимость уже проданного продукта. Обычно работу поддержки измеряют неправильно: поставку функций считают, а задачи поддержки оставляют в чатах, личной почте и расплывчатых блоках календаря. Тогда руководство видит команду, у которой «должна быть» свободная мощность, потому что в дорожной карте только запланированные задачи. Команда видит неделю, исчезнувшую в работе, которую никто не учёл. Разделите поддержку на четыре очереди: - Производственные инциденты, влияющие на доступность, корректность, безопасность или данные. - Дефекты и сбои интеграций, блокирующие работу клиентов. - Технические запросы, требующие инженерного решения, но не блокирующие клиента. - Вопросы, которые должны решать поддержка, документация, продукт или продажи без участия инженера. Затем несколько обычных недель измеряйте фактическое число инженерных часов в каждой очереди. Не берите необычно спокойную неделю или неделю сразу после крупного сбоя. Вам нужна регулярная нагрузка, которую должна выдерживать команда. Для обязательств по поддержке также нужен определённый уровень сервиса. Фраза «мы поддерживаем корпоративных клиентов» не является уровнем сервиса. Уровень сервиса определяет, кто получает ответ, в какие часы, как эскалируются инциденты и за что отвечает инженерная команда. Если основатели не хотят выделять людей на это обязательство, им нужно изменить обязательство, а не наказывать команду за его выполнение. Для компании, которая финансируется самостоятельно, это особенно важно. Существующие клиенты часто самый дешёвый источник будущей выручки. Потерять их из-за сокращения поддержки ради гипотетической функции значит плохо распорядиться ресурсами. Экономия кажется реальной, потому что сокращение зарплат видно сразу. Потерянные продления приходят позже, и их списывают на рынок. Для компании с венчурным финансированием данные поддержки также должны влиять на план роста. Продажи с активным участием команды и большим объёмом индивидуальных интеграций используют инженерную мощность иначе, чем самостоятельный продукт. Нельзя одновременно обещать быстрое расширение в корпоративном сегменте и сохранять маленькую продуктовую команду, делая вид, что внедрение решится само. ## Допустимый риск нужно записать до сокращений Каждый план повышения эффективности перераспределяет риск. Зрелый разговор состоит в том, чтобы решить, какой риск принять, в каком объёме и какой сигнал покажет, что нужно отступить. Риск не выражается одним числом. Компания может согласиться на более медленную внутреннюю отчётность, но отказаться от проблем с целостностью данных. Она может отложить выход на новый рынок, сохранив время ответа платным клиентам. Она может вывести старую функцию из эксплуатации после чёткого уведомления, но не оставить критический сервис с единственным оператором. The Google SRE Book предлагает полезную операционную модель через цели уровня сервиса и бюджеты ошибок. В этой модели команда задаёт целевой уровень надёжности, а разница между идеальной надёжностью и этой целью становится допустимым бюджетом сбоев. Если сервис расходует бюджет, команде следует сократить рискованные изменения и заняться восстановлением надёжности. Не каждая компания нуждается в отдельном отделе SRE. Но для надёжности нужен заранее согласованный предел, а не спор после инцидента. Заранее зафиксируйте решения по рискам в небольшом реестре: ```text Решение: объединить два конвейера развёртывания в один Ожидаемый эффект: убрать работу по обслуживанию и один счёт за хостинг Принятый риск: в первый месяц восстановление может идти медленнее, если новый конвейер выйдет из строя Защита: сохранить старый конвейер доступным только для чтения на 30 дней Условие отмены: два неудачных восстановления в продакшене из-за нового конвейера Владелец: CTO Дата проверки: через четыре недели после переключения ``` Это лучше, чем объявлять каждое изменение безопасным только потому, что инженер его протестировал. Тестирование снижает неопределённость, но не устраняет операционные последствия, путаницу клиентов и время, необходимое для восстановления при взаимодействии нескольких изменений. Компании, которые финансируются самостоятельно, обычно стоит выбирать изменения, которые легко отменить. Отказ от подрядчика, отключение неиспользуемого сервиса, удаление мёртвой интеграции или пауза в проекте с низким спросом наносят меньше необратимого вреда, чем устранение единственного владельца ключевой системы. Обратимость особенно важна при ограниченном бюджете, потому что ошибки тоже расходуют деньги. Компании с венчурным финансированием могут делать более крупные ставки, если они соответствуют стратегии роста и руководство оставило достаточно мощности для восстановления. Большее финансирование не делает небрежность приемлемой. Оно лишь меняет набор экспериментов, которые могут быть разумными. ## Сначала сократите работу, а не людей, которые в ней разбираются Сокращение численности иногда необходимо. Но оно не должно быть первым свидетельством дисциплины. Сначала определите, какую работу нужно остановить, какую превратить в самостоятельный процесс и какую перевести на более дешёвую операционную модель. Проведите двухнедельную инвентаризацию работы. Попросите каждую инженерную функцию записывать время по широким категориям, без слежки за каждой минутой. Цель состоит в том, чтобы увидеть спрос, а не оценивать людей. Используйте категории, связанные с решениями: разработка нового продукта, поставка для клиентов, реагирование на инциденты, обслуживание, внутренние инструменты, встречи и незапланированные запросы. В конце сопоставьте инвентаризацию с ограничениями компании. Часто обнаруживается одна из следующих проблем: 1. Несколько команд создают функции для сегментов клиентов, которыми компания больше не планирует заниматься. 2. Инженеры выполняют повторяющуюся ручную работу, потому что никто не взял на себя решение автоматизировать, задокументировать или остановить её. 3. Продажи и customer success дали технические обещания, не зарезервировав инженерную мощность. 4. Команда обслуживает системы, которые больше не создают выручку, но их никогда официально не выводили из эксплуатации. 5. Руководители сохраняют встречи по статусам и циклы согласований, которые отнимают время, которого, по их словам, не хватает. Популярная рекомендация состоит в том, чтобы «делать больше меньшими силами» с помощью инструмента для программирования с ИИ. Она неполна. ИИ может сократить время на написание черновиков тестов, исследование кода, создание скриптов миграции, подготовку документации и автоматизацию узких операционных задач. Но он не решает, какое обещание клиенту нарушить, какую старую систему вывести из эксплуатации и создаёт ли поспешное развёртывание неприемлемый риск. Используйте ИИ после того, как сузили объём работы. Иначе компания будет производить больше результата при тех же неясных приоритетах. Более быстрый код не означает эффективности, если из-за него растёт объём кода и поддержки, за которые команда отвечает. Полезное правило решения такое: если у работы нет конкретного владельца, результата для клиента или бизнеса, реального срока и цены задержки, остановите её, пока кто-то не сможет её обосновать. Не сохраняйте её только потому, что когда-то идея понравилась руководителю. ## План компании с самостоятельным финансированием должен защищать деньги и удержание клиентов Компания, которая финансируется самостоятельно, должна строить план вокруг превращения работы в деньги и удержания клиентов. Это не значит полностью заморозить развитие продукта. Это значит, что у продуктовой работы должен быть более ясный путь к продлению, расширению, привлечению клиентов или регулярному снижению расходов. Сначала защитите уже существующий двигатель выручки. Определите небольшой набор процессов, благодаря которым клиенты получают ценность, оплачивают счета, интегрируют данные и получают помощь при сбоях. Эти области заслуживают надёжного владельца и контролируемого процесса релизов. Именно они не дают бизнесу постоянно замещать потерянную выручку новыми продажами. Затем снижайте расходы за счёт дисциплины в выборе объёма работ. Небольшая команда, финансируемая выручкой, часто может существенно продвинуться, если сократит число активных инициатив, ограничит индивидуальные доработки, выведет функции с высокой нагрузкой поддержки и перенесёт повторяющиеся задачи в скрипты и документацию. Такие решения выглядят скромнее реорганизации, но продолжают приносить эффект. Практический операционный план часто включает: - Одно направление защиты выручки, которое не конкурирует со спекулятивной дорожной картой. - Одну продуктовую ставку за раз для каждой небольшой группы поставки. - Опубликованную политику индивидуальных запросов клиентов, включая тех, кто может их одобрить, и какую работу придётся отложить. - Ежемесячную проверку инфраструктуры, SaaS-сервисов, подрядчиков и систем, требующих ручного обслуживания. - Правило, по которому у каждой новой регулярной операционной задачи должны быть владелец и план удаления. Здесь нужно прямо говорить о поведении основателя. Если основатель продаёт исключения каждому клиенту, инженерная эффективность не сохранится. Компания создаёт сервисный бизнес, планируя расходы как продуктовая компания. Ответом может стать плата за внедрение, сужение обещаний или найм людей под сервисную модель. Если считать эту работу бесплатной, команда выгорит, а маржинальность станет непредсказуемой. Цель не в том, чтобы команда была маленькой сама по себе. Цель в том, чтобы время команды было связано с выручкой, а нагрузка поддержки не росла быстрее клиентской базы. Два инженера могут хорошо вести сфокусированный бизнес. Но они не смогут бесконечно поддерживать широкий каталог продукта, индивидуальную поставку для крупных клиентов, постоянные запросы основателя и круглосуточное реагирование на инциденты. ## План компании с венчурным финансированием должен покупать скорость только там, где она меняет результат Компания с венчурным финансированием может тратить деньги до появления выручки, если эти расходы создают убедительный путь к более крупному результату. Фразы «двигаться быстрее» недостаточно. Руководство должно объяснить, что даёт эта скорость и что произойдёт, если компания опоздает. Например, увеличение мощности может быть оправдано, если оно ускоряет запуск с партнёром и открывает новый канал распространения, устраняет проблемы надёжности, блокирующие корпоративные продажи, или позволяет передать продукт клиентам вовремя, чтобы получить знания до следующего решения о финансировании. Это менее оправданно, когда компании нужны дополнительные инженеры только потому, что в дорожную карту попала каждая идея из планирования. План должен сделать решения о мощности видимыми. Оставьте небольшое число ставок на рост, назначьте каждой измеримую точку подтверждения и определите дату, когда руководство продолжит, изменит или остановит инвестиции. Команда может работать энергично, если понимает, какие ставки важны. Она замедляется, когда все инициативы претендуют на одинаковую срочность. Компаниям с венчурным финансированием также нужно избегать преждевременной специализации. Крупная организация может позволить себе отдельные команды платформы, данных, мобильной разработки, качества, опыта разработчиков и эксплуатации. Молодая компания часто не может. Специалисты полезны, когда устраняют повторяющееся узкое место, с которым универсальные инженеры не могут безопасно справиться. Они дороги, если создают координационную работу вокруг проблем, которые сфокусированная продуктовая команда могла бы решить напрямую. Это не значит, что продуктовые инженеры должны навсегда отвечать за каждую операционную задачу. Это значит, что специализацию нужно заслужить фактами. Если релизы срываются из-за хрупкого процесса поставки, создайте ясную модель ответственности. Если работа с данными клиентов снова и снова блокирует продажи, инвестируйте в эту возможность. Не создавайте новый отдел только потому, что он похож на организационную схему компании более поздней стадии. Такая же осторожность нужна при внедрении ИИ. Компания с венчурным финансированием может обосновать инвестиции в общие практики программирования, внутренние инструменты и агентские процессы, если заметный рост скорости поставки меняет результат роста. Но рабочий процесс нужно проверять на реальных репозиториях и измерять нагрузку на ревью, количество дефектов, дошедших до пользователей, и время до продакшена. Слайд с примерами сгенерированного кода не доказывает, что операционная модель работает. ## Проверяйте план как операционное решение, а не как разовое сокращение Изменения ради эффективности проваливаются, когда руководство объявляет их, празднует прогнозируемую экономию и ждёт итоговых показателей квартала. Плану нужен короткий цикл проверки, потому что он меняет способ попадания работы в команду, ответственность за инциденты и опыт клиентов. В течение первого месяца каждую неделю проверяйте пять показателей: время поставки значимых изменений, открытые задачи поддержки, требующие участия инженеров, производственные инциденты, время восстановления сервиса и выполненную работу по выбранным обязательствам компании. Для компании, финансируемой самостоятельно, добавьте данные о денежных средствах, а для компании с венчурным финансированием, данные о точке подтверждения роста. Не превращайте проверку в показательное заседание с дашбордом. Задавайте прямые вопросы. Какое обязательство находится под угрозой? Какая работа пришла без выделенной мощности? Создало ли сокращение расходов новую ручную нагрузку? Не отложила ли команда проблему надёжности, которая теперь требует решения? Какой проект по-прежнему потребляет время без доказательств, что его нужно продолжать? Если ответ выявляет ошибочное предположение, измените план. Ранний отказ от неудачного сокращения дешевле, чем три месяца защищать его только ради того, чтобы исходная таблица выглядела правильно. Если у вашей компании есть цель по расходам, но вы не можете определить, какую работу остановить, какие обязательства защитить и какие риски принять, забронируйте Team & AI Audit до принятия необратимого решения о численности. Полезным результатом должен стать план на основе ограничений, которым смогут пользоваться основатели, руководитель финансов и инженерная команда. Компания не становится эффективной от одного только бережливого вида. Она становится эффективной, когда люди тратят время на обязательства, которые бизнес может объяснить, у работы поддержки есть владелец, а каждое сокращение расходов имеет известное последствие ещё до того, как его обнаружат клиенты.