Ошибки в соглашении с CTO на частичной занятости, которые нужно исправить до подписания

Почему эти соглашения рано разваливаются

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

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

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

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

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

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

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

Ошибка 1: неясные права на решения

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

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

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

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

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

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

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

Когда права на решения понятны, доверие строится легче. Люди перестают гадать, и работа двигается вперед.

Ошибка 2: отсутствие сроков ответа

Еще одна частая ошибка — считать, что у всех одинаковое представление о том, что значит «быстро». Основатель пишет в Slack и ждет ответ через 20 минут. CTO на частичной занятости проверяет сообщения два раза в день и не видит проблемы. Работа замедляется еще до конца первого спринта.

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

Часто помогает такой простой базовый вариант:

• Email: ответ в течение 1 рабочего дня
• Чат: ответ в течение 2 часов в согласованные рабочие часы
• Срочный вопрос: подтвердить получение в течение 15 минут и подключиться в течение 1 часа, если человек на дежурстве
• Запросы на согласование: ответ в течение 24 часов или приостановка связанной работы

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

Часовые пояса создают больше проблем, чем ожидают большинство команд. Если основатель работает в Лондоне, а советник — в Нью-Йорке, у них может быть лишь короткое окно пересечения каждый день. Укажите часовой пояс в соглашении и определите рабочие часы с первого дня. Даже одна строка вроде «доступен с понедельника по пятницу, с 10:00 до 16:00 по восточному времени» снимает много напряжения.

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

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

Если задача зависит от ответа, в соглашении должно быть указано, кто отвечает, где отвечает и к какому времени.

Ошибка 3: нет плана на случай конфликта

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

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

Используйте один путь разрешения конфликта, которому должны следовать обе стороны.

Рабочий порядок решения конфликта

Он должен быть достаточно коротким, чтобы люди действительно им пользовались:

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

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

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

С простым порядком эскалации вопрос остается в рамках. У команды есть один предметный разговор, одна точка эскалации и один окончательный ответ.

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

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

Ошибка 4: слабые условия выхода

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

Срок уведомления должен соответствовать работе. Если CTO дает продуктовые советы несколько часов в месяц, может хватить 7–14 дней. Если этот человек управляет релизами, подрядчиками, наймом или продакшен-системами, обычно безопаснее 30 дней.

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

Это особенно важно, если CTO работает с живой инфраструктурой. Если у кого-то есть доступ к AWS, GitLab, Cloudflare, Grafana или биллинговым аккаунтам, у компании уже должен быть контроль над основными логинами. Передача не должна зависеть от того, вспомнит ли один человек, где что лежит.

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

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

Если один человек может уйти, а ваша команда все равно знает, где код, документы и аккаунты, значит, пункт о выходе сработал как надо.

Ошибка 5: объем работ, который постоянно меняется

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

Обе стороны часто думают, что они просто гибкие. Гибкость — это хорошо. Размытый объем работ — дорого.

Начните со времени. Зафиксируйте недельный диапазон или месячный лимит письменно. Если в договоре написано «частичная занятость», но нигде не указаны 10 часов, 20 часов или месячный предел, люди заполняют пробел своими ожиданиями.

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

В договоре также нужно указать работу, которая не входит в соглашение. Частые примеры — подготовка материалов для инвесторов, участие во всех продажных звонках, ведение ежедневных стендапов или работа в роли временного engineering manager. Эти задачи могут быть важными, но они не должны тихо входить в базовую ставку.

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

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

Расплывающийся объем работ не показывает доверие. Он показывает, что договор оставил слишком много недосказанного.

Как проверить черновик перед подписанием

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

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

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

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

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

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

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

Простой пример из жизни стартапа

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

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

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

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

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

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

Быстрая проверка перед первым днем

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

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

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

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

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

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

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

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

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

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

Если вам нужен внешний взгляд, Oleg Sotnikov на oleg.is предлагает консультации для стартапов и работу с fractional CTO с глубоким опытом в продукте, инфраструктуре и командах, которые строят ПО с приоритетом на ИИ. Вторая пара глаз поможет заметить небольшие пробелы до того, как они превратятся в дорогие ошибки в договоре.