На первый взгляд кажется, что между миром продаж и миром аналитики пропасть. В одном мире основа работы - пересборка реальности под ожидания клиента с включением в нее нашей услуги/продукта, в другом - выявление истины и проектирование решений под уже готовые, хотя часто и "недоосмысленные" концепции. Однако, некоторые методики, отточенные в жестких сейлзовых условиях оказываются бесценным инструментом для аналитика, особенно на самых непростых этапах - сбора и верификации требований. Сегодня речь пойдет о методике СПИН-продаж. Так всё же, что из продаж может нам помочь? Засыпать заказчика аргументами? Умело отрабатывать тонны возражений? Бороться с предосуждением заказчика, его видением? Я вам скажу, что до этого просто можно не доводить! Во время выстраивания коммуникации лучше сосредоточиться на диалоге вместо монолога, но куда и как его вести?

И отвечая на этот вопрос давайте как раз включим в формулу нашу новую(для аналитика) методику. СПИН-продажи это подход, в рамках которого коммуникация с клиентом выстраивается а)с помощью вопросов, б)по определенной траектории. Это не просто последовательность вопросов, а скорее философия глубокого исследования проблемы клиента через вопросы. И всё, что нам нужно - это во время поиска причины неудовольствия заказчиком ситуации, что породила требования на доработку вовремя сориентироваться и перестроить оценку клиента под наше решение. Теперь заметили сходство процессов? Обработать требования, отделить зерна от плевел и вписать решение в контур возможностей нашего ПО, либо нашей экосистемы процессов. Чтож, давайте посмотрим, как каждый этап этой методики работает на аналитика.

1. Ситуационные вопросы. Карта вместо слепого пятна. В продажах это вопросы для сбора общих данных о клиенте. Нам важен контекст, диспозиция. Для аналитика - это фундамент. Вместо "Расскажите, какую кнопку вы хотите добавить на эту форму?" выстраиваем вопросы в цепочку: "Опишите текущий процесс согласования заявки от момента получения до передачи в работу." Следом - "Кто является основным исполнителем процесса, под который мы дорабатываем ПО?". Далее - "Какие инструменты используются исполнителем, сколько в среднем занимает одна итерация процесса?". Вместо формальной фиксации потребности - полноценное изучение, где наша цель - объективно зафиксировать контекст "AS IS", избегая преждевременных решений. Это та самая основа, на которой потом выявляются реальные, а не декларируемые проблемы. Вы ведь не раз сталкивались с полным уверенностью заказчиком, требующим "ту самую кнопку", который получив эту кнопку уточняет, что она, конечно, решает часть его проблем, но ещё больше ломает и вообще ставит под угрозу существование самой ткани реальности и вообще мы его неверно поня ли...

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