В какой-то момент я заметила неприятную закономерность. Задачи не заканчиваются. Технический долг копится. Команда начинает перерабатывать.

При этом дело было не в том, что мы «плохо работали». У нас было много активных проектов, а задачи, напрямую влияющие на продажи, закономерно получали более высокий приоритет. Они прилетали в работу и вытесняли то, что уже было запланировано в спринте или бэклоге.

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

Увеличить команду возможности не было. Значит, нужно было искать внутренний резерв производительности.

Попробовали Cursor AI. Мы внедрили его не с идеей «пусть пишет код вместо разработчиков». Хотелось убрать из работы то, что съедает время, но не требует сложных решений: — поиск по большой кодовой базе; — разбор существующего кода; — генерация типового кода; — рефакторинг; — оптимизация кода и SQL-запросов; — написание тестов; — однотипные изменения.

Через несколько месяцев я посмотрела на статистику Trello.

Количество закрытых карточек практически не изменилось: 65 → 63 карточки в месяц. То есть мы не стали работать в два раза больше.

Зато медианное время выполнения задачи сократилось примерно на 40%: 20 → 12,1 дня.

А в общем потоке готовых задач, куда у нас попадают в том числе Kanban-задачи и технический долг, закрытие почти в 5 раз быстрее: 83,9 → 17,1 дня.

Небольшие Kanban-доработки мы не всегда заносим на Trello, поэтому это не абсолютная статистика всего входящего потока. Но тенденция очевидна: объём работы почти не изменился, а задачи стали проходить систему быстрее.

Мы наконец начали разгребать технический долг. Когда команда постоянно занята срочными задачами, технический долг легко превращается в «сделаем потом». А «потом» может длиться месяцами. После ускорения основного потока у нас появился ресурс на то, что раньше постоянно откладывалось. Для меня это один из главных признаков того, что выросла именно пропускная способность команды: мы не просто быстрее закрывали новые задачи, но и начали освобождать место для накопившихся проблем.

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

Я перестала быть «играющим тренером» До этого я совмещала две роли: тимлид и разработчик. Когда команде было тяжело, я могла взять задачу и помочь руками. В краткосрочной перспективе это удобно. Но в долгосрочной это создаёт зависимость команды от тимлида и забирает время у управленческой работы. После внедрения Cursor команда стала более автономной, и я смогла полностью выйти из регулярной разработки.

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

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

У нас часть проблемы была в рутинных операциях разработки и высокой стоимости переключения между задачами. Cursor помог сократить эту стоимость и высвободить ресурс. В итоге мы получили не «в два раза больше кода», а гораздо более ценный результат: тот же объём работы без переработок, возможность добраться до техдолга, устойчивость во время отпусков и более автономную команду. А я смогла перестать быть «играющим тренером» и наконец полноценно заниматься работой тимлида.

Для меня это хороший пример того, что AI в разработке — не обязательно про замену людей, его главная ценность: помочь существующей команде работать устойчивее, не увеличивая нагрузку на людей.