Разработка ПО с нуля под ключ: от идеи до релиза
Заказ разработки с нуля — это всегда риск: заказчик платит за то, чего ещё нет, и не может заранее потрогать результат. Хороший процесс превращает этот риск в управляемый. Ниже — как я веду разработку программного обеспечения под ключ: от первой беседы об идее до релиза и поддержки. Кто я и с чем работаю, написано в статье Кто такой craftzman: от судебного эксперта до архитектора.
Что значит «под ключ»
«Под ключ» — это когда вам не нужно самим собирать команду из аналитика, архитектора, backend- и frontend-разработчиков, тестировщика и девопса и координировать их. Я беру ответственность за результат целиком: от понимания задачи до работающей системы на ваших серверах или в вашей инфраструктуре. Такой подход я применяю и в своих продуктах: «Русло», Keel, Drafta.
Этапы разработки
| Этап | Результат для заказчика |
|---|---|
| 1. Идея и цели | Понятная формулировка: что система делает и зачем она бизнесу |
| 2. Требования | Документ, где описано, что входит в систему, а что нет |
| 3. Архитектура | Схема системы, выбранный стек, обоснование решений |
| 4. Планирование | Декомпозиция, этапы, сроки, порядок поставки |
| 5. Разработка | Работающие части системы, которые можно смотреть по ходу |
| 6. Тестирование | Подтверждение, что система работает и выдерживает нагрузку |
| 7. Релиз | Развёрнутая система, инструкции, передача знаний |
| 8. Поддержка | Исправления, развитие, обновления |
1. Идея и цели
Начинаю с вопросов, а не с технологий. Какую проблему вы решаете? Кто будет пользоваться? Как поймём, что получилось? Хорошая формулировка цели экономит месяцы: чаще всего дорого обходится не разработка, а разработка не того.
2. Требования
Требования делю на функциональные («что делает система») и нефункциональные («как хорошо она это делает»): нагрузка, доступность, безопасность, сроки хранения данных, среда развёртывания. Нефункциональные требования заказчики забывают чаще всего, а исправлять систему под них позже приходится дороже всего. На этом этапе проявляется и опыт эксперта: я привык читать договоры и ТЗ и находить в них противоречия до начала работ.
3. Архитектура
Это самый важный этап, и он идёт до написания основного кода. Я выбираю подход, границы модулей, хранилища данных и способ развёртывания, а затем записываю решения вместе с причинами. Подробный разбор: Архитектура ПО: проектирование и планирование до первой строки кода.
4. Планирование
Разбиваю систему на небольшие части, которые можно сделать и проверить за несколько дней. Сначала делается то, что снимает самый большой риск или приносит заказчику первую пользу. Вы получаете план с этапами, а не обещание «всё будет в конце».
5. Разработка
Работа идёт короткими итерациями. Каждая заканчивается рабочей частью системы, которую можно посмотреть, а не отчётом о проделанном. В процессе действуют правила, о которых я подробно рассказываю в статьях Качество кода: что оно значит для бизнеса и как его обеспечить и Безопасная разработка ПО: как защита закладывается с первого дня: код-ревью, единый стиль, автоматические проверки, безопасность по умолчанию.
6. Тестирование и приёмка
Проверка начинается не в конце, а с первого дня: автоматические тесты, интеграционные проверки, нагрузочное тестирование. Перед релизом проходит приёмка по заранее согласованным критериям. Подробнее: Тестирование и приёмка ПО: как убедиться, что система работает до релиза.
7. Релиз и передача
Систему нужно уметь развернуть, обновить и откатить. Я оставляю конфигурацию развёртывания (docker-compose, nginx, CI), техническую документацию и инструкции. Вы не привязаны ко мне: другой инженер сможет взять проект.
8. Поддержка и развитие
После релиза появляются реальные пользователи, и с ними — новые идеи. Систему, у которой чистая архитектура и тесты, можно развивать без страха сломать существующее.
Чем разработка с нуля отличается от доработки
С нуля легче заложить правильные основы: структуру, безопасность, тесты. Но есть и риск — соблазн сразу сделать «всё». Я придерживаюсь принципа минимального жизнеспособного продукта: сначала ядро, которое решает главную задачу, затем расширения по реальной обратной связи. При доработке существующей системы начинаю с аудита: читаю код, смотрю архитектуру, нахожу узкие места и риски, и только затем планирую изменения. Опыт рефакторинга у меня большой, например, в проекте FlameApp я разделил монолит на микросервисы.
Стек технологий
Выбираю стек под задачу, а не под моду:
- Rust — системы с высокими требованиями к надёжности, производительности и безопасности: промышленные платформы, серверная часть с жёсткими правилами доступа;
- Go, Java (Spring Boot) — корпоративные сервисы и интеграции;
- Node.js / Nest.js — быстрые API и микросервисы;
- Vue 3 и TypeScript, Astro — интерфейсы и сайты;
- Postgres, ClickHouse — реляционные данные и временные ряды;
- Swift — нативные приложения для macOS.
Частые вопросы
Сколько стоит и сколько времени занимает разработка? Это зависит от объёма. Я не называю цифры по описанию «в двух словах»: после этапов идеи, требований и архитектуры вы получаете план с оценкой по этапам.
Что я получаю в конце? Работающую систему, исходный код, документацию, конфигурацию развёртывания и описание архитектурных решений.
А если требования изменятся? Это нормально. Поэтому работа идёт итерациями, а архитектура проектируется с запасом на изменения.
Кому принадлежит код? Условия определяются договором. Я заранее обсуждаю права на исходный код и лицензии.
Можно ли работать из закрытой сети? Да. У меня есть опыт систем, которые полностью работают внутри закрытого контура: «Русло»: как строится IIoT-платформа для закрытой сети предприятия.
Начнём с разговора
Если у вас есть идея продукта или внутренняя система, которую пора построить, напишите мне в Telegram: @w1shmaster. Опишите задачу в нескольких предложениях, и я скажу, с чего лучше начать и чего можно избежать.