Как стать автором
Обновить

Технология сбора требований в процессе проектирования сайта

Время на прочтение10 мин
Количество просмотров46K

Вступление


Сбор требований – это один из самых важных этапов при создании информационных систем и интернет-сайтов в частности. От того, насколько точно и полно будут учтены все пожелания заказчика в процессе проектирования сайта, и будет зависеть итоговый результат: получим ли мы сайт «для галочки» или это будет эффективный инструмент бизнеса, который будет приносить прибыль своему владельцу.
Предлагаемая методика сбора требований используется в нашей компании при разработке несложных клиентских сайтов, реализуемых по каскадной модели (Waterfall). Методика позволяет менеджеру по продажам организовать эффективный сбор требований и написать на его основе «Техническое задание», по которому разработчик будет создавать сайт.
Замечу, что ничего не мешает использовать данную методику сбора требований и в Agile–разработке, в частности, для создания первичного бэклога.
В данной статье я концентрировался именно на содержательной части сбора требований, а не на вопросах внедрения сбора требований в бизнес-процессы компании или на то, как строить диалог с клиентом – это тема для отдельного разговора.

Классификация требований


В нашей компании принята следующая терминология в отношении требований:
  1. Бизнес-требования
    Требования самого высокого уровня, которые определяют цель создания сайта и задачи, которые необходимо выполнить для достижения цели. Бизнес-требования определяются следующей метафорой: «Сайт как инструмент бизнеса, как его часть. Сайт – как лицо компании, как инструмент продаж и развития бизнеса».
  2. Требования участников проекта
    Требования, которые определяют, как представители компании-заказчика будут взаимодействовать с сайтом, что им нужно от сайта. Метафора: «Сайт как неотъемлемая часть бизнес-процессов в компании. Сайт как помощник сотрудникам».
  3. Требования внешних пользователей
    Требования, которые определяют, как внешние пользователи будут взаимодействовать с сайтом, и что им может потребоваться как посетителям ресурса и потенциальным клиентам компании. Метафора: «Сайт как инструмент продаж товаров и услуг компании через Интернет».

Бизнес-процесс по созданию клиентского сайта


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

Схематично бизнес-процесс выглядит следующим образом:

image

Теперь более подробно рассмотрим, как осуществляет сбор требований на всех этапах работы.

Бизнес-требования


При сборе бизнес-требований определяется окружение сайта (см. рисунок) и анализируется, как данное окружение может использовать сайт и соответственно, какой функционал и информация должны быть представлены на сайте.
Например, бизнес заказчика крупный и постоянно привлекаются инвесторы для финансирования проектов. Соответственно, должен быть раздел на сайте с информацией о проектах компании, о формате возможного участия инвесторов и т.п.
Случай из жизни. В ходе сбора бизнес-требований для сайта клиники красоты мы задумались, а что может быть нужно органам власти от сайта. Ответ не заставил себя долго ждать – необходимым оказалось размещение на сайте лицензий на оказываемые услуги.
Заметим, что требования сотрудников компании к сайту – это требования участников проекта, они будут рассмотрены в отдельной главе.
image

При проектировании с учетом бизнес-требований:
  • Заказчик начинает фокусироваться на важных вопросах, касающихся целей и задач сайта, а не на том, «что на сайте будет в левом меню». Повышается мотивация и желание сделать хороший продукт.
  • Большинство важных требований, которые не лежат на поверхности, выявляются в ходе последовательного прохода по внешнему окружению будущего сайта. Например: «…да, партнерам было бы хорошо предоставить личный кабинет…», «…далее сайт будет продвигаться и seo-специалистам необходимо следующее…», «…компания крупная и нужен хороший раздел с вакансиями…» и т.д.

Требования участников проекта


— это требования сотрудников компании к сайту.
После сбора бизнес-требований необходимо уделить время анализу требований сотрудников компании к сайту. Если клиент уже на встрече может предоставить список таких требований – это замечательно, однако не стоит останавливаться на этом. Важно продолжить диалог и попросить клиента рассказать о бизнес-процессах внутри организации, которой мы делаем сайт.
Важно на встрече не столько придумать все варианты использования сайта сотрудниками, а сколько понять и запомнить бизнес-процессы, а также функциональные обязанности работников, чтобы потом в офисе, в спокойной обстановке поразмыслить над тем, каким образом сайт может помочь сотрудникам.
Основной момент, который стоит подробнее изучить на встрече, – взаимодействие менеджера по продажам с клиентом и какую роль в этом взаимодействии должен играть сайт. Рассмотрим некоторые варианты практического применения сайта менеджером:
  1. Сайт может помогать менеджеру при непосредственном общении с клиентом – например, менеджер с экрана компьютера демонстрирует клиенту продукцию или услуги компании.
  2. Менеджер «конструирует» что-то на сайте, например, выбирает для клиента тур в Турцию или рассчитывает стоимость полиса ОСАГО. Частный пример – «конструктор кухонь» на сайте компании Ikea.
  3. Менеджер часто выезжает на встречу с клиентом на местах и с планшетного компьютера демонстрирует продукцию, представленную на сайте – (для себя мы сразу делаем пометку, что будет важна мобильная версия сайта и интерфейс работы с устройствами с сенсорным экраном).
  4. Сайт служит для сопровождения клиентов в процессе продажи товара и после. Это такие действия как: всевозможные консультации, отслеживание статуса заявки на покупку товара, обмен файлами, техническая поддержка.
  5. Во многих случаях менеджеру приходится давать подробные консультации клиентам, и в этом случае на помощь может прийти сайт, где в специальном разделе можно будет разместить справочную информацию. Частный случай: раздел FAQ, где можно посмотреть ответы на основные вопросы и задать свой.

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

Пример из жизни.
В нашу компанию обратился клиент, занимающий оптовой продажей мебельных комплектующих: гайки, стяжки, винты и т.п. Как правило, обычный человек не понимает всей специфики данного вида бизнеса. Поэтому в ходе диалога наш менеджер попросил клиента описать процесс продажи товара подробнее.
Как оказалось, этот процесс очень прост: сначала потенциальный покупатель выбирает через электронные каталоги в формате .pdf товары нужного артикула и в определенном количестве. Далее он звонит в компанию и озвучивает свой заказ менеджеру. Менеджер принимает заявку и ищет требуемый товар у поставщиков. После того, как с поставщиками достигнута договоренность, менеджер связывается с клиентом и озвучивает ему общую стоимость заказа. Как правило, далее следует торг и согласование финальной стоимости.
В данной ситуации, как мы видим, основная работа лежит на менеджере и его действия нельзя заменить каким-либо функционалом на сайте. В связи с эти было принято простое решение: на сайте организуется витрина товаров (все товары переносятся из электронных каталогов на сайт), покупатель выбирает требуемые товары, точно задает их параметры (размеры, материал покрытия, цвет) и количество и далее простым нажатие кнопки отправляет заявку менеджеру.
Вывод из этого примера достаточно простой: не домысливайте за клиента, а просто просите его подробно рассказать о своей работе.

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

Варианты потенциальных требований со стороны участников могут быть такими:
  1. Требования директора по персоналу:
    a. «Управление вакансиями на сайте сделать по аналогии с сайтом SuperJob».
    b. «Создать внутрикорпоративный портал и базу знаний».
    c. «Создать личные странички сотрудников».
    d. «Создать возможность проведения вебинаров для сотрудников через сайт».
  2. Требования директора по рекламе, маркетолога:
    a. «Создать удобное управление баннерной системой – как для показа своих баннеров, так и чужих».
    b. «Сделать возможность выгрузки данных о товарах и услугах».
    c. «Создать функционал проведения опросов через сайт».
    d. «Создать возможность комментирования и обсуждения товара на сайте».
    e. «Организовать кросспостинг материала в социальные сети».
    f. «Создать рейтинги товаров».
  3. Требования администратора сайта:
    a. «Создать возможность одновременной работы нескольких человек в административном разделе».
    b. «Создать функционал автоматического архивирования сайта».
    c. «Создать возможность разграничения прав доступа для редакторов сайта».
  4. Пиар-менеджер:
    a. «Необходимо использовать фирменный стиль в дизайне, подчеркивать бренд».
    b. «Создать функционал «рассылки», «форум», разместить виджеты социальных сетей».
    c. «Создать определённые промо-страницы, промо-блоки, аудио-видео, flash».
  5. Бизнес-аналитик:
    «Осуществить специальную настройку процесса формирования и отправки заказа, чтобы появилась возможность оценивать конверсию посетителей в покупателей».
  6. Юрист:
    «Создать раздел для публикации документов, требующих публичного оглашения».
  7. Представитель службы логистики:
    «Создать раздел с подробными картами складов».

Определение целевых групп посетителей и сценарии использования


После того, как были определены бизнес-требования и требования участников проекта, начиная с базовых: «Я как собственник бизнеса хочу начать реализацию товаров и услуг компании через интернет» и заканчивая второстепенными, менеджер нашей компании упорядочивает всю информацию и формирует на ее основе описание основных функциональных модулей будущего сайта.
После согласования с клиентом функционала сайта и бюджета проекта менеджер определяет целевые группы посетителей сайта.
Типичными целевыми группами являются:
  1. Покупатели
    a. Первичные.
    b. Вторичные.
    c. Не определившиеся.
    d. Постоянные.
  2. Соискатели работы.
  3. СМИ.
  4. Партнеры.
  5. Инвесторы.

Далее определяются сценарии использования сайта посетителями. Такими сценариями могут быть:
  1. Для покупателей:
    a. Для первичных: покупка товара, ознакомление с ценами, сравнение товара, получений консультаций.
    b. Для вторичных: повторный заказ товара, получение скидки.
    c. Для не определившихся: поиск товара, участие в акциях, связь с компанией.
    d. Для постоянных: покупка одних и тех же товаров, использование скидок, техподдержка.
  2. Соискатели работы: поиск вакансий, отправка резюме.
  3. СМИ: импорт новостей, импорт графической информации.
  4. Партнеры: авторизация на сайте, загрузка прайс-листа, чат с персональным менеджером.
  5. Инвесторы: информация об акциях компании, графики котировок.

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

Техническое задание


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

Техническое задание состоит из следующих блоков:
  1. Подробные сценарии использования со стороны заказчика (как представители заказчика взаимодействует с сайтом, например, как менеджер обслуживает через сайт заявки, как менеджер по персоналу публикует вакансии и прочее).
  2. Описание структуры элементов и набор полей в административной части сайта.
  3. Структура сайта и навигация по нему (разделы сайта, порядок расположения элементов на типовых страницах).
  4. Сценарии использования основного функционала (как пользователь может отправить заявку, что получит в ответ, как пользователь использует поиск по сайту и прочее).
  5. Описание функционала основных модулей
  6. Компоновка элементов, дизайн (описываются все требования к дизайну)
  7. Описание работы отдельных сервисов (например, использование калькулятора ОСАГО)

Более подробно останавливаться на написании технического задания я не буду, однако приведу пример того, как требование заказчика в итоге было отражено в техническом задании.

  1. Представитель клиента озвучил следующее требование: «Хочу удобную систему публикации и представления вакансий на сайте, чтобы было удобно создавать новые вакансии, доставать из архива и активировать старые».
  2. После беседы с клиентом помимо прочего менеджер выделил функционал «Вакансии», который учел при оценке общей стоимости создания сайта.
  3. Далее менеджер определил целевые группы: «Соискатели работы» — со стороны посетителей сайта и «HR-менеджер» со стороны участников проекта.
  4. В итоговом техническом задании изначальное требование приобрело следующий вид:
    a. В административном разделе сайта имеется возможность создавать новые вакансии на основе шаблонов, содержащих следующий набор полей: должность/требования/обязанности/зарплата/…
    b. Администратор сайта имеет возможность изменить базовый шаблон или создать новый. Соответственно при публикации вакансии имеется возможность выбрать соответствующий шаблон из имеющихся и создать на его основе вакансию.
    c. Раздел «Вакансии» расположен в основном разделе «О компании».
    d. Список вакансий на странице «Вакансии» имеет табличный вид. Используются поля: «Должность», «Зарплата».
    e. При переходе на конкретную вакансию пользователь видит следующее (см. эскиз дизайна).
    f. На странице конкретной вакансии пользователь может отправить резюме, которое придет на определенный электронный адрес, а также сохранится в базе данных.
    g. Форма отправки резюме имеет следующий вид…


Заключение


После того, как менеджеры нашей компании были обучены вести сбор требований по данной технологии, эффективность реализованных в компании сайтов стала выше. Сайты стали приносить больше пользы как сотрудникам компании клиента, так и посетителям.
А все от того, что мы сами начали лучше понимать заказчика, мы начали строить с ним более содержательные диалоги и более полно собирать требования и учитывать их при проектировании сайта.
Раньше менеджер в основном лишь слушал сумбурную речь заказчика о том, как тот видит главную страницу сайта, и что «нужно звездочками показывать рейтинг товара». Сейчас же менеджер целенаправленно обсуждает с клиентом все аспекты создания сайта, начиная с цели, ради которой создается сайт, и заканчивая описанием использования сайта потенциальными посетителями, а также сотрудниками компании.
Надеюсь, и вам данный материал поможет в процессе работы с заказчиком при разработке сайта.
Теги:
Хабы:
Всего голосов 9: ↑8 и ↓1+7
Комментарии9

Публикации

Истории

Ближайшие события

2 – 18 декабря
Yandex DataLens Festival 2024
МоскваОнлайн
11 – 13 декабря
Международная конференция по AI/ML «AI Journey»
МоскваОнлайн
25 – 26 апреля
IT-конференция Merge Tatarstan 2025
Казань