Этапы разработки программы или веб-сервиса: жизненный цикл простыми словами и роль заказчика

Короткий ответ: разработка ПО проходит одни и те же шаги — идея и цель, требования, ТЗ и договор, проектирование, дизайн, разработка, тестирование, приёмка и запуск, сопровождение и в конце вывод из эксплуатации. Это и есть жизненный цикл программы. Заказчик участвует в каждом шаге: без его ответов, данных и решений проект встаёт. ГОСТы для коммерческого проекта необязательны, но из них полезно взять порядок и состав документов.

Ниже — что происходит на каждом этапе, что от вас потребуется, какие бумаги останутся на руках и где проекты чаще всего буксуют. Без теории ради теории: только то, что пригодится заказчику, который делает программу или веб-сервис впервые.

Из каких этапов состоит разработка ПО?

Из десяти шагов, которые удобно сгруппировать в четыре блока: понять задачу (идея, требования, ТЗ), спроектировать (прототип, дизайн), сделать и проверить (разработка, тестирование, приёмка) и жить с программой (запуск, сопровождение, вывод из эксплуатации).

1. Идея и цель. Какую проблему решает программа, для кого и как вы поймёте, что она работает. «Нужна CRM» — не цель; «менеджеры теряют заявки из почты, нужен единый список с ответственным и сроком» — цель.
2. Сбор требований. Кто будет пользоваться (роли), что каждый делает (сценарии), какие данные хранятся, с какими системами нужен обмен: 1С, CRM, оплата, почта.
3. ТЗ, оценка и договор. Требования превращаются в документ, по которому можно посчитать цену и потом принять работу. Подписывается договор.
4. Проектирование. Прототип экранов, схема данных, схема обмена с другими системами. Самый дешёвый момент, чтобы передумать.
5. Дизайн. Внешний вид ключевых экранов. У внутренних программ он скромнее, у продуктов для клиентов — важнее.
6. Разработка. Код, база данных, интеграции. Обычно по частям, с промежуточными показами.
7. Тестирование. Проверка сценариев, прав доступа, ошибочных данных, работы на разных устройствах.
8. Приёмка и запуск. Заказчик проверяет результат по ТЗ, подписывает акт, программа переезжает на боевой сервер.
9. Сопровождение и развитие. Исправление ошибок, обновления, новые функции по мере того, как программой реально пользуются.
10. Вывод из эксплуатации. Программу заменяют или закрывают: данные выгружают, переносят или удаляют, сервисы отключают.

В гибких подходах шаги 4–7 повторяются короткими кругами: спроектировали часть, сделали, показали, поправили. Порядок от этого не меняется, меняется размер куска, который проходит через цикл за один раз. Если сомневаетесь, делать всё сразу или начать с минимальной версии, — разбор в статье «MVP или полная версия».

Этап	Исполнитель	Заказчик	Документ на выходе
1. Идея и цель	Задаёт уточняющие вопросы, отсекает лишнее	Формулирует, какую проблему и чью решает программа	Короткое описание задачи или заполненный бриф
2. Требования	Описывает роли, сценарии, данные, интеграции	Отвечает на вопросы, даёт примеры документов и доступы	Список требований, сценарии пользователей
3. ТЗ, оценка, договор	Пишет ТЗ и спецификацию, считает смету	Проверяет, что в ТЗ есть всё важное, подписывает	Договор, ТЗ, спецификация, счёт
4. Проектирование	Рисует прототип экранов, схему данных и обмена	Согласует прототип, проходит его глазами сотрудника	Прототип, схема данных
5. Дизайн	Делает макеты ключевых экранов	Даёт правки одним списком	Согласованные макеты
6. Разработка	Пишет код, подключает интеграции	Готовит тексты и данные, смотрит промежуточные версии	Рабочая версия на тестовом адресе
7. Тестирование	Проверяет сценарии, права доступа, ошибки	Прогоняет свои реальные случаи	Список найденных ошибок и их исправлений
8. Приёмка и запуск	Выкладывает на боевой сервер, передаёт доступы	Проверяет по ТЗ, подписывает акт	Акт, доступы, инструкция, исходники в репозитории
9. Сопровождение	Исправляет ошибки, обновляет, дорабатывает	Собирает обратную связь, ставит задачи	Журнал задач и изменений
10. Вывод из эксплуатации	Выгружает данные, отключает сервисы	Решает, куда переносить данные и что удалить	Выгрузка данных, акт отключения

Что делает заказчик на каждом этапе?

Заказчик отвечает за смысл: цель, правила процесса, данные, решения и приёмку. Исполнитель — за то, как это сделать. Чем раньше заказчик подключается, тем меньше переделок в конце. Таблица показывает распределение ролей и документы, которые остаются после каждого шага.

Самая частая ошибка — считать, что после подписания договора заказчик свободен до приёмки. На практике больше всего вашего времени нужно на втором и четвёртом этапах: рассказать, как устроен процесс, и пройти прототип глазами сотрудника, который будет в нём работать каждый день. Это несколько встреч и пара часов на проверку прототипа, но именно они определяют, понравится ли программа людям.

Второе, что держит только заказчик, — решения. Если на вопрос «менеджер видит все заказы или только свои?» ответ ищется неделю, разработка этого места стоит. Удобно назначить одного человека, который принимает решения по проекту и может сказать «да» или «нет» без совещания.

Какие документы появляются по ходу?

Минимальный набор для коммерческого проекта: бриф, ТЗ со спецификацией, договор, согласованный прототип, акт приёмки и инструкция с доступами. Остальное — по размеру проекта. Главное правило: документ нужен, если по нему потом принимают решение или работу.

• Бриф. Ответы на вопросы о задаче до оценки. Его можно заполнить заранее — на странице брифа на разработку.
• Техническое задание и спецификация. Что входит в работу, а что нет; роли, сценарии, интеграции, критерии готовности. Как составить ТЗ без опыта, мы разбирали в статье «Как составить ТЗ на сайт или веб-сервис».
• Договор. Цена, срок, порядок оплаты и приёмки, гарантия, права на результат. В нашем типовом договоре оплата 50/50, на приёмку у заказчика 5 рабочих дней, гарантия — 30 календарных дней с даты акта.
• Прототип и макеты. Согласованная картинка того, что будет сделано. Спорные вопросы на приёмке решаются по ней.
• Акт приёмки. Подтверждает, что работа сделана по ТЗ. С даты акта считается гарантия.
• Доступы и инструкция. Сервер, домен, база данных, админка, платёжный кабинет; как запускать, обновлять и что делать при сбое.
• Исходный код. В репозитории, к которому у вас есть доступ. По нашим договорам исключительное право на код остаётся у исполнителя, а заказчик получает лицензию на весь срок действия права: исходники в его репозитории, запуск на любом сервере, доработки любым подрядчиком. Логотип, тексты и фирменный стиль, созданные для заказчика, — его.

Для больших систем добавляются руководство пользователя, описание интеграций, программа и методика испытаний. Для лендинга часть списка сворачивается в одну страницу. Перечень документов стоит согласовать на старте, чтобы в конце не выяснилось, что «инструкция» в понимании сторон — разные вещи.

Что говорят ГОСТы и нужны ли они коммерческому проекту?

Обязательными для частного проекта ГОСТы не являются: по статье 26 закона о стандартизации документы национальной системы стандартизации применяются добровольно, если иное не установлено законодательством. Обязательными их делает договор, требование заказчика или отраслевые правила.

Чаще всего в разговорах о жизненном цикле всплывают два семейства стандартов:

• ГОСТ Р ИСО/МЭК 12207-2010 «Процессы жизненного цикла программных средств». Российская версия международного стандарта ISO/IEC 12207:2008, введена с 1 марта 2012 года. Она описывает не «этапы по порядку», а набор процессов: соглашения между заказчиком и поставщиком, разработка требований, проектирование, тестирование, сопровождение, вывод из эксплуатации и другие. Полезна как словарь и чек-лист: что вообще бывает в жизни программы.
• Стандарты серии 34 об автоматизированных системах. Их требуют госзаказчики и крупные компании. Самый известный — ГОСТ 34.602-2020 о техническом задании на создание автоматизированной системы, действует с 1 января 2022 года вместо ГОСТ 34.602-89. В нём подробная структура ТЗ: назначение системы, требования, порядок контроля и приёмки.

Что из этого взять малому бизнесу: порядок шагов, привычку описывать критерии приёмки и раздел «что не входит в работу». Писать ТЗ по ГОСТу на сто страниц ради интернет-сервиса для своей команды не нужно — его никто не прочитает, а сроки и деньги он съест. Если ГОСТ требует ваш заказчик или инвестор, скажите об этом на брифе: объём документации влияет на оценку.

Что сравниваем	Сайт	Веб-сервис или программа
Главный вопрос на старте	Что посетитель должен узнать и сделать	Кто пользователи, какие у них права и что они делают
Центр проектирования	Структура страниц и тексты	Сценарии, роли, схема данных
Что проверяют на тестах	Вёрстку на телефонах, формы, скорость	Права доступа, расчёты, пограничные случаи, нагрузку
Главный риск	Нет текстов и фото к запуску	Неописанные правила и исключения процесса
Жизнь после запуска	Обновление контента, редкие доработки	Постоянное развитие, новые роли и интеграции

Чем этапы веб-сервиса отличаются от этапов сайта?

Шаги те же, но вес у них разный. У сайта центр тяжести — структура, тексты и дизайн. У веб-сервиса — роли, сценарии и данные: кто что видит, кто что меняет и что происходит при ошибке. Поэтому у сервиса длиннее требования, проектирование и тестирование.

Пример. Для корпоративного сайта на этапе требований достаточно договориться о разделах, формах заявок и куда они приходят. Для сервиса записи клиентов на тот же этап нужно описать: кто может отменить запись, что видит администратор филиала, что происходит, если клиент опоздал, как считается свободное время, если мастер заболел. Каждое «а если» — это отдельная ветка кода и отдельная проверка на тестах.

Поэтому и вопрос «в каком порядке делать сайт» решается проще: структура, тексты, дизайн, вёрстка, подключение форм и аналитики, публикация. Как этот путь устроен у нас — в статье «Как мы делаем сайты», а что влияет на его длительность — в разборе «Сколько времени делается сайт». Для сервисов, кабинетов и внутренних программ — страница заказной разработки.

Где проекты чаще всего застревают?

Не в программировании. Проекты буксуют на стыках: когда ждут ответа заказчика, материалов, доступов или решения, кто прав в споре о том, что «имелось в виду». Почти все такие места видны заранее и закрываются до старта.

• Цель размыта. «Сделать как у конкурента» без понимания, зачем. Проект растёт во все стороны, а результат не с чем сравнить.
• Правила процесса живут в головах. Исключения всплывают на приёмке: «а у нас оптовики платят по-другому». Лекарство — расписать сценарии на этапе требований с людьми, которые делают эту работу.
• Нет одного ответственного. Правки приходят от трёх руководителей и противоречат друг другу.
• Нет материалов. Тексты, фото, прайсы, справочники, примеры документов приходят в последний день.
• Доступы к внешним системам. Ключи API к 1С, CRM, платёжному сервису, доступ к домену. Их выдача часто зависит от третьих лиц, поэтому запрашивать их стоит в первый же день.
• Правки без границ. Новая идея на каждом показе. В тарифах нашего прайса число раундов правок оговорено заранее (до двух на этап согласования); всё, что меняет согласованный объём, оформляется отдельной задачей, а не растворяется в текущей.
• Приёмка «на ощущениях». Если в ТЗ нет критериев готовности, акт подписать трудно. Критерии стоит записать заранее: «заявка из формы появляется в CRM с источником», а не «удобно».

Видеть, на каком шаге проект и что ждёт ответа от вас, помогает общая доска задач. Как это устроено у нас, рассказано в статье о прозрачности в разработке.

Когда полный цикл с документацией вам не нужен?

Когда задача маленькая и обратимая. Для лендинга, бота заявок или простой интеграции хватает брифа, короткого ТЗ и проверки результата. Тяжёлая документация оправдана, когда ошибка дорога: деньги, персональные данные, много ролей, обмен с учётной системой.

• Не нужно: отдельное архитектурное описание для одностраничного сайта; программа и методика испытаний для бота, который пересылает заявку в чат; ТЗ по ГОСТу для внутреннего сервиса на десять сотрудников.
• Нужно всегда: записанная цель, список того, что входит и не входит в работу, согласованный прототип, критерии приёмки и доступы на ваше имя.
• Нужно обязательно, если: программа хранит персональные данные, принимает оплату, меняет данные в 1С или ею пользуются люди из разных компаний. Здесь экономия на требованиях и тестировании выходит дороже всего.

И отдельно о последнем этапе. О выводе из эксплуатации редко думают на старте, но решение принимается именно тогда: в каком формате выгружаются данные, где лежит код, на кого оформлены сервер и домен. Если всё это оформлено на вас, сменить подрядчика или перейти на другую систему можно без потерь.

Чек-лист заказчика перед стартом разработки

Десять пунктов, которые снимают большую часть задержек ещё до первой строки кода. Если на половину вопросов ответа нет, начните с брифа: эти ответы появятся в разговоре.

1. Одна фраза: какую проблему решает программа и как вы поймёте, что она работает.
2. Список ролей: кто будет пользоваться и что каждому можно.
3. Три–пять главных сценариев словами: «менеджер получает заявку, назначает, клиент видит статус».
4. Исключения, которые бывают в вашем процессе хотя бы раз в месяц.
5. С какими системами нужен обмен и кто выдаст к ним доступ.
6. Примеры реальных документов, отчётов, таблиц, которыми вы пользуетесь сейчас.
7. Один ответственный с правом принимать решения.
8. Кто готовит тексты, фото и справочники и к какому шагу.
9. Критерии приёмки: что должно работать, чтобы вы подписали акт.
10. На кого оформлены домен, сервер, репозиторий и платёжные кабинеты.

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

Короткие ответы на частые вопросы

Сколько этапов у разработки программы?

Единого числа нет: в учебниках встречаются и пять, и семь, и десять этапов. По сути их всегда одни и те же группы — понять задачу, спроектировать, сделать, проверить, запустить и сопровождать. Важно не число, а чтобы у каждого шага был понятный результат и ответственный.

Можно ли пропустить этап проектирования, чтобы сэкономить?

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

Обязательно ли писать ТЗ по ГОСТу?

Для коммерческого проекта — нет: по закону о стандартизации национальные стандарты применяются добровольно, если иное не установлено законодательством; обязательными для вас их может сделать договор. ГОСТ обычно требуют госзаказчики и крупные компании; малому бизнесу хватает ТЗ, в котором понятно описаны роли, сценарии, данные и критерии приёмки.

Кто отвечает за тестирование — заказчик или разработчик?

Разработчик проверяет, что программа работает по ТЗ и не ломается на ошибочных данных. Заказчик проверяет, что она подходит его процессу: прогоняет реальные случаи, которые знает только он. Без второй части даже хорошо протестированная программа может не прижиться.

Что такое жизненный цикл ПО простыми словами?

Это весь путь программы: от решения, что она нужна, через разработку и запуск к годам работы с доработками и, в конце, к отключению с переносом данных. Разработка — только часть этого пути, и обычно не самая длинная.

Услуги и кейсы по теме: заказная разработка · цены и сроки