Платформенная работа и продуктовая работа в малой компании: как задать чёткую ответственность

Почему это быстро становится грязным

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

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

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

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

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

Что считается платформенной работой

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

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

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

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

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

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

Простое правило

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

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

Когда спорят о владении, смотрите на радиус поражения. Чем шире эффект, тем вероятнее, что это платформа. Чем уже эффект, тем вероятнее — продукт.

Что считается продуктовой работой

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

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

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

Этот последний момент вызывает много путаницы в малых командах. Фиче может потребоваться новый API‑эндпоинт, изменение схемы БД, фоновая задача или одноразовая интеграция. Даже если пользователь никогда не видит этот код, это всё равно продуктовая работа, когда код существует только чтобы поддержать эту фичу. Продуктовая команда отвечает за него, потому что движущей силой является пользовательская проблема.

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

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

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

Назначьте владельцев в пять шагов

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

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

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

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

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

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

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

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

Разделите владельцев деплоев без путаницы

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

Запишите каждый шаг между мерджем и продакшеном для каждого клиентского сервиса. Держите описание простым и конкретным.

• Код мерджится в main.
• Запускаются тесты и сборка.
• Артефакты публикуются.
• При необходимости применяются изменения в базе данных.
• Сервис выходит в продакшен.
• Кто‑то проверяет логи, ошибки и базовые пользовательские сценарии.
• Кто‑то откатывает, если релиз вызывает проблемы.

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

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

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

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

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

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

Управляйте общими инструментами, не становясь блокером

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

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

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

Это само по себе сильно сокращает шум. Также это делает видимыми компромиссы.

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

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

Держите список инструментов коротким

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

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

Реалистичный пример из маленькой SaaS‑команды

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

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

Продуктовая команда владеет фичей: UI, изменения API, acceptance‑чеки и дизайн базы данных — потому что схема создана ради фичи, а не ради «чистоты платформы». Ведущий платформы владеет путём деплоя: порядком миграций, обновлением CI‑конвейера, скриптом отката и проверками релиза в продакшене.

Они встречаются дважды, и обе встречи короткие. Сначала на планировании один продуктовый инженер объясняет фичу и отмечает рискованные места. Ведущий платформы задаёт два практических вопроса: можно ли применить изменение схемы без длительных блокировок базы и нужен ли новый шаг в конвейере для обратно‑совместимых релизов? Это занимает 15 минут.

Позже, прямо перед выпуском, они делают ещё одну проверку.

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

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

Теперь деплой падает. Миграция завершилась, но один API‑запрос замедлился, и health‑чеки начинают таймаутиться. Никто не ищет виноватого. Ведущий платформы откатывает путь релиза и возвращает базу в безопасную версию, которую они спланировали. Продуктовый инженер выключает фич‑флаг. Через десять минут сервис снова стабилен.

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

Ошибки, которые создают два «царства»

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

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

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

Ещё одна проблема — время. Команды любят запускать внутренние проекты, но мало кто защищает время на поддержку, апгрейды, документацию или уборку on‑call. Всё выглядит нормально, пока сломанный деплой, истёкший сертификат или флюки CI не блокируют доходную работу на целый день.

Как это выглядит на практике

Следите за такими шаблонами:

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

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

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

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

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

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

Затем протестируйте путь для небольшого клиентского изменения. Продуктовая команда должна суметь выпустить мелкий фикс или обновление текста самостоятельно, если оно остаётся в её зоне. Если то же изменение требует одобрения от платформы, DevOps и другого продуктового лидера — у вас не ясное владение, а лабиринт разрешений.

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

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

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

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

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

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

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

Попробуйте на 30 дней:

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

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

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

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

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