Servant leader без команды: что осталось от руководителя, когда исполнителем стал агент

Три года назад на Saint TeamLead Conf я рассказывал, как меня назначили руководителем, я не справился, ушёл с роли - и вернулся в неё. Вот что было дальше.

У меня был проект, который умер. Состояние на момент остановки: 88% задач закрыты, 445 тестов в репозитории - и ни одной сборки, которая падала бы от красного. И ни одного демо заказчику, прошедшего в полном объёме. Ни разу

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

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

Что ещё будет:

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

• Неудобная находка. Агенты делают ровно то, что я прошу. Значит, когда люди делали не то, проблема была не в них. Здесь же сходятся те самые 88% - определения готовности не существовало, оно жило у меня в голове, и каждая из тридцати задач была честно закрыта по своему собственному определению. Правило "до зеленого " оказалось первым письменным определением готовности в истории проекта. Что стало с тестами, когда у них появилась работа: e2e выросли в 9 раз, бэкенд — вдвое. Растёт то, на чём стоит решение.

• Я не сбежал от менеджмента. ADR до кода, DoD, разделение исполнителя и приёмщика, гейт приёмки. То есть процессной дисциплины стало больше, а не меньше. Кто думает, что агенты отменяют менеджмент, просто ещё не выкатывал ими в прод.

• Чего агент не делает и где граница применимости - разберемсяс этим и с возражением "сейчас будет вал сгенерированного говнокода". И мой ответ не "зато быстро", а критерий, по которому решается, сколько качества продукт вообще обязан стоить.

Что заберете: способ пересчитать замороженные проекты по новым коэффициентам и понять, какие из них живые; почему "команда делает не то" почти всегда диагноз руководителю; что из менеджерской операционки одинаково работает на людях и на агентах, а что было компенсацией её отсутствия; рабочий критерий качества для разработки с агентами