Дата: 2026-02-04
Версия: 1.0
Статус: Research Complete
Жизненный цикл IT-проекта — это полная последовательность фаз от идеи до вывода из эксплуатации. Ключевые находки:
Источник: PMI PMBOK Process Groups
PMBOK определяет 5 процессных групп (не путать с фазами!):
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Initiating │────→│ Planning │────→│ Executing │
└─────────────┘ └─────────────┘ └──────┬──────┘
↑ │
│ ↓
┌──────┴──────┐ ┌─────────────┐
│ Closing │←────│ Monitoring │
└─────────────┘ │& Controlling│
└─────────────┘
Критически важно: Process Groups ≠ Project Phases!
- Process Groups — способ организации задач
- Project Phases — временные этапы с границами
Requirements → Design → Implementation → Verification → Maintenance
↓ ↓ ↓ ↓ ↓
[Gate 1] [Gate 2] [Gate 3] [Gate 4] [Gate 5]
Особенности:
- Жёсткие границы между фазами
- Переход только после полного завершения предыдущей
- Документация — ключевой артефакт на каждой границе
Источник: V-Model Wikipedia
Business Requirements ←───────────────→ Acceptance Testing (UAT)
↓ ↑
System Analysis ←─────────────────────→ System Testing
↓ ↑
Architecture Design ←─────────────────→ Integration Testing
↓ ↑
Module Design ←───────────────────────→ Unit Testing
↓ ↑
└────────→ CODING ←────────────────────┘
Ключевая идея: Каждая фаза разработки (verification) имеет соответствующую фазу тестирования (validation).
Границы:
- Левая сторона → Правая сторона: передача test plans и test data
- Coding → Testing: handoff через code freeze и build artifact
Источник: DevOps Lifecycle Phases
7 C's of DevOps:
┌─────────────────────────────────────────────────┐
│ │
↓ │
Continuous Development → Continuous Integration │
↓ ↓ │
Continuous Testing ←────────────┘ │
↓ │
Continuous Deployment │
↓ │
Continuous Operations │
↓ │
Continuous Monitoring → Continuous Feedback ─────────┘
Критическое отличие:
- Границы размыты — фазы перекрываются
- Цикл бесконечный — feedback loop
- Переходы автоматизированы — CI/CD pipelines
НО: Границы всё равно существуют:
- Dev → Staging: через CI/CD pipeline + automated tests
- Staging → Production: через approval gate + smoke tests
Источник: ISO 12207 Wikipedia
Важно: ISO 12207 не определяет фазы, а определяет процессы.
Стандарт признаёт типичные фазы:
- Concept Exploration
- Development
- Sustainment (Maintenance)
- Retirement
4 группы процессов:
| Группа | Процессы | Применимость |
|---|---|---|
| Agreement | Acquisition, Supply | Все фазы |
| Organizational | Portfolio, HR, Quality | Все фазы |
| Technical Management | Planning, Risk, Configuration | Все фазы |
| Technical | Requirements, Design, Coding, Testing | Development фаза |
Источники:
- Stage-Gate Process
- System Deployment
- Project Closure
┌──────────────┐ G1 ┌──────────────┐ G2 ┌──────────────┐ G3
│ INITIATION │─────→│ PLANNING │─────→│ DESIGN │─────→
│ (Идея) │ │ (Требования) │ │(Архитектура) │
└──────────────┘ └──────────────┘ └──────────────┘
┌──────────────┐ G4 ┌──────────────┐ G5 ┌──────────────┐ G6
│ DEVELOPMENT │─────→│ TESTING │─────→│ DEPLOYMENT │─────→
│ (Код) │ │ (Проверка) │ │ (Релиз) │
└──────────────┘ └──────────────┘ └──────────────┘
┌──────────────┐ G7 ┌──────────────┐
│ OPERATIONS │─────→│ CLOSURE │
│(Эксплуатация)│ │ (Retirement)│
└──────────────┘ └──────────────┘
Цель: Определить стоит ли начинать проект.
Ключевые активности:
- Идея / Opportunity identification
- Feasibility study (техническая, финансовая, организационная)
- Business Case разработка
- Preliminary scope definition
- Stakeholder identification
- Project Charter creation
Артефакты:
- Project Charter
- Feasibility Study Report
- Business Case Document
- Preliminary Budget & Timeline
- Stakeholder Register
Ответственность:
- Кто инициирует: Business owner, Product Manager, CXO
- Кто принимает: Project Sponsor, Steering Committee
Системы управления:
- Идеи: Confluence, Notion, Linear (Product Ideas)
- Бизнес-кейс: Excel, Google Sheets, PowerPoint
Критерий завершения (Gate 1):
✓ Business Case approved
✓ ROI > X% (threshold определён компанией)
✓ Resources available (preliminary check)
✓ Alignment with strategy
✓ Sponsor assigned
Цель: Определить КАК реализовать проект.
Ключевые активности:
- Requirements gathering (BRD, FRD, User Stories)
- Scope definition (WBS)
- Schedule development (Gantt chart)
- Budget planning
- Risk identification
- Team formation
- Communication plan
Артефакты:
- Project Management Plan
- Requirements Document (BRD/FRD)
- WBS (Work Breakdown Structure)
- Project Schedule
- Budget & Resource Plan
- Risk Register
- Communication Plan
Ответственность:
- Кто планирует: Project Manager, Technical Lead, BA
- Кто утверждает: Sponsor, Steering Committee
Системы управления:
- Roadmap: ProductBoard, Aha!, Jira Roadmaps
- Requirements: Jira, Confluence, Azure DevOps
- Schedule: MS Project, Gantt charts, Monday.com
Критерий завершения (Gate 2):
✓ Requirements approved by stakeholders
✓ Scope baseline defined
✓ Budget approved
✓ Schedule approved
✓ Risks identified and mitigated
✓ Team assembled
Цель: Создать blueprint решения.
Ключевые активности:
- Architecture design (high-level, low-level)
- UI/UX design
- Database schema design
- API specifications
- Security design
- Technology stack selection
- Design reviews
Артефакты:
- Architecture Design Document (ADD)
- System Design Specification
- Database Schema
- API Documentation
- UI/UX Mockups & Prototypes
- Architecture Decision Records (ADR)
Ответственность:
- Кто проектирует: Solution Architect, Tech Lead, UX Designer
- Кто утверждает: CTO, Technical Steering Committee, Customer
Системы управления:
- Architecture: Confluence, Miro, LucidChart
- Design: Figma, Sketch, Adobe XD
- ADR: GitHub/GitLab (markdown files)
Критерий завершения (Gate 3):
✓ Architecture approved by tech committee
✓ UI/UX prototypes validated by users
✓ Database schema reviewed
✓ API contracts agreed
✓ Security review passed
✓ Technology stack approved
Цель: Написать код и создать рабочий продукт.
Ключевые активности:
- Coding (following design specs)
- Code reviews
- Unit testing (by developers)
- Integration (continuous)
- Build automation (CI)
- Version control
- Documentation (inline, API docs)
Артефакты:
- Source Code (in version control)
- Build Artifacts (binaries, containers)
- Unit Test Results
- Code Coverage Reports
- API Documentation (Swagger/OpenAPI)
- Developer Documentation
Ответственность:
- Кто разрабатывает: Developers, DevOps Engineers
- Кто утверждает: Tech Lead, QA Manager (readiness for testing)
Системы управления:
- Code: Git (GitHub, GitLab, Bitbucket)
- Tasks: Jira, Linear, Azure DevOps
- CI/CD: Jenkins, GitLab CI, GitHub Actions
- Reviews: Pull Requests, Gerrit
Критерий завершения (Gate 4):
✓ Code complete (all features implemented)
✓ Code reviews passed (100%)
✓ Unit tests passed (coverage > X%)
✓ Build successful (CI green)
✓ Code merged to main branch
✓ Developer documentation complete
Цель: Проверить что продукт работает правильно.
Ключевые активности:
- Integration Testing
- System Testing
- Performance Testing
- Security Testing (pen testing)
- User Acceptance Testing (UAT)
- Regression Testing
- Bug fixing & retesting
Артефакты:
- Test Plans
- Test Cases
- Test Execution Reports
- Bug Reports (Jira tickets)
- Performance Test Results
- Security Audit Report
- UAT Sign-off
Ответственность:
- Кто тестирует: QA Engineers, Security Team, End Users (UAT)
- Кто утверждает: QA Manager, Business Owner, Security Officer
Системы управления:
- Test Management: TestRail, Zephyr, qTest
- Bug Tracking: Jira, Bugzilla
- Automation: Selenium, Cypress, JUnit
- Performance: JMeter, LoadRunner
- Security: OWASP ZAP, Burp Suite
Критерий завершения (Gate 5):
✓ All test cases executed
✓ Critical bugs fixed (P0/P1 = 0)
✓ Performance meets SLA
✓ Security scan passed (no critical vulnerabilities)
✓ UAT approved by business
✓ Regression tests passed
Цель: Выкатить продукт в production.
Источник: Production Readiness Checklist
Ключевые активности:
- Production environment setup
- Database migration (if needed)
- Configuration management
- Release deployment (blue-green, canary)
- Smoke testing in production
- Rollback plan preparation
- Handover to operations
Артефакты:
- Deployment Plan
- Runbook (операционные процедуры)
- Rollback Plan
- Production Readiness Checklist
- Deployment Sign-off
- Handover Document
Ответственность:
- Кто разворачивает: DevOps/SRE, Release Manager
- Кто утверждает: Operations Manager, Change Advisory Board (CAB)
Системы управления:
- Deployment: Kubernetes, Docker, Terraform
- CI/CD: ArgoCD, Spinnaker, Jenkins
- Configuration: Ansible, Chef, Puppet
- Change Management: ServiceNow, Jira Service Desk
Критерий завершения (Gate 6):
✓ Production environment ready
✓ Deployment successful (rollout complete)
✓ Smoke tests passed in production
✓ Monitoring configured
✓ Alerting configured
✓ Operations team trained
✓ Runbook handed over
✓ Rollback plan tested
Цель: Поддерживать продукт в рабочем состоянии.
Источник: System Transition SEBoK
Ключевые активности:
- Monitoring (uptime, performance, errors)
- Incident management (on-call, escalation)
- Bug fixing (maintenance releases)
- Incremental updates (minor features)
- Performance tuning
- User support (L2/L3)
- Documentation updates
Артефакты:
- Incident Reports
- Post-Mortem Documents
- Monitoring Dashboards
- Maintenance Release Notes
- SLA/SLO Reports
- Change Requests
Ответственность:
- Кто поддерживает: SRE, Operations Team, Support Engineers
- Кто отвечает: Operations Manager, Service Owner
Системы управления:
- Monitoring: Grafana, Datadog, New Relic
- Alerting: PagerDuty, Opsgenie, AlertManager
- Incidents: Jira Service Desk, ServiceNow
- Logs: ELK Stack, Splunk, Loki
- Changes: ITSM tools (ServiceNow)
Критерий перехода к Closure (Gate 7):
✓ Product reached end-of-life (EOL)
✓ Business decision to retire
✓ Replacement system ready
✓ Migration plan approved
Цель: Вывести продукт из эксплуатации.
Источник: Application Decommissioning Guide
Ключевые активности:
- Decommissioning plan creation
- Data archival (compliance with retention policies)
- Data migration (to replacement system)
- User notification
- Infrastructure shutdown
- License cancellation
- Post-project review (lessons learned)
- Team release
Артефакты:
- Decommissioning Plan
- Data Archival Report
- Migration Completion Report
- Post-Project Review Document
- Lessons Learned
- Final Financial Report
- Project Closure Document
Ответственность:
- Кто закрывает: Project Manager, Operations Team
- Кто утверждает: Sponsor, Compliance Officer
Системы управления:
- Data Archive: Cold storage (S3 Glacier, Azure Archive)
- Documentation: Confluence, SharePoint (archived)
- Compliance: Compliance Management System
Критерий завершения (Final Gate):
✓ All data archived per retention policy
✓ All infrastructure decommissioned
✓ All users migrated to replacement system
✓ All licenses cancelled
✓ Post-project review completed
✓ Lessons learned documented
✓ Team released
Источник: Phase-Gate Process
Gate — это формальная точка принятия решения между фазами, где:
- Оценивается готовность перехода
- Принимается решение: Go / Kill / Hold / Recycle
- Передаётся ответственность (handover)
Источник: Gate Reviews Explained
┌────────────────────────────────────────────────────┐
│ GATE REVIEW MEETING │
├────────────────────────────────────────────────────┤
│ 1. Презентация результатов фазы │
│ 2. Оценка критериев (Must-Meet + Should-Meet) │
│ 3. Обсуждение рисков и issues │
│ 4. Решение: Go / Kill / Hold / Recycle │
│ 5. Утверждение следующей фазы (если Go) │
└────────────────────────────────────────────────────┘
Must-Meet Criteria (Knockout):
- Чек-листы с Yes/No ответами
- Если хоть один "No" → проект Kill или Recycle
- Пример: "Security audit пройден?" → No = STOP
Should-Meet Criteria (Scoring):
- Рейтинговые критерии (1-5 баллов)
- Сумма баллов → приоритизация проектов
- Пример: "Качество документации" → 1-5
| Решение | Значение | Действия |
|---|---|---|
| Go | Проект переходит к следующей фазе | Утвердить бюджет, ресурсы, план следующей фазы |
| Kill | Проект остановлен | Документировать причины, освободить ресурсы |
| Hold | Проект приостановлен | Дождаться изменения условий (рынок, ресурсы) |
| Recycle | Вернуться к предыдущей фазе | Доработать артефакты, исправить недостатки |
| Conditional Go | Переход с условиями | Устранить minor issues в следующей фазе |
Источник: Project Initiation Phase
☐ Business Case approved by Sponsor
☐ Project Charter signed
☐ Budget allocated (preliminary)
☐ Strategic alignment confirmed
☐ Feasibility study passed (technical + financial)
☐ Legal/compliance review passed
☐ Project Sponsor assigned
[ ] ROI projection (1-5: higher is better)
[ ] Strategic importance (1-5)
[ ] Risk level (1-5: lower is better)
[ ] Resource availability (1-5)
[ ] Market opportunity (1-5)
☐ Requirements approved by all stakeholders
☐ Scope baseline defined (WBS complete)
☐ Budget approved by Finance
☐ Schedule approved by Sponsor
☐ Team assembled (key roles filled)
☐ Risk register reviewed (no showstoppers)
☐ Quality criteria defined
[ ] Requirements clarity (1-5)
[ ] Stakeholder buy-in (1-5)
[ ] Team experience (1-5)
[ ] Risk mitigation plan quality (1-5)
☐ Architecture approved by Technical Steering Committee
☐ UI/UX prototypes validated by users (UAT pre-design)
☐ Database schema reviewed by DBA
☐ API contracts agreed between teams
☐ Security architecture reviewed by InfoSec
☐ Technology stack approved
☐ Non-functional requirements defined (performance, scalability)
[ ] Architecture quality (1-5)
[ ] Design documentation completeness (1-5)
[ ] Testability of design (1-5)
[ ] Scalability (1-5)
☐ All features implemented (100% code complete)
☐ Code reviews passed (100%)
☐ Unit tests passed (coverage > 80%)
☐ Build successful on CI (all pipelines green)
☐ Code merged to main branch
☐ Developer documentation complete
☐ Known bugs documented in backlog
[ ] Code quality (SonarQube score > X)
[ ] Documentation quality (1-5)
[ ] Code maintainability (1-5)
Источник: Production Readiness Checklist
☐ All test cases executed (100%)
☐ Critical bugs fixed (P0/P1 = 0)
☐ High bugs acceptable (P2 < 5)
☐ Performance tests passed (SLA met)
☐ Security scan passed (no critical vulnerabilities)
☐ UAT approved by business (sign-off)
☐ Regression tests passed (no new defects)
☐ Test reports delivered
[ ] Test coverage (1-5)
[ ] Bug severity distribution (1-5)
[ ] UAT user satisfaction (1-5)
Источник: Dev to Ops Handoff
☐ Deployment successful (rollout complete)
☐ Smoke tests passed in production
☐ Monitoring configured (dashboards created)
☐ Alerting configured (on-call setup)
☐ Logs aggregated and accessible
☐ Runbook delivered and reviewed
☐ Operations team trained (handover session done)
☐ Rollback plan tested
☐ Production environment documented
☐ SLA/SLO defined and agreed
[ ] Runbook quality (1-5)
[ ] Operations team readiness (1-5)
[ ] Monitoring coverage (1-5)
Ритуал: Joint Operations Period (2-4 недели совместной работы)
Источник: Project Closure
☐ EOL (End-of-Life) decision approved by business
☐ Replacement system ready (if applicable)
☐ Migration plan approved
☐ Data retention policy defined
☐ Users notified (minimum 3 months notice)
☐ Decommissioning plan approved by Compliance
[ ] Migration readiness (1-5)
[ ] User impact (1-5: lower is better)
☐ All data archived per retention policy
☐ All infrastructure decommissioned
☐ All users migrated (or notified)
☐ All licenses cancelled
☐ Post-project review completed
☐ Lessons learned documented
☐ Financial closure (all invoices paid)
☐ Team released
Ключевая находка: Системы управления радикально меняются на определённых границах.
| Фаза | Системы управления | Фокус управления |
|---|---|---|
| Initiation | Идеи: Confluence, Notion, Linear Ideas | Идеи → приоритизация |
| Planning | Roadmap: ProductBoard, Aha!, Jira Roadmaps | Требования → планирование |
| Design | Design: Figma, Miro, LucidChart | Дизайн → согласование |
| Development | Code: Git, Jira, CI/CD (Jenkins) | Задачи → код → builds |
| Testing | QA: TestRail, Jira (bugs), Selenium | Тесты → баги → качество |
| Deployment | Release: Kubernetes, ArgoCD, ServiceNow (CAB) | Релизы → изменения |
| Operations | Monitoring: Grafana, PagerDuty, ServiceNow (Incidents) | Инциденты → SLA → стабильность |
| Closure | Archive: Confluence (archived), S3 Glacier | Архив → compliance |
ЧТО МЕНЯЕТСЯ:
| Аспект | Development | Operations |
|---|---|---|
| Цель | Создать фичи | Обеспечить стабильность |
| Приоритет | Скорость разработки | Uptime & Performance |
| Системы | Git, Jira, CI/CD | Grafana, PagerDuty, Logs |
| Метрики | Velocity, Sprint burndown | SLA, MTTR, Uptime |
| Ритм | Спринты (2 недели) | On-call (24/7) |
| Ответственность | Developers | SRE / Operations |
| Документация | Code comments, README | Runbooks, Incident playbooks |
| Коммуникация | Stand-ups, Retros | Incident calls, Post-mortems |
ПОЧЕМУ КРИТИЧНО:
- Разные культуры (dev wants change, ops wants stability)
- Разные инструменты (code vs monitoring)
- Разная ментальность (proactive vs reactive)
РЕШЕНИЕ: DevOps культура — размыть границу через:
- Shared ownership (developers on-call)
- Unified tooling (GitOps, Observability)
- SRE practices (SLO, Error budgets)
ЧТО МЕНЯЕТСЯ:
| Аспект | Planning | Design |
|---|---|---|
| Фокус | ЧТО делать | КАК делать |
| Язык | Business language (user stories) | Technical language (patterns, APIs) |
| Системы | Jira, Roadmaps | Figma, LucidChart, ADR |
| Участники | BA, PM, Stakeholders | Architects, Tech Leads, UX |
| Артефакты | Requirements doc | Architecture doc |
Системы, которые ОСТАЮТСЯ:
| Система | Фазы | Зачем |
|---|---|---|
| Jira | Planning → Development → Testing | Task tracking, Bug tracking |
| Git | Development → Operations | Code, Infrastructure as Code |
| Confluence | Все фазы | Documentation hub |
| Slack/Teams | Все фазы | Communication |
Пользователь описал:
"до проектирование, проектирование, производство, эксплуатация"
Почему критична:
- Идея → решение — на этой границе отсеивается 70% плохих проектов
- Feasibility study — без этого проект может провалиться через год
- Business Case — без этого нет бюджета
Последствия пропуска:
- Проекты стартуют без проверки жизнеспособности
- Ресурсы тратятся на заведомо провальные идеи
- Нет критериев успеха (потому что не было бизнес-кейса)
Почему критична:
- В V-Model это 50% модели (правая сторона V)
- QA — это отдельная дисциплина с отдельными инструментами
- UAT — это отдельный gate (business sign-off)
Последствия пропуска:
- Тестирование "размазывается" по Development
- Нет чёткого критерия "готов к релизу"
- Баги находятся в production (дорого!)
Почему критична:
- Deployment ≠ Development — это отдельная фаза с отдельными рисками
- Production Readiness — это отдельный checklist (monitoring, rollback, runbooks)
- Handover to Operations — это отдельный ритуал (joint operations period)
Последствия пропуска:
- Релиз = хаос (нет плана, нет rollback)
- Operations получает неготовый продукт (нет runbook)
- Downtime при релизе (потому что не было smoke tests)
Почему критична:
- Все проекты когда-то заканчиваются (EOL)
- Data archival — compliance требование (GDPR, SOX)
- Lessons Learned — без этого повторяются те же ошибки
Последствия пропуска:
- Системы живут "зомби-жизнь" (maintenance forever)
- Data leaks (не удалили данные при decommission)
- Нет обучения (не зафиксировали уроки)
Классификация пользователя предполагает чёткие границы (Waterfall).
НО: В современных подходах границы размыты:
Planning (Sprint Planning) → Development + Testing (2 недели) → Deployment (Sprint Review)
↓ ↓
Recycle (следующий спринт) ←───────────────────────────────────────┘
Фазы повторяются каждые 2 недели.
Code → Build → Test → Deploy (НЕПРЕРЫВНО)
↓ ↓
└──────← Monitor ←──────────┘
Фазы параллельны и автоматизированы.
Commit → CI → CD → Production (ЕЖЕДНЕВНО)
Границы исчезают — каждый коммит может идти в production.
| Добавить | Вместо | Зачем |
|---|---|---|
| Initiation | — | Проверка идеи до начала |
| Planning | "до проектирование" | Чёткое имя + отдельная фаза |
| Design | "проектирование" | OK, но уточнить что это ТОЛЬКО дизайн |
| Development | "производство" | Ясное имя (производство = manufacturing) |
| Testing | — | Критическая фаза (V-Model) |
| Deployment | — | Отдельный риск (rollout, rollback) |
| Operations | "эксплуатация" | OK |
| Closure | — | Завершение жизненного цикла |
Проект: Запуск онлайн-магазина для retail сети (1000 товаров).
Фазы:
| Фаза | Длительность | Ключевые события | Gate |
|---|---|---|---|
| Initiation | 1 месяц | Feasibility study → ROI 250% за 2 года → GO | ✅ Business Case approved |
| Planning | 2 месяца | 500 user stories → 12 модулей → budget $2M | ✅ Requirements signed |
| Design | 1.5 месяца | Architecture (microservices) → Figma mockups | ✅ CTO approved |
| Development | 6 месяцев | 5 команд → 150k lines of code → CI/CD setup | ✅ Code complete |
| Testing | 2 месяца | 2500 test cases → 87 bugs fixed → UAT passed | ✅ QA sign-off |
| Deployment | 2 недели | Kubernetes rollout → smoke tests OK → handover | ✅ Production ready |
| Operations | Ongoing | 3 incidents/month → SLA 99.9% maintained | — |
Критический момент:
- Gate 5 (Testing → Deployment) — найдено 15 critical bugs за 2 дня до релиза
- Решение: Recycle → 2 недели bug fixing → re-test → GO
Проект: SaaS платформа для управления задачами (MVP).
Фазы (сжатые):
| Спринт | Фазы | Ключевые события |
|---|---|---|
| Sprint 0 | Initiation + Planning | Идея → pitch deck → $100k seed → 3 человека |
| Sprint 1-4 | Design + Development | Wireframes → 1st version (login, tasks, list) |
| Sprint 5 | Testing + Deployment | Beta users (50) → feedback → bugs fixed |
| Sprint 6-12 | Operations (+ incremental dev) | Launch → 500 users → продолжаем фичи |
Ключевые отличия от Waterfall:
- Фазы перекрываются — design + development параллельно
- Gates неформальные — sprint review вместо gate meeting
- Deployment частый — каждый спринт = релиз
Критический момент:
- Sprint 5 — Beta users нашли critical UX issue (не понятна навигация)
- Решение: Emergency redesign (3 дня) → hotfix → launch
Проект: Вывод из эксплуатации старого CRM (15 лет в production).
Фазы:
| Фаза | Длительность | Ключевые события |
|---|---|---|
| Planning | 1 месяц | Анализ: 500k записей, 50 пользователей, 3 интеграции |
| Migration | 3 месяца | Миграция на Salesforce → data mapping → testing |
| Deployment (new) | 2 недели | Salesforce rollout → training → cutover |
| Decommission (old) | 1 месяц | User notification → data archival → server shutdown |
| Closure | 2 недели | Post-mortem → lessons learned → team released |
Критический момент:
- Data archival — compliance требует хранить данные 7 лет
- Решение: Export to S3 Glacier → audit trail → compliance sign-off
✅ Gate reviews предотвращают дорогие ошибки:
- Gate 1 (Initiation → Planning) — отсеивает плохие идеи
- Gate 5 (Testing → Deployment) — не пускает баги в production
- Gate 6 (Deployment → Operations) — обеспечивает stable operations
✅ Самая критичная граница: Development → Operations
- Разные инструменты (Git → Grafana)
- Разные культуры (dev → ops)
- Разные метрики (velocity → uptime)
✅ Waterfall: Чёткие границы, формальные gates, последовательные фазы
✅ Agile: Размытые границы, спринты, частые релизы
✅ DevOps: Continuous, автоматизация, feedback loops
✅ Без Initiation — провальные проекты
✅ Без Testing — баги в production
✅ Без Deployment — хаотичные релизы
✅ Без Closure — зомби-системы
Документ подготовлен: 2026-02-04
Статус: Research Complete
Следующие шаги: Интеграция в стандарты architect/standards/LIFECYCLE.md