Нужно ли платить за услуги консультантов и бизнес-трененов?

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

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

Это часто создает иллюзию бесполезности консультаций: мне помогли осознать то, что я и так знал все это время. Еще и за деньги 🙁 Я ведь и сам мог ...

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

В принципе, если хорошо расслабиться: взять отпуск, съездить на конференцию, сходить в гости к парочке конкурентов (или от чего вас отпускает?) ... а потом сесть и записать проблемы, тенденции и действия. То да, консультант будет не нужен. Вы действительно сами знали и знаете, что делать в работе/жизни в каждый момент времени.

Помните этот прием? Выйти из комнаты, зайти в нее и сказать самому себе все то, что выдал бы крутой консультант.

Болит за тексты

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

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

Логика такая:

1 - экран (приветствие)
2 - экран (рассказываем про топ возможности нашего каталога трусов)
3 - экран (говорим, что можно купить трусняк в один клик без мозговой боли)
4 - кидаем пользователя на каталог, а лучше на топовые труселя с покупкой в один клик

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

Все чаще слышу от рынка, что есть UX копирайтеры. Отдельная профессия такая, когда пишут только под интерфейсы. Работают плотно с продактами и дизами. Насыщают текстами кнопки, меню, подсказки, ошибки, заглушки, заголовки, подписи к формам и прочие элементы.

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

Расскажите, как у вас это устроено? Опрос будет под постом.

А я вам статеек накидаю полезных про UX копирайтинг:

1. https://bit.ly/2OLJEKY - подробно разложена тема UX копирайтинга

2. https://bit.ly/2QQ2JhE - опыт Google по написанию текстов

3. https://bit.ly/34oMOed - про UX писателей

Хорошей практики пост

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

В 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

Часть вторая. Розыгрыш брифов!

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

В этот раз брифы были зашифрованы текстами песен. То есть по 1-2 строчки ты должен был догадаться о чем идет речь.

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

Первый слайд — «Все на свете из пластмассы и вокруг пластмассовая жизнь…»
В голове быстро проносится анализ: так, это либо экология, либо производство чего нибудь. Быстро решаю, что это не интересно, тем временем нужное количество человек уже подняли руки, идем дальше.

Второй слайд — «I really need you really love you, И как бы далеко бы я ни был от тебя…»
Что то про близкие отношения, думаю я, либо сервис знакомств, либо поиск кого то. Точно нет. В аудитории тоже происходит заминка. Серей Гальцев решает дать подсказку сомневающимся и говорит, что тема очень душевная. В итоге появляется нужное количество рук.

Третий слайд — «Перемен, требуют наши сердца! перемен, требуют наши глаза».
Опа, звучит круто, решаю поднять руку, но так же решает добрая половина аудитории, в итоге я был даже не четвертым, строчки явно пришлись многим по душе, так что я в пролете. Идем дальше.

Четвертый слайд — «Я раньше и не думал, что у нас на двоих с тобой одно лишь дыхание…».
Так, звучит подозрительно, дыхание, опять близость? нет не буду рисковать. В итоге команда формируется без меня.

Пятый слайд — «А у нас алкоголь дешевле, чем учебник — Так что, если ты ноешь, ты обсос, как Чендлер.»
Так, тут явно замешано образование, образовательными проектами я в той или иной мере занимался в университете, так что тоже пропускаю.

Шестой слайд — «Город-сказка, город-мечта».
Я смело поднимаю руку. Не особо следил за порядком, поэтому даже не заметил, что это последний слайд, просто понял, что мне это интересно. Урбанистика, город, в этом направление сейчас много чего происходит, должно интересно. Таким образом моя и ещё 3 руки сформировали последнюю команду.
Далее, нам показали те же самые слайды, но с брифом от заказчиков. Это было небольшое видеообращение с описанием проблемы.

1. «Все на свете из пластмассы и вокруг пластмассовая жизнь»
Фонд WWF заказал сервис, который поможет людям более осознанно подойти к проблеме загрязнения пластиком.

2. «I really need you really love you, И как бы далеко бы я ни был от тебя»
Фонд Добрая планета, попросил помочь им с организацией помощи волонтерам по работе с детьми-сиротами.

3. «Перемен, требуют наши сердца»
Фонд Борьбы с Коррупцией — это было довольно неожиданно, бриф читал начальник штаба — Леонид Волков. Он рассуждал о предстоящих выборах и о сложности наблюдений за их честностью. Его просьба была в том, чтобы придумать сервис, который облегчил бы жизнь наблюдателей. Все были немного в шоке, и я в том числе.

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

5. «А у нас алкоголь дешевле, чем учебник», Фонд поддержки образования и науки «Рекурсия» попросил помочь в проекте по менторству студентов.

6. И, наконец, «Город-сказка, город-мечта», где заказчик, в виде Студии транспортного проектирования, просил помочь в организации сбора данных на местности. И так как это моя тема, я остановлюсь на ней чуть подробнее.

Качество кода и счастье

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

Вот, к примеру, качество кодовой базы. По-идее, можно очень долго жить с горами говнокода в продакшене — просто нанимаешь в 2–3 раза больше программистов, игнорируешь высокий churn, пытаясь загасить проблему корпоративами/тимбилдингами/мотивацией, и привычно умножаешь все сроки на 3.

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

Ключевой элемент счастливой команды — качество кодовой базы: архитектура, стандарты кодирования, тесты и автоматизация рутины.

Вчера на сайте бюро вышел первый совет в серии о качестве кода (http://bit.ly/bureau-code-quality), с детальным рассказом о том, зачем это нужно бизнесу. Особенно совет полезен тем, у кого нет времени (или кому не дают времени) на рефакторинг.