TG Telegram Group & Channel
Системный сдвиг | United States America (US)
Create: Update:

Если судить по текстам вакансий и публикаций, самая распространенная форма фиксации пользовательских требований сейчас — Jobs To Be Done (в западных компаниях). Другие варианты гораздо реже встречаются.

Напоминаю, идея в том, что пользователь "нанимает" ваш продукт для выполнения определенной работы ("job").

Записывается похоже на User Story, но фокус не на том, кем является пользователь, а в какой ситуации он находится:

Когда <описание ситуации, которая требует выполнения какой-то работы>
Я хочу <описание работы, которая должна быть выполнена>
Чтобы я мог <описание ценного для пользователя результата>

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

Но вот про что нечасто рассказывают — кроме функциональной работы есть ещё эмоциональный и социальный компоненты.

Это добавления формулируются так:

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

Никогда не видел, чтобы эти части появлялись в технических спецификациях.

А между тем одну и ту же функциональность можно сделать такой, что пользователь будет чувствовать себя как оплеванный или такой, что он будет испытывать сплошное удовольствие. Такие продукты есть, мой любимый пример — Superhuman, в котором создатели год вылизывали интерфейс, чтобы добиться максимально быстрой реакции. А это ведь всего лишь почтовый клиент! Miro по этому же пути идёт — поэтому все его клоны, которых так быстро настрогали, плохо выдерживают сравнение — так многого там нет из привычного, такой плохой зачастую UX — именно опыт использования.

Если эмоциональный компонент — это про чувства, социальный — про взаимодействие или про свой образ в глазах других.
Что другие подумают обо мне? Как я хочу, чтобы они думали? (Или как не хочу, тоже мощный мотиватор). Как постоянно говорят в фильмах про мафию: "Подумай, какой сигнал мы подаем этим другим семьям? Все на улице будут считать, что мы ..."
Это и про видимость, и про социальные взаимодействия в продукте (посмотрите Duolingo, это просто живая энциклопедия всевозможных взаимодействий).

Рассмотрение этих двух добавлений сразу отвечает на вопросы, которые не берутся обычными методами CustDev. Во ФРИИ я работал с проектами заочки, туда попадают ребята, которые почему-то не дотягивают до очного акселератора, то есть им чего-то не хватает. Обычно не сформулирована и не подтверждена проблема. И в этом проблема: методика CustDev пытается смотреть на всё, как на проблему, даже боль. Когда у вас возникала эта проблема? Насколько часто она возникает? Как сильно у вас болит, что вы теряете, в деньгах? Пытались ли вы её решать за деньги? Это всё про функциональную работу.

Когда мы берем просветительские проекты (а ко мне такие как и попадали, по профилю — edTech), то жгучая проблема там только одна — ЕГЭ. Ну и ещё пара связанных, типа высоких способностей, которым не отвечает школа, или учебы в условиях постоянных переездов, или других специальных потребностей, но это не массовые истории. Так что болит у подписчиков Арзамаса или покупателей курсов Страдариума? Ничего, это чисто эмоциональная и социальная работа. Зачем туристы таскаются за большие деньги по древним развалинам по жаре, а не лежат у бассейна с коктейлями? Эмоции и социальные эффекты. И тогда всё становится на свои места, и понятно, что именно они покупают.

Если судить по текстам вакансий и публикаций, самая распространенная форма фиксации пользовательских требований сейчас — Jobs To Be Done (в западных компаниях). Другие варианты гораздо реже встречаются.

Напоминаю, идея в том, что пользователь "нанимает" ваш продукт для выполнения определенной работы ("job").

Записывается похоже на User Story, но фокус не на том, кем является пользователь, а в какой ситуации он находится:

Когда <описание ситуации, которая требует выполнения какой-то работы>
Я хочу <описание работы, которая должна быть выполнена>
Чтобы я мог <описание ценного для пользователя результата>

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

Но вот про что нечасто рассказывают — кроме функциональной работы есть ещё эмоциональный и социальный компоненты.

Это добавления формулируются так:

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

Никогда не видел, чтобы эти части появлялись в технических спецификациях.

А между тем одну и ту же функциональность можно сделать такой, что пользователь будет чувствовать себя как оплеванный или такой, что он будет испытывать сплошное удовольствие. Такие продукты есть, мой любимый пример — Superhuman, в котором создатели год вылизывали интерфейс, чтобы добиться максимально быстрой реакции. А это ведь всего лишь почтовый клиент! Miro по этому же пути идёт — поэтому все его клоны, которых так быстро настрогали, плохо выдерживают сравнение — так многого там нет из привычного, такой плохой зачастую UX — именно опыт использования.

Если эмоциональный компонент — это про чувства, социальный — про взаимодействие или про свой образ в глазах других.
Что другие подумают обо мне? Как я хочу, чтобы они думали? (Или как не хочу, тоже мощный мотиватор). Как постоянно говорят в фильмах про мафию: "Подумай, какой сигнал мы подаем этим другим семьям? Все на улице будут считать, что мы ..."
Это и про видимость, и про социальные взаимодействия в продукте (посмотрите Duolingo, это просто живая энциклопедия всевозможных взаимодействий).

Рассмотрение этих двух добавлений сразу отвечает на вопросы, которые не берутся обычными методами CustDev. Во ФРИИ я работал с проектами заочки, туда попадают ребята, которые почему-то не дотягивают до очного акселератора, то есть им чего-то не хватает. Обычно не сформулирована и не подтверждена проблема. И в этом проблема: методика CustDev пытается смотреть на всё, как на проблему, даже боль. Когда у вас возникала эта проблема? Насколько часто она возникает? Как сильно у вас болит, что вы теряете, в деньгах? Пытались ли вы её решать за деньги? Это всё про функциональную работу.

Когда мы берем просветительские проекты (а ко мне такие как и попадали, по профилю — edTech), то жгучая проблема там только одна — ЕГЭ. Ну и ещё пара связанных, типа высоких способностей, которым не отвечает школа, или учебы в условиях постоянных переездов, или других специальных потребностей, но это не массовые истории. Так что болит у подписчиков Арзамаса или покупателей курсов Страдариума? Ничего, это чисто эмоциональная и социальная работа. Зачем туристы таскаются за большие деньги по древним развалинам по жаре, а не лежат у бассейна с коктейлями? Эмоции и социальные эффекты. И тогда всё становится на свои места, и понятно, что именно они покупают.


>>Click here to continue<<

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







Share with your best friend
VIEW MORE

United States America Popular Telegram Group (US)