Технические memo для CTO стартапа: первые три, которые стоит написать

Почему команды расходятся до выхода продукта

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

Фаундеры думают о запасе денег, сроках запуска и следующем разговоре с клиентом. Инженеры думают о точках отказа, переделках и о том, что может сломаться в 2 часа ночи. Эти взгляды могут совпадать, но только если кто-то четко записывает компромиссы.

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

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

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

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

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

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

Что должно делать техническое memo

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

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

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

Чаще всего memo хорошо работает из четырех частей:

• решение или рекомендация
• проблема простыми словами
• цена ожидания
• следующий ответственный и срок

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

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

Простой пример показывает разницу. Если стартап хочет запустить аналитику, но event pipeline теряет 8 процентов записей, memo должно сказать: отложить запуск на один спринт, починить pipeline и принять недельную задержку сейчас вместо того, чтобы выпускать цифры, которым никто не будет доверять. В этом и состоит задача memo. Сократить спор и дать команде понятный ход.

Memo первое: заметка о рисках

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

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

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

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

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

У действия должен быть срок, который достаточно близок, чтобы что-то значил. «Понаблюдаем» — слабо. «Mina добавит тестирование failover для базы данных до следующей пятницы» дает команде то, что можно реально проверить.

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

Memo второе: заметка о марже

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

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

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

Сильная заметка о марже отвечает на несколько прямых вопросов:

• Сколько платит один клиент?
• Сколько стоит обслуживание этого клиента в месяц?
• Какие функции добавляют расходы каждый раз, когда растет использование?
• Какие цифры — это догадки, а не факты?

Последний вопрос важнее, чем многие ожидают. Ранние планы полны предположений. Вы можете думать, что только 10 процентов пользователей будут трогать функцию на базе ИИ, или что настройка займет 30 минут вместо двух часов. Запишите эти предположения в memo и укажите, как вы проверите их на реальном использовании.

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

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

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

Memo третье: заметка о блокерах поставки

Выпуск часто тормозят причины, которые слишком долго остаются расплывчатыми. Люди говорят, что команда «загружена» или «под давлением», но это не помогает никому исправить сроки. Это memo должно назвать конкретные вещи, которые сегодня замедляют поставку.

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

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

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

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

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

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

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

Как написать три memo за одну неделю

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

Если команда планирует запустить self-serve billing через две недели, пишите все три memo вокруг этого. Не пытайтесь охватить все риски системы или все строки расходов компании. Пишите о том, что может навредить этому релизу, этой марже и этому плану поставки.

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

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

Заметку о блокерах обычно писать проще всего. Команда уже говорит вам, что кажется медленным, грязным или неясным. Вытащите эти жалобы из стендапов, чатов и one-on-one, а затем перепишите их как проблемы, которые можно исправить. «Деплой занимает 40 минут» — полезно. «Нам нужен лучший процесс» — нет.

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

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

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

Простой пример из небольшой продуктовой команды

Стартап на seed-стадии строит B2B-инструмент для операционных команд. Продукт еще ранний. В команде один дизайнер, четыре инженера и фаундер, который пытается закрыть первого крупного клиента.

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

Именно здесь помогают три memo. Не длинные документы. Просто три короткие заметки, которые заставляют команду посмотреть на одну и ту же проблему с трех сторон.

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

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

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

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

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

Ошибки, из-за которых memo бесполезны

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

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

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

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

Memo без имен и дат — это просто жалоба. «Миграция API отстает» — туман. «Mina закончит миграцию auth к четвергу; если нет, релиз мобильного приложения сдвинется на неделю» — уже рабочая формулировка. Каждому серьезному пункту нужен владелец, следующий шаг и срок.

Перед отправкой помогает быстрый тест:

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

Если на любой из этих вопросов ответ «нет», уберите еще больше.

Быстрая проверка перед тем, как делиться

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

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

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

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

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

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

Что делать после первого черновика

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

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

Хорошая проверка выглядит так:

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

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

Это важно, потому что показывает, где компания просто гадала. Если в первом memo о рисках было написано «низкий compliance-риск», а потом два enterprise-клиента просят audit logs, это изменение должно остаться видимым. Если в memo о марже было заложено низкое количество обращений в поддержку, а онбординг начинает съедать шесть часов в неделю, это тоже стоит сохранить.

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

Иногда взгляд со стороны помогает, потому что свежая пара глаз быстро замечает расплывчатое мышление. Oleg Sotnikov на oleg.is работает со стартапами и небольшими компаниями над такими задачами как fractional CTO и советник, особенно когда команде нужен более ясный план по объему работ, инфраструктуре и поставке. Цель — не больше процессов. Цель — план, которому люди действительно могут следовать.

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