Этапы разработки ПО: полный цикл от идеи до поддержки
Разработку программного обеспечения заказывают ради результата, а платят за процесс: за сроки, приёмку, документы и поддержку после запуска. Когда этапы названы и у каждого есть измеримый результат, спор «сделано или нет» решается за один проход по списку, а не перепиской на две недели. Дальше — восемь этапов полного цикла: что происходит внутри, что остаётся у заказчика на выходе, сколько это занимает и где чаще всего теряют время и деньги.
Что такое цикл разработки ПО и почему этапы у всех одинаковые
Ситуация, знакомая многим заказчикам: работы идут третий месяц, отчёты приходят исправно, а что именно готово — понять невозможно. Причина обычно не в подрядчике, а в том, что этапы не названы и ни у одного из них нет предмета, который можно открыть, прочитать или запустить.
Жизненный цикл ПО — это последовательность стадий от первой формулировки задачи до вывода системы из эксплуатации. Набор стадий описан международным стандартом ISO/IEC/IEEE 12207, у которого есть российский аналог — ГОСТ Р. Стандарт не говорит, сколько недель длится проект: он фиксирует, какие процессы нельзя пропустить и какие документы остаются на выходе.
Порядок этапов одинаков для мобильного приложения, сайта, корпоративной системы и обмена данными между складом и учётной системой. Меняется не последовательность, а объём работ внутри каждого этапа и состав участников со стороны бизнеса.
| Класс ПО | Что тяжелее всего в цикле | Кто нужен со стороны бизнеса |
|---|---|---|
| Мобильное приложение для покупателей | Публикация и обновления: новую версию устанавливает пользователь, поэтому старые версии живут месяцами | Электронная коммерция, маркетинг, владелец программы лояльности |
| Сайт интернет-магазина | Контент и поисковая структура: адреса и разделы дешевле задать до публикации | Контент-менеджер, специалист по продвижению, категорийный менеджер |
| Корпоративная система, личный кабинет, B2B-платформа | Требования: роли, права и учётные правила отличаются в каждой компании | Руководители подразделений-пользователей, служба безопасности, ИТ-служба |
| Интеграции и серверная часть | Договор об обмене данными и состояние систем, к которым подключаются | ИТ-служба, ответственный за учётную систему, поставщики смежных сервисов |
Дальше — восемь этапов полного цикла: что происходит внутри, что остаётся у заказчика на выходе и где чаще всего теряют время и деньги. Отдельно разберём модели цикла, параллельные потоки работ, порядок расчёта сметы и состав документов.
Восемь этапов: карта цикла на одной таблице
Перед разбором — общая карта. Доли бюджета приведены для продукта, который делают с нуля: на готовой платформе распределение другое, к этому вернёмся в разделе о смете.
| Этап | Результат — что можно взять в руки | Доля бюджета разработки с нуля |
|---|---|---|
| 1. Идея, цели и ограничения | Описание задачи с измеримой целью и бюджетной рамкой | до 5% |
| 2. Требования и техническое задание | Подписанное техническое задание и состав первой версии | 5–10% |
| 3. Проектирование: архитектура и интерфейсы | Схема системы, описание методов обмена, макеты и дизайн-система | 15–20% |
| 4. Разработка | Сборки на тестовом окружении и исходный код в репозитории | 35–45% |
| 5. Тестирование и приёмка | Отчёт о проверке, закрытые замечания, подписанный акт | 10–15% |
| 6. Запуск и ввод в эксплуатацию | Продукт на боевом окружении или в магазинах приложений, переданные доступы | 5–10% |
| 7. Поддержка после запуска | Регламент обращений, мониторинг, обновления безопасности | ежегодно, отдельно от разработки |
| 8. Развитие и вывод из эксплуатации | План развития, выпуски с новым функционалом, порядок переноса данных | по объёму работ |
Первые шесть этапов — это проект с датой окончания. Седьмой и восьмой продолжаются, пока продуктом пользуются, и планируются отдельной строкой бюджета. Именно эту строку чаще всего забывают заложить на старте.
Этап 1. Идея, цели и ограничения
Этап начинается не с функций, а с вопроса, какое число в бизнесе должно измениться. «Хотим приложение» — не цель. «Хотим перевести повторные покупки в собственный канал, потому что комиссия площадок съедает маржу» — цель, из которой понятно, что считать результатом.
Одновременно фиксируются ограничения: бюджетная рамка, дата, к которой продукт нужен, требования безопасности, учётные системы, с которыми придётся обмениваться данными. Ограничения отсекают половину вариантов решения ещё до сметы, поэтому их формулируют раньше пожеланий.
Здесь же выбирается способ реализации: разработка с нуля, готовая платформа с настройкой под бренд или подписка на типовой сервис. Разбор трёх вариантов — в статье о сравнении моделей разработки, а проверка гипотезы минимальной версией — в материале об MVP.
Результат этапа
Описание задачи с измеримой целью, ограничениями и бюджетной рамкой. Одна-две страницы, а не презентация на сорок слайдов.
Типичная ошибка. Начать с перечня функций, подсмотренных у конкурента. Список чужих экранов легко превращается в смету, но не отвечает на вопрос, за счёт чего вырастет выручка, — и на приёмке нечем измерить результат.
Этап 2. Требования и техническое задание
На этом этапе задача переводится на язык, одинаково понятный бизнесу и разработчикам. Аналитик проводит интервью с будущими пользователями и владельцами процессов, разбирает, как работа устроена сейчас, и описывает сценарии: что делает покупатель, что видит оператор, что происходит с заказом в учётной системе.
Результат — техническое задание. Это одновременно рабочий документ для команды, основание для сметы и приложение к договору, по которому принимают работу. В нём фиксируются состав первой версии, роли и права, список интеграций, требования к нагрузке и защите данных, а также то, что в первую версию сознательно не входит.
Отдельная строка — граница ответственности. Кто даёт доступы к учётной системе, кто готовит тексты и фотографии, кто оформляет учётную запись разработчика в магазинах приложений, кто оплачивает сертификаты и подписки. Половина сдвигов срока живёт именно здесь, а не в коде — подробнее в чек-листе по бюджету и срокам.
Результат этапа
Подписанное техническое задание с составом первой версии, списком интеграций и разграничением ответственности сторон. Разработка технического задания — отдельная услуга с фиксированной ценой, и её результат можно передать любому подрядчику.
Типичная ошибка. Пропустить этап ради экономии двух недель. Без описания сценариев смета считается диапазоном, а каждое уточнение по ходу разработки оплачивается как доработка.
Этап 3. Проектирование: архитектура и интерфейсы
Проектирование идёт двумя параллельными потоками. Технический поток отвечает на вопрос, из чего собрана система: какие в ней части, где хранятся данные, как части общаются между собой и с внешними системами. Здесь же описывается договор об обмене данными — состав методов, формат ответов и порядок изменений, чтобы обновление сервера не ломало установленные у покупателей приложения. Подробный разбор — в статье о проектировании REST API.
Продуктовый поток отвечает за то, что видит пользователь: структура экранов, схемы расположения блоков, макеты и дизайн-система из готовых элементов — кнопок, карточек, форм. Дизайн-система нужна, чтобы через год новые экраны собирались из существующих компонентов, а не рисовались заново. Роль черновых схем разобрана в материале о вайрфреймах, работа над интерфейсом — в статье о дизайне приложения.
На этом же этапе принимаются решения, которые дороже всего менять потом: язык и платформа разработки, схема хранения данных, размещение на серверах компании или в облаке, требования к защите персональных данных. Проверить действующий продукт перед переделкой помогают аудит кода и аудит UX/UI.
Результат этапа
Схема системы, описание методов обмена данными, макеты экранов и дизайн-система. С этими документами смета перестаёт быть диапазоном и превращается в план работ по неделям.
Типичная ошибка. Согласовывать макеты по одному человеку за раз. Каждый следующий согласующий приносит свои правки, и вторая итерация становится пятой. Соберите замечания от всех участников одним списком и передайте одним пакетом.
Этап 4. Разработка
Самый длинный и самый дорогой этап. Работа идёт короткими отрезками по одной-две недели: в конце каждого появляется сборка, которую можно открыть и посмотреть. Такой ритм важнее любой отчётности — по работающей сборке видно фактическое состояние проекта, а не проценты в письме.
Одновременно ведутся три направления: серверная часть с базой данных и методами обмена, клиентские экраны и интеграции с внешними системами. Интеграции обычно и определяют срок: доступ к учётной системе, тестовые данные и согласование форматов зависят не от подрядчика, а от готовности сторон.
Три вещи, которые стоит потребовать с первого дня и которые ничего не стоят, если договориться заранее: исходный код в репозитории, доступ к которому есть у компании; отдельное тестовое окружение, где проверки идут без реальных заказов и списаний; автоматическая сборка и выкладка, чтобы выпуск новой версии не зависел от конкретного человека с настроенным ноутбуком.
Результат этапа
Работающие сборки на тестовом окружении и исходный код в репозитории заказчика. Сюда же относится техническая документация — описание установки и процессов, которое передаётся вместе с кодом.
Типичная ошибка. Отложить контент и данные «на потом». Каталог, тексты, фотографии и справочники нужны в середине этапа, а не перед запуском: экраны, свёрстанные по заглушкам, приходится переделывать под фактический объём данных.
Этап 5. Тестирование и приёмка
Тестирование — не финальная неделя перед запуском, а работа, которая идёт параллельно с разработкой. Инженер по тестированию проверяет каждую готовую часть, а не весь продукт целиком в последний момент: ошибка, найденная в неделю разработки, исправляется за часы, а найденная после релиза — уже с выпуском обновления и ожиданием проверки в магазинах приложений.
В полный набор проверок входят функциональные сценарии, поведение на разных устройствах и версиях систем, скорость и поведение под нагрузкой, безопасность и корректность обмена с внешними системами. Отдельно проверяются денежные операции: оплата, списание бонусов, повторная отправка заказа при плохой связи. Состав работ описан на странице тестирования и QA, а практика проверок — в статьях о тестировании мобильных приложений и о тестировании фронтенда.
Приёмка — отдельная процедура, а не финальный созвон. Заказчик проходит сценарии из технического задания на тестовом окружении и фиксирует замечания списком. Полезно заранее договориться, что считается ошибкой, а что — новым пожеланием: первое исправляется по договору, второе оценивается как доработка.
Результат этапа
Отчёт о проверке, закрытые замечания и подписанный акт приёмки — основание для оплаты этапа и точка отсчёта гарантийного срока.
Типичная ошибка. Принимать работу без сценариев. Когда приёмка идёт «на глаз», замечания приходят месяцами и каждое обсуждается заново. Список сценариев из технического задания превращает приёмку в один проход по пунктам.
Этап 6. Запуск и ввод в эксплуатацию
Запуск — это набор действий, у каждого из которых свой срок. Для корпоративной системы: перенос на боевое окружение, настройка защищённого соединения и резервного копирования, миграция данных из старой системы, обучение сотрудников. Для приложения: сборка выпуска, оформление карточек, скриншотов и описаний, публикация и проверка со стороны магазинов приложений.
Проверку в сторах планируют отдельно, потому что она не зависит от подрядчика: правила публикации описаны в руководстве App Review у Apple, в правилах Google Play и в документации RuStore. Что делать при отклонении, разобрано в статье о блокировках в сторах, а порядок публикации — в материале о публикации в RuStore.
К запуску относится и передача прав доступа. Учётные записи разработчика, домен, серверы, почта, панели управления и аналитика оформляются на компанию, а не на подрядчика или конкретного сотрудника. Это тот случай, когда неудобство всплывает через несколько лет и в неподходящий момент.
Результат этапа
Продукт работает на боевом окружении или опубликован в магазинах приложений, доступы переданы, аналитика собирает события. Какие показатели снимать с первого дня — в статье об аналитике приложения.
Типичная ошибка. Считать релиз финишем. Первые две недели после запуска дают больше данных о продукте, чем весь этап разработки, — но только если заранее настроены сбор ошибок и события аналитики.
Этап 7. Поддержка после запуска
Поддержка — это не «починить, если сломается». Это регулярная работа: наблюдение за ошибками и доступностью, обновления под новые версии iOS и Android, обновления безопасности и библиотек, помощь сотрудникам заказчика, восстановление после сбоев. Без неё продукт деградирует незаметно — сначала перестаёт работать оплата на новой версии системы, потом приложение исчезает из выдачи магазина за несоответствие требованиям.
У поддержки два принципиально разных способа оплаты, и разница видна в годовом бюджете.
| Модель | Как оплачивается поддержка | Что учесть |
|---|---|---|
| Продукт, написанный с нуля | Отдельный договор на сопровождение или собственная команда. Рыночный ориентир расходов — 15–25% стоимости разработки в год | Полный контроль над архитектурой и дорожной картой; расходы на команду от ~400 000 ₽/мес за двух разработчиков и инженера по тестированию |
| Продукт на модульной платформе | Лицензионные платежи, в которые уже включены затраты на техническую поддержку команды FITTIN: мониторинг, обновления модулей и обновления безопасности | Собственная команда разработки не нужна; глубина изменений ограничена архитектурой платформы, уникальные сценарии дописываются отдельно |
Отдельная ситуация — продукт, который делал другой подрядчик. Взять его на сопровождение можно, но начинается это с аудита кода: без понимания состояния системы оценка превращается в гадание. Состав работ описан на странице технической поддержки, а расчёт годового бюджета — в статье о стоимости поддержки после запуска.
Результат этапа
Регламент обращений с временем реакции, настроенный мониторинг ошибок и доступности, регулярные обновления безопасности.
Типичная ошибка. Не заложить поддержку в бюджет первого года. Продукт запускают, команду распускают, а через полгода обновление операционной системы ломает оплату — и вместо плановых работ начинается срочный поиск подрядчика.
Этап 8. Развитие и вывод из эксплуатации
Развитие отличается от поддержки предметом работ: поддержка сохраняет то, что уже есть, развитие добавляет новое. Поэтому и оплачивается оно иначе — по фактически затраченным часам с оценкой перед стартом задачи. Такое разделение снимает главный спор сопровождения: считать ли новую функцию гарантийным случаем.
Порядок работы простой: события аналитики и обращения пользователей дают список гипотез, гипотезы попадают в план на квартал, план разбивается на выпуски. Что именно измерять, разобрано в статье о пятнадцати метриках разработки, а проверка изменений на части аудитории — в материале об A/B-тестировании.
Последняя стадия цикла — вывод из эксплуатации. О ней вспоминают редко, а закладывать её стоит заранее: перенос данных в новую систему, срок хранения архивов, отзыв доступов, снятие приложения с публикации и предупреждение пользователей. Если данные лежат в понятной схеме и есть выгрузка в открытом формате, замена системы через пять лет становится проектом на несколько недель, а не переписыванием истории заказов вручную.
Результат этапа
План развития на квартал, выпуски с новым функционалом и описанный порядок переноса данных при замене системы.
Типичная ошибка. Копить изменения до «большого обновления» раз в год. Крупный выпуск сложнее проверять, а откатывать его при ошибке приходится целиком. Короткие выпуски раз в две-четыре недели дешевле в поддержке.
Модели цикла: водопад, итерации и гибкие методы
Этапы одни и те же, а вот порядок прохождения различается. Модель выбирают не по моде, а по тому, насколько заранее известен объём работ и насколько заказчик готов участвовать в процессе еженедельно.
| Модель | Где работает лучше всего | Чем приходится платить |
|---|---|---|
| Последовательная (водопад) | Объём известен заранее: замена учётной системы, продукт под требования регулятора, тендер с зафиксированным техническим заданием. Позволяет зафиксировать цену и срок до старта | Изменение требований в середине проекта стоит дорого: приходится возвращаться к документам и пересчитывать смету |
| Итерационная | Продукт собирается частями: сначала каталог и оплата, потом лояльность и персонализация. Работающую часть видно с первых недель | Итоговая стоимость известна только рамкой: точный объём последних итераций зависит от результатов первых |
| Гибкая (Scrum и подобные) | Задача исследовательская, приоритеты меняются, продукт развивается постоянно. Порядок работы описан в Scrum Guide, принципы — в Agile-манифесте | Требует еженедельного участия заказчика и владельца продукта с правом решать. Без этого гибкость превращается в отсутствие плана |
На практике модели смешивают: требования и приёмка идут последовательно, потому что их привязывают к договору, а сама разработка — итерациями. Как модель оплаты связана с моделью работы, разобрано в статье Fixed Price или Time & Materials.
Сколько занимает полный цикл и что идёт параллельно
Разработка с нуля: от шести до двенадцати месяцев
Срок зависит не от числа этапов, а от того, сколько на каждом создаётся с нуля. Рыночный ориентир для продукта, который пишут полностью самостоятельно, — от шести до двенадцати месяцев до первого выпуска. Основное время уходит на этапы 3 и 4: архитектуру, экраны и базовые механики вроде каталога, корзины, оплаты и личного кабинета приходится проектировать и писать заново.
Сборка на модульной платформе: до 30 рабочих дней
Второй сценарий — сборка на модульной платформе. Каталог, поиск и фильтры, корзина и оформление заказа, оплата, личный кабинет, программа лояльности, push-уведомления, аналитика и интеграции с 1С, маркетплейсами и эквайрингом уже есть — их настраивают под бренд, а не пишут. Этапы при этом не исчезают: требования, проектирование, проверка и приёмка остаются, но объём работ внутри них другой. Единоразовая интеграция платформы под бренд занимает до 30 рабочих дней.
| Работы при интеграции платформы | Рабочих дней | Что идёт параллельно |
|---|---|---|
| Постановка задачи, состав модулей и список интеграций | 3–5 | Сбор доступов и контента на стороне заказчика |
| Оформление под бренд на дизайн-системе платформы | 5–7 | Подготовка учётных записей в магазинах приложений |
| Настройка модулей и подключение интеграций | 10–12 | Тестирование готовых частей идёт внутри этого срока, а не после него |
| Приёмка и подготовка публикации | 3–5 | Оформление карточек и описаний для магазинов приложений |
Последовательная часть складывается в 21–29 рабочих дней — отсюда и срок «до 30 рабочих дней» на интеграцию. Проверка со стороны магазинов приложений считается отдельно: её длительность зависит от площадки, а не от команды. Тариф «Индивидуальный» с дополнительными интеграциями и нетиповым функционалом идёт от 30 рабочих дней — состав работ определяется после разбора задач.
Сдвигают срок обычно три вещи, и все три — на стороне бизнеса: готовность контента и каталога, доступы к учётным системам и скорость согласований. Разбор источников расхождения плана и факта — в чек-листе заказчика.
Сколько стоит цикл и из чего складывается смета
Кастомная разработка: часы, роли и модель оплаты
Смета кастомной разработки считается по часам и ролям: аналитик, дизайнер, разработчики клиентской и серверной части, инженер по тестированию, менеджер проекта. Часы умножаются на ставку роли; наша сетка ставок опубликована и начинается от 2 625 ₽/час. Работаем в двух форматах: фиксированная цена по утверждённому техническому заданию и оплата по фактически затраченным часам с оценкой перед стартом задачи. Подробный разбор структуры сметы — в статье о стоимости разработки ПО.
Платформа: интеграция, лицензия и доработки
Для продукта на модульной Flutter-платформе действует другая модель, и она состоит из трёх частей. Первое — единоразовый платёж за интеграцию под бренд с фиксированным сроком до 30 рабочих дней. Второе — ежемесячные лицензионные платежи, в которые уже включены затраты на техническую поддержку команды FITTIN: мониторинг, обновления модулей и обновления безопасности; собственная команда разработки при этом не нужна. Третье — новый функционал и доработки, которые оплачиваются отдельно по фактически затраченным часам с прозрачной сметой.
| Направление | Интеграция, единоразово | Лицензия, ежемесячно |
|---|---|---|
| Мобильное приложение, тариф ПРО | от 525 000 ₽ | от 150 000 ₽ |
| Мобильное приложение, тариф ПРО+ (интеграции под ключ) | от 735 000 ₽ | от 170 000 ₽ |
| Приложение и сайт на одной кодовой базе, тариф ПРО | от 735 000 ₽ | от 250 000 ₽ |
| Приложение и сайт на одной кодовой базе, тариф ПРО+ | от 997 500 ₽ | от 290 000 ₽ |
| Тариф «Индивидуальный» | Договорная: состав работ и цена — по результатам разбора задач, срок от 30 рабочих дней | |
Цены указаны с учётом НДС, полный состав пакетов — на странице тарифов. Разница между ПРО и ПРО+ не в масштабе бизнеса, а в том, кто подключает интеграции: в ПРО это делает команда заказчика или его подрядчик, в ПРО+ — команда FITTIN.
Для сравнения: по нашей оценке рынка разработка сопоставимого по функциям продукта с нуля начинается от 5–10 млн ₽ единоразово (диапазоны по классам продуктов), плюс собственная команда сопровождения. Взамен заказчик получает то, чего платформа не даёт: полный контроль над архитектурой и дорожной картой и отсутствие ежемесячных лицензионных платежей. Это и есть предмет выбора на первом этапе — обмен скорости и предсказуемой стоимости владения на глубину контроля.
Отдельный формат — когда задачи ведёт своя команда бизнеса, а специалистов подключают на время проекта: бэкенд-разработчиков, инженеров по тестированию или дизайнеров. Сравнение с наймом внутрь — в статье о подряде и собственной команде.
Документы, которые остаются у заказчика
Признак того, что цикл прошли целиком, — не работающий продукт, а работающий продукт плюс комплект документов. Без них замена подрядчика превращается в повторную разработку, а внутренняя ИТ-служба не может принять систему на сопровождение.
- Техническое задание с составом первой версии и разграничением ответственности сторон.
- Схема системы и описание методов обмена данными — что с чем связано и в каком формате передаётся.
- Макеты и дизайн-система в исходном формате, а не картинками.
- Исходный код в репозитории компании с историей изменений и правами администратора у заказчика.
- Инструкции по установке и эксплуатации и руководство пользователя — комплект технической документации.
- Отчёт о тестировании и акт приёмки — основание оплаты и точка отсчёта гарантии.
- Доступы: домен, серверы, учётные записи разработчика, платёжные и аналитические сервисы — оформленные на компанию.
Для продуктов на платформе FITTIN добавляется ещё один документ — подтверждение того, что программное обеспечение внесено в реестр российского ПО Минцифры (№ 2487103). Для компаний с государственным участием и заказчиков из регулируемых отраслей это условие закупки.
Кейсы: как цикл выглядел на реальных проектах
Ниже — проекты, где хорошо видно, какой этап оказался определяющим. Цифры приведены со страниц кейсов.
«Сатурн» — сеть строительных гипермаркетов в 20+ городах
Определяющим стал этап требований. В каталоге свыше 30 000 товаров, каждый город работал со своими складами и ценами, а к обычному заказу добавлялись колеровка краски, распил материалов, доставка с манипулятором и оформление на юридическое лицо. Пока эти правила не были описаны, любой экран приложения оставался набором частных случаев.
Результат по данным страницы кейса: 7 594 установки за первый месяц после запуска и конверсия в покупку 12,4%. Приложение вышло одновременно в четырёх магазинах приложений.
В «Сыроварне» вес пришёлся на проектирование: сеть ресторанов получила нетиповые сценарии — конструктор блюда, оформление заказа в одном окне, бронирование столика с отправкой друзьям. Полный цикл занял два месяца, проект номинирован на Workspace Digital Awards 2026. В Finn Flare цикл проходили повторно: действующее приложение перезапускали на единой кодовой базе, бюджет разработки оказался в 2,5 раза меньше, а скорость работы — в 1,5 раза выше, релиз занял около 30 рабочих дней. В DAISYKNIT ключевым был восьмой этап — переход со стороннего решения с переносом данных: сохранность клиентской базы составила 100%. В «Пан Чемодане» цикл от старта до публикации уложился в 21 день при 193 закрытых задачах.
Остальные проекты — в разделе кейсов. Состав работ по направлениям описан на страницах разработки ПО на заказ, корпоративных приложений и мобильных приложений для e-commerce.
Итог: полный цикл на одной странице
Восемь этапов, у каждого — свой результат, который можно проверить. Короткий порядок действий для заказчика:
- Сформулируйте цель числом. Не «нужно приложение», а какой показатель бизнеса должен измениться и на сколько.
- Доведите требования до документа. Техническое задание — основание сметы, приёмки и границы ответственности сторон.
- Требуйте результат на каждом этапе. Схема, макеты, сборка на тестовом окружении, отчёт о проверке, акт — а не проценты готовности в письме.
- Планируйте седьмой и восьмой этапы заранее. Поддержка и развитие — постоянная строка бюджета, а не разовые расходы.
- Заберите документы и доступы. Код, документация, домен и учётные записи оформляются на компанию до окончания проекта, а не после.
Что делать дальше:
- Оценить срок и бюджет под свою задачу — калькулятор стоимости или сравнение тарифов.
- Зафиксировать требования документом — разработка технического задания; проверить действующий продукт — аудит кода или аудит UX/UI.
- Обсудить проект целиком или передать продукт на сопровождение — техническая поддержка, контакты.
Вопросы и ответы
Сколько этапов в разработке ПО и можно ли какие-то пропустить?
Полный цикл — восемь стадий: идея и цели, требования, проектирование, разработка, тестирование и приёмка, запуск, поддержка, развитие и вывод из эксплуатации. Пропустить можно любую, но работа с неё никуда не денется: без описанных требований сценарии придумывает разработчик по ходу, без проектирования архитектуру определяет первый написанный экран. Меняется только момент, когда за это платят, — на этапе документа или на этапе переделки готового кода.
Чем этапы разработки ПО отличаются от этапов разработки мобильного приложения?
Последовательность одинаковая, отличается наполнение. У мобильного приложения добавляются публикация в магазинах приложений с проверкой со стороны площадок и поддержка старых версий у пользователей, которые не обновляются. У корпоративной системы вес смещается на требования, роли и права, а вместо публикации идёт ввод в эксплуатацию с обучением сотрудников. Разбор по шагам для приложения — в статье об этапах разработки мобильного приложения.
Что заказчик получает на выходе каждого этапа?
Материальный результат, который можно проверить: описание задачи с целью, подписанное техническое задание, схему системы и макеты, сборку на тестовом окружении, отчёт о проверке и акт приёмки, работающий продукт с переданными доступами. Если результат этапа невозможно открыть, прочитать или запустить, этап не закрыт — это простое правило снимает большинство споров о готовности.
Сколько времени занимает полный цикл разработки?
Зависит от того, сколько создаётся с нуля. Рыночный ориентир для продукта, который пишут полностью самостоятельно, — от шести до двенадцати месяцев до первого выпуска. Интеграция готовой модульной платформы под бренд занимает до 30 рабочих дней: этапы остаются те же, но каталог, корзина, оплата, лояльность и интеграции настраиваются, а не пишутся. Проверка со стороны магазинов приложений считается отдельно и от подрядчика не зависит.
Кто отвечает за приёмку и как она проходит?
Со стороны заказчика — сотрудник, который будет отвечать за продукт после запуска, а не только ИТ-специалист. Приёмка идёт по сценариям из технического задания на тестовом окружении: заказчик проходит их подряд и фиксирует замечания одним списком. До начала полезно договориться, что считается ошибкой, а что новым пожеланием: первое исправляется по договору, второе оценивается как доработка.
Что входит в поддержку после запуска и сколько она стоит?
Наблюдение за ошибками и доступностью, исправление сбоев, обновления под новые версии операционных систем, обновления безопасности, помощь сотрудникам. Для продукта, написанного с нуля, рыночный ориентир расходов — 15–25% стоимости разработки в год, и это поверх содержания собственной команды. На модульной платформе поддержка команды FITTIN включена в лицензионные платежи, а новый функционал оплачивается отдельно по фактически затраченным часам.
Нужно ли техническое задание, если разработка идёт итерациями?
Да, но в другом объёме. При итерационной работе документ фиксирует рамку: цели, роли и права, список интеграций, требования к защите данных и состав первой версии. Детали отдельных экранов уточняются перед соответствующей итерацией. Без рамки итерации превращаются в поток задач без критерия завершения, а смета — в открытый счёт.
Можно ли передать сопровождение ПО другому подрядчику?
Можно, если у компании есть исходный код, документация и доступы — те самые результаты этапов. Начинается передача с аудита кода: он показывает состояние системы, объём унаследованных (legacy) решений и трудоёмкость сопровождения. Продукты, разработанные другими подрядчиками, берём на техническую поддержку — по подписке или по фактически затраченным часам.
Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации.
