COO на неполную занятость устраняет хаос в SaaS

У SaaS-компании может быть разумная архитектура, сильные инженеры и достаточный запас денег, а все значимые сроки она все равно срывает. Обычно в ответ начинают сильнее давить на CTO. Это помогает лишь тогда, когда задержку вызвали инженерные решения или техническое исполнение. Если приоритеты меняются каждый день, продавцы дают обещания в обход планирования, за межкомандные зависимости никто не отвечает, а руководители пересматривают уже принятые решения, узкое место находится в операционной работе. COO на неполную занятость может исправить эту систему, пока CTO исправляет продуктовую и инженерную систему.

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

Такое разделение нужно еще до того, как компания обзаведется полным набором топ-менеджеров. Основатель может сохранить полномочия COO, пока приглашенный операционный руководитель выстраивает контроль. Название должности менее важно, чем устройство принятия решений: кто-то должен иметь право остановить необоснованное обещание, а кто-то остановить небезопасный технический план. Если оба запрета лежат на одном CTO, при каждом усилении давления со стороны выручки возникает конфликт.

Операционный хаос оставляет не те следы, что технический долг

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

Техническое узкое место оставляет такие признаки, как медленная сборка, хрупкие развертывания, повторяющиеся инциденты, неясные границы сервисов или кодовая база, в которой небольшие изменения несут большой риск. У операционного узкого места другие следы: две команды считают одно решение своим, у обязательства перед клиентом нет названного согласующего лица, запуск ждет юристов или поддержки, либо основатель меняет объем работы в личном сообщении. Оба типа сбоев могут существовать одновременно. Если назвать все это инженерной проблемой, незаметной останется часть, которую способен исправить только CEO или COO.

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

Запись об обязательстве A: корпоративный экспорт. Первая блокировка 6 мая, ожидание условий договора. Решение принадлежит COO, под угрозой продление контракта.

Запись об обязательстве B: изменение биллинга. Первая блокировка 9 мая, ожидание способа миграции. Решение принадлежит CTO, нагрузка на поддержку растет.

Запись об обязательстве C: партнерский запуск. Первая блокировка 12 мая, ожидание окончательной комплектации предложения. Решение принадлежит CEO, потому что компания рискует потерять окно кампании.

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

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

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

COO отвечает за систему обещаний, а CTO за техническую реальность

Разделение простое: COO отвечает за то, как компания принимает и выполняет обязательства по поставке, а CTO за безопасность, выполнимость и обеспеченность технического плана людьми. Ни один из них не руководит другим. Они встречаются на границе, где коммерческое обещание превращается в техническое обязательство.

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

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

Большую часть неясности снимает четкое распределение прав на решения:

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

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

Дата становится надежной после встречи объема, мощности и полномочий

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

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

• Результат и явно исключенная работа
• Ответственный бизнес-владелец и технический владелец
• Источник мощности с указанием вытесненной работы
• Внешние и внутренние зависимости
• Диапазон уверенности и дата следующей проверки

CTO подтверждает выполнимость и инженерный диапазон. Продуктовая команда подтверждает, что объем описывает результат, а не набор функций. COO решает, следует ли всей компании принять обязательство. Если информации не хватает, правильный ответ не «нет», а «пока нет», после чего нужно перечислить точные данные для решения.

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

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

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

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

Для перелома сначала нужна одна очередь, а не новый план

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

COO и CTO могут собрать очередь на рабочей встрече, но им нельзя искать компромисс через сохранение всего. Действуйте в такой последовательности:

1. Перечислите все инициативы, которые используют мощность продукта, разработки, данных, безопасности, поддержки или руководителей. Назначьте каждой ответственного за результат.
2. Отметьте жесткие обязательства, например подписанные договоры, нормативные сроки и устранение проблем надежности. Записывайте подтверждения, а не принимайте ярлык самого громкого участника.
3. Оцените мощность крупными категориями. При нестабильном объеме точность будет ложной, а категории «малая», «средняя» и «крупная» покажут перегрузку.
4. Расставьте результаты по приоритету, затем ограничьте активную работу мощностью, которую команды действительно могут поддержать. Остальное перенесите в видимую очередь ожидания без подразумеваемой даты начала.
5. Опубликуйте решения, вытесненную работу и момент следующего пересмотра. Закрытая расстановка приоритетов не меняет поведение компании.

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

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

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

Операционная система должна показывать дрейф каждую неделю

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

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

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

• Минуты 0-10: определить изменения в обязательствах компании и принять или отклонить каждое.
• Минуты 10-25: разрешить решения, блокирующие поставку, назначить владельца и срок каждому открытому пункту.
• Минуты 25-35: определить, куда переместилась мощность, и назвать вытесненную работу.
• Минуты 35-45: решить, что должны узнать клиенты или сотрудники, и назначить говорящего.

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

Kanban Guide определяет незавершенную работу как начатую, но не законченную, и считает контроль над ней частью управления потоком. Компании часто применяют эту мысль только к инженерным задачам. Дорогая незавершенная работа находится уровнем выше: запуски, интеграции, миграции, рыночные эксперименты и обещания корпоративным клиентам. COO должен ограничивать такой портфельный запас. CTO должен ограничивать инженерную работу внутри оставшихся результатов.

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

Один проваленный запуск показывает разрыв полномочий

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

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

Исправление со стороны COO начинается за пределами кодовой базы. Владелец клиента должен описать договорной результат и исключения. Продуктовая команда переводит рабочий процесс клиента в примеры приемки. CTO выбирает безопасную конструкцию и возвращает диапазон. Затем COO согласует обмен на уровне компании: поэтапно выпустить функцию, сдвинуть другую инициативу, изменить коммерческие ожидания или отказаться от работы. CEO подключается, только если риск по клиенту пересекает согласованный порог либо варианты меняют стратегию.

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

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

COO на неполную занятость нужны узкий мандат и реальные полномочия

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

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

Опишите сотрудничество через результаты и доступ к решениям, а не пакет часов на встречах. COO на неполную занятость нужны постоянная сессия с CEO и CTO, прямой доступ к владельцам портфеля, право проверять обязательства перед клиентами и путь ответа на срочные решения. Назовите ответственного за каждый контроль в дни, когда COO не работает. Без такой непрерывности блокировки ждут календаря консультанта, а сама роль создает новую очередь.

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

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

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

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

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

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

Первые 30 дней должны убрать неясность, а не добавить церемонии

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

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

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

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

К четвертой неделе CEO должен получить компактный набор подтверждений:

• Один ранжированный портфель с заявленным пределом активной работы
• Права на решения об обещаниях, технической безопасности и смене приоритетов
• Запись об обязательстве для каждой значимой внешней даты
• Журнал решений с владельцами и условиями повторного рассмотрения
• Динамика блокировок, смен приоритетов и исключений по мощности

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

Граница держится, только если оба руководителя могут отказать

Разделение COO и CTO работает, когда каждый может отклонить свой тип небезопасного обещания. CTO вправе остановить релиз или отвергнуть технический план с неприемлемым риском для безопасности, надежности или сопровождения. COO вправе отклонить обязательство компании без объема, мощности, владельца или готовности разных функций. Каждый должен объяснить основания и условие, при котором ответ изменится.

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

Не нанимайте COO на неполную занятость для лечения слабой архитектуры, а CTO на неполную занятость для надзора за обещаниями продавцов. Если проблема также затрагивает стоимость и выпуск инженерной команды, Team & AI Audit от oleg.is стоит фиксированные $5,000 и занимает пять рабочих дней: он находит не менее $50,000 экономии в год, иначе проводится бесплатно. Такое предложение может выявить вопросы мощности и инженерной системы, но CEO все равно должен назначить операционные полномочия для обязательств всей компании.

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