Главный вопрос, который Консультант должен задавать Заказчику (Стажерам)

Недавно наблюдал картину, стажер очень старательно расспрашивает сотрудника Заказчика по полям одного второстепенного отчета. Типичные и правильные вопросы, как рассчитывается данный показатель, как фильтровать отчет, какие итоги нужны и т.д. Вроде все правильно, потом по данному интервью будут написаны ФТ, Дизайн затем, будет разработан очередной отчет, который будет ни кому не нужен.

Почему так получается?

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

Что делать?

Задайте сотруднику Заказчика главный вопрос «Зачем это нужно?», а потом еще 5 раз переспросите, меняя формулировки и запрашивая подтверждение, пока вам не станет кристально ясно, что дальнейшая работа, которая будет выполнена Вами и разработчиком не будет бесполезна.

Дополнение 1 (по комментарию AlGol, Не является рекомендацией - просто мысли):

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

Очень хороший пример для консультанта (из далекого прошлого) - Ставка НДС - 0%, это не тоже самое что БЕЗ НДС (а при проведении интервью сотрудника фин. департамента, данные термины могут легко смешиваться).

Дополнение 2: Речка

Недавно прочел в одной рассылке фразу "Что нужно чтобы пересечь реку?" и варианты ответов "1. Мост 2. Лодка 3. Умение плавать."...

Так и в жизни консультанта не редко видишь банальную ситуацию: Нам нужна лодка ч-бы пересечь речку. Лодка будет только через 2 недели. Когда лодка появляется, выясняется, что лодка банально не помечается в речку (которая на самом деле ручей).

Или просто тупиковая ситуация: Нам нужно научится плавать, чтобы пересечь речку. Ну так учитесь в этой самой речке. Не можем, потому как глубина 20 см.

Дополнение 3: Методы анализа проблем: 5 Whys (Сакичи Тойода)

Недавно наткнулся в одном блоге на статью:

В 20 веке Сакичи Тойода придумал интересный способ выяснения истинной причины проблемы: пять раз подряд задать вопрос «Почему?» Теперь этот метод стал частью методологии Six Sigma, и вообще очень известен. Легче всего продемонстировать этот метод на примере. У вас есть проблема - много возвратов товара от клиента. Поехали:

1. Почему клиенты возвращают товар? - Ответ: 90% возвратов из-за дефектов во внешнем виде.
2. Почему возникают дефекты во внешнем виде? - Ответ: Дефекты возникают при упаковке товара перед отправкой.
3. Почему возникают дефекты при упаковке? - Ответ: потому что их упаковывают неправильно.
4. Почему упаковывают неправильно? - Ответ: Потому что они не знают, как правильно упаковывать.
5. Почему нет описания правильного способа упаковки? - Ответ: потому что это знал один специалист, и он уволился.