Литература для бизнес-аналитиков. Часть 2. Обзор книги "Спроси маму" Роба Фитцпатрика
Привет!
Продолжаю серию обзоров на полезную литературу для бизнес-аналитиков.
На очереди у нас книга "Спроси маму: как общаться с клиентами и подтвердить правоту своей бизнес-идеи, если все кругом врут?"
Disclaimer: Описанный текст является моим личным мнением и интерпретацией. В статье приведены мысли и тезисы, которые я перекладываю на специфику аналитика(аналитик внутри команды разработки) и общение с заказчиком в IT-специфике. Погнали!
В своей книге Роб описывает подход к созданию стартапов, который должен исключить неудачные идеи и предотвратить разработку неудачного продукта на начальном этапе и поиске инвесторов (Discovery Фаза). Проецируя это на этапы работы бизнес-аналитика — это этап создания продукта/проекта/задачи: "как не облажаться и сделать именно то, что решит проблему заказчика".
Что можно подчерпнуть?
Идея книги аналогична этапу интервью/сбора требований в нашей работе.
- Общайтесь с заказчиком, задавая вопросы не о том, как что-то должно работать, а почему стоит сделать ту или иную функциональность.
- Выделяйте важную функциональность при запросе, и определяйте влияние проблем на продукте(возможно без чего-то можно обойтись) , ищите истинную цель, которую стоит сделать. Спрашивайте о конкретных вещах, а не о взгляде или мнении заказчика на проблему.
Плохо: что, как вам кажется, должно быть в выгрузке Экселя? как вам кажется, нам надо сделать выгрузку pdf в дополнение?
Хорошо: для чего используется выгрузка? Что с ней потом делают? Как вы решаете проблему сейчас? - О культуре общения. Ведите заметки до или после встречи. К встрече с заказчиком нужно готовиться заранее и продумывать как минимум три вопроса, которые хочется обсудить, желательно приходить на нее паре специалистов от команды. Кто-то один должен вести логи встречи.
Встреча, не закончившаяся договоренностями и без артефактов — плохая встреча.
Логи встречи, которые не закончились анализом полученной информации — плохие логи встречи. - Анализ полученной информации(логов встречи) .
Зачем нужна фича, какие действия будут выполнять с ее помощью, как срочно нужно выполнить разработку — сейчас, или еще поживем, как функция впишется в текущую работу заказчика. - Не добивайтесь одобрения.
Важный пункт: комплимент — это прямой путь вникуда. Если фичу хвалят, вместо того, чтобы подробно разобраться о ней, скорее всего, это не то, что является целевым решением. - Не бойтесь общаться и задавать вопросы.
Лучше задать 100 вопросов и на 95 понять, что вы идете в разработке не туда, чем 5, подтверждающих вашу правоту. Банально, но факт: нельзя убегать от неудобных вопросов. Роб пишет, что в каждом интервью(сборе требований) должны быть вопросы, которые вас пугают, потому что именно они могут разнести идею в пух и прах. Я согласна — на этапе обсуждения проблемы изменить ТЗ стоит дешевле всего.
Моя оценка книге: 5/10. Большую часть информации я знала и так, но было полезно заново прочесть и запомнить какие-то мысли.
Кому полезно: начинающим бизнес-аналитикам, которые только учатся общению с людьми и пока не понимают, как подступиться к интервью с заказчиком.
Эта книга – кладезь не только для тех, кто открывает бизнес/тестирует гипотезы/проводит кастдев для различных целей. Я после ее прочтения заметила, что даже в беседе с партнёрами/коллегами/клиентами формулирую вопросы корректнее, с менее субъективной окраской. Более того, замечаю, когда меня вопросами пытаются навести на определённые мысли (может, даже и неосознанно). В общем, это книга, к которой я возвращаюсь постоянно просто перечитать 🖤