Функциональные и бизнес-требования к сайту - что это такое и как собрать
5 мин.
Процесс создания интернет-ресурса состоит из ряда последовательных этапов. Если каждый этап регламентирован и согласован, то результат удовлетворяет заказчика максимально. При этом даже если начинать как положено с написания технического задания (ТЗ), то владельцу бизнеса не в каждом случае понятно, что получится в итоге. Регулярно также возникают ситуации, когда даже по продуктивному ТЗ в голове сохраняется собственная «картинка» результата, не соответствующая итогу.
Таким образом, чтобы результат удовлетворил клиента, а не разочаровал или потребовал переработки, начинают создание со сбора информации — бизнес-требований и планируемого функционала.
Указанные сведения помогают также в корректном планировании бюджета и временных затрат, что особенно важно, если создают масштабный интернет-магазин.
Разберем подробно, какая информация становится предварительной.
Термины и определения
В первую очередь опытные сотрудники интернет-агентств собирают требования, связанные с конкретным бизнесом заказчика.
Бизнес-требования — это описание целей и задач, для решения которых планируется интернет-ресурс. Сбор сведений производят в свободной форме, не опираясь на технические термины или веб-особенности.
К бизнес-требованиям относят:
- Полную информацию об организации.
Наименование компании, область бизнеса, бренд, товарный знак, отличительные особенности для рынка и проч. - Информация о целевой аудитории (ЦА).
Сведения опять же общие: пол, возраст, географическое положение, привычки, склонности и проч. - Цель, которая достигается за счет сайта.
Каждый тип интернет-ресурса характеризуется собственной сложностью и особенностями создания. Определив цель, станет понятней, что требуется заказчику: сайт-визитка, одностраничный лэндинг, интернет-магазин и проч.
Разобравшись с будущим сайтом с точки зрения заказчика, требования переводят в «техническое русло».
Функциональные требования — это составление списка возможностей, которые обязательны исполнению. Речь идет о конкретном внутреннем (техническом) наполнении интернет-ресурса, а не визуальной составляющей.
Набор функциональных требований регулярно определяется типом выбранного сайта. Так, если создается сайт-визитка, то описывают необычные элементы дизайна или наполнения, а для интернет-магазина — автоматически «подтягивается» пул вопросов про личный кабинет, систему отзывов и проч.
К функциональным требованиям относят описания:
- основных планируемых действий пользователей;
- логики работы ключевых элементов и блоков;
- подключаемых дополнительных возможностей и утилит и проч.
Позитивные момента сбора требований
Выше упомянули, что предварительный сбор требований упрощает будущую работу над интернет-ресурсом, но это расплывчатое и урезанное определение. Список решаемых задач шире и включает в себя:
- Облегчение взаимодействия «Заказчик — Исполнитель».
Происходит налаживание диалога даже до начала проектирования интернет-ресурса. Таким образом, исполнитель яснее понимает, чего ждет заказчик, а тот выдвигает и соглашается на логичные требования, избегая ненужных для заявленных целей элементов сайта. - Демонстрацию ключевых аспектов получаемого результата.
Уже на предварительном этапе заказчик понимает, получит ли то, что ожидает, реализуется ли основной функциональный и идейный посыл. Исполнитель же четко очерчивает круг собственных работ, что позволяет обезопасить себя от бесконечных правок и доработок сверх оговоренного функционала. - Сокращение финансовых и временных расходов.
Если изначально понятен объем работ, квалификация и количество требуемых интернет-исполнителей, то в наличии вариант составить временной и финансовый бюджет с наибольшей продуктивностью и экономией ресурсов. При этом расхождение с планом минимальное и по бюджету, и по времени. - Выявление проблемных моментов и потенциальных ошибок.
При определенном заранее функционале легче спрогнозировать, какие этапы вызовут сложности или потребуют дополнительных мощностей и ресурсов на тестирование на ошибки и недочеты. Если это просчитано заранее, то исправление облегчается на порядок. - Наличие конкретных маркеров исполнения.
Этот параметр важен в первую очередь для заказчика. Так по мере исполнения заказчик способен отслеживать исполнение конкретных бизнес- и функциональных требований. Появляется вариант заранее заметить недоработки исполнителя или потребовать доделать те или иные моменты, если заявленные требования не достигнуты.
Процесс сбора требований
Регулярно владельцы бизнеса считают, что полным сбором информации и анализом требуемых решений занимается компания-исполнитель. Ведь это профессионалы, умеющие работать по различным направлениям. Это так отчасти. Ведь никто лучше организации не понимает, что требуется и как это соотносится с имеющимися ресурсами и мощностями.
В связи с этим главным в сборе бизнес- и функциональных требований становится организация заказчика. В первую очередь информация собирается ее маркетологами или менеджерами. Ведь никто кроме них лучше не понимает конкретную специфику. Исполнитель же соотносит собственные ресурсы с желаемым, вносит логичные коррективы и приступает к исполнению.
Если у организации-заказчика нет в наличии соответствующих специалистов, то рекомендуем наладить сотрудничество с профессиональным агентством, которое умеет собирать и анализировать информацию подобного профиля. Это обойдется дешевле и быстрее, чем собственные «неумелые» попытки. В итоге экономия времени при не столь значимом расходе бюджета.
Если сбором сведений занимается одна «контора», а исполнением — иная, то рекомендуем также не бросать сотрудничество с первой, чтобы они помогли оценить, насколько исполнитель предлагает решения, соответствующие собранной информации.
В ситуациях даже если заказчик решает собирать требования самостоятельно, то профессиональное интернет-агентство помогает в этом. Например, присылает образец брифа на разработку. В него логичным образом вносится требуемая информация. Спорные или непонятные моменты обсуждаются и вписываются отдельно.
При полном непонимании заказчиком собственных «хотелок» или невозможности описать, выражают требования хотя бы в виде демонстрации желаемых аналогов. Например, указывают интернет-ресурсы конкурентов или иных компаний, где нравятся те или иные функциональные элементы. Далее эти сведения анализируются и описываются исполнителем в ТЗ и отдельно согласуются с заказчиком для устранения недопониманий.
Проблемные моменты
Главной проблемой сбора требований становится нежелание или невозможность наладить диалог между заказчиком и исполнителем. Когда заказчик стоит на своем, не желая вникать в запрашиваемую избыточную функциональность при ограниченном бюджете, или исполнитель делает «так как умеет», а не учитывает, достигается ли в этом случае заявленная цель разработки, то любая собранная информация не поможет.
В итоге пострадает и результат, и удлинится время разработки, да и перерасход бюджета не исключен.
Также при описании требований проблемой становится сохранение баланса между необходимой и излишней конкретикой. Если перегрузить ТЗ функциональными требованиями, то уйдет ощутимое время на проработку и реализацию. Это лишние затраты бюджета и времени без увеличения достижимости целей.
Заключение
Предварительный сбор функциональных и бизнес-требований упрощает процедуру работы над будущим интернет-ресурсом компании. Этот этап налаживает диалог между заказчиком и исполнителем и экономит массу ресурсов на разработку.
Тщательная проработка предварительного этапа позволяет заранее понять вариант результата. В итоге заказчик получает то, на что рассчитывает, а исполнитель — подробно оценивает требуемые физические и временные ресурсы и бюджет.
Интернет-агентство U-sl+Мирмекс начинает работу над проектами наших клиентов со сбора предварительных требований. Мы считаем, что налаживание диалога и взаимопонимания по главным моментам и целям на этом этапе — залог плодотворного и взаимовыгодного сотрудничества.
