Привет всем, сегодня от лица Артема, нашего ведущего разработчика, делимся некоторыми советами с теми из вас, кто пытаются оценить проект программного обеспечения и определить четкий 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}