В этой статье мы рассмотрим важность спецификации при разработке программного обеспечения и особенности ее составления для eCommerce-проектов.
На первый взгляд может показаться, что спецификация не нужна и не стоит времени, потраченного на ее составление. Некоторые разработчики и их клиенты отказываются от надлежащей документации. Но это ошибка.
Давайте начнем с небольшого объяснения того, что такое спецификация с точки зрения разработки программного обеспечения.
Зачем нужна спецификация программного обеспечения
Спецификация программного обеспечения позволяет зафиксировать детальные требования к разработке, указать роли и ответственности сторон, сроки и стоимость реализации. Так вы сможете четко понимать, что и когда будет реализовано, и, в случае, разногласий, иметь письменное подтверждение договоренностей.
Чем Спецификация отличается от Технического задания (ТЗ)
Мы не составляем технического задания, поскольку этот документ предполагает подготовку по стандартам (таких как ГОСТ 34, IEEE 29148-2011, Rational Unified Process и другие), усложняющих и удоражающих процесс производства конечной услуги.
Вместо ТЗ, обычно мы составляем спецификацию, документ в более свободной форме, который отвечает внутренним стандартам требований к содержимому. Так происходит потому, что мы общаемся непосредственно с владельцами бизнеса, и чтобы не перегружать их техническими деталями и сложностями классического ТЗ и не удорожать разработку за счет высокой стоимости разработки ТЗ, мы используем спецификации.
Чем спецификация отличается от брифа
Спецификация (как и ТЗ) — это детальное описание требований к работе, тогда как бриф — это опросник. Мы отправляем брифы клиентам, чтобы выяснить общие требования и пожелания. Такие опросники помогают понять, что хочет клиент. Пример брифа на дизайн может включать такие вопросы как:
- Есть ли фирменный логотип, брендбук?
- Укажите сайты, которые вам нравится и элементы дизайна, на которые нам следует обратить внимание.
- Что недопустимо на сайте?
- Опишите требования к дизайну:
- На базе готового решения (шаблон/тема)
- Персонализация готового шаблона/темы (изменения цветовой гаммы/иконок/шрифтов под ваш стиль)
- Индивидуальный дизайн (разработка уникального дизайна)
Бриф не является документом закрепления договоренностей, но может предварять спецификацию для выяснения требований заказчика и дальнейшего составления задания.
Кто и когда составляет спецификацию ПО
В действительности, нет правильного ответа на этот вопрос. Как заказчик, так и исполнитель могут составлять спецификацию ПО. Часто, — это совместная работа.Все зависит от конкретной ситуации и условий.
Составляет Заказчик
В таком случае исполнитель получает детальное разъяснение того, что нужно сделать и, если задание понятно, указывает стоимость и срок работ. Тем не менее, часто составитель не ясно представляет себе, что хочет получить в результате работ, из-за чего спецификация на разработку получается размытой и непонятной.
Наши специалисты сами соберут требования. Вы получите точное описание всех разделов магазина и карту реализации проекта с указанием этапов и сроков выполнения работ.
Составляет Исполнитель
Исполнитель, составляющий спецификацию, собирает требования к задаче, определяет цель работы и пользу для заказчика. Далее проходит устное или письменное интервью, где стороны задают уточняющие вопросы и выясняют остальные требования. Только после этих шагов, спецификация составляется и согласовывается с заказчиком. Данный способ основан на доверии заказчика исполнителю. Поэтому так важно выбрать добросовестного подрядчика с самого начала. Все же, при этом подходе от заказчика также требуется активное участие, потом что только он знает особенности своего бизнеса, которые нужно будет учесть в работе.
Совместное составление
Совместное составление спецификации начинается с обращения заказчика, который озвучивает исполнителю требования относительно предстоящей работы. Исполнитель, в свою очередь, предлагает способ, как улучшить проект. Стороны вносят правки в конечную спецификацию продукта и согласовывают ее. Этот способ, как и предыдущий, основан на доверии сторон и профессионализме подрядчика.
Что указывается в спецификации проекта
Обычный сценарий, когда исполнитель задает вопросы, уточняет детали и структурирует информацию. Заказчик излагает, что требуется от продукта.
Как мы составляем спецификацию в Simtech Development
В титульной части указываем наименование работы, проект, для которого выполняется работа, дату составления спецификации, версию спецификации, используемый стек технологий и его характеристики (например, название и версия платформы)
В основной части описываются технические детали: что будет сделано, и какие у проекта есть ограничения.
Третий раздел освещает то, каким образом будет проходить тестирование, для каких систем и браузеров разрабатывается модификация, какие домены и версии платформ участвуют.
Четвертый раздел описывает способы коммуникации с заказчиком. Здесь указываются возможные каналы для общения, а также удобное время.
Далее обсуждается то, каким образом происходит приемка и передача выполненной работы. Как правило, это сначала демонстрация на тестовом магазине с последующим переносом на живой сайт.
В заключении указываются сроки и стоимость работ.
Подробнее о ходе проектирования и составления спецификации (с примером) вы можете узнать, скачав презентацию.
Когда спецификация не нужна
Часто бывает, что без спецификации можно обойтись. Поэтому, рациональнее всего начинать работу с описания общего понимания задачи:
- Что нужно от продукта
- Как и кто его будет использовать
- Что должно быть включено в продукт, а что, наоборот, точно стоит исключить.
С этим пониманием вы обращаетесь к подрядчику. Возможно, исполнитель предложит работать не по спецификации, а использовать гибкие методологии создания продукта. В этом случае, сначала разрабатывают и выпускают небольшой прототип, а затем собирают обратную связь, постоянно дополняя требования на основе собранных данных. Такой способ подходит для крупных проектов с размытыми требованиями, поскольку позволяет совместно выработать продукт, наиболее подходящий целевой аудитории.
Вот слова руководителя группы программистов Александра по поводу сложностей работы над новым проектом:
Для того, чтобы начать делать “кастому” - нужно четко понять, что мы хотим получить на выходе. Могут возникнуть разные ситуации, в зависимости от того, с чем пришел клиент: абстрактной бизнес-идеей, или четкой спецификацией. Когда у сторон нет четкого понимания, как будет выглядеть итоговый проект, требуется проектирование - мы анализируем бизнес-требования, после чего проектируем разделы сайта и подробно описываем функционал. Понимание бизнес-идеи клиента для нас критично, от этого зависит итоговый продукт и процесс его разработки
В нашей компании, гибкий подход к разработке реализуется выделенной командой разработчиков через услугу Проектирование. Команда работает по спринтам и отчитывается перед заказчиком в оговоренное время.
