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