Литература для бизнес-аналитиков. Часть 2. Обзор книги "Спроси маму" Роба Фитцпатрика

Привет!
Продолжаю серию обзоров на полезную литературу для бизнес-аналитиков.
На очереди у нас книга "Спроси маму: как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?"

Disclaimer: Описанный текст является моим личным мнением и интерпретацией. В статье приведены мысли и тезисы, которые я перекладываю на специфику аналитика(аналитик внутри команды разработки) и общение с заказчиком в IT-специфике. Погнали!

В своей книге Роб описывает подход к созданию стартапов, который должен исключить неудачные идеи и предотвратить разработку неудачного продукта на начальном этапе и поиске инвесторов (Discovery Фаза). Проецируя это на этапы работы бизнес-аналитика — это этап создания продукта/проекта/задачи: "как не облажаться и сделать именно то, что решит проблему заказчика".

Что можно подчерпнуть?
Идея книги аналогична этапу интервью/сбора требований в нашей работе.

1. Общайтесь с заказчиком, задавая вопросы не о том, как что-то должно работать, а почему стоит сделать ту или иную функциональность.
   
2. Выделяйте важную функциональность при запросе, и определяйте влияние проблем на продукте(возможно без чего-то можно обойтись) , ищите истинную цель, которую стоит сделать. Спрашивайте о конкретных вещах, а не о взгляде или мнении заказчика на проблему.
   Плохо: что, как вам кажется, должно быть в выгрузке Экселя? как вам кажется, нам надо сделать выгрузку pdf в дополнение?
   Хорошо: для чего используется выгрузка? Что с ней потом делают? Как вы решаете проблему сейчас?
3. О культуре общения. Ведите заметки до или после встречи. К встрече с заказчиком нужно готовиться заранее и продумывать как минимум три вопроса, которые хочется обсудить, желательно приходить на нее паре специалистов от команды. Кто-то один должен вести логи встречи.
   Встреча, не закончившаяся договоренностями и без артефактов — плохая встреча.
   Логи встречи, которые не закончились анализом полученной информации — плохие логи встречи.
4. Анализ полученной информации(логов встречи) .
   Зачем нужна фича, какие действия будут выполнять с ее помощью, как срочно нужно выполнить разработку — сейчас, или еще поживем, как функция впишется в текущую работу заказчика.
5. Не добивайтесь одобрения.
   Важный пункт: комплимент — это прямой путь вникуда. Если фичу хвалят, вместо того, чтобы подробно разобраться о ней, скорее всего, это не то, что является целевым решением.
6. Не бойтесь общаться и задавать вопросы.
   Лучше задать 100 вопросов и на 95 понять, что вы идете в разработке не туда, чем 5, подтверждающих вашу правоту. Банально, но факт: нельзя убегать от неудобных вопросов. Роб пишет, что в каждом интервью(сборе требований) должны быть вопросы, которые вас пугают, потому что именно они могут разнести идею в пух и прах. Я согласна — на этапе обсуждения проблемы изменить ТЗ стоит дешевле всего.

Моя оценка книге: 5/10. Большую часть информации я знала и так, но было полезно заново прочесть и запомнить какие-то мысли.
Кому полезно: начинающим бизнес-аналитикам, которые только учатся общению с людьми и пока не понимают, как подступиться к интервью с заказчиком.