Аудит CTO в первую неделю: клиентские обещания уже под угрозой

Почему живые обещания важнее всего

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

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

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

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

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

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

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

Составьте список обещаний, за которые клиенты уже заплатили

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

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

Превратите каждое обещание в одно короткое предложение. Делайте его конкретным. Синхронизация данных завершается меньше чем за 10 минут — полезно. Быстрая выгрузка — нет. Двусторонняя синхронизация с Salesforce — проверяемо. Работает с вашим процессом — не говорит почти ничего.

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

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

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

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

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

Привяжите каждое обещание к стеку

Обещание важно только тогда, когда стек может его выдержать.

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

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

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

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

Ручная работа тоже заслуживает отдельного внимания. Многие стартапы незаметно зависят от того, что кто-то выгружает CSV, перезапускает воркер, подтверждает очередь или проверяет входящие письма до того, как клиенты что-то заметят. Днём во вторник это ещё может держаться. Ночью, в выходные и в праздники всё разваливается.

Допустим, SaaS-компания обещает ежедневные отчёты к 8:00. Реальная цепочка может выглядеть так: ночной импорт данных, задача очистки в 1:00, генерация отчёта в 4:00, отправка письма в 7:00 и проверка поддержки в 8:30. Если задача очистки падает, а никто не замечает этого до начала рабочего дня, обещание для всей этой партии клиентов уже нарушено.

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

Оцените ущерб до того, как трогать код

Сломанное обещание бьёт не сразу. Ущерб нарастает по слоям.

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

Прежде чем кто-то откроет редактор, оцените каждую проблему по трём промежуткам времени:

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

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

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

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

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

Проведите аудит в первую неделю

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

Пять сосредоточенных дней обычно достаточно, чтобы расставить приоритеты.

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

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

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

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

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

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

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

Простой пример из SaaS-команды

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

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

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

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

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

Всё это не выглядит эффектно. Но оно решает то, что в первую очередь бьёт по выручке.

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

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

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

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

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

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

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

Ещё одна частая ошибка — огромный документ по аудиту. Новые CTO иногда тратят дни на отчёт в 40 страниц, полный заметок по архитектуре, оценок рисков и будущих идей. Потом за исправления никто не отвечает, и ничего не меняется. Работает лучше более короткий документ с понятными владельцами, сроками и простым порядком действий.

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

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

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

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

Команды часто останавливаются на шаг раньше. Они находят баг, пишут патч, выкатывают его и считают, что всё сделано.

Пять проверок перед релизом

• Попросите одного человека в одном предложении объяснить клиентское обещание, а затем описать точный путь сбоя. Если он уходит в детали кода или рассказывает две разные версии, команда ещё не поняла настоящий риск.
• Проверьте, как быстро вы замечаете повтор проблемы. Хороший мониторинг должен показывать её за минуты. Если вы узнаёте о проблеме только из злых писем или когда основатель вручную смотрит логи, система всё ещё уязвима.
• Дайте поддержке простой ответ до выхода релиза. Клиентам не нужен урок про очереди, блокировки или таймауты базы данных. Им нужна ясная фраза о том, что пошло не так, кого это затронуло и что изменилось.
• Протестируйте откат так, как будто ждёте проблемы. Если команде нужен длинный runbook, три согласования и удачная догадка, откат не является реальным.
• Решите, что будет считаться доказательством после релиза. Выберите один или два сигнала, связанных с самим обещанием, например, процент успешных оплат, время завершения выгрузки или число неудачных входов.

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

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

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

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

Возьмите два или три главных риска из аудита и превратите их в 30-дневный план. Сохраняйте его коротким. Если вы перечислите десять исправлений, команда не закончит ни одно.

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

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

Используйте метрики, которые сможет понять любой. Клиентские тикеты о неудачных импортах падают с 12 в неделю до 2 — отлично. Ошибки на этапе оплаты держатся ниже 0,5% в течение 14 дней — тоже отлично. Улучшить надёжность — слишком расплывчато и потом только вызовет споры.

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

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

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

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

Хороший 30-дневный план должен казаться немного скучным. Обычно это хороший знак. Значит, команда понимает, что сломалось, кто это исправит и как она поймёт, что исправление сработало.