Перезагрузка отношений основателя и CTO после срыва сроков

Что на самом деле ломает срыв

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

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

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

Отделите срыв от людей

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

Начните с обещания, которое не было выполнено. Запишите точную дату, объем, который все считали готовящимся к релизу, и одного владельца этого обещания. Пишите простыми словами. «Бета для 10 пилотных пользователей 15 мая, владелец — CTO» намного лучше, чем «готовность этапа 1».

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

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

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

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

Пересмотрите права на решения

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

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

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

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

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

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

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

Постройте путь эскалации

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

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

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

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

Назначьте людей, которые подключаются в течение 24 часов после эскалации. Держите группу небольшой. Обычно это основатель, CTO, человек, который ведет delivery, и, при необходимости, один product owner или дизайнер, если вопрос касается объема. Десять человек в созвоне — это не синхронизация. Это задержка.

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

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

Решите, что нужно фиксировать письменно

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

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

Начните с одной страницы по объему. На ней должно быть написано, что входит в поставку, что не входит и что считается готовым. Если под «отчетностью» один человек понимает одну панель для основателя, а другой — три формата экспорта для CTO, у вас нет объема. У вас есть две личные догадки.

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

Открытые риски тоже должны быть письменно зафиксированы, и у каждого должен быть один владелец. Держите список коротким и актуальным. «Миграция может повредить старые данные клиентов, владелец: CTO, решение нужно до пятницы» — понятно. «Риск по данным» слишком расплывчато и никому не помогает.

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

Ведите заметки по встречам кратко. Трех-четырех строк часто достаточно: принятое решение, открытый вопрос, владелец, следующая дата. Длинные заметки создают ложное чувство контроля. Короткие — реально читают.

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

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

Проведите встречу по перезагрузке

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

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

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

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

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

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

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

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

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

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

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

Они исправили ситуацию двумя простыми шагами.

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

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

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

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

Ошибки, которые делают второй срыв хуже

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

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

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

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

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

Последняя ошибка — пропустить письменный follow-up. Тяжелая встреча может казаться продуктивной, но память быстро меняется. К следующему утру люди уже помнят разные обещания. Запишите перезагрузку: что остается в объеме, что уходит, кто может менять дату и когда нужно эскалировать.

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

Быстрые проверки на следующие 30 дней

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

Используйте одни и те же проверки каждую неделю. Если команда не может ответить на них за пять минут, перезагрузка уже дрейфует.

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

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

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

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

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

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

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

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

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

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

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

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

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

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