SDLC (Software Development Life Cycle) — это структурированная последовательность процессов, по которой идея превращается в рабочий и поддерживаемый IT-продукт. SDLC используют продуктовые команды, аутсорс и интеграционные компании, стартапы и корпоративные ИТ-подразделения, когда нужно снижать риски, прогнозировать сроки и бюджет, управлять качеством, ответственностями и ожидаемым эффектом на бизнес. Шесть этапов – звучи. Но на практике за каждым стоит своя большая работа.
В классическом виде SDLC состоит из 6 этапов
1. Инициирование проекта и анализ требований – формирование идеи, понимание что нужно сделать и зачем.
2. Проектирование системы – продумывание, как система будет устроена, ее архитектура и дизайн.
3. Разработка – собственно написание кода и создание продукта.
4. Тестирование – проверка качества, поиск и исправление ошибок до выпуска.
5. Деплой – развертывание готового продукта в рабочей (продакшн) среде, релиз для пользователей.
6. Поддержка и развитие – сопровождение работающего продукта, исправление багов и доработка функциональности по мере необходимости.
Сейчас мы пройдемся по каждому этапу подробнее и разберемся, что именно там происходит и кто что делает на каждом шаге. Если у вас возникнут ассоциации или примеры из вашего опыта – замечательно, сопоставляйте их с этими этапами!
Этап 1: Инициирование проекта и анализ требований
Задача этапа: Проверить, что мы решаем реальную проблему и понимаем, какую ценность хотим получить.
Вход: жалобы пользователей, просадка метрик, ощущения команды, инсайты продаж/саппорта/продукта.
Выходы: четко сформулированная проблема, гипотезы-ценности, ориентир по метрикам, контур рисков.
Кто что делает:
- Product Manager: формулирует гипотезу, задает целевую метрику
- Business Analyst: уточняет проблему через короткие интервью и данные, фиксирует бизнес требования
- System Analyst: быстро инвентаризирует источники данных и интеграции, проверяет какие есть лимиты/форматы API, формулирует ключевые NFR и список рисков/неизвестных.
- Designer: создает (отрисовывает) целевой пользовательский путь и отмечает болевые точки, делает простые вайрфреймы.
- Architect: оценивает, не рушим ли существующую архитектуру
- Developer: делает быстрый spike: можем ли собрать сегмент за приемлемое время.
- Project Manager: собирает риски/ограничения воедино, прикидывает ресурс/срок.
- QA: смотрит на проверяемость гипотезы, планирует что и как будем тестировать после релиза.
Этап 2: Проектирование системы
Задача этапа: Превратить согласованные требования в проверяемое техническое решение (архитектура, данные, интерфейсы).
Вход: утвержденные бизнес-требования/гипотезы, NFR, пользовательские сценарии, карта интеграций/данных.
Выходы: архитектурное решение (C4/ADR), модель данных, контракты API, детализированное SRS (FR/NFR), макеты и спецификации UI, план наблюдаемости (метрики/логи/трейсинг).
Кто что делает:
- Product Manager: сверяет проектное решение с целевыми метриками и приоритетами релиза.
- Business Analyst: уточняет правила/границы, формулирует критерии приемки на уровне бизнес-ценности.
- System Analyst: детализирует SRS, проектирует сущности/события, интеграции, негативные сценарии и версионирование API.
- Designer: делает пользовательские потоки, high-fi макеты и состояния (empty/error/loading), спецификацию для разработки.
- Architect: выбирает интеграционный стиль, границы сервисов, NFR/SLO и наблюдаемость, фиксирует решения в ADR
- Developer: предлагает реалистичный техстек и компоненты, оценивает сложность, готовит шаблоны/скелеты.
- Project Manager: синхронизирует зависимости, артефакты и готовность команд к старту имплементации.
- QA: готовит стратегию тестирования (функц./интегр./NFR), определяет точки контроля качества.
Этап 3: Разработка
Задача этапа: Реализовать инкремент так, чтобы смысл требований не потерялся, а качество было встроено в код.
Вход: архитектура/ADR, SRS, UX-спецификации, DoR/DoD, план тестирования.
Выходы: рабочий инкремент, код/миграции/конфиги, unit/интеграционные авто-тесты, CI/CD, обновленная документация.
Кто что делает:
- Product Manager: контролирует соответствие приоритетам и продуктовой цели инкремента.
- Business Analyst: отвечает на смысловые вопросы, следит за соблюдением бизнес-правил и границ.
- System Analyst: помогает с данными/контрактами, закрывает пограничные кейсы и системные зависимости.
- Designer: уточняет детали интерфейса, поддерживает консистентность компонентов.
- Architect: проводит ревью критичных решений, следит за соответствием ADR и NFR
- Developer: пишет код, тесты, делает code review, поддерживает стандарты и покрытие.
- Project Manager: снимает блокеры, управляет сроками/загрузкой и коммуникациями между командами.
- QA: подготавливает тест-наборы по мере готовности модулей, настраивает тестовые среды/данные.
Этап 4: Тестирование
Задача этапа: Доказать, что «как задумано» соответствует «как работает», и продукт выдерживает реальные условия.
Вход: сборки/артефакты разработки, тест-план/среды, SRS/NFR, UX-спецификации.
Выходы: отчеты о тестировании, список дефектов с приоритетами, автоматизированный регресс, рекомендации по Go/No-Go.
Кто что делает:
- Product Manager: проверяет ранние продуктовые сигналы (CR, CTR, отказ/отписки) на стендах/канарейке.
- Business Analyst: валидирует критерии приемки и бизнес-сценарии, подписывает готовность по ценности.
- System Analyst: проверяет корректность интеграций/контрактов, негативные/граничные сценарии.
- Designer: подтверждает визуальные/контентные состояния, доступность и консистентность.
- Architect: оценивает перф/устойчивость, деградационные режимы, готовность наблюдаемости.
- Developer: исправляет дефекты, усиливает покрытие и надежность; помогает с тестовыми хуками.
- Project Manager: ведет дефект-трекинг, контролирует качество/сроки и готовность к релизу.
- QA: проводит функциональные, интеграционные, e2e и перф/безопасность тестирования, формирует финальный отчет.
Этап 5: Деплой
Задача этапа: Безопасно выкатить изменения и иметь возможность быстро откатить.
Вход: одобренные сборки, чек-листы релиза, фиче-флаги/канареечные стратегии, план отката.
Выходы: работающая функциональность в проде, релиз-ноты, включенный мониторинг/алерты, подтверждение стабильности.
Кто что делает:
- Product Manager: согласует окно релиза и критерии успеха первой волны.
- Business Analyst: проверяет корректность бизнес-правил на проде и ранние метрики эффекта.
- System Analyst: мониторит ошибки интеграций/контрактов, валидирует события и потоки данных.
- Designer: подтверждает ключевые пользовательские пути и тексты в боевой среде.
- Architect: настраивает стратегию выката (blue-green/canary), контролирует SLO и план отката
- Developer: проводит деплой, миграции, включает фиче-флаги, реагирует на инциденты.
- Project Manager: ведет релиз по чек-листу, коммуникации и статус для стейкхолдеров.
- QA: делает смоук-тесты в проде/на канареечном трафике, следит за инцидентами/алертами.
Этап 6: Поддержка и развитие
Задача этапа: Стабильно держать продукт в форме и развивать его на основе данных и обратной связи.
Вход: пострелизные метрики/дашборды, инциденты/тикеты, фидбек пользователей, техдолг.
Выходы: план улучшений и релизов поддержки, погашение техдолга, актуальная документация, устойчивые SLO.
Кто что делает:
- Product Manager: принимает решения об улучшениях и экспериментах на основе метрик/ROI.
- Business Analyst: анализирует влияние на процессы и ценность, уточняет правила и гипотезы следующего релиза.
- System Analyst: поддерживает совместимость версий/контрактов, актуализирует SRS и схемы данных.
- Designer: улучшает UX по данным/фидбеку, поддерживает дизайн-систему.
- Architect: планирует рефакторинг/масштабирование, управляет техническими рисками
- Developer: исправляет баги, оптимизирует производительность, автоматизирует рутину.
- Project Manager: организует релизы поддержки, управляет рисками/временем команды.
- QA: поддерживает автотесты, следит за «утечкой дефектов» и стабильностью релизов.
Подведем итоги
Мы прошлись по всем этапам SDLC — от идеи до поддержки. На каждом шаге есть своя цель, понятные входы/выходы и зона ответственности ролей. Ключ к качеству — согласованные требования, проверяемые решения и наблюдаемость с первого дня. Когда роли работают в связке, есть единый источник правды по требованиям, прозрачные границы и учтенные NFR — поставка становится предсказуемой, а продукт растет без сюрпризов. SDLC — это оркестр: каждый играет свою партию, но вместе из этого получается главное — устойчивый продукт, который приносит реальную ценность пользователю и бизнесу.
Полезные ссылки
- Курс «Бизнес-аналитик в IT» на Stepik — структурированный старт, шаблоны и практика с проверкой артефактов автором курса + спец предложение для присоединившихся по ссылке ниже, скидка 25%.
Реклама. Семенов А.Д. ИНН 645503942344.
- Telegram-канал «Аналитика в IT» — полезные статьи, шаблоны, чек-листы и разборы из реальных задач. Канал будет полезен аналитикам, продактам и тем, кто только начинает свой путь в IT. [ссылка на канал]