Как общаться с заказчиком: наблюдения из мира разработки IT-проектов
Создание цифрового продукта — долгий процесс. И если сразу не выстроить правильную коммуникацию с заказчиком, можно оказаться в ситуации, когда сроки бесконечно сдвигаются, функциональные требования дописываются на ходу. А потом спустя тысячи часов разработки выясняется, что делать нужно было совсем не это. В статье разбираемся, как общаться с заказчиком на всех этапах проекта, чтобы избежать недоразумений и прийти к единому пониманию бизнес-целей.
Правильно обрабатываем входящие заявки
Общение начинается в тот момент, когда клиент оставляет заявку. Причем заявка еще не означает желание или готовность работать с вами. Вероятнее всего, заказчик просто мониторит рынок и пытается выяснить, кто и за сколько сможет решить его проблему.
Обычно входящая заявка содержит краткое описание задачи и проекта, контакты ответственного лица. Для студии критически важно расширить количество вводных данных. Предположим, приходит банк и говорит: «Нам нужно мобильное приложение для физлиц». Запрос понятен в общих чертах, но нужно уточнить детали. Что за банк, какие продукты он выпускал за последние годы, почему появилась потребность в приложении? Мы формируем список вопросов для обратного письма, которое обязательно начинаем со слов благодарности. Заказная разработка — высококонкурентный рынок, и я считаю важным сказать заказчику «спасибо» за то, что он по тем или иным причинам выбрал нас.
Не забываем про большую роль «маленького» разговора
Следующий этап — знакомство и погружение в контекст. Нужно собрать как можно больше информации о проекте, чтобы четко понимать, какие задачи предстоит решать. Но прежде чем переходить к глубоким вопросам, стоит наладить контакт. В этом помогает small talk.
Да, кажется, что small talk не такой эффективный по сравнению с общением по сути. Но мы работаем с людьми, поэтому, прежде чем погружаться в бизнес-задачи, важно познакомиться и разрядить обстановку. Показать клиенту, что перед ним не «бездушный сейлз», а такой же человек, как и он.
Задаем вопросы и фиксируем ответы
Когда контакт установлен, можно переходить к предметному обсуждению проекта. На этом этапе мы выясняем, какую задачу предстоит решить и действительно ли есть потребность в ее решении. Например, заказчик говорит, что хочет разработать продукт, который автоматизирует рутинные рабочие процессы. Прежде чем обсуждать функциональные особенности будущего приложения, стоит разобраться, как все работает сейчас, что конкретно нужно автоматизировать и почему. Грубо говоря, мы узнаем, действительно ли есть потребность в продукте или на одном из совещаний кто-то просто подумал: «А почему бы не сделать приложение, сейчас же все в мобильниках».
Чтобы понять истинные проблемы и потребности заказчика, задаем как можно больше уточняющих вопросов. Условно их можно разбить на две группы: технические и бизнесовые. Технические связаны с тем, как все должно работать, — интерфейс, серверная часть и др. Бизнесовые — какие задачи должен решать продукт, для кого он создается, когда он нужен и почему именно в эти сроки. Например, релиз к определенной дате может быть важен, потому что начинается сезон продаж и уже запланированы маркетинговые активности. Соответственно, если не выпустить приложение к этому моменту, компания понесет убытки.
Помимо этого, стоит узнать, что заказчик хочет получить в первой версии продукта и какая у него цель: протестировать гипотезу или вывести на рынок полноценный продукт. Обсуждение таких деталей на старте помогает избежать недопонимания в будущем. А еще показывает нашу заинтересованность — в разработке решения, в клиенте, в его проекте. Мы ищем ценность, а не сводим все к деньгам. Это способствует выстраиванию отношений двух равнозначных партнеров, а не продавца и покупателя.
Конечно, мы не совсем игнорируем материальные вопросы. Но меняем угол зрения — подбираем решения исходя из потребностей и возможностей клиента. «Сколько у вас денег на проект?» и «Давайте разработаем решение под ваш бюджет» — два совершенно разных подхода.
Обосновываем решение
Следующий шаг — представить решение и убедить заказчика, что именно мы сможем справиться с его задачей.
На рынке заказной разработки заказчик редко обращается только в одну компанию. Обычно он отправляет заявку сразу в несколько, затем анализирует предложения и выбирает то, что кажется наиболее подходящим. Компанию, чей единственный аргумент: «Мы с этим всегда работали», вряд ли выберут. Необходимо обосновать свое решение со всех сторон: «Технически это правильно, потому что…», «С точки зрения бизнеса наше решение позволит…», «Если мы сделаем так, пользователи смогут…».
Да, такой путь требует больше усилий. Скорее всего, для обоснования решения на встречу придется пригласить дополнительных специалистов, например лидов разработки. Но, с другой стороны, именно так создаются команды, которые решают проблемы, экономят время и делают жизнь легче и приятнее.
Регулярно сверяем часы и поддерживаем прозрачность в работе
Представим, что наше решение понравилось и с нами подписали договор. Как общаться с заказчиком дальше? Основной принцип — быть честным и открытым. Нужно выстраивать коммуникации так, чтобы у клиента не возникало сомнений в том, что мы делаем и зачем. Здесь помогает регулярная «сверка часов». Например, мы в MobileUp еженедельно сверяемся с планом проекта и корректируем его под актуальные запросы, а также проводим командные синки, на которых синхронизируемся по задачам.
Важным элементом общения на данном этапе выступает документ с актуальными статусами по проекту. Из него заказчик может быстро узнать, чем закончилась прошлая неделя (если он забыл, конечно) и что планируем на текущей. Это помогает нам быть в одном инфополе, управлять ожиданиями и избегать недопонимания.
Создание продукта — долгий процесс. С течением времени количество коммуникаций может снижаться. Чтобы держать руку на пульсе и оперативно реагировать на изменения, понадобятся дополнительные инструменты. У нас в MobileUp это таблица со статусами. В ней есть разные метрики, по которым проджект-менеджер оценивает состояние проекта. Это позволяет быстро понять степень удовлетворенности и команды, и заказчика и при необходимости принять меры.
«Этого не было в ТЗ!» — адекватно реагируем на новые идеи и предложения
По ходу проекта могут рождаться идеи, которые не обсуждались изначально. Это нормально. Их можно положить в бэклог или взять в работу сразу — все зависит от приоритетности. Предположим, заказчик приходит с каким-то предложением, но мы понимаем, что есть более приоритетные задачи. Важно не бросаться делать все и сразу, а отталкиваться от целей. Зачем это нужно, какую проблему мы хотим решить? Ответы на эти вопросы дадут понимание, как быть.
Например, уже готов и согласован дизайн, но внезапно из отпуска возвращается директор по маркетингу и говорит, что использующийся подход — несовременный. Стоит уточнить смысл понятия «несовременный подход в дизайне». А в идеале — попросить показать примеры, какие подходы кажутся ему современными и что в них нравится. Дальше на основании его ответа принимать решение.
Создаем совместные события
Чтобы создать успешный цифровой продукт, предстоит провести с заказчиком не один месяц, а иногда и год. Это внушительный промежуток времени, когда помимо рабочих отношений обретают значение неформальные общечеловеческие. Сформировать их помогают совместные события. Например, состоялся релиз первой версии приложения — его нужно отметить вместе заказчиком. Встретиться, вспомнить, как решали какие-то сложные задачи, поделиться радостью.
В процессе создания продукта у членов команды могут происходить значимые изменения в личной жизни, которые так или иначе влияют на ход проекта. Не стоит игнорировать их. У кого-то день рождения — поздравьте. Кто-то заболел — пожелайте скорейшего выздоровления и предложите помощь. На одном из наших проектов однажды заболел девопс из команды заказчика, из-за чего релиз оказался под угрозой. Мы предложили привлечь к задачам своего специалиста, чтобы не терять время. Это простые вещи, но они складываются воедино и формируют положительное впечатление от работы с вами.
Вместо заключения: почему важно понимать заказчика
Мы используем перечисленные правила и принципы, чтобы улучшать коммуникацию с заказчиком и сохранять прозрачность в отношениях. Однако есть еще один немаловажный аспект общения, который тоже стоит учитывать. Это способность понимать заказчика и говорить с ним на одном языке. Это ваша экспертность в нише — об этом и многом другом я, Александр Маслов, COO MobileUp, рассказываю в своем телеграм-канале «The Гриша».
Если вы можете взаимодействовать с заказчиком, используя его терминологию, это мгновенно дает сто очков вперед. Потому что помогает избежать понятийной дистанции и быстрее погрузиться в проект. Без знания фундаментальных особенностей ниши экспертом стать невозможно. Можно количественно собирать опыт, например в финтехе, но не знать ровным счетом ничего о том, как этот самый финтех работает. Специалитет без погружения в предметную область порождает кучу возражений. Например, в стоимости услуг. Экспертиза повышает доверие и дает возможность построения долгосрочных отношений, основанных на уважении, созидании и взаимной выгоде.
Хотите рассказать о своем бизнесе или поделиться экспертизой?
В рубрике «Блоги компаний» вы можете бесплатно публиковать статьи о своем бизнесе. Публикации помогут укрепить ваш личный бренд или привлечь внимание партнеров, клиентов, инвесторов.
О чем можно рассказать?
- Обо всем, с чем вы столкнулись лично, например, вышли на новый рынок, нашли неочевидный канал сбыта или придумали, как увеличить продажи в несезон.
- О работе с инструментами, сервисами или технологиями для бизнеса.
Для помощи в подготовке статьи мы сделали телеграм-бот. В нем — рекомендации по содержанию статьи и инструкции по ее оформлению. Следуйте инструкциям, пишите статьи и отправляйте готовые тексты так же в чат-бот.
После короткой проверки ваш материал выходит на сайте Бизнес-секретов, а лучшие статьи мы отправляем на главную страницу медиа.
Ждем ваших историй!
