Кроме эмоций и впечатлений в бортовом журнале, хочется отметить и существенно полезные вещи.
Так и хочется добавить «правильные», но это еще успеется.
Итак, что же такое это умение задавать вопросы?
1) Вопрос должен быть правильным, т.е. важна его формулировка.
* Читая вопрос, бизнес (заказчик или его представитель) должен осознавать так называемое business value.
* Открытые вопросы помогают узнать оригинальные ожидания бизнеса, Уточняющие, наводящие или альтернативные вопросы помогут сформулировать ожидания в терминах приложения или склонить к варианту. Закрытые вопросы помогут получить однозначный ответ.Примерно так: «Пофиксим в этом релизе (+1 чел\день) или следующем?» будет лучше чем «Что делать?»
* Вопросы должны быть максимально содержательны, вежливые, и лаконичны.
2) Вопросы должны быть в правильном порядке. Следует сначала уточнить ожидания бизнеса, а не предлагать всевозможные варианты (они могут быть просто бесполезными).
3) Вопросы должны быть заданы в правильное время.
* Чем раньше, тем правильнее. Просто? Нет. Читаем дальше.
* Есть нюанс, в зависимости от того с чем работаем: BR, FR или FS. Спрашивать о деталях реализации, когда идет обсуждение концепции задачи?
* Да вы можете хорошо поговорить и договориться, но после окажется, что идея не в том была.
* Результат – впустую потраченное время и полезность 0.
* Отмазка типа «зато лучше понимаем заказчика» - липа.
* Не понимая его ожиданий, мы не понимаем бизнес. Да и в инвойсе у нас нет пункта на оплату «просто пообщаться», это только у психотерапевтов.
4) Вопросы надо уметь правильно подавать. Выслав простыню в 45 вопросов, вы не обрадуете бизнес, даже если они все правильные и нужные.
* И вопрос-ответ тут идет не в одну итерацию. Даже у хорошего аналитика это будет цепочка писем – больше похоже на беседу.
*Лучше разделять и читабельно оформлять вопросы. Даже в очень коротких сроках, эти 45 вопросов можно обработать в один день да еще с удовольствием.
*Исключением, наверное, может быть давно скисшие все сроки. Чтобы не потерять что-то лучше в одном письме, а еще лучше в документ и прикрепить.
5) (точно еще что-то было, но оставлю это на потом)
И еще одно замечание, уже ближе к тестировщикам.
Умение задавать вопросы применимо как к аналитикам, так и тестировщикам (и многим другим ролям в проекте). Но а) универсальные солдаты, бываю только в кино б) «разделяй и властвуй» это Цезарь сказал о проектах, хотя их тогда еще не существовало.
Ядро работы аналитика, как мне кажется, содержит умение задавать вопросы, в то время как для тестировщика это будет рядом. Если тестировщик может задавать много и разные вопросы, то аналитик должен быть внимательным, так как он лицо компании для бизнеса. Тут не поспамишь вопросами, и застенчивыми смайликами (это в общем случае).
Иначе говоря, у аналитика более жесткие требования к наличию и качеству данного навыка. Ну если совсем упрощая, то можно сказать что для аналитика это приоритет 1, а для тестировщика 10.
5 comments:
Вот бы еще про умение отвечать на вопросы, особенно неправильные ! ;)
Ох - если бы все так было просто...
>1)Читая вопрос, бизнес (заказчик или его представитель) должен осознавать так называемое business value
>«Пофиксим в этом релизе (+1 чел\день) или следующем?» будет лучше чем «Что делать?»
Наташа, простите за скептицизм, а где в вопросе бизнес ценность?
Кстати на вопрос "Что делать" заказчик имеет предрасположенность отвечать - вы же профессионалы, почему вы спрашиваете у меня. Так что именно с такой формулировкой, я бы был осторожнее.
>Вопросы должны быть в правильном порядке. Следует сначала уточнить ожидания бизнеса, а не предлагать всевозможные варианты (они могут быть просто бесполезными)
А случаи, когда бизнес об этом не подумал?
А случаи, когда бизнес сам не знает, что он хочет?
А случаи, когда представитель заказчика, не является компетентным?
Бояться задавать "глупые" вопросы это от лукавого.
>Вопросы должны быть заданы в правильное время.
Чой то я с утра тормозной - при чем тут правильное время и не те заданные вопросы? Наташа, можно уточнить?
>Даже у хорошего аналитика это будет цепочка писем...
Нууууу не знаю. Наташа, вы не пробовали вики? Простая таблица в вики. Все что не включается в спецификацию требований, тупо выноситься вопросами и правиться по мере возможности и времени заказчика или аналитика.
Ваша переписка уйдет с вами, а acion points и вопросы остануться.
>как мне кажется, содержит умение задавать вопросы, в то время как для тестировщика это будет рядом
>Если тестировщик может задавать много и разные вопросы, то аналитик должен быть внимательным, так как он лицо компании для бизнеса.
>Иначе говоря, у аналитика более жесткие требования к наличию и качеству данного навыка
Ох Наташа, не скатывайтесь в обобщения (сам грешен). Тестировщики, аналитики, разработчики, менеджеры - все люди задают вопросы, но каждый о разном и в разное время (как правило разное), не умение задавания вопросов ведет к плачевным результатам и упрекать тестировщиков, чо они поголовно не лица компании немного неправильно.
Еще один вопросик. Заголовок имеет "Итак, что же такое это умение задавать вопросы?"
Так что же такое умение задавать вопросы? ;)
"Иначе говоря, у аналитика более жесткие требования к наличию и качеству данного навыка. Ну если совсем упрощая, то можно сказать что для аналитика это приоритет 1, а для тестировщика 10."
- боюсь, что не согласна. Умение задавать вопросы для тестировщика - может и менее важно, чем для аналитика, но не настолько. Если у тестирвщика постоянно не возникают вопросы (на которые ему же так или иначе надо искать ответы), то для меня это даже как-то странно. Да и по сути сама работа тестировщика - это постоянная постановка вопросов вроде "А что будет, если?.." И подобные вопросы задаются далеко не только тестируемому приложению.
Хотя может в идеальном мире, где все нужные вопросы своевременно задал аналитик - тестеру вопросы задавать будет нужно в гораздо меньшей степени :)
@Александр Селяев
1) Детализация пунктов, это скорее ситуации с которыми мне пришлось столкнуться на практике.
А второй пункт даже очень нагляден. Бизнес видит, что мы профи и знаем какие есть решения и нам нужно решение от него: когда он будет оплачивать эту работу.
На этот вопрос мы ответить никак не можем лишь попросить или предложить.
2)
> А случаи, когда бизнес об этом не подумал?
> А случаи, когда бизнес сам не знает, что он хочет?
читать пункт 1. задавая альтернативные, наводящие вопросы можно ....
>А случаи, когда представитель заказчика, не является компетентным?
Всякое бывает.
ИМХО "Давайте искать пуговицу"(С)
Всегда можно чтото изменить, обойти подточить. Безвыходных ситуаций не бывает.
3) есть шкала времени и по ней разнесены действия. насколько я понимаю примерно так:
обсуждение BR ->обсуждение FR -> обсуждение FS
это может в один день, а может и не один (у меня на проекте это может быть неделя и больше)
обсуждая BR мы не задаем вопросы по детализации спеки и реализации, типа вам лейбл с большой или с маленькой буквы вывести?
Иногда есть у нас знание об особеностях реализации и архитектуры, которые , мы знаем что повлияют на то что хочет клиент. Но даже в этой ситуации, мы же будем оговарить нюанс и риски, а не то как это будет решаться исполнителем.
4) Если на проекте есть возможность это делать в вике, да наверное это класно. Не могу сказать. У меня нету :(
Вот как раз сейчас размышляю как лучше хранить action points :)
у меня есть JIRA и SharePoint
А вот обобщить я хотела не людей, а роли :-Р.
@Lena
А если скажу что 10 это по 100 бальной шкале ;)
Мне очень не просто, я же тестировщик.
Кстати, я думаю, что даже с идеальным аналитиком хороший тестировщик не останится без работы.
Post a Comment