Интересный метод исследования тут обнаружил: исследование путем провокации.

Нашел я его в обзоре этнографических методов исследования, когда мы выезжаем на местность и изучаем объект непосредственно в среде и естественных условиях. Ну, мы, как аналитики, часто таким занимаемся — это включенное и невключенное наблюдение, хронометраж и картирование рабочего дня, партисипативное наблюдение, теневое наблюдение (shadowing), рефлексивное озвучивание (thinking aloud), анализ контекста.

А вот провокационное наблюдение мне встретилось, пожалуй, впервые. Хотя я его и раньше применял — случайно или намеренно.

В статье оно описано так:

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

Очень простое определение и понятная техника, но мощная!

Пока вы задаете вопросы про то, что должно быть в продукте и какие функции должны быть в системе — вы получаете во многих случаях фантазийные ответы. Всё должно быть — и вот это, и это, и ещё вот то. И всё важно. Всё нужно делать.

А вот что по-настоящему важно, можно определить только через эмоцию и через лишение этого. Спровоцируйте стейкхолдеров. Скажите, что эту функцию в продукте сделать не получится. Покажите интерфейс, в котором "забыто" одно из "обязательных" требований. Отключите случайно второстепенную, но очень "важную" интеграцию. И посмотрите на реакцию.

Ладно, я шучу. Тут нужно действовать очень аккуратно.

Но иногда такие сбои получаются не по чьему-то умыслу. Тогда получается извлечь интересную информацию. Отвалилась "очень важная" функция, но это обнаружили только через пару недель? Хм. А так ли она была важна.

Нужно обязательно автоматизировать вот этот процесс? А давайте сделаем кнопку, по которой будет уходить запрос в службу поддержки, а там, если такой запрос придёт, руками быстро поправим. Сколько раз нажали на кнопку за месяц? (реальный пример)

У нас числится больше 90 смежных систем, все очень нужны, но неизвестно кому? А давайте на день отключим их (с предупреждением о регламентных работах и контакте, куда обращаться в случае чего), и посмотрим — кто прибежит с просьбой срочно включить? (реальный пример)

Очень действенная техника!

А вы как относитесь к провокациям? Применяете?

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

Системный сдвиг

Интересный метод исследования тут обнаружил: исследование путем провокации.

Нашел я его в обзоре этнографических методов исследования, когда мы выезжаем на местность и изучаем объект непосредственно в среде и естественных условиях. Ну, мы, как аналитики, часто таким занимаемся — это включенное и невключенное наблюдение, хронометраж и картирование рабочего дня, партисипативное наблюдение, теневое наблюдение (shadowing), рефлексивное озвучивание (thinking aloud), анализ контекста.

А вот провокационное наблюдение мне встретилось, пожалуй, впервые. Хотя я его и раньше применял — случайно или намеренно.

В статье оно описано так:

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

Очень простое определение и понятная техника, но мощная!

Пока вы задаете вопросы про то, что должно быть в продукте и какие функции должны быть в системе — вы получаете во многих случаях фантазийные ответы. Всё должно быть — и вот это, и это, и ещё вот то. И всё важно. Всё нужно делать.

А вот что по-настоящему важно, можно определить только через эмоцию и через лишение этого. Спровоцируйте стейкхолдеров. Скажите, что эту функцию в продукте сделать не получится. Покажите интерфейс, в котором "забыто" одно из "обязательных" требований. Отключите случайно второстепенную, но очень "важную" интеграцию. И посмотрите на реакцию.

Ладно, я шучу. Тут нужно действовать очень аккуратно.

Но иногда такие сбои получаются не по чьему-то умыслу. Тогда получается извлечь интересную информацию. Отвалилась "очень важная" функция, но это обнаружили только через пару недель? Хм. А так ли она была важна.

Нужно обязательно автоматизировать вот этот процесс? А давайте сделаем кнопку, по которой будет уходить запрос в службу поддержки, а там, если такой запрос придёт, руками быстро поправим. Сколько раз нажали на кнопку за месяц? (реальный пример)

У нас числится больше 90 смежных систем, все очень нужны, но неизвестно кому? А давайте на день отключим их (с предупреждением о регламентных работах и контакте, куда обращаться в случае чего), и посмотрим — кто прибежит с просьбой срочно включить? (реальный пример)

Очень действенная техника!

А вы как относитесь к провокациям? Применяете?

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

hottg.com/systemswing/754

2.6K viewsJun 25 at 13:19