Соглашение о работе между фаундером и техлидом, которое сокращает переделки

Почему работа всё время возвращается к фаундеру

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

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

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

Из-за этого переделки появляются очень быстро. Команда делает версию one, а потом слышит, что фича должна быть нацелена на другого клиента. Инженеры переписывают поток. QA снова всё проверяет. Релиз-ноты меняются. Календарь сдвигается, а сам продукт почти нет.

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

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

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

Что должно быть в соглашении на одной странице

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

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

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

В блоке бюджета пропишите лимиты одобрения простыми числами. Здесь хорошо работает скучная точность. «Техлид может одобрять инструменты до $300 в месяц» — гораздо лучше, чем «разумные расходы на софт».

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

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

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

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

Как разделить решения без путаницы

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

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

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

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

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

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

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

Как настроить правила бюджета, которым будут следовать

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

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

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

Большинству команд подходят три диапазона расходов:

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

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

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

Небольшой стартап может использовать такие правила: техлид может одобрять до $1,000 в месяц на обычный софт, до $3,000 на разовую инженерную задачу и временную работу подрядчика до двух недель. Фаундер по-прежнему утверждает новые долгосрочные контракты, любой незапланированный рост облачных расходов выше 15% от месячной цели и всё, что добавляет постоянные затраты.

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

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

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

Как должны работать права на эскалацию

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

Большинству команд хватает нескольких триггеров:

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

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

Когда меняется scope, в разговоре должны участвовать фаундер и техлид, а если есть product owner — ещё и он. Когда меняются деньги, подключайте того, кто контролирует расходы, чаще всего это фаундер, финансовый руководитель или операционный руководитель. Когда сдвигаются сроки запуска, добавляйте человека, который отвечает за продажи или общение с клиентами, чтобы никто не пообещал дату, которую команда не сможет выдержать. Если в компании есть fractional CTO, он может помочь с архитектурой, наймом или компромиссами по delivery, где нужен более высокий уровень оценки.

Срок ответа тоже важен. Без него каждое сообщение либо звучит как пожарная тревога, либо остаётся без ответа слишком долго. Хорошо работает простое правило:

• срочно: ответ в течение 1 часа в рабочее время, решение в тот же день
• важно, но не срочно: ответ в течение 4 рабочих часов, решение в течение 24 часов
• обычная эскалация: ответ в течение 1 рабочего дня, решение в течение 2 рабочих дней

Слово «срочно» используйте редко. Сломанный checkout — это срочно. Идея приятной, но необязательной фичи — нет.

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

Как составить это за одну рабочую сессию

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

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

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

Например: «Техлид может одобрять инструменты до $500 в месяц, если они ускоряют delivery». Или: «Фаундер утверждает любое изменение scope, которое сдвигает дату запуска». Если для объяснения одной фразы нужен целый абзац, перепишите её.

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

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

Держите первую версию маленькой. Десять понятных правил лучше двадцати пяти размытых. Через две недели пересмотрите страницу и исправьте решения, которые всё ещё казались мутными. Большинство первых черновиков не проваливаются драматично. Они ломаются в мелких, раздражающих моментах, которые каждый раз съедают по полдня.

Если у вас уже есть fractional CTO advisor, он может провести эту сессию и помочь сохранить язык простым. Но документ всё равно должен отражать то, как фаундер и техлид работают на самом деле, а не то, как им хотелось бы работать.

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

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

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

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

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

Они также ввели одно чёткое правило по расходам. Команда нанимала подрядчиков для дизайна и очистки данных, но только в пределах лимита, который все знали. Если кто-то хотел выйти за него, запрос в тот же день уходил к фаундеру с тремя фактами: стоимость, причина и что именно сдвинется, если подождать.

Изменения почувствовались быстро. Еженедельное планирование стало короче. Фаундер перестал переписывать технические задачи. Техлид перестал спрашивать разрешение на каждое архитектурное решение.

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

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

Ошибки, которые ломают соглашение

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

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

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

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

Несколько простых исправлений помогают:

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

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

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

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

Быстрая проверка перед тем, как начать использовать соглашение

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

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

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

Используйте такой быстрый тест:

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

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

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

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

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

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

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

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

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

• какие решения стали приниматься быстрее
• какие лимиты расходов сработали в реальных случаях
• какие вопросы всё ещё требовали эскалации
• какими правилами никто не пользовался

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

Если после одного пересмотра разделение всё ещё кажется запутанным, поможет внешний взгляд. Advisor-ы, которые работают как Fractional CTO, часто быстро замечают пересечения, потому что видели тот же паттерн во многих командах. Oleg Sotnikov на oleg.is делает именно такую startup-advisory работу, и короткий обзор может помочь чётко настроить границы решений, не превращая простую страницу в имитацию процесса.