Лишние люди на совещаниях

— Что сейчас обсуждать будем?
— Не знаю точно, вроде, какую-то новую систему с разработчиками.
— А, понятно — новые технологии!
— Да, когда только работать успевать!?

Такой диалог я слышал много раз перед обсуждением проекта или дизайна с заказчиком. У многих больших компаний, а особенно у госов в ДНК заложено: позвать как можно больше людей на совещание. И вот сидит целая толпа и обсуждает то, о чём ещё 5 минут назад многие даже не знали.
Эффективность такого совещания очень сомнительна: активничает 10% участников, а остальные ждут, когда закончится и думают: лишь бы слово не дали. Если молчуну дадут слово, то в лучшем случае, он скажет, что добавить нечего. В худшем — начнет на серьёзных щах фантазировать и предлагать ерунду или суперфункции.

Хуже всего, когда лишних людей позвали обсуждать дизайн 🤦‍♂️ — случайные люди не всегда молчат. Включается синдром актёра — позвали критиковать, значит надо критиковать. А это же дизайн — в нём все "сильные критики".

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

Чтобы совещание удалось:

  • Нужна повестка — все могли заранее подготовиться и прийти с обратной связью или мнением. Надо избегать совещаний без контектста.
  • Не нужны молчуны — все, кого позвали были активны. Кто отмалчивался — не надо больше звать в эту тему.
  • Нужны зафиксированные итоги — с ними можно ознакомить остальных, да и в целом полезно зафиксировать. О навыке резюмировать итоги обсуждений есть отдельная заметка (https://t.me/proudobstvo/187).

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

Core Protocols 2

На прошлой неделе я начал писать про Core Protocols и мы посмотрели на список Core Commitments. Если вы пропустили пост и не понимаете, о чем вообще речь, можете вернуться вот к этому посту — https://t.me/designgest/377.

Сегодня хочется перейти к самим протоколам. Но не хочется пересказывать 100% того, что вы и сами можете прочитать в статьях и книжках, а хочется подсветить части протоколов, которые кажутся наиболее интересными.

И первый протокол, о котором хочется поговорить — Check In.

Чек-ин чаще всего используется в начале встречи рабочей группы. Цель чек-ина — в заранее определенной форме поделиться мыслями и эмоциями по поводу ситуации, проекта, задачи с другими членами команды.

Иногда мы испытываем недовольство ситуацией в проекте, или у нас есть какие-то опасения, которые мы боимся или стесняемся высказать всей команде. Мы замалчиваем такие вещи или делимся с парой человек, но формально они остаются скрытыми от команды. В результате с каждым днем мы все дальше сдвигаемся от идеального пути. И только когда уже все становистя совсем плохо, начинаются разборы в духе «Я знал, что так и будет».

Чек-ин протокол предлагает простую схему для изложения чувств, он предлагает использовать всего 4 основные эмоции (напишу их на английском, чтобы у вас потом не было путаницы, если пойдете читать книгу):

GLAD (радость)
SAD (грусть)
MAD (бешенство)
AFRAID (испуг).

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

Плюс комбинацией этих базовых эмоций можно получать описание более сложных эмоций. Так например, EXCITEMENT = GLAD + AFRAID.

Стандартные правила для чек-ина следующие:
1) высказывать свои чувства без оценки и цензуры. Можно объяснить причину, по которой вы испытываете конкретные эмоции. Нельзя преуменьшать свои эмоции, говоря, например: «немного грустно».
2) нужно говорить только о своих эмоциях
3) с уважением слушать чек-ины других
4) не обсуждать и не ссылаться на чек-ины других, если нет явного приглашения для этого.

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

Вы можете даже сами с собой зачекиниться прямо сейчас, попытавшись описать свое текущее состояние по поводу вашей работы/проекта/ситуации, выделив те из 4 эмоций, которые испытываете и подумать, почему именно они выделились сейчас.

Нечто большее

В какой-то момент мы в команде стали думать о том, как приложение, которое способно автоматически определять проблемы с помощью дополненной реальности, можно выпустить в AppStore, чтобы любой пользователь мог его скачать и стать глазами исследователей, отмечая проблемы города. Правда, мы засомневались такой концепции: чем это лучше того же активного гражданина и прочих сервисов.

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

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

Таким образом, получился бы сервис, который с одной стороны собирает заказчиков-исследователей: они назначают задания и указывают стоимость за их выполнение; а с другой стороны имеются исполнители — ребята полевики, которые заинтересованы заработать и прокачаться в урбанистике.

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

Представьте, что вы как заказчик, оставляете заявку и вам за считанные дни проводят целое исследование. Прелесть!

В Usethics написали о том, как объединить подход персонажей и Jobs to be done

JTBD описывает потребности пользователя по формуле: когда X, я хочу Y, чтобы Z. «Когда я не знаю, как добраться до места (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z).

Во подходе персонажей первое место занимает персонаж: как Х, я хочу Y, чтобы Z. «Как турист (X), я хочу быстро узнать направление (Y), чтобы прийти, куда нужно (Z)». Персонажи рассказывают о пользователях продукта, а «работы» сообщают об их ключевых целях.

Подходы можно объединить: установки влияют на вероятность возникновения разных ситуаций, а ситуации влияют на конкретный опыт. На верхнем уровне — персонажи (основные типы пользователей), затем — «работы» (задачи персонажей в рамках определённых обстоятельств), а в основании — конкретные переживания пользователя на разных этапах пути.

У приложения-будильника ключевая работа — проснуться и встать вовремя. Используя JTBD, при редизайне мы не фиксируемся на конкретном решении в виде будильника. Человек может попросить другого человека разбудить или лечь спать заранее, чтобы проснуться самостоятельно и т.п.

Объединённый подход:

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

2. Проводим интервью, где оцениваем участников с точки зрения выделенных свойств, узнаём контекст, делим работу на составляющие («подработы»). Например: Подготовка ко сну → Планирование подъёма утром → Засыпание → Сон → Пробуждение → Подъём. Это не обязательно должна быть последовательность.

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

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

5. Составляем карту пользовательского опыта для каждого персонажа. В ней могут быть слои опыта: цели/потребности, опасения, действия, барьеры, инструменты, эмоции.

6. Profit (выявляем инсайты о проектируемом продукте).

https://medium.com/usethics-doc/b35d4174cea3

В какой последовательности ведётся исследование?

Глобально, исследования сводятся к тому, чтобы зафиксировать интенсивное и повседневное использование территории, поэтому вся работа строятся для удовлетворения этих требований.

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

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

Когда наблюдения выявляют частый переход дороги в неположенном месте — проводят подсчёт, чтобы выяснить распределение потоков.

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

Испытываю слабость к сделанным с любовью вещам.

Испытываю слабость к сделанным с любовью вещам.

Продукты — физические и цифровые — за которыми чувствуется человек и его мысль, не оставляют тебя равнодушным.

Казалось бы:
«Просто» крекеры.
«Просто» упаковка.

Но.

Смотрите, что написано внутри

«Привет!

Я — специальная конструкция :)

Именно благодаря мне при транспортировке крекеры не ломаются и остаются целыми.

Хорошего дня!»

То есть кто-то прошёл экстра милю:
— согласовал идею
— договорился о технологии
— и вовлёк команду в эти экстра косты на производство (с одной стороны)

С другой → удивил меня и порадовал.

Это настоящий микро-момент, где ты испытываешь своё микро-WOW: коробка рассказывает тебе свою историю в категориях пользы для тебя.

Дружественный, но не инфантильный tone-of-voice. Пожелание хорошего дня.

Если мы все с вами так будем подходить к работе, так строить команду и компанию, чтобы этого было больше — будем жить в другом мире.

Если знаете ребят — передайте респект.