[Я — проджект-менеджер, и я выпустила фичу: вот как это было]

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

Это вторая версия.

Я — проджект-менеджер. Моя работа — координация релизов, управление дедлайнами поставки, работа с командой над приоритизацией и контроль за тем, чтобы то, что должно выйти, действительно выходило. Написание кода никогда не было частью этой работы. И тем не менее в последнем релизе четыре фичи, которые я довела до продакшена сама, добрались до пользователей через реальные пул реквесты, ревью коллег и стейджинг-сборки.

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

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

1. Значок уведомления для раздела "Отсутствия" в боковой панели: у утверждающих не было визуального индикатора, что запросы ждут рассмотрения.
2. Фильтр по типу сотрудника в "Global Worklogs": все, кто занимался расчетом зарплаты, каждый месяц делали сортировку вручную.
3. Баг с дублированием сотрудника при создании нового проекта: добавление уже существующего участника команды создавало вторую запись в базе данных вместо ссылки на существующую.
4. И последующий фикс — когда значок не обновлялся после действия "Отклонить".

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

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

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

Cursor нашел нужные файлы: MainMenu.vue, MenuTree.vue. Создал необходимые новые файлы. Я никогда не открывала ни один из них раньше и понятия не имела, где находитчя код боковой панели. Я его запустила и получила белый экран и ошибку в консоли:

TypeError: _ctx.badgeCount is not a function at MenuTree.vue:45

Cursor добавил скобки к badgeCount(), воспринимая его как функцию, хотя на самом деле это было вычисляемое свойство. Я скопировала ошибку, отправила обратно с пояснением, и он ее исправил.

Так я получила первый урок: даже простая фича редко работает с первого раза.

Затем я поняла, что значок только на "Отсутствиях" не решает проблему — раздел HR обычно свернут. Мы добавили точку-индикатор на родительский пункт меню. Перед отправкой пул реквеста я попросила Cursor сгенерировать чеклист для тестирования: граничные случаи, поведение с нулевым количеством запросов, свернутые состояния и лишние API-вызовы. Этот чеклист значительно ускорил мое самостоятельное тестирование перед передачей в QA.

Ревью вернулось с двумя комментариями: устаревшая переменная цвета и пустой блок перехвата без console.error. Оба исправила через Cursor. Затем стейджинг-сборка упала с ошибкой TypeScript — проблема типизации в hasChildWithBadge, где дочерние узлы были типизированы как unknown[]. Cursor исправил и это, выделив правильный интерфейс TreeNode. Еще один пул реквест.

Три пул реквеста для одного значка. После этого стандартное тестирование прошло, и фича вышла в продакшн.

Следом появился новый баг: значок обновлялся после одобрения, но не после отклонения — без перезагрузки страницы. Cursor проанализировал код и быстро нашел причину: sendAbsenceSaved() присутствовал в handleApprove и handleSave, но отсутствовал в handleReject. Затем он проверил стейджинг-ветку и обнаружил, что вызов пропал между слияниями — был запушен в ветку уже после того, как основной пул реквест был закрыт. Фикс — одна строка.

Второй ценный урок: Cursor умеет диагностировать расхождения между локальной средой и стейджингом. Он сделал это, запустив:

git show origin/staging:path/to/file | grep -n "sendAbsenceSaved"

Сама этот запрос я бы не придумала.

Фильтр по типу сотрудника затронул одновременно фронтенд и бэкенд — мой первый опыт работы в двух репозиториях сразу. Весь процесс занял около двух часов. Задача не была технически сложной, и именно это сделало ее показательной. Она обозначила, как сместилась граница между "описать проблему" и "решить ее". У PM с двумя свободными часами и четкой задачей больше нет необходимости ставить ее в очередь к разработчику.

Фикс с дублированием сотрудника потребовал понять разницу между режимами create и update в API. employee_id передавался только при isUpdate = true, поэтому добавление "нового" участника создавало новую запись в базе данных вместо ссылки на существующую. После исправления появилось новое сообщение: "1 участник был пропущен". Бэкенд возвращал статус "skipped", потому что email уже существовал, а фронтенд отображал это как предупреждение, хотя по технической части проблем не было. Я скорректировала уведомление в интерфейсе, чтобы оно отражало это корректно.

На протяжении всего процесса мой рабочий процесс выстроился в паттерн:

1. Описывать задачу в терминах поведения, а не кода: "Значок должен обновляться сразу после отклонения, без перезагрузки" работает лучше, чем просить конкретную функцию.
2. Просматривать дифф в конце, а не на каждом шаге: поначалу я требовала подтверждения на каждое действие — это было узким местом.
3. Спрашивать "почему", а не только "что": "Объясни, что ты нашел", "Почему здесь?", "Что произойдет, если мы сделаем иначе?".

Каждая задача становилась возможностью для обучения. Теперь я понимаю, что такое шина событий и в чем разница между режимами create и update в API.

Инфраструктура оказалась наиболее непредсказуемой частью: несовместимые версии Node.js, Docker, не видящий новые файлы без пересборки, контейнеры, не желающие перезапускаться. Это требует интуиции в отладке, которую я ещё только нарабатываю.

Паттерн подтвердился на всех четырех задачах. Вот что добралось до продакшна:

• Значок уведомления для раздела "Отсутствия" в боковой панели с точкой-индикатором на родительском пункте меню HR.
• Фикс обновления значка после отклонения.
• Фильтр по типу сотрудника (штатный / внештатный) в глобальных ворклогах.
• Фикс дублирования сотрудника при создании нового проекта.

Да, это небольшие фичи — те, что не попадают в заголовок примечаний к релизу. Но в этом отчасти и суть.

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

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

То, что сделало это возможным, — среда, в которой работали инструменты. В Enji есть AGENTS.md, стайлгайд, задокументированные границы сервисов и устоявшиеся процессы пул реквестов. Cursor следовал правилам, которые команда уже установила. Хорошо организованная кодовая база позволяет людям без технического бэкграунда работать по-другому.

Как отметил наш технический лид в более раннем материале о мультиагентных системах, ИИ масштабирует тот фундамент, который ему дают. Мой опыт это подтверждает.

Это не аргумент в пользу того, что все должны писать код или что ИИ делает техническую экспертизу ненужной. Фичи, которые я реализовала, были небольшими и четко ограниченными. Процесс ревью выявил реальные проблемы: устаревшую переменную, отсутствующий обработчик ошибок и проблему типизации, сломавшую стейджинг-сборку. Умение понять разницу между "я разберусь с этим с помощью ИИ" и "это требует инженера" само по себе является навыком, и его развитие требует времени.

Это аргумент в пользу другого: граница между "технической" и "нетехнической" работой движется. И люди, лучше всего способные заметить, куда она сместилась — это те, кто готов это проверить.

Пожалуй, наиболее долгосрочный эффект — не скорость и не автономность, а качество понимания. Когда ты прослеживаешь проблему от симптома до конкретной строки кода, ты иначе формулируешь задачи, точнее оцениваешь сложность и говоришь на языке команды. Это меняет то, как ты работаешь с инженерами, потому что увидела то, что видят они.

О внедрении ИИ написано много материалов, трактующих его как инициативу сверху вниз: стратегия, раскатка, программа трансформации. То, что произошло здесь, не было ничем из этого. Один человек в команде заметил проблему, решил попробовать, и в итоге выпустил это в продакшн.

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