Thursday, 5 May 2011

Аналитика – Умение задавать вопросы

Кроме эмоций и впечатлений в бортовом журнале, хочется отметить и существенно полезные вещи.


Например: Умение задавать вопросы.
Так и хочется добавить «правильные», но это еще успеется.

Итак, что же такое это умение задавать вопросы?

1) Вопрос должен быть правильным, т.е. важна его формулировка.
* Читая вопрос, бизнес (заказчик или его представитель) должен осознавать так называемое business value.
* Открытые вопросы помогают узнать оригинальные ожидания бизнеса, Уточняющие, наводящие или альтернативные вопросы помогут сформулировать ожидания в терминах приложения или склонить к варианту. Закрытые вопросы помогут получить однозначный ответ.
Примерно так: «Пофиксим в этом релизе (+1 чел\день) или следующем?» будет лучше чем «Что делать?»
* Вопросы должны быть максимально содержательны, вежливые, и лаконичны.

2) Вопросы должны быть в правильном порядке. Следует сначала уточнить ожидания бизнеса, а не предлагать всевозможные варианты (они могут быть просто бесполезными).

3) Вопросы должны быть заданы в правильное время.
* Чем раньше, тем правильнее. Просто? Нет. Читаем дальше.
* Есть нюанс, в зависимости от того с чем работаем: BR, FR или FS. Спрашивать о деталях реализации, когда идет обсуждение концепции задачи?
* Да вы можете хорошо поговорить и договориться, но после окажется, что идея не в том была.
* Результат – впустую потраченное время и полезность 0.
* Отмазка типа «зато лучше понимаем заказчика» - липа.
* Не понимая его ожиданий, мы не понимаем бизнес. Да и в инвойсе у нас нет пункта на оплату «просто пообщаться», это только у психотерапевтов.

4) Вопросы надо уметь правильно подавать. Выслав простыню в 45 вопросов, вы не обрадуете бизнес, даже если они все правильные и нужные.
* И вопрос-ответ тут идет не в одну итерацию. Даже у хорошего аналитика это будет цепочка писем – больше похоже на беседу.
*Лучше разделять и читабельно оформлять вопросы. Даже в очень коротких сроках, эти 45 вопросов можно обработать в один день да еще с удовольствием.
*Исключением, наверное, может быть давно скисшие все сроки. Чтобы не потерять что-то лучше в одном письме, а еще лучше в документ и прикрепить.

5) (точно еще что-то было, но оставлю это на потом)

И еще одно замечание, уже ближе к тестировщикам.
Умение задавать вопросы применимо как к аналитикам, так и тестировщикам (и многим другим ролям в проекте). Но а) универсальные солдаты, бываю только в кино б) «разделяй и властвуй» это Цезарь сказал о проектах, хотя их тогда еще не существовало.

Ядро работы аналитика, как мне кажется, содержит умение задавать вопросы, в то время как для тестировщика это будет рядом. Если тестировщик может задавать много и разные вопросы, то аналитик должен быть внимательным, так как он лицо компании для бизнеса. Тут не поспамишь вопросами, и застенчивыми смайликами (это в общем случае).



Иначе говоря, у аналитика более жесткие требования к наличию и качеству данного навыка. Ну если совсем упрощая, то можно сказать что для аналитика это приоритет 1, а для тестировщика 10.

5 comments:

will said...

Вот бы еще про умение отвечать на вопросы, особенно неправильные ! ;)

Александр Селяев said...

Ох - если бы все так было просто...

>1)Читая вопрос, бизнес (заказчик или его представитель) должен осознавать так называемое business value
>«Пофиксим в этом релизе (+1 чел\день) или следующем?» будет лучше чем «Что делать?»
Наташа, простите за скептицизм, а где в вопросе бизнес ценность?

Кстати на вопрос "Что делать" заказчик имеет предрасположенность отвечать - вы же профессионалы, почему вы спрашиваете у меня. Так что именно с такой формулировкой, я бы был осторожнее.

>Вопросы должны быть в правильном порядке. Следует сначала уточнить ожидания бизнеса, а не предлагать всевозможные варианты (они могут быть просто бесполезными)

А случаи, когда бизнес об этом не подумал?

А случаи, когда бизнес сам не знает, что он хочет?

А случаи, когда представитель заказчика, не является компетентным?

Бояться задавать "глупые" вопросы это от лукавого.

>Вопросы должны быть заданы в правильное время.

Чой то я с утра тормозной - при чем тут правильное время и не те заданные вопросы? Наташа, можно уточнить?

>Даже у хорошего аналитика это будет цепочка писем...

Нууууу не знаю. Наташа, вы не пробовали вики? Простая таблица в вики. Все что не включается в спецификацию требований, тупо выноситься вопросами и правиться по мере возможности и времени заказчика или аналитика.

Ваша переписка уйдет с вами, а acion points и вопросы остануться.

>как мне кажется, содержит умение задавать вопросы, в то время как для тестировщика это будет рядом
>Если тестировщик может задавать много и разные вопросы, то аналитик должен быть внимательным, так как он лицо компании для бизнеса.
>Иначе говоря, у аналитика более жесткие требования к наличию и качеству данного навыка

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

Еще один вопросик. Заголовок имеет "Итак, что же такое это умение задавать вопросы?"

Так что же такое умение задавать вопросы? ;)

Lena said...

"Иначе говоря, у аналитика более жесткие требования к наличию и качеству данного навыка. Ну если совсем упрощая, то можно сказать что для аналитика это приоритет 1, а для тестировщика 10."

- боюсь, что не согласна. Умение задавать вопросы для тестировщика - может и менее важно, чем для аналитика, но не настолько. Если у тестирвщика постоянно не возникают вопросы (на которые ему же так или иначе надо искать ответы), то для меня это даже как-то странно. Да и по сути сама работа тестировщика - это постоянная постановка вопросов вроде "А что будет, если?.." И подобные вопросы задаются далеко не только тестируемому приложению.

Хотя может в идеальном мире, где все нужные вопросы своевременно задал аналитик - тестеру вопросы задавать будет нужно в гораздо меньшей степени :)

Novotna Natalia said...

@Александр Селяев

1) Детализация пунктов, это скорее ситуации с которыми мне пришлось столкнуться на практике.
А второй пункт даже очень нагляден. Бизнес видит, что мы профи и знаем какие есть решения и нам нужно решение от него: когда он будет оплачивать эту работу.

На этот вопрос мы ответить никак не можем лишь попросить или предложить.

2)
> А случаи, когда бизнес об этом не подумал?
> А случаи, когда бизнес сам не знает, что он хочет?

читать пункт 1. задавая альтернативные, наводящие вопросы можно ....

>А случаи, когда представитель заказчика, не является компетентным?

Всякое бывает.
ИМХО "Давайте искать пуговицу"(С)
Всегда можно чтото изменить, обойти подточить. Безвыходных ситуаций не бывает.

3) есть шкала времени и по ней разнесены действия. насколько я понимаю примерно так:

обсуждение BR ->обсуждение FR -> обсуждение FS

это может в один день, а может и не один (у меня на проекте это может быть неделя и больше)

обсуждая BR мы не задаем вопросы по детализации спеки и реализации, типа вам лейбл с большой или с маленькой буквы вывести?

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

4) Если на проекте есть возможность это делать в вике, да наверное это класно. Не могу сказать. У меня нету :(

Вот как раз сейчас размышляю как лучше хранить action points :)
у меня есть JIRA и SharePoint

А вот обобщить я хотела не людей, а роли :-Р.

Novotna Natalia said...

@Lena

А если скажу что 10 это по 100 бальной шкале ;)

Мне очень не просто, я же тестировщик.

Кстати, я думаю, что даже с идеальным аналитиком хороший тестировщик не останится без работы.

Post a Comment