architect/standards/arh/process-project-start.md

type: standard
aspect: process
title: "Стандарт: Начало проекта (Project Start)"
version: 1.0.0
date: 2026-02-19
status: active

Стандарт: Начало проекта (Project Start)

Версия: 1.0.0
Дата: 2026-01-05
Статус: Стандарт

НАЗНАЧЕНИЕ

Этот стандарт описывает как ПРАВИЛЬНО начинать любой IT-проект.

Основан на Теории 9 вопросов.

ПОСЛЕДОВАТЕЛЬНОСТЬ (обязательная!)

ФАЗА 0: INTAKE (сбор входных данных)
   ↓
ФАЗА 1-5: ПОСЛЕДОВАТЕЛЬНЫЕ ВОПРОСЫ
   1. ПОЧЕМУ  → Проблема
   2. ЗАЧЕМ   → Видение
   3. ЧТО     → Решение
   4. КТО     → Команда
   5. КАК     → Архитектура
   ↓
ФАЗА 6-8: ПАРАЛЛЕЛЬНЫЕ ВОПРОСЫ
   6. ЧЕМ     → Технологии
   7. ГДЕ     → Инфраструктура
   8. КОГДА   → Roadmap
   ↓
ФАЗА 9: ИТОГОВАЯ ОЦЕНКА
   9. СКОЛЬКО → Ресурсы
   ↓
ФАЗА 10: СТАРТ РАЗРАБОТКИ

ФАЗА 0: INTAKE (2-4 часа)

Цель

Собрать ВСЕ входные данные перед проектированием.

Документ

00_INTAKE.md

Что заполнить

  1. Исходная идея — что хотим, откуда идея, аналогия
  2. Стартовые данные — что уже есть (код, доки, инфра)
  3. Ограничения — время, бюджет, технологии, юридические
  4. Цели — бизнес, технические, MVP
  5. Риски — что может пойти не так
  6. Референсы — конкуренты, аналоги, best practices
  7. Стейкхолдеры — кто участвует, кто решает

Критерии готовности

Выход из фазы

ТОЛЬКО если всё заполнено → переход к ФАЗА 1.

Если НЕ всё заполнено → провести исследование:
- Market research
- Competitor analysis
- User interviews
- Technical feasibility

ФАЗА 1: ПОЧЕМУ (4-8 часов)

Цель

Определить и описать проблему, которую решаем.

Документ

01_PROBLEM.md

Что заполнить

  1. Суть проблемы — что не работает сейчас
  2. Масштаб — размер рынка, темпы роста
  3. Кто страдает — бизнес, разработчики, пользователи
  4. Сколько стоит — деньги, время, упущенная выгода
  5. Почему существует — технологические, экономические, организационные причины
  6. Почему существующие решения не работают — анализ конкурентов
  7. Технологический момент — почему сейчас время решать

Критерии готовности

Выход из фазы

ТОЛЬКО если проблема чётко сформулирована → переход к ФАЗА 2.

Если проблема размыта → углубить анализ:
- Больше market research
- User interviews
- Competitor deep dive

ФАЗА 2: ЗАЧЕМ (4-6 часов)

Цель

Сформулировать видение: как мир изменится когда проблема решена.

Документ

02_VISION.md

Что заполнить

  1. Видение — картина будущего (как будет выглядеть мир)
  2. Ценность — что получат пользователи
  3. Миссия — зачем мы это делаем
  4. Принципы — на каких ценностях строим
  5. Метрики успеха — как поймём что достигли
  6. North Star Metric — главная метрика

Критерии готовности

Выход из фазы

ТОЛЬКО если видение вдохновляет → переход к ФАЗА 3.

ФАЗА 3: ЧТО (6-10 часов)

Цель

Описать решение: что именно мы делаем.

Документ

03_SOLUTION.md

Что заполнить

  1. Определение — что это (продукт/сервис/платформа)
  2. Ключевые функции — топ-5 возможностей
  3. Границы — что НЕ входит в проект
  4. Уникальность — чем отличаемся от конкурентов
  5. User flow — как пользователь работает
  6. MVP scope — минимум для первого запуска

Критерии готовности

Выход из фазы

ТОЛЬКО если ЧТО делаем понятно → переход к ФАЗА 4.

ФАЗА 4: КТО (2-4 часа)

Цель

Определить команду и стейкхолдеров.

Документ

04_STAKEHOLDERS.md

Что заполнить

  1. Product Owner — кто принимает решения
  2. Команда разработки — роли и ответственность
  3. Пользователи — кто использует (сегменты)
  4. Стейкхолдеры — кто влияет на проект
  5. RACI матрица — кто что делает

Критерии готовности

Выход из фазы

ТОЛЬКО если роли определены → переход к ФАЗА 5.

ФАЗА 5: КАК (8-16 часов)

Цель

Спроектировать архитектуру системы.

Документ

05_ARCHITECTURE.md

Что заполнить

  1. Общая схема — как устроена система (диаграмма)
  2. Слои/компоненты — из каких частей состоит
  3. Взаимодействие — как части общаются
  4. Паттерны — какие используем (DDD, Clean, MVC)
  5. Принципы — SOLID, DRY, KISS
  6. Технические решения — почему выбрали именно так

Критерии готовности

Выход из фазы

ТОЛЬКО если архитектура спроектирована → переход к ФАЗА 6-8 (параллельно).

ФАЗА 6-8: ПАРАЛЛЕЛЬНЫЕ (8-12 часов ВСЕГО)

Эти фазы можно делать одновременно (после КАК).

ФАЗА 6: ЧЕМ (4 часа)

Документ: 06_TECH_STACK.md

Что: Выбор технологий (язык, фреймворк, БД, инфра)

Критерии:
- [ ] Backend stack выбран (с обоснованием)
- [ ] Frontend stack выбран
- [ ] Database выбрана
- [ ] Infrastructure определена

ФАЗА 7: ГДЕ (4 часа)

Документ: 07_INFRASTRUCTURE.md

Что: Где разворачиваем (Dev, Staging, Production)

Критерии:
- [ ] Окружения определены
- [ ] Хостинг выбран
- [ ] CI/CD описан
- [ ] Мониторинг определён

ФАЗА 8: КОГДА (6 часов)

Документ: 08_ROADMAP.md

Что: Фазы разработки и сроки

Критерии:
- [ ] Фазы определены
- [ ] Зависимости описаны
- [ ] Сроки оценены
- [ ] Milestones зафиксированы

ФАЗА 9: СКОЛЬКО (4-6 часов)

Цель

Оценить ресурсы: время, деньги, люди.

Документ

09_RESOURCES.md

Что заполнить

  1. Время — сколько часов/недель/месяцев
  2. Деньги — бюджет разработки + инфра
  3. Люди — сколько человек в команде
  4. ROI — когда окупится

Критерии готовности

Выход из фазы

ТОЛЬКО если ресурсы оценены → переход к ФАЗА 10 (старт разработки).

ФАЗА 10: СТАРТ РАЗРАБОТКИ

Критерии готовности проекта

ОБЯЗАТЕЛЬНЫЙ чек-лист перед первой строкой кода:

ЕСЛИ хотя бы один НЕ готов → НЕ начинать разработку!

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

  1. Создать репозиторий
  2. Настроить инфраструктуру (Dev окружение)
  3. Первый спринт — MVP фичи
  4. Установить ритм — стендапы, ретро, планирование

ВРЕМЯ НА ПОДГОТОВКУ

Минимум (быстрый старт)

INTAKE:     2 часа
PROBLEM:    4 часа
VISION:     4 часа
SOLUTION:   6 часов
STAKEHOLDERS: 2 часа
ARCHITECTURE: 8 часов
TECH/INFRA/ROADMAP: 8 часов
RESOURCES:  4 часа
─────────────────────────
ИТОГО:     38 часов (1 неделя)

Рекомендуемый (полный)

INTAKE:     4 часа
PROBLEM:    8 часов
VISION:     6 часов
SOLUTION:   10 часов
STAKEHOLDERS: 4 часа
ARCHITECTURE: 16 часов
TECH/INFRA/ROADMAP: 12 часов
RESOURCES:  6 часов
─────────────────────────
ИТОГО:     66 часов (1.5-2 недели)

ЧАСТЫЕ ОШИБКИ

❌ Что НЕ делать

❌ Начать с КАК (архитектуры) без ПОЧЕМУ и ЗАЧЕМ
   → Будете делать не то что нужно

❌ Пропустить INTAKE
   → Ограничения всплывут в середине проекта

❌ Сделать всё параллельно
   → Противоречия и переделки

❌ Копировать шаблоны не заполняя
   → Бесполезная документация

❌ Начать разработку без архитектуры
   → Технический долг с первого дня

✅ Что делать

✅ Идти строго по порядку: 0 → 1 → 2 → 3 → 4 → 5 → 6-8 → 9
✅ Заполнять каждый документ ПОЛНОСТЬЮ
✅ Удалять инструкции после заполнения
✅ Добавлять реальные факты и цифры
✅ Обновлять при изменениях

ВАРИАНТЫ ИСПОЛЬЗОВАНИЯ

Вариант 1: Полная документация (рекомендуется)

Для: Серьёзные проекты, enterprise, стартапы с инвестициями

Что: Все 10 документов отдельно

Время: 1.5-2 недели

Результат: Полная ясность перед разработкой

Вариант 2: Быстрый старт

Для: Прототипы, MVP, эксперименты

Что: Один документ PROJECT.md (все разделы в одном)

Время: 1-2 дня

Результат: Минимальная документация для старта

Вариант 3: Итеративный

Для: Непонятно с чего начать, много неизвестного

Что:
1. INTAKE → исследование → PROBLEM
2. PROBLEM → исследование → VISION
3. И так далее...

Время: 2-4 недели

Результат: Глубокое понимание через итерации

ШАБЛОНЫ

Все шаблоны в:

$WORKSPACE/architect/templates/project-start/
Файл Документ
00_INTAKE.md Входные данные
01_PROBLEM.md Проблема
02_VISION.md Видение
03_SOLUTION.md Решение
04_STAKEHOLDERS.md Команда
05_ARCHITECTURE.md Архитектура
06_TECH_STACK.md Технологии
07_INFRASTRUCTURE.md Инфраструктура
08_ROADMAP.md План
09_RESOURCES.md Ресурсы
PROJECT_TEMPLATE.md Всё в одном

СВЯЗИ

FAQ

Q: Обязательно делать все 10 документов?
A: Для серьёзного проекта — да. Для прототипа — можно один PROJECT.md.

Q: Сколько времени на подготовку?
A: Минимум 1 неделя, рекомендуется 1.5-2 недели.

Q: Можно ли начать разработку раньше?
A: Нет. Подготовка экономит месяцы переделок.

Q: Что если не знаем ответ на вопрос?
A: Провести исследование ДО заполнения шаблона.

Версия: 1.0.0
Дата: 2026-01-05