Перейти к содержанию

Подход

Не начинаем с фреймворка. Начинаем с того, что должно измениться

Технология — часть решения, а не само решение. Сначала разбираемся в пользователях, данных, ограничениях и цене ошибки.

01ЗАДАЧА
02ОГРАНИЧЕНИЯ
03РЕШЕНИЕ
04ПРОВЕРКА
05ЗАПУСК

Принципы

Уменьшаем неопределённость до дорогой разработки

01

Уменьшаем неопределённость

Сначала проверяем спорные места, данные и технические ограничения.

Практика

Прототип · проверка интеграций · ограничения

РЕЗУЛЬТАТ

Риски понятны до основной разработки

02

Показываем рабочее

Двигаемся короткими итерациями и регулярно демонстрируем продукт в состоянии, которое можно проверить.

Практика

Рабочая демонстрация · превью версии

РЕЗУЛЬТАТ

Направление можно проверить заранее

03

Проектируем ошибки

Учитываем пустые состояния, ограничения API, потерю соединения, повторные действия и восстановление.

Практика

Обработка ошибок · восстановление · откаты

РЕЗУЛЬТАТ

Система предсказуемо ведёт себя при сбоях

04

Оставляем понятную основу

Структурируем код и контент так, чтобы следующий этап не требовал полной переделки.

Практика

Архитектура · документация · рефакторинг

РЕЗУЛЬТАТ

Следующий этап не требует полной переделки

Риски

До основной разработки проверяем критичные неизвестные: интеграции, данные, ограничения среды, доступы и спорные сценарии.

Коммуникация

Без технического тумана

Фиксируем решения, показываем прогресс и заранее поднимаем вопросы, влияющие на сроки или объём.

Фиксируем

  • · принятые решения
  • · ограничения
  • · изменения объёма
  • · открытые вопросы

После запуска

Выпуск — это начало реального использования

ЗАПУСКНАБЛЮДЕНИЕИСПРАВЛЕНИЯУЛУЧШЕНИЯСЛЕДУЮЩАЯ ВЕРСИЯ

Реальное использование раскрывает новое. Приоритеты пересматриваются, изменения планируются, поддержка может продолжаться по согласованному формату.

Формат сопровождения, приоритеты и сроки реакции согласовываются отдельно.

Как устроены этапы

Контролируемый процесс от задачи до передачи

  1. 01

    Разобраться

    Понимаем задачу, пользователей, ограничения и существующий процесс.

    Исследование · требования · риски

    Результат

    Контекст / требования / ограничения

    Проверка / приёмка

    Согласован объём следующего этапа

  2. 02

    Спроектировать

    Собираем структуру, прототип и технический контур.

    Сценарии · UX/UI · архитектура

    Результат

    Прототип / архитектура / план

    Проверка / приёмка

    Понятно, что именно будет реализовано

  3. 03

    Собрать

    Делаем интерфейс и логику короткими итерациями.

    Frontend · backend · API

    Результат

    Рабочая версия

    Проверка / приёмка

    Функциональность можно проверить

  4. 04

    Запустить и развивать

    Проверяем, выпускаем и поддерживаем после запуска.

    Тесты · релиз · поддержка

    Результат

    Production / документация / передача

    Проверка / приёмка

    Результат передан и готов к эксплуатации

Контрольные точки

СогласованиеРабочая версияПроверкаПередача
Изменения по ходу проекта

Если объём меняется — определяем влияние, пересматриваем приоритеты, обсуждаем сроки и стоимость, фиксируем решение.

Качество

Для веб-интерфейсов учитываем семантическую структуру, клавиатурную навигацию, контраст, состояния ошибок, адаптивность и производительность. Где применимо — ориентир WCAG 2.2 AA.

Безопасность и доступы

На этапе проектирования фиксируем требования к аутентификации, ролям и правам, интеграциям, хранению данных, журналированию и среде размещения.

Передача

Состав передаваемых материалов

исходный кодрепозиторийдоступыинструкцииописание интеграцийтехническая документацияdeployment / handover notes

Состав передаваемых материалов фиксируется в рамках проекта.

Частые вопросы

Процесс, объём и передача

Да. Часто это лучший способ проверить сценарий и снизить риск. Мы поможем отделить обязательное от того, что можно добавить позже.