«Возьми ownership» — одна из самых бесполезных фраз менеджера.

Её удобно произносить.

Разработчик принёс проблему?

Возьми ownership.

Задача зависла?

Нужно больше ownership.

Никто не принимает решение?

Ну вы поняли.

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

1. Понятная зона ответственности

За что конкретно отвечает человек?

За сервис?

За отдельную фичу?

За техническую реализацию?

За delivery целиком?

«Отвечай за всё» обычно означает, что границы ответственности не определены вообще.

2. Полномочия

Если разработчик отвечает за сервис, но любое изменение требует согласования трёх руководителей, такой ownership носит скорее декоративный характер.

Ответственность без права принимать решения создаёт не автономию, а удобного виноватого.

3. Контекст

Чтобы принимать решения, человек должен понимать:

— зачем существует продукт; 
— какие ограничения есть у бизнеса; 
— какие риски допустимы; 
— что сейчас важнее всего.

Нельзя требовать продуктового мышления и одновременно передавать человеку только номер задачи в Jira.

4. Понятный ожидаемый результат

Ownership — это не «разберись как-нибудь».

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

Например, фраза «ты отвечаешь за сервис» сама по себе почти ничего не означает.

Нормальный ownership предполагает, что человек может:

— принимать большинство технических решений; 
— определять необходимые улучшения; 
— обсуждать SLA; 
— поднимать риски; 
— инициировать работу с техдолгом.

При этом он понимает, какие изменения можно делать самостоятельно, а какие требуют обсуждения с командой или архитекторами.

Мне кажется, зрелость команды хорошо видна именно здесь.

Не по количеству раз, когда руководитель произнёс слово ownership.

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

Conway’s Law: почему оргструктура протекает в архитектуру

Есть три команды.

Каждая отвечает за свою область. У каждой свои задачи, приоритеты и релизный цикл.

Через некоторое время в системе появляются три сервиса.

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

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

Это и есть закон Конвея:

Организации проектируют системы, структура которых повторяет структуру коммуникаций внутри организации.

Архитектура возникает не только из технических решений. На неё влияют:

— границы команд; 
— ownership компонентов; 
— процессы согласования; 
— распределение экспертизы; 
— общие базы и модели данных; 
— возможность самостоятельно выпустить изменение.

Поэтому некоторые архитектурные проблемы невозможно решить одним рефакторингом.

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

На диаграмме сервисы разделены.

В работе — всё ещё один распределённый монолит, только теперь ещё и с сетевыми ошибками.

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

Например, независимому продуктовому домену нужен end-to-end ownership.

Не только backend.

Не только frontend.

Не несколько таблиц в общей базе.

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

Поэтому хороший system design иногда начинается не с вопроса:

«Как разделить сервисы?»

А с вопроса:

«Как между людьми разделены ответственность, решения и право на релиз?»

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

Люди зачем-то продолжают участвовать в архитектуре.

Нужен ли вашей команде отдельный AI Champion

Во многих командах внедрение AI выглядит одинаково.

Один разработчик использует Copilot. Другой пишет код через Cursor. Третий собрал собственный набор промптов. Остальные попробовали пару раз, получили сомнительный результат и вернулись к привычным инструментам.

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

Здесь может помочь AI Champion — человек, который:

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

Важно: это не обязательно отдельная должность. Чаще это дополнительная роль на несколько часов в неделю.

И точно не нужно превращать AI Champion в «AI-службу поддержки».

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

Хороший результат работы AI Champion — не количество проведённых демо. А появление общего командного подхода:

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

Роль полезно ротировать раз в несколько месяцев. Иначе знания концентрируются у одного человека, а команда начинает зависеть от его интереса и доступности.

Особенно полезна ротация между разработчиками, QA, аналитиками и техлидами: у каждой роли свои сценарии применения AI.

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

А у вас AI-практики уже распространяются системно — или пока держатся на нескольких энтузиастах?