Conway’s Law: почему оргструктура протекает в архитектуру
Есть три команды.
Каждая отвечает за свою область. У каждой свои задачи, приоритеты и релизный цикл.
Через некоторое время в системе появляются три сервиса.
Между командами изменения проходят через долгие согласования. В архитектуре вырастают сложные интеграции.
Одна команда не может получить нужное изменение от другой без очереди, встречи и пары задач в Jira. Вскоре сервисы начинают зависеть друг от друга примерно так же.
Это и есть закон Конвея:
Архитектура возникает не только из технических решений. На неё влияют:
— границы команд;
— ownership компонентов;
— процессы согласования;
— распределение экспертизы;
— общие базы и модели данных;
— возможность самостоятельно выпустить изменение.
Поэтому некоторые архитектурные проблемы невозможно решить одним рефакторингом.
Можно формально разделить монолит на два сервиса. Но если для любого изменения команды по-прежнему должны синхронизироваться, согласовывать общий релиз и вместе менять одну модель данных, независимости не появилось.
На диаграмме сервисы разделены.
В работе — всё ещё один распределённый монолит, только теперь ещё и с сетевыми ошибками.
Есть и обратный подход: Inverse Conway Maneuver. Если нужна определённая архитектура, границы команд сознательно выстраивают так, чтобы её поддерживать.
Например, независимому продуктовому домену нужен end-to-end ownership.
Не только backend.
Не только frontend.
Не несколько таблиц в общей базе.
Команда должна иметь возможность сама провести изменение от идеи до пользователя: изменить код, проверить его, выпустить и отвечать за результат.
Поэтому хороший system design иногда начинается не с вопроса:
«Как разделить сервисы?»
А с вопроса:
«Как между людьми разделены ответственность, решения и право на релиз?»
Нарисовать независимые прямоугольники на диаграмме легко. Сделать так, чтобы команды действительно могли менять их независимо, заметно сложнее.
Люди зачем-то продолжают участвовать в архитектуре.
Есть три команды.
Каждая отвечает за свою область. У каждой свои задачи, приоритеты и релизный цикл.
Через некоторое время в системе появляются три сервиса.
Между командами изменения проходят через долгие согласования. В архитектуре вырастают сложные интеграции.
Одна команда не может получить нужное изменение от другой без очереди, встречи и пары задач в Jira. Вскоре сервисы начинают зависеть друг от друга примерно так же.
Это и есть закон Конвея:
Организации проектируют системы, структура которых повторяет структуру коммуникаций внутри организации.
Архитектура возникает не только из технических решений. На неё влияют:
— границы команд;
— ownership компонентов;
— процессы согласования;
— распределение экспертизы;
— общие базы и модели данных;
— возможность самостоятельно выпустить изменение.
Поэтому некоторые архитектурные проблемы невозможно решить одним рефакторингом.
Можно формально разделить монолит на два сервиса. Но если для любого изменения команды по-прежнему должны синхронизироваться, согласовывать общий релиз и вместе менять одну модель данных, независимости не появилось.
На диаграмме сервисы разделены.
В работе — всё ещё один распределённый монолит, только теперь ещё и с сетевыми ошибками.
Есть и обратный подход: Inverse Conway Maneuver. Если нужна определённая архитектура, границы команд сознательно выстраивают так, чтобы её поддерживать.
Например, независимому продуктовому домену нужен end-to-end ownership.
Не только backend.
Не только frontend.
Не несколько таблиц в общей базе.
Команда должна иметь возможность сама провести изменение от идеи до пользователя: изменить код, проверить его, выпустить и отвечать за результат.
Поэтому хороший system design иногда начинается не с вопроса:
«Как разделить сервисы?»
А с вопроса:
«Как между людьми разделены ответственность, решения и право на релиз?»
Нарисовать независимые прямоугольники на диаграмме легко. Сделать так, чтобы команды действительно могли менять их независимо, заметно сложнее.
Люди зачем-то продолжают участвовать в архитектуре.
❤3👍2🔥1
Нужен ли вашей команде отдельный AI Champion
Во многих командах внедрение AI выглядит одинаково.
Один разработчик использует Copilot. Другой пишет код через Cursor. Третий собрал собственный набор промптов. Остальные попробовали пару раз, получили сомнительный результат и вернулись к привычным инструментам.
Проблема не в мотивации команды. Просто AI adoption плохо масштабируется, если каждый разработчик заново изобретает свой способ работы.
Здесь может помочь AI Champion — человек, который:
— тестирует новые инструменты на реальных задачах;
— собирает удачные сценарии и промпты;
— поддерживает инструкции и командные правила;
— показывает коллегам практические примеры;
— помогает новичкам быстрее освоить рабочий набор инструментов;
— следит, чтобы AI использовался безопасно и осмысленно.
Важно: это не обязательно отдельная должность. Чаще это дополнительная роль на несколько часов в неделю.
И точно не нужно превращать AI Champion в «AI-службу поддержки».
Он не должен писать промпты за всех, разбираться с каждой настройкой и отвечать на бесконечное «а какой инструмент лучше?». Его задача — не стать единственным экспертом, а сделать так, чтобы знания распространялись по команде.
Хороший результат работы AI Champion — не количество проведённых демо. А появление общего командного подхода:
— какие инструменты разрешены;
— для каких задач они полезны;
— что нельзя отправлять во внешние модели;
— как проверять сгенерированный код;
— где лежат рабочие примеры и инструкции.
Роль полезно ротировать раз в несколько месяцев. Иначе знания концентрируются у одного человека, а команда начинает зависеть от его интереса и доступности.
Особенно полезна ротация между разработчиками, QA, аналитиками и техлидами: у каждой роли свои сценарии применения AI.
AI Champion нужен не для того, чтобы использовать AI лучше всех. Он нужен, чтобы всей команде не приходилось начинать с нуля.
А у вас AI-практики уже распространяются системно — или пока держатся на нескольких энтузиастах?
Во многих командах внедрение AI выглядит одинаково.
Один разработчик использует Copilot. Другой пишет код через Cursor. Третий собрал собственный набор промптов. Остальные попробовали пару раз, получили сомнительный результат и вернулись к привычным инструментам.
Проблема не в мотивации команды. Просто AI adoption плохо масштабируется, если каждый разработчик заново изобретает свой способ работы.
Здесь может помочь AI Champion — человек, который:
— тестирует новые инструменты на реальных задачах;
— собирает удачные сценарии и промпты;
— поддерживает инструкции и командные правила;
— показывает коллегам практические примеры;
— помогает новичкам быстрее освоить рабочий набор инструментов;
— следит, чтобы AI использовался безопасно и осмысленно.
Важно: это не обязательно отдельная должность. Чаще это дополнительная роль на несколько часов в неделю.
И точно не нужно превращать AI Champion в «AI-службу поддержки».
Он не должен писать промпты за всех, разбираться с каждой настройкой и отвечать на бесконечное «а какой инструмент лучше?». Его задача — не стать единственным экспертом, а сделать так, чтобы знания распространялись по команде.
Хороший результат работы AI Champion — не количество проведённых демо. А появление общего командного подхода:
— какие инструменты разрешены;
— для каких задач они полезны;
— что нельзя отправлять во внешние модели;
— как проверять сгенерированный код;
— где лежат рабочие примеры и инструкции.
Роль полезно ротировать раз в несколько месяцев. Иначе знания концентрируются у одного человека, а команда начинает зависеть от его интереса и доступности.
Особенно полезна ротация между разработчиками, QA, аналитиками и техлидами: у каждой роли свои сценарии применения AI.
AI Champion нужен не для того, чтобы использовать AI лучше всех. Он нужен, чтобы всей команде не приходилось начинать с нуля.
А у вас AI-практики уже распространяются системно — или пока держатся на нескольких энтузиастах?
👍3
Что добавить в матрицу разработчика в эпоху AI
Раньше путь junior → senior выглядел относительно понятно.
Сначала разработчик решает простые задачи по готовому описанию. Потом берёт более сложные, проектирует решения и помогает другим.
С AI первая ступень начинает ломаться. Агент может написать код быстрее, чем junior успеет разобраться в задаче. Тикет закрыт, PR создан, тесты зелёные. Но произошло ли обучение — непонятно.
Поэтому строки «знает язык» и «умеет реализовать задачу» уже недостаточно. В матрице нужно оценивать ещё несколько вещей.
Декомпозиция задачи для агента
Разработчик умеет разбить большую задачу на части с понятными границами, входами и критериями готовности. Не просит «сделать авторизацию», а последовательно выделяет контракт, модель данных, проверки, миграцию и тесты.
Работа с контекстом
AI не знает договорённостей команды, истории проекта и причин странных архитектурных решений. Разработчик должен уметь восстановить этот контекст и передать агенту только то, что действительно нужно.
Верификация результата
«Код выглядит нормально» больше не считается проверкой. Нужно уметь проверить поведение, граничные случаи, безопасность, производительность и соответствие требованиям. Тесты здесь важны, но сами по себе ничего не гарантируют: их тоже мог сгенерировать тот же агент.
Способность объяснить код
Если разработчик не может объяснить, почему решение устроено именно так, какие у него ограничения и где оно может сломаться, он этим решением не владеет. Даже если код уже работает в проде.
Управление риском
Сгенерировать CRUD и изменить механизм авторизации — задачи с разной ценой ошибки. Зрелость разработчика проявляется в том, насколько он умеет выбирать глубину проверки, размер изменения и необходимость ручного ревью.
Выбор задач для AI
Не всё нужно отдавать агенту. Иногда быстрее написать самому. Иногда важнее сначала разобраться в предметной области. А иногда передача контекста займёт больше времени, чем сама задача.
Способность работать без AI
Разработчик должен сохранять базовые навыки: читать чужой код, отлаживать, проектировать и принимать решения самостоятельно. Иначе при первой нестандартной ошибке он останется один на один с агентом, который уверенно предлагает четвёртый неправильный вариант.
При этом я бы не добавлял в матрицу отдельную строку «умеет пользоваться AI». Это слишком похоже на «умеет пользоваться IDE».
Лучше изменить описание уровней.
Junior может использовать AI для ограниченной задачи и объяснить полученный результат.
Middle самостоятельно ставит агенту задачи, собирает контекст и проверяет решение.
Senior определяет границы применения AI, управляет рисками и выстраивает правила работы для команды.
Главный сдвиг простой: оценивать нужно уже не только способность написать код, но и способность отвечать за результат, часть которого написал не ты.
А ваша матрица уже различает «быстро сгенерировал» и «понимает, проверил и готов отвечать»?
Раньше путь junior → senior выглядел относительно понятно.
Сначала разработчик решает простые задачи по готовому описанию. Потом берёт более сложные, проектирует решения и помогает другим.
С AI первая ступень начинает ломаться. Агент может написать код быстрее, чем junior успеет разобраться в задаче. Тикет закрыт, PR создан, тесты зелёные. Но произошло ли обучение — непонятно.
Поэтому строки «знает язык» и «умеет реализовать задачу» уже недостаточно. В матрице нужно оценивать ещё несколько вещей.
Декомпозиция задачи для агента
Разработчик умеет разбить большую задачу на части с понятными границами, входами и критериями готовности. Не просит «сделать авторизацию», а последовательно выделяет контракт, модель данных, проверки, миграцию и тесты.
Работа с контекстом
AI не знает договорённостей команды, истории проекта и причин странных архитектурных решений. Разработчик должен уметь восстановить этот контекст и передать агенту только то, что действительно нужно.
Верификация результата
«Код выглядит нормально» больше не считается проверкой. Нужно уметь проверить поведение, граничные случаи, безопасность, производительность и соответствие требованиям. Тесты здесь важны, но сами по себе ничего не гарантируют: их тоже мог сгенерировать тот же агент.
Способность объяснить код
Если разработчик не может объяснить, почему решение устроено именно так, какие у него ограничения и где оно может сломаться, он этим решением не владеет. Даже если код уже работает в проде.
Управление риском
Сгенерировать CRUD и изменить механизм авторизации — задачи с разной ценой ошибки. Зрелость разработчика проявляется в том, насколько он умеет выбирать глубину проверки, размер изменения и необходимость ручного ревью.
Выбор задач для AI
Не всё нужно отдавать агенту. Иногда быстрее написать самому. Иногда важнее сначала разобраться в предметной области. А иногда передача контекста займёт больше времени, чем сама задача.
Способность работать без AI
Разработчик должен сохранять базовые навыки: читать чужой код, отлаживать, проектировать и принимать решения самостоятельно. Иначе при первой нестандартной ошибке он останется один на один с агентом, который уверенно предлагает четвёртый неправильный вариант.
При этом я бы не добавлял в матрицу отдельную строку «умеет пользоваться AI». Это слишком похоже на «умеет пользоваться IDE».
Лучше изменить описание уровней.
Junior может использовать AI для ограниченной задачи и объяснить полученный результат.
Middle самостоятельно ставит агенту задачи, собирает контекст и проверяет решение.
Senior определяет границы применения AI, управляет рисками и выстраивает правила работы для команды.
Главный сдвиг простой: оценивать нужно уже не только способность написать код, но и способность отвечать за результат, часть которого написал не ты.
А ваша матрица уже различает «быстро сгенерировал» и «понимает, проверил и готов отвечать»?
👍2❤1
У хорошего AI-агента должно быть право сказать «не знаю»
Плохой сценарий работы с AI-агентом выглядит так:
он получил задачу, столкнулся с неопределённостью, сам додумал недостающие детали и уверенно пошёл дальше.
Через час у нас готово решение. Только не той задачи.
Мы много обсуждаем Human in the Loop как набор точек, где человек должен нажать Approve. Но проблема не только в согласовании действий. Агент должен понимать, когда продолжать работу уже нельзя.
По сути, ему нужна escalation policy. Такая же, как у инженера: вот ситуации, в которых не нужно героически разбираться в одиночку, нужно позвать того, у кого есть контекст или полномочия.
Я бы заложил эскалацию минимум в семи случаях:
1. Конфликт требований
В документации написано одно, в задаче другое, а код реализует третье.
2. Недостаточный контекст
Непонятны бизнес-правила, ограничения или критерии готовности. Продолжать можно только через догадки.
3. Неизвестная зависимость
Агент обнаружил сервис, библиотеку или интеграцию, роль которой не может надёжно определить.
4. Необратимое действие
Удаление данных, изменение production-инфраструктуры, публикация, платёж или миграция без понятного отката.
5. Резкое расширение scope
Задача начиналась с небольшого исправления, а внезапно потребовала переписать модуль и изменить несколько соседних систем.
6. Низкая уверенность проверки
Код написан, но тесты не покрывают нужный сценарий, окружение недоступно или результат нельзя проверить автоматически.
7. Изменение критичной архитектуры
Решение затрагивает модель данных, границы сервисов, протоколы обмена или требования безопасности.
При эскалации агент не должен просто сообщать: «Не получилось».
Хорошая эскалация содержит четыре вещи:
- где именно возникла неопределённость;
- почему агент не может безопасно выбрать сам;
- какие варианты он видит;
- что можно сделать дальше без риска.
Например:
Это не отказ от автономности. Наоборот, это признак нормальной автономности: агент способен действовать самостоятельно и распознавать границы своих полномочий и знаний.
Если агент всегда доводит задачу до конца, даже когда не понимает происходящее, это не самостоятельность. Это отсутствие предохранителей.
Поэтому при проектировании агента стоит спросить не только «что он умеет делать», но и:
при каких условиях он обязан остановиться?
У людей такие правила обычно появляются после первого серьёзного инцидента. Для AI-агентов лучше определить их заранее.
Плохой сценарий работы с AI-агентом выглядит так:
он получил задачу, столкнулся с неопределённостью, сам додумал недостающие детали и уверенно пошёл дальше.
Через час у нас готово решение. Только не той задачи.
Мы много обсуждаем Human in the Loop как набор точек, где человек должен нажать Approve. Но проблема не только в согласовании действий. Агент должен понимать, когда продолжать работу уже нельзя.
По сути, ему нужна escalation policy. Такая же, как у инженера: вот ситуации, в которых не нужно героически разбираться в одиночку, нужно позвать того, у кого есть контекст или полномочия.
Я бы заложил эскалацию минимум в семи случаях:
1. Конфликт требований
В документации написано одно, в задаче другое, а код реализует третье.
2. Недостаточный контекст
Непонятны бизнес-правила, ограничения или критерии готовности. Продолжать можно только через догадки.
3. Неизвестная зависимость
Агент обнаружил сервис, библиотеку или интеграцию, роль которой не может надёжно определить.
4. Необратимое действие
Удаление данных, изменение production-инфраструктуры, публикация, платёж или миграция без понятного отката.
5. Резкое расширение scope
Задача начиналась с небольшого исправления, а внезапно потребовала переписать модуль и изменить несколько соседних систем.
6. Низкая уверенность проверки
Код написан, но тесты не покрывают нужный сценарий, окружение недоступно или результат нельзя проверить автоматически.
7. Изменение критичной архитектуры
Решение затрагивает модель данных, границы сервисов, протоколы обмена или требования безопасности.
При эскалации агент не должен просто сообщать: «Не получилось».
Хорошая эскалация содержит четыре вещи:
- где именно возникла неопределённость;
- почему агент не может безопасно выбрать сам;
- какие варианты он видит;
- что можно сделать дальше без риска.
Например:
В задаче требуется удалить старые записи, но политика хранения данных не указана. Я нашёл два возможных правила в документации, и они противоречат друг другу. Могу подготовить dry run и список затронутых записей, но удаление останавливаю до уточнения.
Это не отказ от автономности. Наоборот, это признак нормальной автономности: агент способен действовать самостоятельно и распознавать границы своих полномочий и знаний.
Если агент всегда доводит задачу до конца, даже когда не понимает происходящее, это не самостоятельность. Это отсутствие предохранителей.
Поэтому при проектировании агента стоит спросить не только «что он умеет делать», но и:
при каких условиях он обязан остановиться?
У людей такие правила обычно появляются после первого серьёзного инцидента. Для AI-агентов лучше определить их заранее.
❤1