Поиск  программного решения — первое интервью с потенциальным клиентом по продукту

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

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

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

Проведя десятки интервью, я пришел к некоему общему шаблону вопросы для первой встречи с потенциальным клиентом. Самое главное для меня на первом собеседовании — выяснить основные болевые точки и получить знакомство с терминологией из отрасли клиента. Но прежде чем мы приступим к вопросам к клиенту, мы должны установить наши цели, инструменты и ограничения.
_{Артем Трушинский}

Цели:

● Ознакомьтесь с бизнесом клиента и его терминологией/"языком";
● Обсудите основные болевые точки и общее видение будущей системы;
● Создайте сначала прочную основу для перехода к следующим этапам интервью, которые содержат конкретные вопросы;
● Демонстрируйте свою реальную компетентность и выстраивайте доверительные отношения с клиентом;
● Объясните, что формирование продукта — это взаимный процесс. Вы и клиент вместе ищете квинтэссенцию решений;
● Определите все заинтересованные стороны проекта;
● Всегда планируйте следующее собеседование (это в корне меняет правила игры — просто поверьте).

Простые инструменты, которые помогут вести проект:
● Figma, Miro или любой другой инструмент для визуализации ваших идей в Интернете вместе с клиентом;
● Zoom, Google Meet, Teams или их альтернативы для проведения сессий с клиентом;
● Запишите свое интервью с помощью Zoom или любого другого инструмента. Это поможет не упустить никакие детали и вернуться к интервью в любой момент.

Ограничения

● Продолжительность интервью не должна превышать 60 минут. Поверьте, вы не можете узнать все о новом бизнесе за один день;
● Не углубляйтесь в технические вопросы. Оставь их на будущее интервью;
● Не спешите сообщать окончательную стоимость до завершения оценки продукта. Если клиент действительно настаивает, вы могли бы указать приблизительный диапазон. Как правило, стоимость программного обеспечения находится в диапазоне 30000$ - 40000$ за MVP.
Конечно эта стоимость является средней оценкой и зависит от платформы клиента, технологии, количество функций и опыт вашей команды.
● Сообщите клиенту, что весь процесс оценки должен быть оплачен.

Попробуйте не работать бесплатно.

Если у клиента нет желания платить за оценку и поиск решения, возможно это не ваш клиент.

Общие вопросы для обсуждения о бизнесе клиента:

● Тип бизнеса клиента: сфера деятельности, размер бизнеса ;
● Не забывайте о текущих болевых точках клиента и его ожиданиях. Составьте список основных проблем. В будущих интервью, вы подробно разберете их с помощью техники, которая называется «Лестница» или «Пять почему».
● Какие затруднения у клиента на пути к масштабированию. Для пример: в бизнесе слишком много рутинных ручных операций. Другой случай — устаревшие технологии, которые все сложнее поддерживать;
● Какие бизнес-процессы клиент хотел бы улучшить/убрать/создать в долгосрочной перспективе. Вам нужен обзор. Не погружайтесь глубоко в бизнес-процессы на первом собеседовании;
● Общий обзор портрета/роли пользователя системы.

Возможно что заинтересованная сторона — не является пользователем решения, которое вам предстоит разработать (особенно в B2B). Важно и нужно ориентироваться на решение для конечного пользователя.Поэтому как можно быстрее вы должны сделать профиль пользователя. Обратите внимание на технику "Персона". В сети есть десятки статей об этом.

● Если клиент говорит о программном обеспечении для e-commerce/SaaS, было бы полезно спросить о способах связи (push, sms, электронная почта) с пользователем. Эта часть попрой игнорируется в интервью, хотя это может быть весомой частью программного обеспечения;
● Заинтересованные стороны/лица, влияющие на проект.

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

● Ожидания относительно бюджета проекта и сроков реализации первого MVP.
Собственно, если у вас есть отдел продаж, этот вопрос нужно задавать на квалификационный вызов перед стартом оценки. Фильтруйте лиды, поскольку разработка программного обеспечения - дорогое удовольствие.

Общие вопросы о программном обеспечении

● Количество внутренних программных систем и количество пользователей в каждой;
● Обозначение каждого программного обеспечения и используемая технология. Оцени его плюсы и минусы.
Например: стоимость, обслуживание, мобильность, безопасность, UX/UI, масштабируемость. 

● Критическая, определяющая функция, среди всех остальных. Это важно, поскольку этот пункт подчеркнет возможную функциональность для начального MVP или PoC (доказательство концепции).

PoC направлен на подтверждение осуществимости проекта и проверку общей жизнеспособности идеи

 ● Решения конкурентов, которые нравятся клиенту. Что именно им нравится или не нравится. Это поможет вам установить правильные отсылки для твоей команда; 

● Какие внешние интеграции уже существуют внутри системы клиента и его цель.
Например, интеграция с платежными шлюзами, IoT-устройствами, провайдеры sms/email, VOIP и т.д.; 

● Предпочтительная технология.
Например, клиент предпочел бы веб-интерфейс вместо приложения IOS или наоборот;

 ● Если у клиента есть четкое представление о его желаниях/идеях, вы можете мгновенно расставить приоритеты с помощью быстрых методов классификации, таких как метод 100 долларов или МОСКВА.

Метод 100 баллов 100 долларов был предложен Дином Леффингуэллом и Доном Видригом в 2003 году. Цель состоит в том, чтобы придать больший вес ожидающим элементам с более высоким приоритетом.

Метод Метод MoSCoW:
Все задачи или требования делятся на 4 категории: must, should, could, would.

• Must – то, что необходимо сделать в любом случае. Без выполнения этих задач продукт не будет работать в принципе.

• Should – не самые важные требования, но они тоже должны быть выполнены. Естественно, после реализации «must».

• Could – желательные требования, которые можно сделать, если останется время и будут ресурсы.

• Would – требования, которые хотелось бы сделать, но их можно проигнорировать или перенести на следующие релизы без вре

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

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

У всех этих клиентов хорошо налаженный бизнес. Следовательно, их идеи и желания были очень сфокусированы и точны.

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

Лайфхак — задавайте вопросы в chatGPT, чтобы быть наготове.
Иногда еще до первого собеседования вы уже знаете, какой у него тип бизнеса.
Например, логистика, аренда или выращивание орхидей.
И ты знаешь, что ты не эксперт конкретно в этом виде бизнеса.
Просто зайдите в чат GPT и напрямую попросите его генерировать предложения. Это тот самый случай, когда AI рулит.
Взгляните на пример ниже:

Я надеюсь, что эта статья была полезной для вас.
Будем очень признательны за ваши вопросы, любые отзывы и ваши предложения о следующих публикациях.
_{Артем Трушинский, руководитель проекта Devstars}