Начало работы на проекте — чек-лист самопроверки
Пройдите блоки честно: галочка "да" — только если артефакт существует, актуален и команда им пользуется, а не лежит в черновике Confluence.
Теория — раздел 7.17. Итоги и FAQ — 998.
Как пользоваться чек-листом
- Greenfield — пройдите все блоки до первого демо на stage.
- Реанимация хаоса — отметьте красные флаги, закройте блоки с наименьшим счётом.
- Новичок в команде — блок "Онбординг" + выборочно остальное для понимания зрелости проекта.
Инициация
Соответствует главе 1: charter, спонсор, границы, критерии успеха.
- Есть спонсор с именем, должностью и полномочиями принимать итог.
- Зафиксированы письменные границы scope in и scope out.
- Критерии успеха измеримы (не "сделать хорошо", а "сократить цикл с 5 до 2 дней").
- Выбран тип поставки: продукт / заказ / аутстафф / поддержка.
- Понятна бизнес-цель проекта для организации (1–2 предложения).
- Есть укрупнённый бюджет или лимит T&M с периодом пересмотра.
- Зафиксированы ключевые вехи (пилот, MVP, промэксплуатация) с ориентирами по датам.
- Список стейкхолдеров и канал эскалации конфликтов scope.
- Для заказного проекта — контракт или LOI с моделью оплаты (fixed / T&M).
- Для госконтракта — связь charter с ТЗ по ГОСТ или план её подготовки.
- Команда может пересказать границы scope без "ну мы же договаривались устно".
Команда
Соответствует главе 2: роли, RACI, найм, ядро.
- Назначены владельцы: PO/PM, техлид, аналитик (или явно задокументировано совмещение).
- Матрица RACI на ключевые решения: архитектура, приоритет backlog, релиз на prod.
- Нет ситуации "все ответственны — никто не ответственен" за приёмку и приоритеты.
- Техлид или архитектор назначен до массового найма разработчиков.
- План найма / аутстаффа согласован со сроками roadmap, а не "15 dev с понедельника".
- Для каждой роли понятен первый артефакт на старте (charter, C4, backlog, CI).
- Buddy-программа описана: кто назначает, срок 2–4 недели, снижение нагрузки buddy.
- Контакты HR / кадров и юридических вопросов (NDA, IP) известны команде.
- При аутстаффе — границы: кто ставит задачи, кто ревьюит, кто принимает на prod.
- Core hours или overlap для удалённой команды согласованы (7.23).
Инфраструктура
Соответствует главе 3: среды, доступы, секреты, администрирование.
- Среды dev и stage поднимаются по инструкции новым разработчиком за 1 рабочий день.
- Есть runbook или wiki-страница: как поднять local, куда стучаться при сбое доступа.
- Секреты не в репозитории — Vault, CI variables, .env в .gitignore с примером .env.example.
- Известен контакт администрирования (IT, DevOps, security) и SLA на выдачу доступа.
- VPN / SSO / корпоративный IdP работают для всех членов команды.
- Stage конфигурационно близок к prod (версии runtime, схема БД, имена env-переменных).
- Prod не используется для отладки без процедуры (инциденты 7.21).
- Резервное копирование и восстановление stage/prod описаны или в backlog с датой.
- Мониторинг и алерты запланированы до первого пилота на prod.
- Лицензии ПО и облака оформлены, нет "временных" ключей в личных аккаунтах.
- Политика данных: PII, маскирование на stage, DLP при необходимости.
Инструменты
Соответствует главе 4: Git, трекер, wiki, CI.
- Git: репозиторий с README, веточной политикой (main защищён), CODEOWNERS при необходимости.
- CI на каждый PR: сборка, lint, минимум unit-тестов или smoke.
- Merge в main только через PR с хотя бы одним approve (кроме оговорённого hotfix).
- Трекер (Jira / YouTrack / аналог): все задачи команды видны на доске.
- Workflow трекера отражает реальность — статусы совпадают с тем, как работает команда.
- PR связан с тикетом (PROJ-123 в названии или поле в трекере).
- Wiki или docs-as-code: онбординг-пакет, ссылки на архитектуру, runbooks.
- ADR хранятся рядом с кодом или в wiki с перекрёстными ссылками (7.20).
- Нет параллельного учёта задач в чате без дублирования в трекере.
- Шаблоны тикетов: story, bug, spike, ONBOARD для онбординга.
- Интеграция трекер ↔ Git ↔ CI настроена (статусы, деплой на stage по merge).
- Новый разработчик получает доступы к всем трём инструментам в день 1.
Архитектура
Соответствует главе 5: runway, C4, NFR, ADR.
- Есть диаграмма контекста (C4 Level 1) — система и внешние акторы.
- Есть диаграмма контейнеров (C4 Level 2) — приложения, БД, очереди.
- Минимум 5 ADR: стек, БД, аутентификация, ключевые интеграции, логирование.
- Таблица NFR заполнена: производительность, безопасность, доступность, объём данных.
- Разграничены зоны аналитика / архитектор / разработчик — кто пишет stories, кто ADR.
- Глоссарий доменных терминов (10–30 записей) доступен новичку.
- OpenAPI / контракты интеграций задокументированы или в backlog с приоритетом.
- Нет "трёх разных способов" хранить пользователей в разных модулях без ADR.
- Архитектурные решения обсуждаются в PR/ADR, а не только в личных чатах.
- Связь с 7.06 понятна — runway не заменяет глубокое проектирование позже.
План
Соответствует главе 6: roadmap, backlog, первый инкремент, DoR/DoD.
- Roadmap на 3 месяца с измеримыми результатами, а не списком всех желаний.
- Backlog приоритизирован — верх очереди согласован с PO/спонсором.
- Первый инкремент (thin slice) определён: один сквозной сценарий на stage.
- DoR и DoD согласованы командой (7.25).
- Stories содержат критерии приёмки, а не только название фичи.
- Sprint 0 / первая итерация имеет демо стейкхолдерам, а не только "настроили инфраструктуру".
- Выбран процесс: Scrum / Kanban / гибрид — и команда следует ему (7.03).
- Epic → story → task иерархия в трекере, нет плоского списка из 200 технических задач.
- Зависимости и blocked задачи видны на доске с причиной.
- Для госконтракта — матрица трассировки ТЗ ↔ backlog.
- Ритм встреч задан: планирование, daily, review/demo, ретро (или Kanban cadence).
Онбординг
Соответствует главе 7 и онбординг-пакету.
- Для каждого нового человека создаётся тикет ONBOARD до выхода на работу.
- Назначен buddy с пониженной нагрузкой на 2–4 недели.
- Онбординг-пакет в wiki: charter (кратко), архитектура, среда, процесс, контакты.
- Чек-лист первого дня: доступы, intro, локальная среда, первая задача.
- Чек-лист первой недели: 1–2 PR, участие в daily, знание DoR/DoD.
- Критерий 2-й недели: среда без помощи, PR с ревью, знает эскалацию.
- Первый PR новичка — небольшой (документация, мелкий баг, тест), не рефакторинг на 3000 строк.
- Buddy проводит обзор архитектуры (C4 + 2–3 ADR) в первые 3 дня.
- Remote-онбординг: видео intro, core hours, явный канал вопросов к buddy.
- Фидбек-сессия buddy + тимлид в конце 4-й недели.
- Онбординг обновляется после каждого нового человека (что сломалось, что добавить).
Интерпретация результатов
Подсчитайте галочки по всем блокам (ориентир — ~90 пунктов).
| Доля "да" | Скорее всего | Действие |
|---|---|---|
| ≥ 75% | Проект готов к устойчивой разработке | Поддерживать ритм, закрыть оставшиеся пробелы |
| 50–74% | Старт нестабильный — риск срыва демо и онбординга | Закрыть блоки с < 50% "да" по приоритету ниже |
| < 50% | Хаотичный старт — код без управления и инструментов | Стоп новых фич на 1–2 недели, sprint 0 по главе 6 |
Приоритет закрытия пробелов
| Если слабый блок | Сначала сделать |
|---|---|
| Инициация < 50% | Charter за 1–2 дня со спонсором — глава 1 |
| Команда < 50% | RACI на одной странице, назначить техлида — глава 2 |
| Инфраструктура < 50% | Dev/stage + секреты вне repo — глава 3 |
| Инструменты < 50% | Repo + CI + трекер за 3–5 дней — глава 4 |
| Архитектура < 50% | C4 L1 + 3 ADR за неделю — глава 5 |
| План < 50% | Thin slice + DoR/DoD — глава 6 |
| Онбординг < 50% | ONBOARD-шаблон + buddy — глава 7 |
Быстрая диагностика за 30 минут
Ответьте на пять вопросов без подглядывания в wiki:
- Кто спонсор и что не входит в scope?
- Где посмотреть статус задачи и связанный PR?
- Как поднять проект локально?
- Где лежат ADR по стеку и БД?
- Что покажем на следующем демо?
Три и более неясных ответа — пройдите полный чек-лист и 998.
Типичные провалы (по блокам)
| Симптом | Вероятный блок | Как исправить |
|---|---|---|
| "Мы же договаривались по-другому" | Инициация | Scope in/out в charter, согласовать со спонсором |
| 15 разработчиков, нет техлида | Команда | Назначить техлида, RACI на архитектуру и релиз |
| "Работает на моём ноутбуке" | Инфраструктура | Общий dev/stage, docker-compose или IaC |
| Секреты в Slack и в .env в Git | Инфраструктура | Ротация ключей, Vault, pre-commit |
| Задачи в Telegram, код без тикетов | Инструменты | Правило: нет тикета — нет merge |
| CI красный неделями, все мержат | Инструменты | Защита main, fix или skip с тикетом |
| Три стиля API в одном проекте | Архитектура | ADR + ревью техлида, не BDUF на 200 стр. |
| Backlog = 300 задач без приоритета | План | Story mapping, top 20 на квартал |
| 6 недель без демо | План | Thin slice за 2 недели, показать на stage |
| Новичок неделю сидит без задачи | Онбординг | ONBOARD-тикет, buddy, мелкий PR в день 3–5 |
| Wiki 500 страниц без маршрута | Онбординг | Онбординг-пакет на 5–10 страниц |
Чек-лист "первая неделя" (минимум)
Если полный список пугает — закройте этот минимум за 5 рабочих дней:
- Одностраничный charter (цель, scope in/out, спонсор).
- RACI: PO, техлид, кто мержит в main.
- Repo + защищённый main + CI lint/build.
- Трекер с 10–20 задачами первого инкремента.
- Dev-среда по README (clone → run за < 1 час).
- C4 context на одной диаграмме.
- 3 ADR: язык/фреймворк, БД, auth.
- DoD на одной wiki-странице.
- Назначен buddy для ближайшего новичка (или себя как первого).
Связанные чек-листы
| Чек-лист | Раздел |
|---|---|
| Scrum работает или театр? | 7.14/999 |
| Kanban или доска в Jira? | 7.18/999 |
| DoR / DoD зрелость | 7.25 |
| Итоги запуска | 998 |
FAQ по чек-листу
Вопрос. Мы в середине проекта — нужен ли charter?
Ответ. Да, в ретроактивном виде: зафиксировать текущие границы и критерии успеха со спонсором. Иначе каждое изменение — конфликт. См. глава 1, 7.22.
Вопрос. У нас один разработчик — какой блок можно пропустить?
Ответ. Команда и формальный buddy — упростить. Не пропускайте: charter (хотя бы для себя), repo + CI, NFR/ADR на 1 страницу, backlog с приоритетами.
Вопрос. 90 пунктов — слишком много. С чего начать?
Ответ. Блок Инструменты + План (thin slice + CI). Затем Инициация и Архитектура. Чек-лист "первая неделя" выше — сжатая версия.
Вопрос. Как часто повторять чек-лист?
Ответ. Полный проход — раз в квартал или после смены спонсора/техлида. Блок Онбординг — при каждом новом человеке.
Что делать после диагностики
| Результат | Следующий шаг |
|---|---|
| ≥ 75% | Войти в ритм Scrum/Kanban, углубить 7.06 по мере роста |
| 50–74% | План на 2 недели по таблице приоритетов выше |
| < 50% | Воркшоп со спонсором и техлидом: charter + sprint 0, пауза новых epics |
| Только онбординг слаб | Глава 7 + онбординг-пакет 24 за 3 дня |