В этой статье мы хотим поговорить о подготовительной работе перед началом разработки любого программного обеспечения, а именно о необходимости детального технического описания eCommerce-проектов.
Для каких проектов мы рекомендуем начинать со спецификации, зачем делать проектирование перед написанием технического задания, и когда разумнее стартовать работу без полноценного ТЗ?
На первый взгляд может показаться, что спецификация не нужна и не стоит времени, потраченного на ее составление. Некоторые разработчики и их клиенты совсем отказываются от какой-либо документации. Давайте начнем с объяснения того, что такое спецификация с точки зрения разработки программного обеспечения.
Выведите ваш бизнес в онлайн. Начните разработку маркетплейса уже сегодня!
ЗАКАЗАТЬ РАЗРАБОТКУ МАРКЕТПЛЕЙСА
Что такое спецификация
Разработка по спецификации или модель сотрудничества Fixed Price – это модель, при которой фиксируется содержание работ, сроки и стоимость. При этом описанный состав работ закрепляется и не может меняться после его согласования, бюджет для клиента также не меняется за исключением тех случаев, когда по ходу выполнения проекта появляются новые вводные по бизнес-требованиям клиента. В таком случае составляется новая спецификация с уточненным составом работ и бюджетом.
Разработка по спецификации – это как заказ еды в ресторане. Ты заранее знаешь, что и когда будешь есть, и сколько заплатишь за это. Если ты передумал заказывать стейк и хочешь добавить салат, то это будет уже другой заказ, с отдельной ценой. Так и с разработкой – если надо что-то поменять, то это будет новая сделка.
Для каких проектов подходит эта модель?
- У вас четко обозначены требования на каждом этапе проекта
- Проекты с ограниченным бюджетом и сжатыми сроками, например доработка отдельного функционала магазина
- Короткие проекты длительностью до 3 месяцев, когда вы уверены, что требования не изменятся
- Вы хотите сократить свое участие в процессе разработки, поэтому готовы на начальном этапе потратить время на составление подробного технического описания проекта.
Зачем нужна спецификация программного обеспечения. Чем она отличается от Технического задания (ТЗ)
Спецификация программного обеспечения позволяет зафиксировать детальные требования к разработке, указать роли и ответственности сторон, сроки и стоимость реализации. Так вы сможете четко понимать, что и когда будет реализовано, и в случае разногласий иметь письменное подтверждение договоренностей. В отличие от Технического задания (ТЗ), которое предполагает подготовку по таким стандартам как ГОСТ 34, IEEE 29148-2011, Rational Unified Process и значительно усложняет процесс производства конечной услуги, некоторые IT-компании составляют спецификацию с учетом внутренних процессов и особенностей разработки интернет-магазинов.
Вместо ТЗ, обычно мы составляем спецификацию, документ, который отвечает внутренним стандартам требований к разработке ПО. Так происходит потому, что мы общаемся непосредственно с владельцами бизнеса, и чтобы не перегружать их техническими деталями и сложностями классического ТЗ и не удорожать разработку за счет высокой стоимости разработки технического задания, мы используем спецификации.
Андрей, CTO
Чем спецификация отличается от брифа
Спецификация — это детальное описание требований к работе, тогда как бриф — это опросник. Мы отправляем брифы клиентам, чтобы выяснить общие бизнес-требования, предполагаемый функционал и пожелания. Такие опросники помогают понять, что хочет клиент. Пример короткого брифа на разработку дизайна интернет-магазина может включать такие вопросы как:
- Есть ли фирменный стиль или брендбук?
- Укажите сайты, которые вам нравятся и элементы дизайна, на которые нам следует обратить внимание.
- Что недопустимо на сайте?
- Опишите требования к дизайну:
- На базе готового решения (шаблон/тема)
- Персонализация готового шаблона/темы (изменения цветовой гаммы/иконок/шрифтов под ваш стиль)
- Индивидуальный дизайн (разработка уникального дизайна)
Бриф не является документом закрепления договоренностей, но может предварять спецификацию для выяснения требований заказчика и дальнейшего составления задания.
Кто и когда составляет спецификацию ПО
В действительности, нет правильного ответа на этот вопрос. Как заказчик, так и исполнитель могут составлять спецификацию ПО. Часто, — это совместная работа. Все зависит от конкретной ситуации и условий.
Составляет Заказчик
В таком случае разработчик получает готовое детальное разъяснение того, что нужно сделать и, если задание понятно, указывает стоимость и срок работ. Тем не менее часто составитель неясно представляет себе, что хочет получить в результате работ, из-за чего спецификация на разработку ПО получается размытой и непонятной.
Совет от наших экспертов: Рекомендуем обсудить свои требования с подрядчиком перед тем, как принимать решение о составлении спецификации. Так вы избежите затрат времени на разработку детальной спецификации, которая может оказаться нереализуемой или сложной для выполнения. Вместо этого подрядчик может предложить более простое решение и подсказать, как лучше реализовать требования, опираясь на оптимальные технологии.
Составляет Исполнитель
Исполнитель, разрабатывающий спецификацию, собирает требования к задаче, определяет цель работы и пользу для заказчика. Далее проходит устное или письменное интервью, где стороны задают уточняющие вопросы и выясняют остальные требования. Только после этих шагов, спецификация на разработку ПО составляется и согласовывается с заказчиком. Данный способ основан на доверии заказчика исполнителю. Поэтому так важно выбрать добросовестного подрядчика с самого начала. Все же, при этом подходе от заказчика также требуется активное участие, потом что только он знает особенности своего бизнеса, которые нужно будет учесть в работе.
Как мы составляем спецификацию
В титульной части указываем наименование работы, проект, для которого выполняется работа, дату составления спецификации, версию спецификации, используемый стек технологий и его характеристики (например, название и версия платформы)
В основной части описываются технические детали: что будет сделано, и какие у проекта есть ограничения.
Третий раздел освещает то, каким образом будет проходить тестирование, для каких систем и браузеров разрабатывается модификация, какие домены и версии платформ участвуют.
Четвертый раздел описывает способы коммуникации с заказчиком. Здесь указываются возможные каналы для общения, а также удобное время.
Далее описывается то, каким образом происходит приемка и передача выполненной работы. Как правило, это сначала демонстрация на тестовом магазине с последующим переносом на живой сайт.
Спецификация и проектирование архитектуры сайта
Как мы поняли из предыдущего раздела, составление спецификации требует глубокого понимания состава работ, механик функционирования и взаимодействия элементов интернет-магазина. От полноты составления спецификации зависит точность сроков и бюджета работа. Чтобы избежать ошибок на старте, мы рекомендуем начинать проект не с написания спецификации, а с проектирования архитектуры интернет-магазина. Что это такое?
В процессе проектирования анализируется идея сайта, его цели и задачи для подготовки технических требований. Если проект разрабатывается на базе готовой платформы, то в процессе проектирования аналитики накладывают бизнес-требования на дефолтные и кастомные возможности платформы. Проектируются разделы и страницы сайта, а также их функционал, разрабатываются схемы взаимодействия подсистем сайта, адаптированные под клиента.
По завершению этапа проектирования и клиент, и команда разработчиков получают четкое представление о том, как будет выглядеть и работать готовый проект.
Для того, чтобы начать делать кастомную разработку – нужно четко понять, что мы хотим получить на выходе. Могут возникнуть разные ситуации, в зависимости от того, с чем пришел клиент: абстрактной бизнес-идеей, или четкими требованиями. Когда у сторон нет ясного понимания, как будет выглядеть итоговый проект, требуется проектирование – мы анализируем бизнес-требования, после чего проектируем разделы сайта и подробно описываем функциональность. Понимание бизнес-идеи клиента для нас критично, от этого зависит итоговый продукт и процесс его разработки
Александр, Руководитель группы программистов
Когда спецификация не нужна
Итак, мы разобрались, что работа по спецификации идеально подходит для небольших проектов с понятными требованиями, когда ни заказчик, ни подрядчик не предвидят значительных изменений в ходе работ. Часто бывает, что без спецификации можно обойтись. Если на старте у вас есть только приблизительное понимание что нужно от продукта, как и кто его будет использовать, что должно быть включено в продукт, а что точно стоит исключить, возможно исполнитель предложит работать не по спецификации, а использовать гибкие методологии создания продукта. В этом случае сначала разрабатывают и выпускают небольшой прототип, а затем собирают обратную связь, постоянно дополняя требования на основе собранных данных. Такой способ подходит для крупных проектов с размытыми требованиями, поскольку позволяет совместно выработать продукт, наиболее подходящий целевой аудитории.
Такая модель работы известна как Time & Material или работа по модели выделенной команды, когда за вашим проектом закрепляется команда специалистов “под ключ”, а задачи, требования и приоритеты проекта определяются и меняются итеративно.
Для каких проектов подходит выделенная команда
- Если проект находится на стадии идеи, и бизнес-процессы, функционал и окончательное видение ещё не до конца продуманы.
- Если вы хотите быстро запустить MVP интернет-магазина для проверки бизнес-гипотезы
- Если нужна поддержка и дальнейшее развитие функционала уже существующего проекта.
- Если клиент хочет быть активно вовлечен в процесс разработки, видеть прогресс, общаться с командой и проверять промежуточные результаты.
В таких случаях, лучше нанимать выделенную команду разработки. Данная форма сотрудничества предполагает гибкий подход и допускает внесение изменений в требования к проекту по ходу разработки. Команда работает по спринтам и отчитывается перед заказчиком в оговоренное время.
Совет от экспертов: Решение о выборе модели сотрудничества и необходимости написания спецификации на старте проекта зависят от ваших бизнес-идей и требований к проекту, предполагаемой сложности разработки и жизненного цикла проекта. Бизнес-анализ в рамках разработки интернет-магазина поможет уже на старте определиться с оптимальной моделью работы и значительно сократить срок подготовительной работы.
Ловушка ИИ ТЗ
Отдельная проблема последнего времени — ТЗ, полностью сгенерированные нейросетью. К нам регулярно приходят заказчики с документами на 30–50 страниц, которые “написал ИИ по запросу: “Составь детальное ТЗ для интернет-магазина / маркетплейса”. На бумаге оно выглядит солидно, но на практике такие ТЗ почти всегда:
- неконкретные — много общих фраз уровня “система должна быть удобной, быстрой и безопасной”, но нет четких сценариев “кто что делает в системе”;
- нереалистичные — в один релиз закладываются сложные интеграции, личные кабинеты для пользователей различных ролей, десятки редких функций, которые бизнесу не нужны на старте;
- очень дорогие в реализации — чтобы воплотить все, что перечислено в документе, нужен бюджет уровня Enterprise-проекта, хотя клиент ожидал MVP.
Реальный пример из практики. Один из клиентов пришел с запросом “хочу интегрировать блокчейн-модуль”, но в ТЗ, которое он показал, оказалось 42 страницы функциональности всего маркетплейса, описанной текстом и без связи между частями документа. Под каждой ролью и функцией было перечислено, “что должно быть”, но в документе отсутствовало самое главное — как эти функции работают вместе, какая часть действительно нужна, а какая — просто набор идей нейросети.
В итоге исполнителю приходится объяснять, почему реализация ИИ ТЗ выходит в разы дороже, чем ожидалось, и почему половину документа нужно убрать или переписать с нуля. Это отнимает время у заказчика и команды, и зачастую демотивирует запускать проект.
Примеры некорректных и корректных ТЗ
Как выглядит перегруженное ИИТЗ
Предприниматель хочет запустить нишевый маркетплейс для продавцов детской одежды. Он просит нейросеть: “Составь ТЗ на маркетплейс уровня Ozon” — и получает 45 страниц со списком:
- десятков отчетов и дэшбордов;
- системы рекомендаций на основе машинного обучения;
- сложных многоуровневых программ лояльности;
- гибкой ETL-системы для обмена данными с десятком внешних сервисов;
- поддержки всех возможных ролей: оператор склада, региональный менеджер, супер-администратор бренда, модератор отзывов и т.д.
Другое ТЗ, сгенерированное ИИ, перечисляет требования:
- “Настроить гибкие способы выплат продавцам” — но нигде не было указано, что именно считается “гибкими” выплатами и какие варианты нужны конкретно этому проекту.
- “Синхронизировать остатки между несколькими площадками в реальном времени” — хотя клиент не планировал работать на других площадках и не представлял, сколько стоит такая интеграция.
- “Предоставлять инсайты по эффективности продавцов на основе ключевых данных о продажах” — но не было перечислено, какие данные считаются ключевыми и какие отчеты нужны бизнесу на самом деле.
- “Оптимизировать доставку за счет интеграции с внешними логистическими операторами” — но не было указано, с какими именно операторами клиент собирается работать.
Это типичные “маркетинговые фразы” нейросети, из-за которых документ выглядит “толстым”, но непригоден для оценки сроков и бюджета.
При этом в документе нет четких пользовательских сценариев вроде:
- “Продавец регистрируется, добавляет первый товар, настраивает доставку и публикует витрину”;
- “Покупатель находит товар, кладет в корзину, оплачивает и отслеживает заказ”.
Разработчик видит перед собой не MVP, а многолетний проект.
Как не попасть в ловушку ИИ-ТЗ
Использовать нейросеть можно и даже полезно — но как помощника, а не как единственного автора ТЗ. Вместо просьбы “сделай полное ТЗ” лучше:
1. Сначала самим описать основу:
- цель проекта (что должно измениться в бизнесе через 6–12 месяцев);
- ключевые роли (покупатель, продавец, администратор);
- 5–7 главных сценариев, без которых проект не имеет смысла.
2. Попросить ИИ помочь развернуть это в структуру:
- оформить сценарии в виде списка требований;
- подсказать, какие нефункциональные требования не забыть (безопасность, скорость, масштабируемость);
- предложить варианты формулировок.
3. Отфильтровать результат через призму MVP:
- отделить “must have” от неприоритетных функций;
- убрать то, что не влияет на запуск первой версии;
- оставить только то, что команда готова реализовать в разумный срок и бюджет. Если сомневаетесь, какие временные рамки и стоимость заложить, можно попросить ИИ сделать предварительную оценку.
Какое ТЗ действительно полезно
Вместо 50-страничного “энциклопедического” документа эффективнее работает компактное ТЗ на 5–10 страниц с понятной структурой:
Краткое описание проекта (1 страница)
Цель проекта, целевая аудитория, модель монетизации.
Роли пользователей
Покупатель, продавец, администратор (и другие роли, если нужны).
Основные пользовательские сценарии (MVP)
- Регистрация и логин.
- Просмотр каталога и поиск.
- Добавление в корзину и оформление заказа.
- Управление товарами и заказами для продавца.
- Базовая отчетность для администратора.
Функциональные требования по разделам
Каталог, корзина, заказы, оплата, доставка, личные кабинеты, панель администратора. По каждому разделу — короткие и конкретные требования.
Ключевые нефункциональные требования
Скорость загрузки, предполагаемые нагрузки, требования к безопасности.
План развития
- Что войдет в первую версию (MVP).
- Что можно реализовать на последующих этапах.
Пример корркектного ТЗ
Чтобы понять, как выглядит хорошо структурированный, полезный документ, можно ориентироваться на то, как формируются бизнес-требования и функциональные требования в реальных проектах.
Например, в одном проекте:
- требования сгруппированы по типам (бизнес-требования, пользовательские истории, интеграции, права доступа);
- каждая функция связана с конкретным сценарием использования;
- интеграции описаны конкретно — с указанием поставщиков логистики, сервиса подарочных карт, условий работы API;
- роли пользователей (HR, сотрудник, администратор) имеют четкие зоны ответственности;
- будущие ограничения и особенности (например, начисление баллов) расписаны заранее.
Такой подход дает понятную картину MVP, реальных сроков и бюджета.
Пример хорошего ТЗ на разработку маркетплейса можно скачать по кнопке ниже:
Каталог продуктов и сервисов CS-Cart
- ★ CS-Cart для маркетплейсов: онлайн-демо
- ★ CS-Cart для интернет-магазинов: онлайн-демо
- ★ Мобильное приложение: App Store, Google Play
- ★ Cloud-хостинг: преимущества и условия
- ★ Сервис Заботы: чем полезен сервис
Читать далее:
- Что такое нефункциональные требования к сайту интернет-магазина
- Как оформить функциональные требования к сайту электронной коммерции?
- Сбор и формирование бизнес-требований для сайта интернет-магазина
Гаянэ
Гаянэ Тамразян — писатель и контент-маркетолог, специализирующийся на электронной коммерции. Она создает информативные и актуальные статьи, которые помогают читателям разобраться в сложностях цифровой торговли. Ее стиль написания отличается ясностью и доступностью, что делает материал понятным как для профессионалов, так и для широкой аудитории. Гаянэ стремится делиться знаниями, вдохновляя бизнес и потребителей на успешное взаимодействие в быстро меняющемся мире онлайн-торговли.
