Инструкция по общению с заказчиками

Советы до начала коммуникации

Наше мнение – если проект хоть немного отличается от типовых задач с максимально шаблонным исполнением, не стоит использовать брифы для коммуникации. Только личное общение!

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

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

Общая структура переговоров

Icebreaking. "Ломаем лёд в общении с клиентом". Знакомимся, получаем всю доступную информацию. Примечание! Если есть возможность узнать что-либо о человеке, с которым ведём переговоры, и о компании – обязательно узнаём. Хобби, различные интересы, публикации, достижения и т.д. Вдвойне круто, если ваши хобби совпадают. Сделай комплимент, выкажи заинтересованность каким-либо фактом из жизни, сошлись на публикацию или достижение. Каждый заказчик имеет свой опыт общения с исполнителями, и он далеко не всегда позитивный. Грамотная подготовка откроет "скрытые ветки" в диалоге и позволит быстрее и проще пройти первый этап. Заинтересованность должна быть искренней!
Рассказываем о себе. На данном этапе даем понять клиенту кто мы и что можем. Данный этап требуется для получения ответа на вопрос "подходим ли мы друг другу?".
Узнаем проект. Изучаем с чем пришел клиент. Какая у него "боль". Какие цели и задачи он видит и т.д. Самый долгий этап общения. Задача: досконально узнать все о проекте. Понять, что клиент хочет получить на выходе и каким образом. Больше деталей в разделах "Ключевые вопросы по проекту" и "Общие вопросы по проекту".
Финальная стадия. Обсуждается дальнейшее общение и подготовка КП, договора, ТЗ и прочего. Отношения выходят на официальный уровень. Молодцы!

Важно! Цель первого контакта – не продать свои услуги, а определить является ли клиент "вашим" и, если да, то представиться таким образом, чтобы он сам захотел сотрудничать. Если так произойдёт, даже если сделка "не выгорит", с большой вероятностью он вернётся позже или порекомендует другим.

Ключевые внутренние вопросы

В процессе диалога необходимо ответить себе на следующие вопросы:

Кто с нами говорит, и является ли он ЛПР?

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

На одном ли языке мы говорим?

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

Ключевые вопросы по проекту

3 главных вопроса, без которых остальные просто не имеют смысла.

"С нуля" или переработка? Два самых крупных сценария, от которых толкаемся дальше.

Если проект существует – изучаем, обсуждаем с клиентом, запрашиваем все метрики и имеющуюся статистику;
Если предстоит реализовывать проект "с нуля" – собираем референсы с клиента, подбираем сами. На следующую встречу можно подготовить полноценный мудборд (набор фотографий, иллюстраций, паттернов, слоганов, шрифтов и цветовых схем для представления будущего стиля проекта).

Какие цели и задачи у проекта?

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

Как правило, у проекта есть одна глобальная бизнесовая цель/задача, по которой определяется тип проекта. Всё остальное является подзадачами.

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

Какие существуют технические ограничения?

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

Общие вопросы по проекту

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

Целевая аудитория проекта;
Референсы от клиента;
Основные сценарии взаимодействия;
Список разделов;
География;
Язык;
Юридическая обвязка;
Точки входа;
Устройства;

Пояснения к пунктам – ниже.

Целевая аудитория проекта

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

Референсы

Вместо того, чтобы слушать долгое описание пожеланий клиента, проще попросить собрать примеры. Они могут быть:

Функциональными – демонстрирующими те или иные возможности безотносительно визуального оформления;
Визуальными – демонстрирующими стилистику, визуальные элементы безотносительно функциональности;

Если никаких примеров нет, собираем мудборд на наше усмотрение, либо совместно с заказчиком ищем в интернете.

Основные сценарии взаимодействия

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

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

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

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

Как описано выше, если проект новый – придётся моделировать и придумывать сценарии на основе оффлайн бизнес-процессов и собственного опыта в данной сфере.

Если ты или твои специалисты не обладают достаточными компетенциями, советую взять подготовку "на дом" и изучить инструмент CJM и методологию JTBD. В интернете есть куча материалов на эти темы.

Список разделов

Требуется уточнить список необходимых разделов сайта/приложения. Как правило, клиент сам делится своими соображениями касательно структуры, тогда наша задача – привести всё в порядок. Либо придётся разработать структуру с нуля.

География

Зная географию аудитории, мы сможем ответить на такие важные вопросы касательно функционала как:

Потребуется ли определение региона;
Влияет ли выбор региона на цену/контент/сроки/документы;

Язык

Здесь множество нюансов, определяющих функциональные требования:

Потребуется ли выбор языков;
Потребуется ли "словарь" в админ панели;
Длина текста на call-to-action кнопках, контроллерах, навигации и т.д.;
Зеркальные интерфейсы (например, иврит);

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

Если же в проекте один язык – не стоит на будущее продумывать какие-то универсальные варианты. Используем основной контекст и язык по-максимуму.

Юридическая обвязка

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

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

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

Точки входа

Откуда и куда приходит трафик. Зная источники и пункты назначения, мы определим приоритеты при проектировании проекта. Данный вопрос снимается, если есть данные аналитики.

Устройства

Будет/есть много мобильного трафика? Обязательно нужен адаптив или мобильная версия;
Делаем панель для внутреннего использования в компании с доступами только к стационарным ПК? Значит отлаживаем десктопную версию под мониторы в офисах и всё такое;

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

Специфика проектов

Глобально, можно выделить следующие основные группы проектов:

Посадочные страницы, визитки, корпоративные сайты;
E-commerce, b2b/b2c-маркетплейсы;
Мобильные приложения;
Различные парсерсы, роботы и т.д.;
CRM, ERP и подобные сервисы управления чем-либо;
СМИ, социальные сети;
Различные специфические сервисы и проекты со своими моделями;

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

Под какие платформы разрабатываем, в какие магазины заходим? От этого зависят объём разработки, ограничения в реализации, скорость реализации, наличие согласованных аккаунтов, другие юридические документы и т.д.;
Модель монетизации? SaaS, Freemium и еще большое число возможных моделей (можно написать отдельную статью). Это сильно влияет на путь пользователя, но, в зависимости от выбранной модели, позволяет сократить количество возможных вариантов. Сюда же входят вопросы по методам оплаты, способам активации/привязки карты и т.п.;
Нужны ли пуши? Если да, выясняем какие типы: системные, промо, триггерные? В зависимости от типов появляется еще и внутренняя CRM с управлением пушами или созданием триггеров для них. Либо понадобится искать готовое решение подходящее именно под мобильные приложения;
Аналитика и управление пользователями? Проект в проекте, где еще разрабатывается внутренняя админка, со своей авторизацией, правами и т.д.
Внутри есть раздел со статьями или динамическим контентом? И вот мы снова расширяем функционал будущей внутренней CRM;

И это просто базовые вещи. Вопросов может быть ещё много. Например, "а нужна ли горизонтальная версия?" или "нужен ли адаптив под планшеты?".

Но помните! При общении с заказчиком не нужно задавать вопросы, в которых, вы точно знаете, он не разбирается. Отдельно составьте драфт/схему и уже на ней детально согласуйте каждый пункт.

Определение сложности проекта

По сложности составления основного ТЗ можно понять и сложность предстоящего проекта:

Проект простой, если мы можем выдать ТЗ почти сразу же после первых переговоров;
Проект средний, если для ТЗ нам понадобится еще 1-2 раунда переговоров;
Проект тяжелый, если для составления ТЗ нам придется делать крайне кропотливую работу с немалым количеством встреч и аналитики;

И тут мы сразу:

Оцениваем сколько ресурсов это займет у нас как у исполнителя. Прикидываем, есть ли такие ресурсы в моменте, дополнительную стоимость и т.д.;
Синхронизируем клиента по времени, которое ему необходимо выделить в будущем и даём понять, насколько это быстрый/долгий процесс;

Формат работы и финальная стадия

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

Самыми распространёнными форматами работы являются:

Постоплата или предоплата + постоплата. Формат, на наш взгляд, подходит только под супер шаблонные работы, где отработан алгоритм и всё поставлено на поток. Для сложных проектов можно дописывать условия и кучу определений насчёт доработок в договоре, но это сильно усложнит коммуникацию;
Поэтапная оплата. Неплохой формат. С доработками подходит практически подо всё. Основное требование, чётко обсудить сами этапы и рассчитать стоимость. Рисков меньше чем в пункте 1 в связи с дроблением проекта на этапы, но суть риска остаётся той же самой: любое разногласие по поводу этапа, его доработок и т.д. может привести к денежным и временным потерям;
Time and Material или "Время и материалы". Формат, при котором заказчик оплачивает затраченное на работу время. Идеальный вариант для любых нестандартных разработок. Плюс в довольно большой свободе действий без дополнительной юридической волокиты. Минус в том, что в России не все понимают данный формат и изначально часто отказываются. Необходимо объяснять, что это не работает так, что команда бездельничает весь месяц, затем накручивает часы и получает миллионы за "воздух". Отдельно про формат можно почитать на просторах интернета. Материалов много.

Определяем формат и заключаем договор. Поздравляю, вы официально получили новый проект. Дело за малым – реализовать!

Из опыта

Пунктов много, вопросов много. Необходимо найти баланс между перегрузкой вопросами и, как следствие, потерей заказчика и боязнью задавать вопросы лишь бы его не потерять. Заказчику нужно объяснить, что магии не бывает. Потребуется его участие, если он хочет, чтобы проект был сделан качественно. Потому что невозможно залезть к нему в голову и вытащить видение и необходимую информацию. Объяснить, что сделав это сейчас, на старте, он сэкономит кучу денег и времени в будущем. И даже если с вами не сложится, у него будет готовый план для передачи кому-либо другому.
Кто-то из умных программистов/тех.директоров некоторое время назад разработал следующий метод оценки сроков нетривиальных задач: узнаём оценку разработчика –> умножаем её на Пи (3.14) –> прибавляем ещё 2 недели на случай, если разработчик не справится, чтобы было время доделать самому. Как ни странно, очень жизнеспособный метод, подтверждённый годами опыта. Иногда хватает и умножения на 2 вместо Пи, но если есть возможность подстраховаться – подстрахуйтесь. Лучше сдать раньше и обрадовать клиента, чем каждый раз извиняться и переносить сроки.
Старайтесь делать чуть больше чем требуется и налаживать личные отношения с клиентами. Это касается любого вида деятельности. Со временем это окупится 100%.
Инструкция кажется сложной, но стоит составить по ней план, обкатать на нескольких проектах и диалоги станут проходить сильно проще.
Всегда составляйте чек-лист перед переговорами и лучше ходить на них парами. Менеджер и тех. специалист. Всегда один сможет подхватить другого там, где он "плавает".
Если вам кажется, что вы что-то упустили, спросите заказчика, есть ли у него к вам вопросы. Возможно он подметит что-то, что не было учтено.
Всё описанное выше не обязательно узнавать за одну сессию. Если чувствуете, что разговор затягивается и люди начинают уставать – разбейте его на несколько мини сессий. А что-то и вовсе можно узнать через мессенджеры.
Повторюсь, записывайте всё. Многие пренебрегают этим и получают кучу проблем. Простая привычка, решающая практически любые разногласия.