Проектирование и разработка ПО в здоровом проекте — не два враждебных лагеря. Проектирование отвечает на вопросы «какие сущности, какие правила, какие границы». Разработка делает их исполняемыми. Если пропустить первый шаг, команда кодирует догадки: статусы плодятся в коде, отчёты не сходятся, интеграция с 1С переписывается третий раз. Если застрять только в схемах, вы получите красивый альбом без работающего сценария.
Ниже — какой объём проектирования достаточен для коммерческого продукта, какие артефакты смотреть заказчику и как не превратить архитектуру в самоцель.
Что проектировать обязательно
- Цели v1 и явные исключения.
- Роли и права на данные, не только меню.
- Сущности и статусы: что может перейти во что, кто имеет право.
- Интеграции: направление, хозяин данных, поведение при отказе внешней системы.
- Нефункциональное: объём пользователей, окна простоя, хранение логов, бэкапы.
- Критерии приёмки сквозного сценария.
Этого хватает, чтобы разработка не гадала. Остальное — детали интерфейса и уточнения в спринтах. Как упаковать в документ для закупки — как составить ТЗ. Для контуров учёта — ПО систем управления.
Артефакты, которые можно принять, а не «полюбоваться»
Карта сценариев. Модель данных хотя бы на уровне списка полей must. Черновик API: ресурсы и ошибки. Схема сред: dev / stage / prod. Список рисков: нет тестового контура банка, грязный Excel, один человек знает пароль от 1С. Прототип главного пути — тоже проектирование, только проверяемое руками.
Не обязательны: пятьдесят диаграмм ради диаграмм, выбор стека как религия, микросервисы «на вырост» для двадцати пользователей. Архитектура должна объяснять, как вы будете менять правила через полгода, а не как красиво размазать репозитории.
Тест качества проекта: новый разработчик за день понимает, где создаётся заказ и где живёт право на отмену. Если это только в голове автора — проектирования не было.
Как переходить от проекта к спринтам
Зафиксируйте must-have срез и начните вертикальный кусок: от кнопки до записи в базе и обратно. Не пилите полгода «слой доступа к данным» без экрана. Каждую неделю сверяйте модель со реальностью заказчика: всплывут исключения. Исключения либо входят в scope с пересмотром срока, либо сознательно откладываются.
Безопасность закладывайте в проект, не в заплатки: безопасная разработка ПО. Сопровождение планируйте сразу: разработка и сопровождение. Если будет клиент в сторе — не забудьте контракт для старых версий приложения.
Ошибки проектирования
Копировать чужую ER-диаграмму. Проектировать от отчёта директора, а не от работы исполнителя — тогда данные никто не вносит. Забывать пустые и ошибочные состояния. Выбирать стек «как в статье» без команды сопровождения. ИИ-генерация схемы без вычитки домена: выглядит стройно и не совпадает с процессом. Про ИИ в коде — ИИ для написания кода.
Когда проектирование избыточно
Избыточно на лендинге с формой. Избыточно, если вы сознательно делаете однодневный прототип выкидываемого типа. Избыточно как способ откладывать решение собственника: «ещё чуть уточним модель» месяцами без пилота. Тогда честнее time & materials на исследование с датой stop.
Следующий шаг
Соберите шесть пунктов обязательного проекта на нескольких страницах. Покажите сквозной сценарий. Только потом оценивайте разработку целиком. Услуга работ — разработка ПО, клиенты — приложения.
Обсудить рамку — Grevin, контакты, +7 993 302-62-55.
Модель данных как язык компании
Пока «заказ», «заявка» и «сделка» означают три разных объекта в головах и один в коде, проектирование не закончено. Согласуйте словарь. Напишите, что создаётся когда, что можно отменить, что попадает в отчёт. Этот словарь дешевле любой диаграммы. Его можно положить в онбординг новых сотрудников и в промпты ИИ, чтобы агент не выдумывал четвёртую сущность.
Справочники: статусы, причины отказа, типы объектов — версионируйте. Удаление статуса, который есть в истории, ломает отчёты. Правило: закрываем для новых, историю не переписываем без миграции. Это скучная архитектура, которая спасает сверки через год.
Интеграционный контур на бумаге до ключей
Для каждой внешней системы: кто инициирует обмен, частота, идемпотентность, что делать при дубле, кто чинит, когда внешняя сторона лежит, есть ли песочница. Если песочницы нет, риск и срок растут — это часть проекта, не сюрприз разработки. Нарисуйте последовательность «создали у нас → отправили → получили id → сохранили». Без стрелки «получили id» вы будете плодить дубли.
Очереди и повторы проектируйте сразу для оплат и отгрузок. Синхронный вызов «ждём 1С 40 секунд на кнопке» не переживает рабочий день склада. Это решение архитектуры, его видно на схеме, его можно принять до кода.
Эволюция: как менять систему, не переписывая всё
Хороший проект оставляет швы: модуль уведомлений, модуль прав, модуль обмена. Плохой проект — бог-объект «всё в одном сервисе с комментарием потом разнесём». Вам не обязательно микросервисы. Вам нужны границы, чтобы команду и спринты можно было делить. Зафиксируйте, что менять дорого (деньги, права), а что можно итерировать часто (тексты, фильтры списков).
Версии API для клиентов — часть проектирования, если будет приложение. Без этого «ускоренная разработка ядра» ломает стор. См. ПО и приложения. Сопровождение изменений — сопровождение.
Проектирование для приёмки и аудита
Каждый критичный сценарий должен быть воспроизводим на стенде с тестовыми ролями. Проектируйте фикстуры: тестовый клиент, тестовый заказ, тестовый отказ оплаты. Без этого приёмка — театр на проде. Для аудита клиента-корпорации заранее решите, какие журналы храните и сколько. Это дешевле, чем экстренно пилить логи перед проверкой.
Безопасность в проекте — список мер, привязанный к данным: безопасная разработка. Услуга реализации — разработка ПО. Заявка на рамку — контакты.
Нагрузка, деградация и честные ограничения
Проектирование без цифр нагрузки врёт. Напишите порядок: сколько пользователей одновременно, сколько документов в день, пики утра понедельника. Для двадцати человек в офисе не нужна шина «как у ритейлера». Для сети точек — нужны очереди и наблюдаемость. Честно зафиксируйте, что система не обещает в v1. Это защищает и акт, и нервы, когда маркетинг внезапно приводит в десять раз больше заявок.
Деградация: что видит пользователь, если отчёт строится долго, если 1С лежит, если очередь пушей забита. Заглушки и повторы — часть проекта, не «придумаем в проде». Для приложений деградация ещё и офлайн: ПО и приложения.
Проектирование ролей вместе с оргструктурой
Роли в софте, которых нет в жизни, не заполняются. Ролей в жизни, которых нет в софте, порождают общие учётки. Сверьте оргсхему и матрицу доступа. Замещение, совместительство, внешние подрядчики с ограниченным входом — отдельные случаи. Их пропускают, а потом дают VPN «как всем». Это дыра. Закладывайте в проект.
Для холдингов заранее решите мультитенантность: одна база с меткой юрлица или раздельные контуры. Переделка позже — почти новая разработка. Лучше назвать развилку на проектировании. Системы управления — отдельный разбор.
От проекта к коду без потери смысла
Каждую сущность в модели свяжите с экраном или API, где она рождается. Сущность без места рождения — мёртвая схема. Каждое правило — с тестом или сценарием приёмки. Правило «только в комментарии архитектора» умрёт в отпуске. Разработка начинается, когда вертикальный срез проходит по живому стенду, а не когда презентация согласована всеми вице-президентами.
ИИ может набросать схему, человек обязан сверить со словарём компании. Иначе вы спроектируете чужой бизнес. См. ИИ для кода. Реализация как услуга — услуги разработки ПО, страница работ — разработка ПО, клиенты — приложения. Контакты — форма и телефон.
Минимальный пакет проектирования, после которого можно кодить
Словарь сущностей. Статусы и переходы. Матрица прав. Список интеграций со стрелками и хозяином. Критерии приёмки главного сценария. Ограничения нагрузки v1. Чек-лист безопасности минимума. Черновик сред. Если пакет собран, разработка не гадает. Если не собран, любой спринт — исследование под видом фич. Не раздувайте пакет до тома, который не читают. Раздувайте до ясности споров: что можно отменить, кто видит сумму, что делать, когда 1С молчит.
Дальше итерируйте экраны и отчёты. Не итерируйте смысл заказа каждую неделю без пересмотра срока. Это и есть стык проектирования и разработки: проект даёт язык, разработка даёт работающий срез. Услуги: ПО, приложения. Обсудить рамку: контакты Grevin.
Проектирование отчётов в конце, не в начале
Директор хочет дашборд в первый день. Данные для дашборда рождаются из дисциплинированного ввода. Если начать с отчёта, поля начнут заводить «чтобы график красивый», а не потому что процесс так идёт. Спроектируйте ввод и статусы, затем отчёт как проекцию. Исключение — регуляторный отчёт, без которого нельзя работать: его критерии входят в v1 явно. Остальное подождёт пилота. Так проектирование служит управлению, а не презентации.
Каждый отчёт имеет владельца и определение метрики. «Средний чек» без определения убивает доверие. Запишите формулу. Это часть модели данных, не «настроим в BI потом». Связка с системами управления — ПО систем управления. Реализация — услуги разработки.
Проект, который можно положить в git
Держите словарь, матрицу прав и контракт API в репозитории рядом с кодом, с версией. Тогда проектирование не умрёт в PDF на диске директора. Разработчик и агент ИИ читают один источник. Расхождение схемы и кода видно в диффе. Это самый практичный стык проектирования и разработки в 2026 году: документы как артефакты поставки, не как приложение к договору, которое никто не открывает.
Обновляйте их тем же процессом, что код: ревью, не «поправим в чате». Иначе через полгода снова археология. На этом пакете можно честно стартовать реализацию и не путать исследование с фичами. Услуги: ПО, приложения. Вопросы — контакты. Если словаря нет в git к первому спринту, вы всё ещё в исследовании — назовите его своим именем и отдельной сметой, не прячьте в «разработку».
Критерий остановки проектирования
Останавливайтесь, когда главный сценарий воспроизводим на прототипе и споры о статусах записаны, а не когда закончились маркеры на доске. Если спор «что такое заказ» не закрыт, рано кодить ядро. Если закрыт — дальше дешевле проверять кодом и стендом, чем ещё одной презентацией. Этот стоп-кран бережёт месяцы.
Критерий остановки проектирования — закрытый словарь и воспроизводимый главный сценарий. Назначьте дату стопа в календаре проекта. После стопа новые споры о смысле сущности идут как изменение scope, а не как «ещё чуть схема». Так проектирование заканчивается, а разработка начинается без бесконечного уточнения. Дальше — реализация по услуге разработки ПО и, если нужен клиент, приложений.
Частые вопросы
Нужен ли полный технический проект по ГОСТ?
Редко для коммерческого v1. Нужна достаточная модель: сущности, статусы, права, интеграции, критерии приёмки. ГОСТ уместен, если его требует закупка или регулятор. Иначе вы платите за том, который никто не откроет в спринте.
Кто проектирует: аналитик, архитектор, разработчик?
На маленьком контуре — один сильный человек с ревью. На интеграциях и нагрузке — явно выделяют роли. Главное, чтобы результат принадлежал заказчику как документ, а не «в голове подрядчика».
Можно ли проектировать параллельно с кодом?
Главный путь — сначала хотя бы черновик модели. Детали экранов — параллельно. Если кодировать статусы, которых ещё нет в процессе, переписывать придётся целиком.
Как проектирование стыкуется с приложением?
Клиент потребляет контракт. Сначала ядро и API, затем экраны. См. ПО и приложения и процесс разработки приложений.
Сколько длится проектирование?
От нескольких дней на узкий пилот до нескольких недель на контур с миграцией и 1С. Если проектирование длится месяцами без прототипа — вы застряли в документах.