В 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

Мягкие навыки для продуктовой работы

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

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

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

Это было краткое вводное в понятия hard/soft skills.

А теперь к делу — какие же мягкие навыки нужны тем, кто работает в продуктовых командах?
Помимо очевидных, я бы выделил следующий ТОП-5:
1. Любопытство и тяга к знаниям
2. Умение доставать нужную информацию
3. Решительность и находчивость
4. Структурирование информации
5. Умение вовремя остановиться

Могу рассказать по каждому навыку с примерами из опыта- почему навык важен и как его проверить/проявить.
Надо?

О таланте

О таланте

О таланте. Таланте и стае. Знаю полсотни талантливых ребят, тех кому дано природой, космосом, родителями, средой, умение видеть в своем деле больше и глубже других. Все — сложные. Но видел я и как сложно бывает таким людям попадать в среду людей и задач не обремененных сложностью. Талантливый всегда в сомнении, в понимании промежуточности любого успеха и жестоком давлении на самого себя.

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

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

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

Заметки на полях. Из психологии.

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

Общая формула: событие → [автоматическая мысль] → эмоция

П Р И М Е Р

Событие:
прилетает внезапная срочная задача

Автоматическая мысль, которую не замечаем:
«Я не справлюсь» (или «Я могу не справиться»)

Эмоция:
тревога

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

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

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

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

И понятно, что будет полезно уметь замечать и работать с автоматическими мыслями в обычной жизни. Если вам интересно чуть подробнее покопать для себя эту тему, то можете просто начать хотя бы со статьи на Википедии (https://ru.wikipedia.org/wiki/%D0%90%D0%B2%D1%82%D0%BE%D0%BC%D0%B0%D1%82%D0%B8%D1%87%D0%B5%D1%81%D0%BA%D0%B8%D0%B5_%D0%BC%D1%8B%D1%81%D0%BB%D0%B8), чтобы как-то сориентироваться. Понимаю, что источник не самый глубокий, но для старта может подойти.

И здесь хочется привести только опросник об автоматических мыслях Джудит Бек, который хоть немного может помочь поработать с автоматическими мыслями:

1. Каковы доказательства, поддерживающие эту идею? Каковы доказательства, противоречащие этой идее?
2. Существует ли альтернативное объяснение?
3. Что самое плохое может произойти? Смогу ли я пережить это? Что самое лучшее может произойти? Каков самый реалистичный исход?
4. Каковы последствия моей веры в автоматическую мысль? Каковы могут быть последствия изменения моего мышления?
5. Что я должен делать в связи с этим?
6. Что я мог бы посоветовать ___ (другу), который находится в такой же ситуации?

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

Записал вводное видео про регулярные выражения

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

https://youtu.be/b-EkpnLINKw

Если кратко. Регулярные выражения помогают искать в тексте куски по сложному шаблону. Например, шаблон /[0-9]+/ найдёт в тексте все цифры, которые повторяются один или более раз подряд.

Но это самый простой случай. В примере я разбираю как работает вот такое выражение: /^(Смартфон\s)?(Apple)\s([a-z ]+)\s(\d+)GB\s(.*)\(([^(]+)\)\s([\d ]+)\sруб.$/igm.

Регулярные выражения помогают обрабатывать большие объёмы данных и приводить их к читаемому виду.

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

Периодически обновлять фреймворк

У нас в ГдеМатериале есть хорошая практика — мы периодически проверяем актуальность зависимостей. Я говорю не о мелких обновлениях и не о фиксах безопасности (они давно автоматизированы), а об обновлении мажорных версий библиотек, скажем Django с 1.11 до 2.0.

Вообще, обновление любого фреймворка — кошмар программиста. Во-первых это сложно из-за проблем с обратной совместимостью. Причём, чем больше проект, тем сложнее.

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

Самое важное в обновлении фреймворка — не копить изменения. Гораздо проще 5 раз обновить джанго на соседнюю версию, чем прыгнуть с 1.8 сразу на 2.2. Маленькие обновления приносят меньше регрессий и в целом проходят легче — согласитесь, ведь всегда же лучше растянуть один пиздец на 5 маленьких пиздецочков. Даже психологически гораздо легче решиться на маленький апгрейд, чем на большой скачок.

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