Узкое место в знаниях основателя и скрытые издержки контекста

Как это выглядит через несколько месяцев

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

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

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

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

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

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

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

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

Почему каждый новый сотрудник замедляет процесс

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

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

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

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

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

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

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

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

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

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

С процессом деплоя та же проблема. Три месяца назад основатель изменил его во время ночного инцидента. Перед релизом теперь есть один ручной шаг, потому что одна миграция может заблокировать таблицу, если запустить ее слишком рано. Основатель это помнит. Репозиторий — нет. В чате нет заметки, нет короткой инструкции и нет простого чек-листа для релизов.

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

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

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

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

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

Соберите базовый пакет для передачи дел

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

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

Простой стартовый пакет состоит из четырех частей: страницы с системами, карты ответственности, заметок по доступам и рабочей инструкции.

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

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

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

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

В конце добавьте короткий журнал решений. Зафиксируйте последние продуктовые или архитектурные выборы и почему команда их сделала. «Мы оставили одну общую базу данных, потому что ее разделение замедлит следующие три релиза» — этого достаточно. Как и «Мы выбрали сначала вход по email, потому что enterprise SSO не входит в этот квартал». Такие заметки не дают новым сотрудникам заново поднимать старые споры и повторять работу.

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

Где устные решения порождают переделки

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

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

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

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

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

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

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

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

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

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

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

Учетные данные — еще одна ловушка. Если основатель хранит production-логины в личном приложении для заметок или в менеджере паролей, которым управляет только он, команда не может действовать без разрешения. Даже простая работа замедляется. Кому-то нужен доступ к логам, облачному аккаунту или почтовому сервису, и десятиминутная задача превращается в паузу на полдня.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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