Бизнес требования к сайту

Бизнес требования к сайту

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

В идеале, что хотелось бы получить PMу, – это документ, в котором заказчик описал все, что он знает о предметной области, то, как проект должен быть использован Пользователем, как бы заказчик хотел управлять проектом, показал дизайн, подумал о будущем развитии. Мечтать, как говорится, не вредно. Потому что так никогда не бывает.

Как обычно поступают требования

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

Заказчик – не программист, ТЗ писать не умеет, от него этого не требуется. Что требуется от заказчика, который пришел с заданием, – это знать свою предметную область и отвечать на вопросы для уточнения требований. Случается, что добиться ответа довольно проблематично.

Какие бывают затыки

Заказчик не в курсе или не до конца в курсе, что от него хочет работодатель/топ-менеджер, и, соответственно, не может сформулировать требования по задаче. В этом случае к разработчикам с заданием лучше не приходить, ничего хорошего в таком проекте не получится. Лучше идти в обратную сторону и получать информацию от первоисточника. Заказчик недостаточно компетентен в области разработки и стесняется излагать свои мысли простым языком. Такие сложности быстро решаются, так как задача PMа – разговорить собеседника, задать наводящие вопросы и выудить информацию. Кстати, описание требований на простом, «гражданском» языке – только приветствуется. Гораздо хуже, когда специальные термины применяются не по делу.

Почему мы не можем «сделать как-нибудь»

Если у заказчика возникают вышеописанные затыки, он предлагает сделать «как-нибудь», «на ваше усмотрение». Белые пятна в требованиях и предложения «сделать как-нибудь» – это зло. Алгоритм «как-нибудь» не напишешь, в нем все должно быть строго. Молодой разработчик, глядя на такое описание, сделает удивленные глаза, а опытный разработчик запрограммирует по-своему. В первом случае задача не будет выполнена, во втором – будет выполнена не так, как нужно бизнесу.

Как нам сделать, чтобы всем было хорошо

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

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

Требования нужно детализировать до такой степени, пока у разработчиков не останется вопросов. Конечно, они появятся в процессе кодирования, но требования мы зафиксируем именно в том состоянии, когда разработчику в первый раз стало все по ним понятно. Детализация требований – это совместная работа PMа и заказчика. Пример из жизни: первоначальные требования, поступившие от заказчика на одной странице (с двумя картинками на ней же), после уточнения превратились в 19 страниц. То есть 18 страниц информации было вытянуто получено от заказчика в процессе утверждения требований, которые были доведены до той степени детализации, которая требовалась для начала разработки.

Не нужно в требованиях проектировать архитектуру. Есть прокачанные заказчики 80 уровня, которые углубляются в тему настолько, что в требованиях начинают проектировать приложение или строить схему базы данных. Это лишнее. На стороне группы разработки всегда есть человек, который придумает архитектуру и будет за нее отвечать. А вот отвечать за навязанную им со стороны архитектуру эти люди не любят.

Не нужно усложнять. Это прекрасно, когда заказчик – опытный интеллектуал с IT-бэкграундом. Когда он способен придумать и изложить сложную логику. Как приятно с ним общаться и формулировать требования! Однако в реальности с этой сложной логикой придется работать не только аналитикам и программистам (они, как правило, способны ее понять), но и контент-менеджерам, редакторам, саппортникам, наконец. Да и не будем забывать про Пользователя, всегда ли ему нужно вникать в сложную логику нашего проекта, в перегруженный интерфейс или понятную только избранным навигацию? Есть такое правило – Упрощай (за бугром это правило известно как KISS — keep it simple stupid).

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

Приносите ваши требования, будем вместе их уточнять 🙂

Онлайн-курсы профессиональной разработки ПО

Виды требований к программному продукту

Текстовая расшифровка третьего видеоурока курса Введение в профессию аналитика.

Давайте более подробно рассмотрим виды требований, и будем при этом пользоваться классификацией Вигерса. Возможно, многие из вас уже с этой классификацией знакомы. Я для каждого вида требований приведу пример.

Вот эта картинка Вигерса, о которой я уже говорил, и на которой он перечислил различные виды требований. Эти названия уже, пожалуй, общеприняты. Большинство аналитиков их понимает, но иногда всё-таки путаются. Давайте мы по ним пройдёмся.

В курсе будет эта терминология использоваться довольно активно, потому что когда мы будем говорить о методах разработки требований, мы всегда будем подразумевать какой-то определенный вид требований в соответствии с этой классификацией.

Самый первый вид требований: бизнес-требования . Что это такое, обобщённо? Описание высокоуровневых целей организации или заказчика, достигаемых посредством разрабатываемой системы.

Я понимаю, что эти определения несколько суконным языком написаны. Но я взял их из книги Вигерса, и мы попробуем перевести их на простой человеческий язык.

Что дает описание бизнес требований? Описывает бизнес-идею , без реализации которой продукт не будет нужен потребителю. Это описание тех самых проблем и возможностей, для решения или реализации которых создается продукт.

Например, если мы разрабатываем сайт поиска авиабилетов, мы можем описать в бизнес-требованиях , какие возможности он предоставляет.

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

Авиакомпаниям дает возможность использовать дополнительный канал продаж авиабилетов. Владельцу сайта дополнительно может дать возможность продавать на сайте что-то ещё. Например, дополнительные услуги для путешественников — бронирование машин, заказ гостиниц, заказ такси и так далее.

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

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

В конечном итоге при описании требований они будут выглядеть несколько иначе. Но для того, чтобы понять, что стоит за этим видом требований, я привел такой пример. В данном случае этот перечень возможностей — бизнес-требования к сайту поиска авиабилетов.

Часто бизнес-требования путают с бизнес-правилами , потому что они начинаются со слова «бизнес». Что понимается под бизнес-правилом ? Положение, определяющее или ограничивающее какие-либо стороны бизнеса. Я не буду перечитывать то, что написано у Вигерса, а лучше сразу покажу на примерах, что за этим стоит.

Читайте так же:  Расходы на банкротство гражданина

За этим стоят, во-первых , какие-то документы, регламентирующие на уровне законов или отраслевых стандартов (или ещё каких-то стандартов) то, как должен работать наш продукт. Если, например, мы разрабатываем банковскую систему, то там есть огромное количество правил, которые генерируют Центробанки. Если говорить о России, то это наш Центральный Банк, который выпускает различные инструкции, и банковская система должны обязательно им следовать.

Это законы. Сейчас это становится более актуальным для интернет-проектов в нашей стране, потому что выпускается всё больше законов, регулирующих эту отрасль.

Это могут быть ещё какие-то общепринятые или стандартные функции и алгоритмы, которые должны быть реализованы в системе. Ну, первое что приходит в голову, — например, алгоритм расчёта НДС, который тоже является бизнес-правилом .

То есть, ещё раз, это такие требования, принятые в практике бизнеса, либо в законодательстве, либо в отрасли, которые мы в любом случае должны исполнять при реализации нашей системы.

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

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

И второй закон, который тоже был принят в этом году. Если что-то продается на сайте с использованием электронных денег или банковских карт, то к сайту должна быть подключена онлайн-касса .

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

Следующий вид требований: пользовательские требования.

Это большой класс требований. Я его, наверное, достаточно подробно описал, когда говорил о втором — пользовательском — уровне требований. Описывает конкретный способ использования продукта конечным пользователем.

Как я уже сказал, основная масса существующих методов разработки требований относится именно к этому уровню. Use Cases, User Stories, «персоны» и ещё некоторые методы, не так часто используемые. Лучше всего проработанные, концептуально завершенные, они как раз относятся к уровню взаимодействия людей с продуктом. Но это естественно, потому что продукты, в основном, до сих пор создаются для людей.

Здесь может быть очень много разных примеров. Я даже не стал их детализировать.

Например, мы можем описать пошаговый сценарий покупки авиабилета на выбранный маршрут, и сам этот сценарий, собственно, и будет формой представления пользовательских требований.

Мы можем описать требования в виде набора user stories, например, для интернет-магазина . Если я хочу выполнить покупку на сайте интернет-магазина , то мне нужно будет реализовать user stories для сравнения товаров, для добавления в корзину, для управления корзиной и оформления заказа, для онлайн-оплаты . Каждая user story имеет определенный формат, который не представлен на этом слайде.

Каждая user story — это такой единичный кусок, unit при разработке требований, обладающий своими собственными характеристиками, и разработанный по определённому методу.

Это всё примеры пользовательских требований. Их может быть ещё больше, как я говорил, но этих достаточно, я думаю, для понимания.

Атрибуты качества. Более детально мы атрибуты качества рассмотрим ещё сегодня на этом вебинаре.

Что за этим стоит? Свойство продукта, выраженное через описание характеристик, важных для пользователей или разработчиков. Тоже несколько суконное определение.

Есть понятие качества программного обеспечения или качества программного продукта. Для него есть стандарты, там есть своя теория, есть методы определения качества, его оценки, обеспечения качества. И за этим стоит множество разных точек зрения на то, как должен работать программный продукт.

Мы сегодня эти точки зрения рассмотрим на этом вебинаре, а пока три примера, которые разные точки зрения представляют.

Я снова делаю оговорку: то, что здесь написано, это не сами атрибуты качества, а то, как могут выглядеть требования, которые эти атрибуты качества представляют по отношению к создаваемому продукту.

Например, время загрузки главной страницы и карточки товара не должно превышать 3 секунд при нагрузке до 20 посетителей в минуту. Это требование отражает атрибуты качества «производительность» и «надёжность». Производительность — это время загрузки страницы, а надёжность — это какую нагрузку должен держать сайт.

База данных сайта должна устанавливаться на сервера mysql или MS SQL Server или Oracle без необходимости внесения изменений в установочные скрипты. Это, опять же, конкретное представление требования, которое отражает такой атрибут качества как «переносимость». Мы можем наш разработанный сайт устанавливать в разном окружении, и при этом должны быть реализованы эти требования, чтобы мы могли использовать разные системы баз данных.

Сайт должен быть адаптирован для мобильных устройств. Это может вам показаться спорным, но это требования тоже отражают атрибут качества. Удобство использования тоже является атрибутом качества. Сейчас он больше известен под словом «юзабилити», которое в стандарте последнем так и переведено: «удобство использования».

Эти три примера, конечно, совсем не отражают всё многообразие атрибутов качества, но мы на это многообразие сегодня ещё посмотрим. Пока для нас важно только, что стоит за этим за этим видом требований.

Я должен сказать, что книга Вигерса уже выдержала три издания, и он в каждом издании эту картинку немножко меняет. Он перемещает отдельные виды требований между разными уровнями, он иногда меняет зависимости между ними. Это нормально, и это отражает тот факт, что в общем-то все требования на самом деле связаны друг с другом. Почему я об этом вспомнил: потому что раньше бизнес-правила у него находились на втором уровне, а сейчас он их поднял наверх, на уровень бизнес-требований .

Следующий вид требований — это ограничения. Условия, которые модифицируют требование или набор требований, сужая выбор возможных решений. Обычно это внешние по отношению к системе условия или принятые ранее решения.

Мы лучше всего знаем, наверное, ограничения технические, которые часто отражаются в ТЗ, исходя из имеющихся возможностей заказчика или разработчика.

Например: сервер приложений сайта должен разрабатываться на языке Java. Почему? А потому что, например, у заказчика есть множество специалистов, которые могут эту джаву сопровождать, и все другие его сервера приложений тоже работают в этом окружении.

Или похожий пример: сайт должен устанавливаться на определенную версию операционной системы.

Это самые простые виды ограничений, бывают и более сложные. Это ограничения, которые мы должны учитывать ещё до начала разработки системы, и они сужают область возможных решений в процессе её разработки.

Внешние интерфейсы. Описание интерфейса между системой и пользователем, другой системой или оборудованием.

Этот вид требований становится все более актуальным в эпоху интернета, потому что сейчас интернет-приложения всё больше сращиваются друг с другом, находят какие-то интерфейсы для взаимодействия и, в общем, представляют всё более единую среду. Если в эпоху первых больших машин этот вид требований был не очень актуален, то сейчас он иногда даже начинает замещать и вытеснять пользовательские требования. Я говорил, что большинство систем до сих пор разрабатывается для людей, но уже появляются системы, которые разрабатываются для взаимодействия машин друг с другом. Поэтому внешние интерфейсы становятся всё более важный частью требований.

Ну например, что это может быть.

Спецификации взаимодействия с платежным агрегатором для оплаты на сайте — тоже распространённый внешний интерфейс. Если вы принимаете оплату в любом интернет-магазине , то должен быть реализован такой интерфейс взаимодействия с платежным агрегатором. Это определенная спецификация передачи данных, и она собой представляет описание внешнего интерфейса.

Ещё пример: протокол взаимодействия с сервером транспортной компании для резервирования и оплаты билетов. Уже приведенный пример для авиакомпаний: единая точка для возможности сравнить и купить билеты разных авиакомпаний. Для такого сервиса очень важными тоже являются внешние интерфейсы взаимодействия с разными внешними сервисами резервирования и оплаты билетов.

Системные требования — это самый запутанный вид требований у Вигерса. Он, по-моему , пишет, что тоже взял его из каких-то других документов. В книге системные требования упоминаются только в самом начале и в одной из глав книги, посвященной архитектуре. Поэтому в результате под системными требованиями люди понимают всё, что угодно.

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

Я знаю, что во многих компаниях термин «системные требования» используется для всего третьего уровня требований. Практически все знают, что такое бизнес-требования , что такое пользовательские требования тоже все прекрасно понимают. А вот на этом (третьем) уровне я предлагаю использовать термин «требования к реализации», Вигерс предлагает использовать термин «функциональные требования», но я знаю несколько компаний, где для обозначения этого всего использовуют термин «системные требования».

Читайте так же:  Басистов алексей адвокат

Но, тем не менее, если мы придерживаемся терминологии Вигерса, то можно привести такие примеры системных требований, то есть именно требований к системе, состоящей из нескольких подсистем.

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

Функциональные требования. Я говорил, что мне не нравится называть так целый уровень требований именно потому, что в этом случае он перемешивается вот с этим видом требований, и получается некоторая путаница.

На самом деле, в это яйцо на картинке Вигерса включается всё, что не попало в остальные виды требований. Это описание требований к системе в разнообразных форматах, которые, собственно, описывают, как она должна функционировать.

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

Давайте пока просто на примеры посмотрим. Но эти примеры, наверное, не отражают и на пять процентов (а может быть, и на один процент) всё разнообразие методов представления этих требований, потому что они очень сильно зависят от разрабатываемой системы.

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

Ещё пример: операции оплаты со счёта должны быть доступны только с использованием двухфакторной авторизации. Тоже функциональное требование, которая ограничивает нас в реализации разных видов операций работы со счётом в интернет-банке .

Может быть, это не самые лучшие примеры. Я честно признаюсь, что я очень долго думал над этим слайдом, но у меня просто мысль растекается, потому что, как я уже говорил, большинство требований, которые не укладываются в другие виды требований, можно назвать функциональными. Как правило, технические задания или спецификации требований состоят из множества предложений, каждое из которых можно отнести к функциональным требованиям.

Давайте мы на этом закончим обзор видов требований. Это такой очень верхнеуровневый обзор, который даёт только, собственно, определения. Так, чтобы в рамках курса, когда мы будем говорить о бизнес-правилах , вы их не путали с бизнес-требованиями , или чтобы вы понимали, чем пользовательские требования отличается до внешних интерфейсов. В общем, эта часть просто задаёт определенную терминологию.

Бизнес-требования проекта. Часть 1

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

  • Общие потребности, которые нужно удовлетворить.
  • Направление процесса проектирования. Пока без детализации.
  • Самостоятельные элементы. Их можно независимо отслеживать и ранжировать.

Чтобы составить сводный список требований, выполните следующие указания или ответьте на вопросы:

  1. Какие есть представления о текущем состоянии проекта?
  2. Соберите идеи, проясните потребности потенциальных и текущих пользователей.
  3. Превратите готовые идеи в требования.
  4. Расставьте приоритеты. Опирайтесь на цели проекта.

Анализ текущей ситуации

О текущем состоянии можно многое узнать из разговора с заинтересованной стороной.

Эвристический анализ – метод на основе практического опыта. Им оценивают юзабилити текущего пользовательского интерфейса. Его используют для переработки текущей версии и анализа конкурентных сайтов. Результат работы — документ, который описывает недостатки, достоинства сайта и пути улучшения.

Эвристический анализ проводят и как недорогой способ обратной связи. Но он не может заменить полноценный сбор данных.

Что нужно для эвристического анализа?

  1. Собрать общие сведения о проекте. Что нужно учесть, какие существуют цели, какова квалификация пользователей?
  2. Выбрать эвристические правила. Но не очень много, иначе это создаст неудобства для читателя и вас. Списков и систем придумали немало, поэтому вы всегда найдете что-то свое.
  3. Проанализируйте важные участки сайта, выделите области, которые хорошо выполняются или наоборот. Распределите их следующим образом:
    • Суть. Короткая формулировка, обобщает полученные данные. Пронумеруйте все наблюдения.
    • Краткое описание. Пара абзацев с описанием наблюдений. Например, о месте, где нашли проблему.
    • Серьезность. Насколько эта проблема опасна. Высокая степень – потеря информации пользователя. Средняя – раздражение и ошибки.
    • Рекомендации. Шаги и идеи, которые направлены на обнаружение проблем.
  4. Представить результат проектной команде и заказчикам.

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

Как собирать информацию у заказчика?

Сбор идей – это превращение их в требования. Если рабочий процесс недостаточно структурирован, он станет тратой времени и приведет к неверным шагам.

Эффективная организация включает в себя:

  1. Подготовку плана встреч.
  2. Распределение ролей и обязанностей.
  3. Правильный подбор для консультаций людей со стороны заказчика.
  4. Эффективные встречи.
  • Ключевые представители – люди из компании, которые заинтересованы в успехе проекта. Они подключаются в самых важных точках. На постоянной основе не работают.
  • Спонсор – ключевой представитель бизнеса. Несет прямую ответственность за успех проекта. Принимает активное участие в сборе требований.
  • Проектная команда – люди для работы над проектом.

Задайте последней группе вопросы, который помогут вам:

  1. Кто несет ответственность за привлечение людей из бизнеса?
  2. Кто проводит встречи?
  3. Кто ведет заметки?
  4. Кто выступает первым?
  5. Кто из разработчиков участвует на встрече?

10 лет работаем с лидерами рынков и молодыми амбициозными компаниями

— Реализуем любой сервис с нетипичным функционалом;

— Переезды на Битрикс, интеграции со всем на свете;

— Налаженная система менеджмента: четкое соблюдение дедлайнов и ТЗ

Бизнес требования к сайту

Базовый бизнес-процесс по созданию клиентского сайта в нашей компании выглядит следующим образом:

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

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

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

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

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

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

  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. Форма отправки резюме имеет следующий вид…
Читайте так же:  Специальный приказ 191