Андрей Шапиро написал серию статей о методологии сбора требований и планирования релизов программного продукта User Story Mapping

Часть 1. Пользовательская история: https://medium.com/xraizor/b0b0d724d77e

Карта историй создаётся для нового продукта или когда существующий продукт надо частично или полностью переделать, и требуется описать объём имеющейся функциональности.

На входе метода: гипотезы состава стейкхолдеров, их интересов и основных планируемых эффектов ближайшего релиза. Хорошо, если есть картирование процессов в форматах Customer Journey Map или Service Blueprint.

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

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

Любая пользовательская истории записывается для действующего лица: персоны или функциональной роли в системе. Близкая методика Use Cases лишена эмпатии к человеку, для которого создаётся программа.

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

Часть 2. Алгоритм проведения и рекомендации для ведущего: https://medium.com/xraizor/9a90beb2ff57

Часть 3. Чистка историй от ложных требований. Критика метода: https://medium.com/xraizor/2f7bd967a54a

Производственное мышление

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

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

Итог такого подхода: бессистемное восприятие компании. Отсутствие жизненно необходимых отделов в компании. Недостаток компетенций за пределами производства. И неуспешность компании как следствие.

Лечить это сложно. Если человек уверен, что работать можно только руками, а не головой — переубедить почти нереально. Можно попробовать расширить понимание технологического цикла. Ведь это не только изготовление изделий или оказание услуг. Это более длинная цепочка от анализа рынков до продвижения и продаж. Дизайн, маркетинг, продажи — просто участки производственной цепи.

Чему научился

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

- Именно в британке узнал о существовании длинного тире и стал активно его использовать — потому что это правильно;

- Сделал первый и последний (почти) шот на дриббл;

- Количество пинов на пинтересте увеличилось в 20 раз;

- Стал читать/смотреть Варламова (спасибо блоку исследования);

- Читаю описание всех обновлений у приложений;

- Завёл привычку делать скриншоты удачных или интересующих меня моментов или паттернов используемых приложений. Иногда скриншоты жальче удалять чем фотки. На данный момент образовалась объемная коллекция на несколько гигабайт;

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

Валерия Курмак написала об организации юзабилити-тестов, в которых участвуют люди с инвалидностью

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

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

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

Лучше, если респондент использует своё устройство, поскольку каждый подстраивает скринридер под себя: скорость произношения, произносить или нет знаки препинания и так далее.

Договариваясь о встрече, спросите, нужна ли человеку помощь, чтобы добраться до вас, и какая. Если никогда не общались с человеком с инвалидностью, прочитайте специальные правила этикета.

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

Эффективно, когда команда встречается с незрячим тестировщиком, вместе с ним тестирует интерфейс и на месте договаривается о том или ином решении.

https://medium.com/Valeria.kurmak/73845933b550

Гигиена здорового коллектива

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

Необходимы процедуры, которые будут поддерживать здоровье коллектива:

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

В общем, самые классные продукты рождаются и развиваются в здоровых коллективах. Сотрудник должен профессионально расти в компании, а не за её пределами — иначе, зачем ему компания.

Необратимые действия

Есть действия, выполнение которых необратимо. Ну например,

  • отправка e-mail, СМС и прочего;
  • удаление чата;
  • удаление профиля и т.п.

Обычно перед таким действием система спрашивает: Вы уверены?
Но люди не читают, не думают наперёд, торопятся и всё равно делают необратимое действие, а потом ищут способ восстановить.
На одном b2b проекте представитель заказчика просил добавить в систему двойной вопрос на удаление:
- Вы уверены?
<Да>
- Вы точно уверены?

Мы не сделали, конечно. Добавили вместо этого для админа возможность восстанавливать удалённые записи, чтобы он это не через поддержку делал, а сам.

Но есть действия, которые пользователь выполняет часто и "задалбывать" его вопросами про уверенность — лишний шаг.
Приличные продукты для таких необратимых действий делают возможность оперативной отмены по горячим следам.
Например, при отправке письма в gmail можно отменить отправку по-быстрому (временем отмены можно управлять).
Или при удалении чата в Телеге можно отменить удаление в течение 5 секунд.

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

А выводы по необратимым действиям такие:
1. Если действие можно сделать обратимым — сделайте его таким. Особенно полезно в b2b-проектах, когда случайное удаление записи может приводить к тому, что люди готовы бэкап развернуть лишь бы восстановить.

2. Если действие необратимо и вы решили спрашивать подтверждение — спрашивайте максимально чётко с донесением последствий действий. У меня есть отдельная мини-заметка (https://telegra.ph/UX-neobratimyh-processov--pro-udalenie-04-17) про это.

3. Если делаете возможность отмены необратимого действия — покажите пользователю, сколько у него есть времени для отмены.