Технический владелец систем в небольшой софтверной компании

Почему работа застревает между людьми

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

Backend-разработчик исправляет код. Кто-то из infrastructure меняет сервер. Support отвечает клиенту. Через неделю та же ошибка возвращается. Все были причастны. Никто не отвечал за весь путь от причины до влияния на клиента.

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

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

Именно поэтому ошибки так часто прыгают между engineering, infrastructure и support. Каждая группа может объяснить свою часть проблемы. Но никто не чувствует полной ответственности за весь путь. Support видит боль. Infrastructure видит alert. Engineering видит код. Сбой остаётся между этими точками зрения.

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

Technical owner for systems закрывает этот пробел. Этот человек отвечает за то, как общие системы работают на стыке команд: правила релизов, шаблоны сбоев, runbooks, правила доступа и дальнейшую работу, которая предотвращает повторение проблем. Обычно это полезнее, чем добавлять ещё одного координатора, потому что проблема не в нехватке обновлений. Проблема в слабой ответственности за систему.

За что отвечает эта роль

Technical owner for systems отвечает за части компании, от которых все зависят, но которые никто полностью не защищает. В большинстве небольших софтверных компаний это production, путь от кода до релиза и разбор того, что нужно после сбоя.

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

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

Здесь ответственность означает право принимать решения, а не общий объём работы. Это не значит, что один человек выкатывает каждый сервис или проверяет каждый pull request. Это значит, что один человек удерживает систему в едином виде, снимает споры и закрывает разрывы между продуктовым кодом, инфраструктурой, support и operations.

Некоторые части стека должны иметь названного владельца, потому что задержка там слишком дорога. Если изменения в схеме базы данных, billing flow, authentication, CI pipeline или production secrets могут быстро навредить клиентам, команда должна знать, кто это утверждает и какие проверки идут первыми. Небольшие команды часто называют это гибкостью. Чаще всего это просто неясная ответственность.

Помогает короткий список приоритетов. Во многих командах первые задачи простые:

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

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

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

Когда эта роль нужна раньше, чем ещё один менеджер

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

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

Одинаковые паттерны повторяются снова и снова. Outage перекидывается между frontend, backend и infrastructure, потому что каждая группа может объяснить свою часть, но никто не владеет всей цепочкой. Один senior-инженер оказывается втянут в каждый пожар, каждую проверку, каждую миграцию и каждый «быстрый вопрос». Координаторы тратят половину недели на сбор технических ответов у трёх людей и пересылку их дальше. Маленькие изменения превращаются в длинные цепочки сообщений, потому что никто не имеет права сказать: «Делаем так».

Когда так происходит, оргструктура уже даёт ответ. Вам не нужен ещё один уровень для 1:1, standup и статус-апдейтов. Вам нужен человек, который отвечает за общие технические системы, принимает кросс-системные решения и остаётся в фокусе, когда в production начинается хаос.

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

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

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

Чем эта роль не является

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

Technical owner for systems не заменяет team lead или product owner. Team lead по-прежнему занимается людьми, delivery и ежедневными вопросами команды. Product owner по-прежнему решает, что команда должна делать и зачем. Владелец системы отвечает на другой набор вопросов: как система устроена, какие изменения безопасны, где лежат риски и кто принимает решение, когда появляются компромиссы.

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

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

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

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

Как добавить роль, не устроив ещё больший хаос

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

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

Запуск можно сделать простым. Сначала запишите три-пять систем, которые дали больше всего задержек, и используйте реальные примеры. Релиз, который съехал, потому что никто не отвечал за deploy pipeline, лучше, чем общая заметка про «проблемы с координацией». Потом выберите одного владельца для этого набора. Возьмите человека, который понимает, как система ведёт себя под нагрузкой, даже если он не самый senior в команде.

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

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

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

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

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

Представьте софтверную компанию из 12 человек: пять инженеров, дизайнер, тестировщик, project manager, founder и ещё несколько людей в sales и support.

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

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

Никто не отвечает за release checklist. Никто не проверяет, совпадают ли правила CI с тем, как команда работает сейчас. Мониторинг с пробелами. Правила доступа уплывают. Мелкие изменения копятся, пока один плохой deploy не превращается в полдня разборов.

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

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

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

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

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

Ошибки, которые команды повторяют снова и снова

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

Ещё одна частая ошибка — раздать ответственность слишком многим part-time добровольцам. Один инженер смотрит CI, когда есть время. Другой проверяет production logs. Founder утверждает изменения в базе данных. Senior developer подключается во время инцидентов. На бумаге это выглядит гибко. В реальности никто не тратит достаточно времени на устранение первопричин, потому что у всех уже есть основная работа.

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

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

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

Быстрая проверка перед изменением оргструктуры

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

Календарь, забитый sync, может скрывать простой пробел: никто не отвечает за deploy pipeline, резервные копии, auth flow или billing logic целиком. Все касаются системы, но никто не решает, как её запускать, менять и защищать.

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

• Может ли один человек назвать себя владельцем каждой общей системы?
• Если изменение может сломать production, все ли знают, кто может это утвердить или остановить?
• Отслеживаете ли вы повторные инциденты по причине, а не только по дате?
• Уберёт ли ещё один координатор первопричину или просто организует реакцию?

Паттерны важнее одной плохой недели. Один неудачный релиз — это нормально. Тревожный сигнал — повторяемость: один и тот же сервис ломается, одно и то же рискованное изменение проскальзывает, одна и та же передача задач между product, engineering и operations проваливается.

Вот где эта роль действительно нужна. Она не заменяет team lead или founder. Она даёт общим системам стандарты, права на решения и доведение до результата.

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

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

Не перестраивайте всю оргструктуру сразу. Выберите одну область системы, которая уже вызывает повторяющуюся путаницу: например, deploys, billing, customer data или internal tools. Небольшие команды обычно быстрее улучшаются от одного чистого теста, чем от перестановки всей компании.

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

Держите зону ответственности узкой. «Отвечает за надёжность platform для API и deploy process» — это понятно. «Отвечает за качество engineering» — это расплывчато, а расплывчатые роли снова создают старый хаос под новым названием.

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

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

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

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