Как собрать требования маркетинга, продаж и руководителя к одному сайту

Почему общий список пожеланий не становится заданием

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

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

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

Пожелание к функции и задача человека — разные записи

Просьба «добавить калькулятор» называет возможное решение. Прежде чем обсуждать его устройство, полезно выяснить, кому и на каком этапе не хватает расчёта: посетителю при выборе услуги, продавцу при подготовке предложения или руководителю при оценке загрузки отдела. От ответа зависит объём. Иногда достаточно объяснения состава стоимости, иногда нужны правила автоматического расчёта, а иногда — возможность приложить сведения к заявке для последующего разговора.

В руководстве GOV.UK по потребностям пользователей предлагается опираться на исследования и отделять проблему от предполагаемого способа её решения. Среди методов названы интервью, наблюдение и работа с уже накопленными сведениями, включая данные обращений в контактный центр. Мнения, полученные не от самих пользователей, рассматриваются как предположения для дальнейшего исследования. Для коммерческого сайта это полезное различие: знание внутреннего процесса отдела и знание потребностей посетителя могут опираться на разные основания.

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

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

Как сформулировать требование, которое одинаково прочитают

Удобная запись отвечает на три вопроса: кто действует, что ему нужно сделать и зачем. Такой состав приведён в руководстве GOV.UK по пользовательским историям. Критерии приёмки там описаны как результаты, по которым команда убеждается, что задача выполнена. Автор руководства допускает разные формы записи при сохранении участника, действия и цели.

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

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

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

Как разбирать противоречия между отделами

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

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

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

Другой предмет спора — материалы страницы услуги. Маркетолог отвечает за понятность предложения, специалист компании — за точность состава работ, директор — за обещания, которые компания готова выполнять. У каждого свой вклад. Редактор запрашивает технические ограничения у специалиста, а специалист объясняет их, не беря на себя окончательный выбор порядка абзацев. Такое распределение даёт каждому участнику предмет для замечаний и помогает отличить фактическую ошибку от вкусового предпочтения.

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

Что входит в первый выпуск, а что ждёт своей очереди

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

Метод MoSCoW у Agile Business Consortium делит требования на четыре группы: Must Have — обязательное, Should Have — важное, Could Have — желательное и Won’t Have this time — не включённое в текущий период. Последняя пометка относится к выбранному этапу, а не означает, что к идее никогда не вернутся. Для команды важны не английские названия, а одинаковое понимание последствий переноса.

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

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

Одна версия решений вместо нескольких цепочек переписки

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

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

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

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

Что произойдёт, если оставить противоречия подрядчику

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

До начала разработки полезнее определить, что входит в первый запуск, кто готовит содержание и по каким результатам принимается форма: эти ответы дают подрядчику основания для оценки, а компании — для приёмки. Для выбора общего назначения пригодится материал о задачах корпоративного сайта; для совместного разбора требований можно обратиться в ШТАБ ИТ.