PubHub — это внутренняя система управления контентом Cisco DevNet, и это четвертая часть серии статей о том, как команда DevNet перестраивала ее с нуля. В первой части мы рассказали о достижениях и препятствиях при перестройке PubHub, а во второй исследовали, как ИИ ускорил наш жизненный цикл разработки программного обеспечения (SDLC). Третья часть посвящена пути команды UX DevNet по превращению стандартов дизайна Cisco в навыки ИИ и сервер MCP. Теперь мы погружаемся в эволюцию рабочего процесса, где мы использовали ИИ для сбора требований к проекту, критериев приемки и многого другого. Этот сдвиг, возможно, оказался чем-то большим, чем мы ожидали.
Восторг от ИИ
Поскольку мы перестраивали систему с нуля, мы увидели возможность переписать ее на основе десятилетнего личного опыта. Мы использовали ИИ, чтобы помочь задокументировать требования для этого проекта, используя VS Code Copilot в сочетании с Claude Sonnet и Opus.
В мире Agile-разработки и SDLC мы используем эпики для организации сложных проектов. Эпик — это высокоуровневое требование или масштабная функция, которая слишком велика, чтобы быть выполненной за один спринт. Он выступает в качестве контейнера для нескольких связанных пользовательских историй, предоставляя необходимый контекст и объем для инженерной команды. Чтобы не отставать от скорости ИИ, мы не использовали традиционные программы для работы с документами, такие как Word. Вместо этого навык ИИ генерировал эпики и пользовательские истории в формате Markdown и размещал их во внутреннем репозитории GitHub. Версионирование каждого изменения и ведение четкого журнала изменений по мере развития проекта позволили нам относиться к нашим требованиям как к коду.
Первоначальные результаты были захватывающими. ИИ превратил процесс написания историй из рутины в суперсилу. Я мог передать ИИ конкретные критерии и болевые точки, и он мгновенно генерировал:
- Исчерпывающий контекст: четкая бизнес-ценность и объем, чтобы предотвратить разрастание рамок проекта.
- Техническая точность: подробные критерии приемки, перспективы участников и ключевые концепции.
- Быстрое прототипирование: модели запросов/ответов API, каркасы и HTML-макеты для согласования работы инженеров, дизайнеров и руководства.
ИИ не просто писал; он управлял. Он версионировал документы и вел тщательный журнал изменений по 12 объемным эпикам, каждый из которых был связан с дочерними историями и их зависимостями.
Я чувствовал, что нашел чит-код для технического руководства.
Переломный момент: когда «полнота» становится «избыточностью»
По мере роста документации я уперся в стену. Эпики стали настолько объемными, что даже я, человек, который их создал с помощью промптов, с трудом мог их просматривать и редактировать. Например, я часто встречался с инженерной командой, чтобы обсудить проблемы и найти компромиссы при запуске. После встреч я использовал своего агента в VS Code Chat, чтобы обновить требования в эпиках. Хотя инструмент безупречно синхронизировал обновления в нашем конвейере документации, он подкинул мне огромную очередь на проверку. Я отказался слепо одобрять сотни изменений, предпочитая оставить человека (меня) в цикле, а не создавать еще одного агента для обработки проверки.
Это создало парадокс: ИИ обеспечил нам идеальную согласованность, но я заплатил за это часами ручной проверки.
Я помню, как думал: если бы ИИ не указал на эти крошечные зависимости, мне потребовались бы дни, чтобы найти их вручную, или я бы пропустил их вовсе. Но потом до меня дошло: я бы вообще не написал столько контента. ИИ создал гору контента, и я тратил все свое время на то, чтобы разгребать ее.
«Налог на проверку» стал очевиден, когда я поделился тщательно написанными эпиками с коллегами. После того как я показал эпики главному инженеру, я услышал, что документация слишком предписывающая для инженеров. Она была слишком подробной, не оставляла достаточно места для адаптации инженеров на основе новой системы, которую они строили, и, что самое важное, всей команде потребовалось бы слишком много времени, чтобы ее прочитать.
Сначала я усмехнулся, подумав: зачем им читать это, если ИИ может прочитать это за них?
Это подняло практический вопрос: не создавал ли я цикл, в котором я использовал ИИ для генерации документации просто для того, чтобы она была прочитана и реализована ИИ? Хотя контент был ясным и исчерпывающим, его огромный объем стал барьером для того самого сотрудничества, которое он должен был поддерживать.
Поворот: пишем для людей
Я понял, что в своем стремлении к техническому совершенству я забыл о самом важном участнике: человеке.
Мы перешли к подходу бережливой документации, но не выбросили эпики. Эти эпики остались «глубоким» источником истины, идеально подходящим для обработки ИИ и технической справки. Вместо этого мы создали резюме. Это были краткие, высокоуровневые справочные материалы, которые позволяли инженерам, дизайнерам и менеджерам охватить общую картину, понять ключевые рабочие процессы и определить связанные и зависимые эпики, не утопая в деталях. Создавая параллельные «читаемые ИИ» эпики с «читаемыми людьми» резюме эпиков, мы восстановили баланс между технической глубиной и организационной гибкостью.
ИИ может экспоненциально увеличить объем того, что мы производим, но он не может заменить человеческую потребность в ясности и краткости. Если мы не будем осторожны, мы будем тратить больше времени на управление результатами работы наших инструментов, чем на руководство нашими командами.
В дальнейшем я рекомендую использовать бережливый подход к созданию документации, будь то эпики, пользовательские истории или стратегические документы. Когда мы восхищаемся тем, что может создать ИИ, мы должны не забывать остановиться, поднять голову и спросить себя: в погоне за продуктивностью, кто кем руководит?
