devopsd / waterfall_report_1.md

Public

Created 2026-04-06

0 stars

Code

28 KiB

Модуль 1. Внутренняя ИС управления проектами для IT-интегратора (Waterfall)

Роль автора: руководитель проекта.
Срок: 6 месяцев (ориентир — около 24 рабочих недель).
Заказчики: руководство (1 человек) — картина по портфелю и отчётность; руководители проектов (5 человек) — ключевые пользователи.
Команда: аналитики А1 и А2; разработчики Р1 и Р2; тестировщики Т1 и Т2; вы — РП.

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

Краткое резюме

Цель — внедрить внутреннюю информационную систему управления проектами: портфель, статусы, базовая отчётность для топа и удобные сценарии для пяти РП (планы, риски, трудозатраты — в рамках того, что успеете за полгода). Методология — Waterfall: сначала договорились о требованиях и границах, потом спроектировали, потом код, потом тесты, потом выкатили в тест и ОПЭ, затем пром и сопровождение. РП держит календарь, риски и приёмку; аналитики тянут смысл и ТЗ; разработка и тест — по двое, чтобы можно было параллелить модули и проверки без фанатизма.

Фазы Waterfall: задачи, исполнители, результаты

Границы фаз у водопада — это ворота: не утвердили пакет артефактов на выходе — в следующую фазу не перешли (иначе потом «доделаем требования в коде» и получите вечный сдвиг).

Сводная таблица

Фаза	Кто в основном занят	Конкретные задачи (по людям)	Результат фазы
Сбор требований	А1, А2; РП; заказчики	А1: интервью с топом и двумя РП, карта процессов, нефункциональные требования. А2: интервью с тремя остальными РП, user stories/сценарии, прототипы экранов в низкой детализации. РП: план интервью, реестр рисков и заинтересованных, приоритизация с заказчиком.	Утверждённое Vision и спецификация требований (что в релиз 1, что отложено).
Проектирование	А1, А2; Р1, Р2 (ревью); РП	А1: модель данных, интеграции (если с 1С/AD/почтой — на уровне идей). А2: ТЗ по разделам, BPMN/схемы процессов, макеты UI. Р1/Р2: ревью архитектуры и оценка трудозатрат по ТЗ. РП: контроль полноты, календарный план релиза.	ТЗ на разработку, модели (ER, диаграммы), план проекта разработки/тестов.
Реализация	Р1, Р2; А1, А2 (частично); РП	Р1: бэкенд, API, БД, CI. Р2: фронт или второй сервис — по разбиению в ТЗ. А1/А2: ответы на вопросы по ТЗ, мелкие уточнения (через запросы изменений). РП: еженедельный статус, эскалации.	Рабочий код, сборки, черновик инструкции по развёртыванию, API-док по возможности.
Тестирование	Т1, Т2; Р1, Р2; РП	Т1: тест-план, функциональные сценарии, регресс. Т2: нагрузочное/безопасность — выборочно по рискам; интеграционные тесты. Р1/Р2: исправление дефектов. РП: приёмка внутренняя, критерии выхода.	Отчёт о тестировании, журнал дефектов, решение «готово к выкладке».
Развёртывание (тест, ОПЭ)	Р1, Р2; Т1, Т2; РП; пилотные РП	Р1/Р2: выкладка в тест и предпрод, скрипты, миграции. Т1/Т2: смоук, регресс на контуре. РП: организация ОПЭ с 2–3 РП, сбор обратной связи. РП (пользователи): реальная работа в пилоте.	Система в тестовом/предпром контуре, протокол ОПЭ, список доработок до прома.
Поддержка (пром)	Р1, Р2 по дежурствам; Т1; РП; топ	Р1/Р2: дежурный разработчик на инциденты, патчи. Т1: разбор критичных багов с прода, контроль регресса на хотфиксах. РП: SLA с бизнесом, релизы патчей. Топ: получает отчётность по факту.	Регламент эксплуатации, SLA, журнал инцидентов, стабильный пром.

Примеры артефактов и документов

Документ / артефакт	Откуда берётся	Зачем нужен
Vision / концепция	Интервью с топом и РП, фасилитация	Общая картина и границы релиза 1; согласование «что точно делаем».
Спецификация требований	Интервью, уточнения, приоритизация	Основа для ТЗ и тестов; защита от scope creep.
Техническое задание	Проектирование по спецификации	Контракт для разработки и приёмки.
ER-диаграмма, схемы API	Аналитики + ревью разработчиков	Понимание данных и интеграций.
План тестирования	Тестировщики по ТЗ	Что и как проверяем, критерии готовности.
Акт приёмки / протокол ОПЭ	РП + заказчики после тестов/пилота	Формальное «приняли к эксплуатации» или список доработок.
Регламент и SLA	Поддержка, согласование с топом	Правила жизни системы в проме.

Диаграмма Ганта и смысл

Что такое диаграмма Ганта и зачем она здесь

Диаграмма Ганта — это календарная шкала: работы — полоски во времени, видно что за чем и кто чем занят. В учебном смысле и в жизни она нужна не ради красоты, а чтобы: не обещать одну дату пяти людям без учёта зависимостей; увидеть критический путь (где задержка бьёт по концу проекта); договориться с заказчиком, когда ждать пилот и пром. Для Waterfall она особенно удобна: фазы последовательны, и на глазах видно «ворота» между ними.

Ниже — упрощённая схема на 24 недели (условный старт 5 января 2026, длительности в днях подогнаны под ~24 недели суммарно).

gantt
    title Внедрение внутренней ИСУП (~24 недели)
    dateFormat YYYY-MM-DD

    section СборТребований
    Интервью Vision приоритеты А1 А2     :req, 2026-01-05, 28d

    section Проектирование
    ТЗ модели ревью архитектуры         :des, after req, 35d

    section Реализация
    Разработка бэк фронт CI Р1 Р2       :dev, after des, 56d

    section Тестирование
    Тест план кейсы регресс Т1 Т2       :test, after dev, 28d

    section Развертывание
    Тест контур ОПЭ пилот               :dep, after test, 14d

    section Поддержка
    Пром эксплуатация дежурства         :sup, after dep, 7d

Что идёт последовательно

Сбор требований до заморозки базового объёма — иначе ТЗ будет писаться в пустоту.
Проектирование (ТЗ, модели) до массовой разработки по смыслу Waterfall — код как основной поток идёт после утверждённого ТЗ (мелкие уточнения потом — через изменения, не «втихаря»).
Основное тестирование приёмочного уровня после того, как есть стабильная сборка для тестового контура — иначе тестируете воздух.
Промышленный контур после успешных тестов и ОПЭ — иначе рискуете «пожаром» у себя же в офисе.

Что можно и нужно параллелить

Два аналитика: в сборах — параллельные интервью и черновики разделов; в проектировании — один тянет данные и интеграции, второй — сценарии UI и процессы.
Два разработчика: параллельно бэкенд и фронт (или два сервиса) после того, как в ТЗ зафиксированы контракты API — чтобы не блокировать друг друга.
Тестирование и разработка: на хвосте реализации Т1 может начать готовить тест-кейсы по утверждённому ТЗ, пока Р1/Р2 ещё дописывают последние модули — полное регрессионное тестирование всё равно после стабильной сборки.
Инфраструктура тестового контура: можно поднимать параллельно поздней разработке, когда понятны зависимости (БД, очереди, SSO).

Ресурсы по фазам (кто загружен)

Фаза	РП	А1	А2	Р1	Р2	Т1	Т2	Топ	РП-пользователи (5)
Сбор	Высокая	Высокая	Высокая	—	—	Низкая	Низкая	Средняя (интервью)	Высокая (интервью, воркшопы)
Проектирование	Высокая	Высокая	Высокая	Средняя (ревью)	Средняя (ревью)	Низкая	Низкая	Средняя	По запросу
Реализация	Средняя	Средняя (вопросы)	Средняя	Высокая	Высокая	Низкая	Низкая	Низкая	Редко
Тестирование	Средняя	Низкая	Низкая	Высокая (фиксы)	Высокая	Высокая	Высокая	Низкая	Участие в приёмке
Развёртывание	Высокая	Низкая	Низкая	Высокая	Высокая	Высокая	Высокая	Средняя	Пилот (2–3 чел.)
Поддержка	Средняя	Низкая	Низкая	По графику	По графику	Средняя	Низкая	Отчётность	Постоянные пользователи

Детально по фазам

Ниже — по каждой фазе одно и то же: что делаем, какой инструмент (минимум один с применением), какой документ (откуда берётся и зачем), согласования, кто с кем общается и что передаёт.

1. Сбор требований

Задачи и действия. Понять, как сейчас РП живут без единой системы: где боль, что хотят видеть в отчётах для топа, какие сценарии обязательны в первой версии. Провести серию интервью (структурированных), зафиксировать роли и отчётность, собрать нефункциональные требования (сколько пользователей, доступ извне, резервное копирование — хотя бы в голове). Приоритизировать MoSCoW или простым списком с заказчиком. Результат — понятная граница релиза 1.

Инструменты. Например Miro (или аналог) для совместной доски: на воркшопе с РП выкладываете стикеры «боль — идея — приоритет», потом это превращается в структуру требований. Удобно тем, что пять РП не спорят голосом в одном чате — они видят одну картинку.

Документы. Vision / концепция рождается из интервью и воркшопов: сначала черновик у А1/А2, потом итерация с топом. Назначение — одна страница, с которой согласованы цель, границы и «не делаем в v1», чтобы дальше не тащить лишний scope.

Согласования. Утверждение Vision с топом (по сути go для проектирования) и согласование списка must-have с пятью РП (хотя бы письменно: «согласны с приоритетами»).

Взаимодействие. А1 и А2 передают РП сводку по интервью и рискам; РП несёт это топу на одну страницу «что получим через 6 месяцев». РП-пользователи отдают аналитикам реальные сценарии («как закрываю месяц»); аналитики возвращают уточняющие вопросы и черновик требований на ревью. Задача взаимодействия — не потерять нюансы отчётности для топа и не забыть про удобство РП.

2. Проектирование (моделирование, ТЗ)

Задачи и действия. Развернуть требования в ТЗ: модули, роли, права, отчёты, интеграции на уровне «надо / не надо». Построить модель данных и основные потоки (BPMN или блок-схемы — как удобнее команде). Прототипы ключевых экранов — чтобы РП не подписывали «кота в мешке». Р1/Р2 подключаются к ревью архитектуры: хватает ли двух человек на срок, нет ли противоречий с инфраструктурой компании.

Инструменты. Например draw.io (diagrams.net) для ER и схем интеграций: рисуете сущности «проект», «задача», «трудозатраты», связи — и эту же картину потом используют разработчики при создании БД и API.

Документы. Техническое задание появляется из спецификации требований и моделей: аналитики пишут разделы, разработчики дают комментарии в ревью. Назначение — единый источник правды для кода и тестов; по нему же потом проверяете приёмку.

Согласования. Внутреннее ревью ТЗ с Р1, Р2 (техническая выполнимость), затем подписание с топом или уполномоченным (бюджет времени команды уже внутренний, но формально «мы так поняли задачу» лучше зафиксировать).

Взаимодействие. А1/А2 спорят с Р1/Р2 о API и границах модулей (что отдаём на фронт, что храним в БД). РП сводит конфликты по срокам и отдаёт заказчику дату пилота из плана. Передаваемые артефакты: черновики диаграмм, список открытых вопросов, финальное ТЗ в Confluence или в файле — главное, чтобы у всех была одна версия.

3. Реализация (написание кода)

Задачи и действия. Разработка по ТЗ: репозиторий, ветки, код-ревью между Р1 и Р2, миграции БД, подключение CI (сборка и базовые тесты на каждый merge). Документирование развёртывания и API (хотя бы минимально). Запросы на изменение ТЗ — через РП, если без этого нельзя.

Инструменты. Например GitLab (или GitHub): репозиторий, merge requests, CI pipeline. Применение: каждый merge в main гоняет сборку и автотесты — вы раньше видите «сломали ли сборку», чем на конце тестирования.

Документы. README / инструкция по развёртыванию рождается из того, как Р1/Р2 реально поднимают контур: какие переменные окружения, как миграции. Назначение — чтобы Т1/Т2 и потом дежурный могли повторить выкладку без шаманства.

Согласования. Внутренние code review обязательны; крупные отклонения от ТЗ — согласование с РП и аналитиком (чтобы не потерять трассировку требований).

Взаимодействие. Р1 ↔ Р2: обмен по контрактам API и разбивке задач в трекере. Аналитики ↔ разработчики: уточнения по ТЗ (в идеале — задачи в Jira с ссылкой на пункт ТЗ). РП ↔ команда: статус, блокеры, риски срыва срока. Передаётся: задачи, ссылки на ТЗ, решения по компромиссам.

4. Тестирование

Задачи и действия. Т1 ведёт тест-план и функциональные сценарии по ТЗ; Т2 — интеграционные сценарии, при необходимости нагрузочный скрининг (хотя бы «не падает при N пользователях»). Регресс после исправлений. РП проверяет, что критерии выхода из фазы выполнены (например, нет блокирующих дефектов, закрыт must-have).

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

Документы. Отчёт о тестировании (итоговый) собирается Т1 из результатов прогонов: что проверено, что не вошло, известные ограничения. Назначение — основание для решения «идём в развёртывание» или «нужна доработка».

Согласования. Согласование критериев приёмки с РП и представителем заказчика (хотя бы один из РП-пользователей и топ по отчётности).

Взаимодействие. Т1/Т2 → Р1/Р2: баг-репорты, уточнения «это баг или фича». РП → заказчик: честный статус по качеству. Тестировщики ↔ аналитики: если поведение спорное — сверка с ТЗ.

5. Развёртывание (тестовый контур, ОПЭ)

Задачи и действия. Выкладка в тестовый контур, затем предпрод / зона ОПЭ: ограниченный круг 2–3 РП работает как в бою, Т1/Т2 — смоук и регресс на новом контуре. Сбор обратной связи, план обучения остальных РП. Решение go/no-go в пром.

Инструменты. Например Ansible (или другой IaC) для повторяемых выкладок: один playbook — одинаковый тест и предпрод. Применение: меньше ручных ошибок при переносе на «боевой» сервер.

Документы. Протокол ОПЭ — фиксирует период, участников, список замечаний и решение (принять / доработать). Появляется после пилота, когда РП собирает входящие от РП-пользователей. Назначение — защита от ситуации «в пром выкатили, а про критичный косяк забыли в переписке».

Согласования. Go/no-go с топом и ключевыми РП после ОПЭ; согласование окна вывода в пром (чтобы не в пик закрытия внешних проектов, если у вас так принято).

Взаимодействие. Р1/Р2 с инфраструктурой (если есть внутренняя ИТ-служба) — доступы, сертификаты. РП с пилотными РП — ежедневный короткий синк или чат. Тестировщики подтверждают готовность контура.

6. Поддержка (промышленный контур, промышленная эксплуатация)

Задачи и действия. Ввод в пром, мониторинг, дежурства разработчиков по графику, разбор инцидентов, мелкие патчи, сбор обратной связи от пяти РП и топа. Регулярная отчётность для руководства — как договорились в Vision.

Инструменты. Например Grafana (или встроенный мониторинг) + алерты по доступности и ошибкам API. Применение: вы видите «сервер лёг» раньше, чем топ напишет в личку.

Документы. SLA и регламент эксплуатации: сроки реакции на инциденты, кто дежурный, как эскалировать. Появляется из совместной работы РП, ИТ и топа после ввода в пром. Назначение — чтобы поддержка не была «позвони программисту в выходной», а понятным процессом.

Согласования. Утверждение SLA с топом; при смене версии — релиз-ноты и согласование окна обновления.

Взаимодействие. Пользователи (РП) → дежурный (через тикет-систему): описание проблемы. Дежурный разработчик ↔ Т1 на критичных багах (регресс хотфикса). РП → топ: периодический отчёт по использованию и инцидентам. Передаётся: тикеты, метрики, решения по изменениям в следующих релизах.