ВХОДНЫЕ ДАННЫЕ ПРОЕКТА (Project Intake)

Дата: [ЗАПОЛНИ: YYYY-MM-DD]
Версия: 1.0.0
Статус: [ЗАПОЛНИ: Черновик / Утверждён]

НАЗНАЧЕНИЕ

Этот документ собирает ВСЕ входные данные ПЕРЕД началом проектирования.

Заполняется ПЕРВЫМ, до любых других документов.

1. ИСХОДНАЯ ИДЕЯ

1.1. Краткое описание (1-2 предложения)

[ЗАПОЛНИ: Что хотим сделать одной-двумя фразами]

Пример:

Создать платформу, которая генерирует бизнес-приложения (CRM, ERP)
из YAML-спецификаций без программирования.

1.2. Откуда идея?

[ЗАПОЛНИ: Как возникла идея]

Варианты:
- [ ] Собственная боль (описать какая)
- [ ] Запрос клиента (кто?)
- [ ] Анализ рынка (что увидели?)
- [ ] Развитие существующего продукта (какого?)
- [ ] Другое: [описать]

1.3. Аналогия (метафора)

[ЗАПОЛНИ: "Это как [X], но для [Y]"]

Пример:

Это как Microsoft Word, но для создания приложений.
В Word настраиваешь документ → в нашей платформе настраиваешь приложение.

2. СТАРТОВЫЕ ДАННЫЕ

2.1. Что уже есть?

Код:
- [ ] Есть репозиторий: [ссылка]
- [ ] Есть прототип: [описание]
- [ ] Есть legacy система: [описание]
- [ ] Нет кода (с нуля)

Документация:
- [ ] Есть спецификации: [список]
- [ ] Есть исследования: [список]
- [ ] Есть аналитика рынка: [источники]
- [ ] Нет документации

Инфраструктура:
- [ ] Есть серверы: [описание]
- [ ] Есть БД: [описание]
- [ ] Нет инфраструктуры

2.2. Что известно о рынке?

[ЗАПОЛНИ: Если есть данные]

Вопросы:
- Размер рынка?
- Конкуренты?
- Целевая аудитория?
- Тренды?

2.3. Что известно о пользователях?

[ЗАПОЛНИ: Кто будет использовать]

Типы:
- [ ] B2B (описать компании)
- [ ] B2C (описать пользователей)
- [ ] B2B2C
- [ ] Internal (внутренняя система)

Характеристики:
- Количество: [оценка]
- Геолокация: [страны/регионы]
- Технический уровень: [высокий/средний/низкий]

3. ОГРАНИЧЕНИЯ

3.1. Временные

[ЗАПОЛНИ: Есть ли дедлайны]

• [ ] Жёсткий дедлайн: [дата]
• [ ] Мягкий дедлайн: [дата]
• [ ] Нет дедлайна

Причина дедлайна:
[ЗАПОЛНИ: Почему к этой дате]

3.2. Бюджетные

[ЗАПОЛНИ: Сколько денег доступно]

Разработка:
- Бюджет: [сумма или "нет бюджета"]
- Источник: [собственные / инвестиции / грант / другое]

Инфраструктура:
- Месячный бюджет: [сумма]
- Ограничения: [описать]

3.3. Технологические

[ЗАПОЛНИ: Есть ли технические ограничения]

Обязательные технологии:
- [ ] Язык программирования: [какой и почему]
- [ ] БД: [какая и почему]
- [ ] Облако: [какое и почему]
- [ ] Нет обязательных

Запрещённые технологии:
- [ ] Нельзя использовать: [что и почему]
- [ ] Нет запретов

Совместимость:
- [ ] Должно работать с: [системы]
- [ ] Нет требований

3.4. Организационные

[ЗАПОЛНИ: Есть ли организационные ограничения]

Команда:
- Кто доступен: [роли и количество]
- Кто недоступен: [причины]

Процессы:
- [ ] Обязательные процессы: [какие]
- [ ] Compliance требования: [какие]
- [ ] Нет требований

3.5. Юридические и регуляторные

[ЗАПОЛНИ: Есть ли юридические ограничения]

• [ ] GDPR
• [ ] HIPAA
• [ ] SOC2
• [ ] ISO 27001
• [ ] Другие: [описать]
• [ ] Нет требований

4. ЦЕЛИ И КРИТЕРИИ УСПЕХА

4.1. Бизнес-цели

[ЗАПОЛНИ: Чего хотим достичь бизнесом]

Примеры:
- Выручка $X через Y месяцев
- Z пользователей через Y месяцев
- Занять N% рынка
- Другое: [описать]

4.2. Технические цели

[ЗАПОЛНИ: Чего хотим достичь технически]

Примеры:
- Скорость работы < X мс
- Uptime > Y%
- Масштабируемость до Z юзеров
- Другое: [описать]

4.3. MVP критерии

[ЗАПОЛНИ: Что МИНИМАЛЬНО должно работать]

Обязательные функции:
1. [Функция 1]
2. [Функция 2]
3. ...

НЕ входит в MVP:
1. [Функция X]
2. [Функция Y]
3. ...

5. РИСКИ И ЗАВИСИМОСТИ

5.1. Известные риски

[ЗАПОЛНИ: Что может пойти не так]

5.2. Зависимости

[ЗАПОЛНИ: От чего зависим]

Внешние:
- [ ] API третьих сторон: [какие]
- [ ] Партнёры: [кто]
- [ ] Поставщики: [кто]

Внутренние:
- [ ] Другие проекты: [какие]
- [ ] Команды: [какие]
- [ ] Ресурсы: [какие]

6. РЕФЕРЕНСЫ И ВДОХНОВЕНИЕ

6.1. Конкуренты

[ЗАПОЛНИ: Кто уже делает похожее]

6.2. Аналоги (не конкуренты, но похожие)

[ЗАПОЛНИ: Откуда берём вдохновение]

Примеры:
- Microsoft Word → концепция настройки без кода
- Linux distributions → одна платформа, разные конфигурации
- WordPress → plugin система
- Другое: [описать]

6.3. Лучшие практики

[ЗАПОЛНИ: Какие best practices хотим применить]

Источники:
- Книги: [список]
- Статьи: [ссылки]
- Фреймворки: [какие]

7. КОНТАКТЫ И СТЕЙКХОЛДЕРЫ

7.1. Product Owner

Имя: [ЗАПОЛНИ]
Роль: [ЗАПОЛНИ]
Контакт: [ЗАПОЛНИ]

7.2. Ключевые стейкхолдеры

7.3. Эксперты для консультаций

[ЗАПОЛНИ: К кому можем обратиться]

• Домен: [Имя, контакт]
• Технологии: [Имя, контакт]
• Дизайн: [Имя, контакт]

8. СЛЕДУЮЩИЕ ШАГИ

8.1. Чек-лист готовности

Перед переходом к проектированию проверь:

• [ ] Идея описана ясно
• [ ] Ограничения определены
• [ ] Цели сформулированы
• [ ] Риски зафиксированы
• [ ] Референсы изучены
• [ ] Стейкхолдеры определены

8.2. Что делать дальше?

Если всё заполнено:
→ Переходи к 01_PROBLEM.md — анализ проблемы

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

9. ТЕГИ

---
tags:
  - [ЗАПОЛНИ: теги проекта]
  - intake
market: [ЗАПОЛНИ: b2b-saas / b2c / marketplace / platform]
stage: intake
priority: [ЗАПОЛНИ: high / medium / low]
---

РЕЗЮМЕ

После заполнения этого документа у вас должно быть:

✅ Ясное понимание идеи
✅ Список ограничений
✅ Критерии успеха
✅ Карта рисков
✅ Контакты стейкхолдеров

Только после этого начинаем проектирование!

Версия: 1.0.0
Шаблон: $WORKSPACE/architect/templates/project-start/00_INTAKE.md