Операционные правила для нового CTO, которые стоит написать до того, как команда собьется

Почему это нужно оформить в правила уже сейчас

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

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

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

Проблема становится еще заметнее, когда sales, product и engineering по-разному заполняют одну и ту же пустоту. Sales хочет закрыть сделку. Product хочет сохранить фокус. Engineering хочет снизить риск и избежать сюрпризов в последний момент. Все три цели понятны. Но без письменных правил каждая команда принимает свое решение под давлением.

Новый CTO обычно видит симптомы раньше причины. Вы снова и снова слышите одни и те же фразы:

• «Мы уже делали это однажды для другого клиента.»
• «Я думал, согласование подразумевалось.»
• «Никто не сказал, что я не могу так сделать.»
• «Нужно было действовать быстро.»

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

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

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

Три решения, которые нужно определить в первую очередь

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

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

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

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

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

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

Кто может согласовывать изменения в объеме работ

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

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

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

Практическое правило согласования может выглядеть так:

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

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

Попросите короткое письменное обоснование до того, как кто-то что-то пообещает. Сделайте его простым:

• Что изменилось
• Почему это меняется сейчас
• Как это повлияет на сроки, стоимость или загрузку команды
• Кто это согласовал

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

Кто может трогать продакшен

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

Большинству команд хватает нескольких уровней доступа:

• Дежурный инженер с доступом на чтение по умолчанию и временным доступом на запись во время инцидента
• Senior-инженер или tech lead с ограниченным доступом на запись для тех систем, за которые он отвечает
• CTO или head of engineering с полным доступом для аварийных случаев и окончательного согласования
• DevOps- или platform-инженер с доступом к инфраструктуре для тех частей, которые он обслуживает
• Сотрудники поддержки или продукта с доступом только на чтение к дашбордам, логам и административным инструментам, если это нужно для их работы

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

Для срочных инцидентов заранее пропишите один путь согласования, который сработает и в 2 часа ночи. Простого правила достаточно: дежурный инженер может попросить incident lead или CTO выдать временный доступ на запись, использовать его для устранения проблемы и потерять его, когда инцидент закончится. Если временный доступ никто не уберет, он становится постоянным случайно.

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

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

Как обходиться с кастомной работой по сделкам

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

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

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

Хорошее решение обычно начинается с четырех вопросов:

• Кто это разработает?
• Кто будет поддерживать это после запуска?
• Кто отвечает за отношения с клиентом, если что-то сломается?
• Это помогает больше чем одному клиенту или только этой сделке?

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

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

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

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

Как записать правила на бумаге

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

Каждому конфликту — одно правило. Формулировка должна быть достаточно простой, чтобы уставший тимлид прочитал ее один раз и сразу понял, что делать. Если для объяснения правила нужна долгая встреча, значит правило все еще слишком размытое.

Хорошее правило обычно состоит из четырех частей:

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

Так политика превращается в вещь, которой действительно можно пользоваться во вторник в разгаре аврала.

Используйте реальные примеры, а не теорию

Когда черновик готов, проверьте каждое правило на ситуации, которая уже случалась в прошлом месяце. Спросите себя: если бы это правило существовало тогда, команда бы двигалась быстрее и спорила бы меньше? Если ответ «нет», перепишите его.

Допустим, продажи пообещали кастомную интеграцию ближе к концу квартала. Product сказал, что это выбьет двух инженеров из работы над roadmap. Engineering сказал, что никто не уполномочен обещать такой объем работ. Рабочее правило может звучать так: только владелец продукта и владелец инженерии могут утверждать кастомную работу по сделкам выше установленного порога трудозатрат, и они должны ответить в течение одного рабочего дня. Если они не согласны, решение принимает CTO.

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

Проверьте правила с теми, кто чувствует боль на практике

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

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

Если человек может найти правило меньше чем за 30 секунд, он им воспользуется. Если не может, старые споры вернутся уже к пятнице.

Простой пример для стартапа

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

Хороший CTO в этот момент немного притормаживает. Первый вопрос — не «может ли команда это закодить», а «что именно меняет этот запрос».

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

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

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

Один простой набор правил удерживает всех в рамках:

• Sales фиксирует запрос и объясняет, почему он нужен клиенту.
• Product решает, подходит ли он под roadmap.
• Engineering оценивает трудозатраты, риски и работу по поддержке.
• CTO утверждает любое исключение, которое добавляет объем работ или постоянную поддержку.
• Sales предлагает либо оплачиваемый кастомный проект, либо ближайший стандартный вариант.

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

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

Ошибки, которые создают ежедневную путаницу

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

Самая плохая ошибка — дать двум людям последнее слово. Если и sales, и product могут утверждать изменения в объеме, инженеры начинают ждать, гадать или выбирать тот ответ, который им больше нравится. То же самое происходит с доступом к продакшену, когда основатель говорит «да», а инженерный лидер — «пока нет».

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

Некоторые тревожные сигналы появляются быстро:

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

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

Срочная работа тоже нуждается в ограничении по времени. Если никто не скажет, кто отвечает на запрос доступа к продакшену через 15 минут, через час или до конца следующего рабочего дня, люди под стрессом изобретут свое правило. Именно тогда доступы расползаются, hotfix проходят без проверки, а разбор виноватых начинается позже.

Изменения в команде тихо разрушают старые правила. Стартап нанимает нового engineering manager, привлекает Fractional CTO или передает аккаунты новому руководителю продаж. Если никто не обновит правила согласования, люди продолжат следовать версии, которая живет у них в памяти.

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

Быстрая еженедельная проверка

Правило, которое никто не может найти или объяснить, провалится при первом же давлении. Потратьте 10 минут в неделю на проверку того, совпадают ли письменные правила с тем, как люди реально работают.

Лучше всего это работает как короткая встреча с по одному лидеру от product, engineering и sales. Если вы новый CTO, такая привычка позволяет поймать дрейф до того, как он станет нормой.

Каждую неделю используйте одни и те же пять проверок:

• Спросите нескольких людей, кто утверждает изменения в объеме работ. Не спрашивайте только менеджеров. Если два человека называют разных людей, правило уже слабое.
• Спросите нового сотрудника, где лежат правила по доступу к продакшену. Если он не может найти ответ за минуту, правило спрятано слишком глубоко или сформулировано слишком расплывчато.
• Проверьте, не утвердил ли sales какую-то кастомную работу вне письменного процесса. Одно обещание мимо процесса часто потом превращается в дни переделок.
• Посмотрите на изменения ролей за последнюю неделю. Если кто-то перешел в другую команду или ушел с hands-on роли, убедитесь, что доступ к продакшену у него не остался по ошибке.
• Ищите повторяющуюся путаницу. Если одно и то же правило вызвало один и тот же вопрос дважды за неделю, перепишите его. Команда прямо показывает вам, что формулировка плохая.

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

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

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

Что делать дальше

Выделите 60 минут на этой неделе и соберите sales, product и engineering в одной комнате. Не превращайте это в стратегическую сессию. Примите три решения и запишите их до того, как все уйдут.

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

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

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

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

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

Если команда продолжает возвращаться к одному и тому же спору, внешняя помощь может сэкономить время. Oleg Sotnikov на oleg.is делает именно такую работу Fractional CTO для стартапов и небольших команд, помогая им выстроить понятные линии согласования без лишнего процесса ради процесса.

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