Value Enhancing Proposal

Лёгкая методология разработки для личных проектов и сольных инженеров. Без спринтов, дедлайнов и бюрократии. Только поток ценности, прозрачные решения и здравый смысл. Весь процесс ведётся в GitVerse Задачи.

Открыто → Запланировано → В работе → Готово

Что такое Ценность (Value)?

Ценность — это законченная, работающая функция продукта, которую пользователь может увидеть, потрогать и использовать для решения своей задачи.

❌ НЕ ценность:

• «Сделал 5 API ручек на бэкенде» → Пользователь не видит
• «Нарисовал 2 компонента на фронтенде» → Не работает без данных
• «Написал тесты с покрытием 90%» → Не решает задачу пользователя
• «Оптимизировал запросы, ускорил на 20%» → Невидимо без контекста

✅ Ценность:

Законченная фича, которая включает:

• Backend API — данные и логика работают
• Frontend UX/UI — пользователь видит и взаимодействует
• Use-case тесты — сценарии использования подтверждены
• Документация — понятно, как использовать

Пример:

VEP: «Входящие лиды с Tilda»

✅ Ценность: Менеджер видит заявку с Tilda в интерфейсе CRM, может сменить статус и добавить комментарий.

❌ Не ценность: «API для приёма вебхуков готов» (но в интерфейсе пусто)

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

VEP считается завершённым (Done), только когда:

1. Backend → API endpoint работает, данные сохраняются в БД
2. Frontend → Пользователь видит результат, может взаимодействовать
3. Use-case → Реальный сценарий использования работает от начала до конца
4. Feedback → Ты (или пользователь) попробовал и подтвердил: «Это работает и удобно»

Правило: Лучше сделать 1 законченную фичу за неделю, чем 5 API ручек и 3 компонента, которые не работают вместе.

12 принципов

1. User First — потребность пользователя важнее бизнес-задач.
2. Vision First — видение цели и приоритетов до начала работ.
3. Simplicity First — простота и минимализм важнее сложных решений.
4. Design First — проектируем интерфейс (UX/UI) до кода. Код без дизайна — технический долг с первого дня.
5. Security First — безопасность важнее скорости публикации.
6. Mockups First — обезличенные данные и прототипы до реальной базы.
7. Use-case First — пишем функционал под сценарии использования, а не под тесты.
8. Consistency First — чистый код и порядок важнее слияния.
9. Documentation First — описание изменений важнее выпуска.
10. Process First — завершаем начатый цикл, прежде чем брать новое.
11. Log First — логируем события для понимания системы.
12. Feedback First — обратная связь (опыт использования) важнее финальной реализации.

Процесс (Workflow)

Мы работаем в GitVerse через Задачи, где: Один VEP = Одна задача.

Доска задач состоит из 4 колонок. Каждый VEP проходит через них слева направо.

Открыто

• Здесь рождаются идеи. Создаём задачу с префиксом [VEP-XXX].
• В описании кратко: Зачем? и Что делаем?.
• Голосование: Ставим лайки 👍 задачам, которые реально нужны сейчас. Чем больше лайков — тем выше приоритет.

Запланировано

• Сюда перемещаются задачи с наибольшим количеством лайков.
• Это очередь на разработку. Формируется естественным путём: комьюнити/ты сам голосует → задача поднимается вверх.
• Никаких спринтов и оценок времени. Просто «следующее в списке».

В работе

• Берём задачу из Запланировано и перетаскиваем сюда.
• Жёсткое правило: WIP = 1. Только одна активная задача. Пока не закроем текущую — новую не трогаем.
• В процессе опираемся на 12 принципов (дизайн → код → логи → безопасность → документация).

Готово

• Код написан, залит в основную ветку, CHANGELOG обновлён.
• Задача закрывается.
• Обратная связь без отдельного этапа: Мы просто продолжаем пользоваться продуктом. Если что-то ломается, неудобно использовать или хочется улучшить — создаём новую задачу в Открыто. Баг или идея автоматически попадают в общий поток и сортируются лайками.

Метки (Labels)

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

• FEAT — Новая функция с нуля
• UPG — Улучшение существующего (UX, код, удобство)
• FIX — Исправление ошибки
• SEC — Безопасность и права доступа
• PERF — Оптимизация производительности
• DOCS — Документация и инструкции

Обратная связь по проекту

Мы не выделяем “тестирование” в отдельный этап. Если после релиза что-то сломалось или неудобно в работе, то это просто новый VEP.

• Баг? Создаём Issue с меткой FIX ….
• Идея по улучшению? Создаём Issue c меткой UPG ….

Всё это попадает в бэклог и сортируется лайками.

Шаблон задачи (для GitVerse Issues)

# VEP-XXX: [Краткое название]

Краткое описание VEP 1-3 предложения

## Контекст (Зачем?)

**Проблема:** [Какую боль решаем?]  
**Пользователь:** [Кто выиграет от этого?]  
**Без этого:** [Что будет, если не сделать?]

## Решение (Что делаем?)

**Описание:** [Кратко, что меняем/добавляем]  
**Макеты/Схемы:** [Ссылки на Figma/Excalidraw, если есть]

## Компоненты ценности

VEP считается готовым, только когда **все** компоненты выполнены:

### Backend

- [ ] API endpoint(s) работают
- [ ] База данных (миграции, индексы)
- [ ] Валидация и обработка ошибок
- [ ] Логирование ключевых событий
- [ ] Security (RLS, аутентификация, rate-limit)

### Frontend

- [ ] UI компоненты реализованы
- [ ] UX сценарий продуман (ошибки, загрузка, пустые состояния)
- [ ] Адаптивность (мобильные/планшет)
- [ ] Доступность (a11y, если применимо)

### Use-case

- [ ] Сценарий «от начала до конца» работает
- [ ] Тесты на ключевые сценарии (ручные или автотесты)
- [ ] Mockup-данные заменены на реальные

### Документация

- [ ] CHANGELOG обновлён
- [ ] VEP-документ в `docs/veps/` заполнен
- [ ] Инструкции для пользователя (если нужно)

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

[Опиши конкретный сценарий: «Менеджер может создать лид из Tilda, увидеть его в списке, сменить статус на „В работе“ и добавить комментарий»]

**Проверка:**

- [ ] Я лично попробовал этот сценарий
- [ ] Всё работает без ошибок
- [ ] Это удобно и не раздражает

## Метрики успеха (опционально)

[Как поймём, что ценность доставлена? Например: «Время создания лида сократилось с 2 мин до 30 сек»]

## Оценка усилий (грубо)

[1 час | 0.5 дня | 1 день | 3 дня | Неделя+]

Структура репозитория

📂 your-project/           # Каталог проекта
├── 📂 docs/
│    └── 📂 veps/
│        ├── 📄 VEP.md      # Видение проекта
│        ├── 📄 VEP-001.md  # Первая ценность
│        ├── 📄 VEP-002.md  # Вторая ценность
│        └── 📄 README.md   # Методология (как работать с VEP)
├── 📄 CHANGELOG.md        # История версий 1 изменение = 1 VEP
…

Вклад

Методология открыта к улучшению. Предлагай правки через Issues с меткой UPG. Code of Conduct — как мы общаемся.

Лицензия

Этот проект распространяется под лицензией MIT.