Tiny teams. Маленькие команды не берутся из воздуха.

Мне нравится идея маленьких команд. Очень нравится.

Три-четыре человека, десяток AI-агентов, и всё это хозяйство работает быстрее команды из двадцати человек.

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

Есть, правда, одна небольшая проблема.

Так не работает.

Нельзя в понедельник объявить, что теперь у нас tiny teams, во вторник раздать всем Cursor, а в среду удивляться, почему аналитик всё ещё нужен.

Мы пошли немного другим путём.

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

Задача довольно простая по формулировке: агент должен взять задачу из Jira и с высокой вероятностью сделать её правильно.

Не угадать. Не выдать красивую галлюцинацию. А сделать то, что действительно нужно команде. И вот тут начинается интересное.

Недавно у нас аналитик ушёл в отпуск.

Раньше это означало бы, что часть задач вежливо отправилась отдыхать вместе с ним.

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

И тут у меня родилась идея, которая кажется мне важнее самой концепции tiny teams.

Каждая компетенция в команде должна быть максимально заменяемой.

Когда аналитик на месте, он работает с агентом и делает свою работу быстрее. Когда аналитик в отпуске, агент выполняет условные 90%, а оставшиеся 10% докручивает команда.

То же самое с разработкой, тестированием, DevOps.

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

В тестировании есть известный принцип Shift Left. Начинать проверять качество как можно раньше.

Есть и Shift Right — проверять и изучать поведение системы уже в эксплуатации.

А я для себя придумал ещё одну интерпретацию.

Агент должен одинаково хорошо двигаться и влево, и вправо.

Разработчик должен уметь с помощью агента зайти в аналитику. Аналитик — в разработку. Тестировщик — помочь с кодом. И наоборот.

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

Но кто всему этому научит агента?

Команда.

Я для себя называю это просто — агент команды.

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

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

Аналитики учат агента анализировать. Разработчики — разрабатывать. Тестировщики — проверять. DevOps — эксплуатировать.

Причём не один раз написали промпт и забыли. Агент сделал задачу, команда проверила, исправила ошибки, внесла изменения в инструкции. И так по кругу.

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

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

И ещё одна важная вещь.

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

Поэтому качество агента я бы измерял не количеством написанного кода и не красотой ответов.

А тем, сколько работы команда принимает без существенных переделок.

И вот только после этого, как мне кажется, можно всерьёз разговаривать о tiny teams.

Потому что маленькая команда — это не большая команда, из которой убрали лишних людей.

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