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

Почему большинство уставов игнорируют

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

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

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

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

Это часто видно в работе fractional CTO. Компания тратит время на обсуждение идеальной архитектуры, а потом застревает на вещах, которые действительно тормозят delivery: ручные релизы, непонятная ответственность во время инцидентов, очереди на code review и рост затрат на инфраструктуру быстрее, чем пользуются продуктом.

В такой момент старый документ уже не просто устарел. Он направляет внимание не на ту проблему.

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

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

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

Что должно быть в уставе

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

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

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

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

Не включайте в устав подробные проектные решения. Форматы API, схемы баз данных, шаги миграции и системные диаграммы должны быть в отдельных документах, которые инженеры могут обновлять без переписывания правил команды. Устав должен объяснять, как принимать решения. А дизайн-документы — показывать, что именно было сделано.

Это разделение важно. Когда устав короткий и привязан к боли в delivery, им можно пользоваться на планировании, code review и созвонах по релизам, а не относиться к нему как к документу, который никто не открывает.

Начинайте с текущей боли в delivery

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

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

Быстрый разбор часто показывает закономерность. Релиз сдвинулся, потому что команда согласилась на неполную спецификацию. Клиентский баг два дня оставался в продакшне, потому что за алерт никто не отвечал. Фича потребовала переделки, потому что два разработчика по-разному поняли API.

Затем задайте один простой вопрос для каждого случая: что именно это вызвало?

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

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

Это ещё и момент, чтобы отбросить устаревшие страхи. Возможно, полгода назад команда боялась vendor lock-in. Теперь настоящая проблема — медленные релизы и неясная ответственность. Устав должен соответствовать сегодняшним рискам, а не спорам прошлого квартала.

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

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

Определите людей и сферу применения

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

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

Держите горизонт коротким. Устав должен помогать в ближайшие 6–12 месяцев, а не на горизонте пяти лет. Размер команды, бюджет и направление продукта могут меняться быстро. Правила, которые соответствуют текущему риску delivery, полезнее размытых обещаний о будущем.

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

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

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

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

Пишите устав по шагам

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

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

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

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

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

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

Простой пример снимает спор. Люди могут сравнить новую ситуацию с тем, что уже понятно.

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

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

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

Превращайте правила в повседневные привычки

Устав работает только тогда, когда команда использует его, пока изменения ещё дёшевы. Если он лежит в документе, который никто не открывает, он превращается в фон. Разместите его там, где люди уже принимают решения: в планировании, design review и подготовке спринта.

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

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

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

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

Фиксируйте исключения в одном простом месте. Записывайте правило, причину исключения, кто согласовал и когда вы к этому вернётесь. Формулировка должна быть простой: «Использовали кастомный сервис вместо стандартной очереди, потому что до дедлайна клиента оставалось 10 дней. Перепроверить после запуска».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Простой тест помогает: спросите, «Какую болезненную ошибку за последние два месяца это правило предотвратит?» Если никто не может ответить, уберите правило или перепишите его.

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

Быстрые проверки перед каждым пересмотром

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

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

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

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

Если никто не может показать, как правило меняет поведение, это просто украшение.

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

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

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

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

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

Сделайте первый вариант коротким. Он должен умещаться на одной странице, быть написан простым языком и покрывать правила, которые можно применять при планировании, delivery и review. Если для правила нужно длинное объяснение, оно, скорее всего, слишком размытое и не поможет.

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

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

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

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

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