Что такое жизненный цикл разработки ПО (SDLC)?

Жизненный цикл разработки программного обеспечения (SDLC) представляет собой последовательность этапов, через которые проходит программное обеспечение в процессе его создания. Классические стадии включают:

Планирование: определение, что и зачем нужно строить.

Дизайн: разработка внешнего вида, функциональности и поведения продукта.

Создание: написание кода.

Тестирование: проверка корректности работы кода.

Развертывание: выпуск продукта пользователям.

Поддержка: мониторинг, исправление и обновление продукта после его выпуска.

Эти шесть этапов традиционного SDLC были разработаны еще в 1960-х годах и часто называются "водопадной моделью". Однако с приходом Agile в начале 2000-х годов они были переработаны в короткие, повторяющиеся циклы. Важно отметить, что структура SDLC в первую очередь описывает инженерную перспективу.

AI-нативный SDLC

В августе 2026 года компания Anthropic представила свою концепцию AI-нативного жизненного цикла разработки ПО, что стало продолжением публикаций Google (май 2026) и OpenAI (ноябрь 2025). Все три подхода имеют свои отличия, но в целом они сводят UX к контексту, который управляет генерацией AI. Основная идея заключается в том, что AI-агенты значительно ускоряют и удешевляют процесс написания кода, поэтому остальные стадии также должны адаптироваться для максимизации продуктивности. Google подытоживает: "Самое значительное изменение в разработке ПО заключается не в новом языке, фреймворке или облачном сервисе, а в переходе от написания кода к выражению намерений и доверию к интеллектуальным системам, которые переводят эти намерения в рабочее ПО."

Как выглядит плейбук AI-нативного SDLC от Anthropic

Плейбук Anthropic сохраняет шесть традиционных стадий SDLC, но AI становится основным исполнителем, а люди контролируют качество на каждом этапе. Стадии сосредоточены вокруг цепочки артефактов, контролируемых версиями, которые генерируются AI-агентами в формате Markdown и проверяются ответственными за каждую стадию. Контекст, который направляет работу AI, включает в себя курацию инструкций, определяющих, как организация выполняет свои процессы, а также правила кодирования, брендовые стандарты и UX-стандарты. Теоретически, чем лучше контекст, тем выше вероятность, что выходные данные AI будут соответствовать стандартам организации без необходимости человеческой коррекции. Это значительное отклонение от традиционного SDLC, где человек как создавал, так и оценивал всю работу.

Предположения о UX в AI-нативном SDLC

В плейбуке Anthropic UX не занимает отдельную стадию или контрольный пункт. Предполагается, что знания UX, закодированные как контекст, помогут AI создавать высококачественные, ориентированные на пользователя продукты. Однако не предусмотрено, что UX-специалисты будут непосредственно вовлечены в процесс.

Предположения на этапе планирования

На этапе планирования создается файл intent.md, который должен отражать потребности пользователей. Однако нет гарантии, что автор будет учитывать реальные потребности пользователей, а не просто свои предпочтения. Это может привести к созданию файлов intent.md, не связанных с реальными нуждами пользователей, что в свою очередь способствует образованию изолированных решений без учета мнений других членов команды.

Предположения на этапе дизайна

На этапе дизайна предполагается, что AI адекватно учтет стандарты дизайна организации при создании spec.md и макетов. Однако, кто будет управлять и поддерживать этот контекст, остается неясным. AI может создавать макеты, но это не гарантирует, что они соответствуют реальным потребностям пользователей.

Предположения на этапе тестирования

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

Предположения на этапе поддержки

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

Необходимость всех трех ролей UX в AI-нативном SDLC

UX играет три важные роли в условиях ускоренной разработки ПО с помощью AI:

Определение, что стоит строить, и укрепление общего суждения о UX.

Оценка того, что было построено.

Добавление контекста в процесс генерации AI.

Плейбук Anthropic предоставляет механизм только для третьей роли, но не учитывает первые две. Контекст UX станет все более важной частью AI-нативного SDLC, но это не единственный вклад UX в разработку ПО.

Шесть шагов, которые вы можете предпринять уже сегодня

Если ваша организация начинает внедрять видение AI-лабораторий, проактивные UX-специалисты могут стать теми, кто формирует процесс и определяет, кто будет участвовать на каждом этапе. Вот несколько вещей, которые стоит обсудить и решить: 1. Определение, что стоит строить: сосредоточьтесь на шаблоне intent.md и процессе документации на потребностях пользователей. 2. Укрепление общего суждения о UX: помогите определить критерии приемлемости для intent.md, которые будут учитывать потребности пользователей. 3. Определение, когда требуется обзор UX-специалиста: установите, в каких случаях необходима проверка UX-профессионала. 4. Добавление пользовательских сигналов в мониторинг: работайте с инженерной командой, чтобы определить UX-сигналы, которые требуют более глубокого исследования. 5. Принятие на себя ответственности за контекст UX: UX-специалисты должны владеть контекстом UX и навыками, чтобы быть автоматически вовлеченными в процесс. 6. Создание машинно-читаемых исследовательских данных и систем дизайна: это поможет AI-агентам находить нужные данные и компоненты.

Что будет дальше

SDLC, который нативно интегрирует AI, представляет собой интересную концепцию для инженеров и бизнес-стейкхолдеров, поскольку хорошо управляемый AI может писать мощный код. Однако UX отвечает за общий опыт пользователей с продуктом. Если цикл не остановится, это может привести к постепенному ухудшению пользовательского опыта из-за множества мелких изменений. Важно задавать вопросы о том, как укрепить способность всей команды определять, что стоит строить с точки зрения пользователей, и как оценивать UX продуктов, созданных AI, так же быстро, как AI-агенты пишут код.