Как упростить стек стартапа, не замедляя команду

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

Большинство стеков в стартапах растут не по плану, а под давлением.

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

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

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

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

Одни и те же тревожные сигналы появляются снова и снова:

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

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

Начните с работы, а не с инструментов

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

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

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

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

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

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

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

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

Решите, что оставить, а что убрать

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

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

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

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

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

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

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

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

Сбросьте стандартные настройки, которыми пользуется команда

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

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

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

Сделайте обычный путь очевидным

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

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

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

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

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

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

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

План чистки, который не сломает команду

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

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

Хорошо работает такой порядок:

1. Сначала наведите порядок с ответственностью, а потом уже что-то удаляйте. У каждого инструмента должен быть назначенный владелец, общий административный доступ и понятная дата продления. Команды часто теряют больше из-за случайной блокировки доступа в неподходящий момент, чем экономят на быстрой отмене.
2. Переносите один рабочий поток, а не одно приложение. Начните с отчётов об ошибках, передачи дизайна или заметок о релизах. Сделайте изменение достаточно маленьким, чтобы его можно было проверить на реальной работе.
3. Запустите новую схему на неделю или две. Не полагайтесь на демо. Пропустите через неё реальные задачи и посмотрите, где работа застревает, где пропускают согласования и где люди всё ещё возвращаются к старому инструменту.
4. Сначала архивируйте, потом закрывайте. Выгрузите данные, сохраните журналы и запишите, что было перенесено, а что нет. Потом назначьте дату выключения неиспользуемых аккаунтов, а не оставляйте их полуживыми на месяцы.

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

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

Простой пример из растущего стартапа

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

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

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

Они исправили ситуацию, разобрав один типичный поток: обращение клиента, разбор, спецификация, разработка, релиз, последующие действия. Как только они записали этот путь, дубли стали очевидны. Три инструмента хранили документы. Два инструмента хранили тикеты. Алерты приходили из нескольких сервисов, но никто не отвечал за полный след инцидента.

Тогда они сократили стек.

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

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

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

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

Ошибки, которые тормозят чистку

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

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

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

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

Есть несколько признаков, что чистка идёт не туда:

• Люди не могут объяснить, зачем существует инструмент, а помнят только, кто попросил его годы назад.
• Две системы делают одну и ту же работу, но каждая команда доверяет своей.
• Доступ администратора есть только у одного человека.
• «Временные» исключения живут месяцами.

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

Быстрая проверка перед удалением чего-либо

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

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

Используйте короткую проверку перед удалением:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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