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

Каждому клочку текста из ТЗ (на голубом фоне над точкой) ставится в противопоставление ключевая точка

В этом году мы совместно с нашим техлидом Алёной Вальтер запускаем для студентов 4-го курса кафедры Прима ЮУрГУ курс по проектированию человеко-машинного интерфейса. 32 академических часа теории и столько же лабораторных практик. Слушатели — будущие разработчики ПО. Знания о Human Computer Interaction (HCI) для них важны.

В этот раз я решил соединить лучшее из двух версий своих курсов, прочитанных ранее в Мидис и курса интернатуры UX/UI, читаемого только внутри нашей компании. Должно получиться обширнее и мощнее.

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

❦

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

Готов сюжет про персонажей Карты процесса-опыта с их создателем. Мы встретились с Сергеем Чикиным, чтобы записаться, ещё в конце прошлого года, но домонтировать получилось только сейчас.

Работать с Сергеем одно удовольствие. Его остроумие и жизнерадостность не только способствуют поиску, но и превращают его в весёлое приключение.

https://vkvideo.ru/video-226266193_456239029

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

Спасибо Сергею за такой теплый отзыв и его историю проникновения Карты процесса-опыта в жизнь компании.

Книга-метод, которая изменила многое.

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

Пытаясь наладить работу, я перепробовал множество инструментов для самостоятельного проектирования и визуализации процессов — но получалось не очень. Привлекал на помощь профессиональных проектировщиков-консультантов, работающих на всю компанию, опытных и владеющих BPMN 2.0. Сотрудничать с ними было увлекательно, но подготовленные схемы оказывались слишком сложными, а мои коллеги и руководители не хотели в них разбираться. Самое же печальное было в том, что я не понимал: создаём ли мы удобный всем процесс или просто заковываем в «BPMN-бетон» то, что в итоге не будет работать…

И тут случилось чудо. Где-то полтора года назад я совершенно случайно наткнулся на книгу Андрея Шапиро в «ЛитРес». Полистал и заинтересовался картинкой на первых страницах — там была изображена карта процесса-опыта (КПО) на клочке бумаги. После этого прочитал книгу почти взахлёб. Во-первых, она написана классно, а во-вторых, я чувствовал, что в ней — именно то, что мне не просто поможет, а спасёт.
Сейчас, спустя время, мои коллеги, включая продавцов, технарей и маркетологов, сами (!) просят нарисовать им КПО, а один замечательный финансист даже сделал парочку карт самостоятельно. Вовлечённость в метод и польза от него растут у нас по экспоненте!

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

Спасибо, Андрей!


Сергей Степанушкин

Мы уже несколько лет ведём локальные встречи дизайнеров в Челябинске и Питере под маркой «Дизайн-завтраков». В Челябинске их организует моя коллега, техлид стрима UX-дизайна, Алёна Вальтер. Люди из разных городов спрашивали как организуются дизайн-завтраки, чтобы начать делать такие же мероприятия в своём городе. Алёна описала свой опыт в небольшой статье.

https://byndyusoft.com/blogs/desingbreakfastorganization

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

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

А вот схема встречи с любым артефактом из главы и её версия в форме Карты процесса-опыта

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

📍О жизни, работе и книге неспешно

📍О создании книги и невыгорании

📍О перерождении CJM

📍О рабочих и пользовательских историях

Во вторник рассказываю про Карту процесса-опыта на IIBA Kazakhstan Chapter, а в четверг веду сборку карты в прямом эфире на канале UsabilityLab. Обе встречи открыты для посещения и участия

Начинаем презентацию Карты процесса-опыта на KZ Chapter IIBA — https://us06web.zoom.us/j/81889176749?pwd=oiqlaTivxXlmd4ka9xTZevxjQUhJUz.1

Взгляд юзабилистов на КПО

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

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

Напоминаю, что сегодня в 16:00 по Москве буду картировать процесс-опыт в прямом эфире. Специальный гость расскажет свою ситуацию и для неё будет построена карта процесса-опыта.

Регистрация на сегодняшний мастер-класс

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

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

Этот танец и является современной услугой.

Проектирование процессов современной услуги — дело непросто и осложнено тем, что услуга — это что-то незримое. А то, что для нас невидимо, то и неподвластно. Не видя процессов во всех их подробностях, невозможно ни управлять ими, ни развивать их

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

Сегодня поделюсь секцией из книги «Рабочие истории. Проектирование через текстовые модели поведения с Картой реализации историй». Надеюсь закончить её черновик к концу сентября. В этом отрывке разобран щепетильный момент замены в историях пользователя на систему.

❦

Инверсия Носителя действия
В главе 7 мы встретили приём, когда рабочая история была переписана так, что в Носителе действия вместо пользователя появилась система. Этот приём как мощный, так и чрезвычайно опасный. Многие так и записывают требования к системе, вот небольшой отрывок из подобных описаний.

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

Проблема здесь в том, что написавший это, ещё мог как-то думать о сути происходящего. Он представлял себе части своей деятельности, конечный результат и то, как в результате изменений поменяется процесс. Однако по получившимся описаниям невозможно восстановить эти мысли. Главная проблема всех технических заданий (ТЗ), в шутку называемых «не ТЗ, а ХЗ», в том, что они скрывают ход мысли тех, кто их составлял. Даже писавший их через некоторое время не вспомнит почему он сделал то или иное допущение в качестве конкретного решения. Концентрация на функциях системы всегда приводит к такому зауженному видению и амнезии.

Рабочая история — это в первую очередь текстовая модель поведенческой потребности человека, и рассматривать в ней нужно действующее лицо. В период активного развития пользовательских историй в практике User Story Mapping допускалось записывать истории для разрабатываемой информационной системы, чтобы описать некоторые технические действия в ответ на предыдущую историю пользователя. Однако, на мой взгляд, все необходимые действия системы можно и лучше описать в Формах реализации под историей, так что отдельная история для системы не нужна. Когда же тогда допустимо записавать рабочии истории для системы?

Во всех ситуациях, когда нам важно что-то разработать, но у потребителя нет его собственной явной потребности, мы всё равно должны отыскать к чему прикрепить этот запрос. Чаще всего это ситуации, когда мы встречаемся с потребностью бизнеса как-то влиять на потребителя или пользователя. В этом случае мы могли бы записать рабочую историю для бизнеса, с Целью действия в его картине мира. Например, там будет «Побудить потребителя покупать залежавшийся на складе товар». Бизнес хочет побудить потребителя, однако делать он это будет скорее всего некоторым поведением системы. Например, будет рассказывать об акционных скидках и распродажах. Вот когда в Носителе действия закономерно появляется часть системы, которая будет воплощать эту потребность бизнеса.

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

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

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

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

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

Готовясь к первой лекции в вузе, вспоминал экстраординарные примеры интерфейсов, чтобы зажечь интерес студентов. В число примеров вошел чат головастиков, где каждый участник может подплыть к другим и что-то прокричать в надежде быть услышанным. А также два фрагмента из презентации «Изобретая на основе принципа» гениального Брета Виктора.

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

«Увидеть немедленно». Фрагмент из речи Брета Виктора «Изобретая на основе принципа»

«Сыграть анимацию собой», оттуда же