Что не так с процессом Discovery?
Привет! С вами Анна Гореванова, UX-дизайнер. Хочу поделиться своей болью от применения разных фреймворков по типу Discovery в проектировании космолётов — сложных продуктов с большим количеством требований и жуткой комплексной техникой под капотом.
Сейчас продуктовые IT-компании повально — и не без причины — увлечены Agile и Scrum. Естественно, мне, как UX-дизайнеру, интересно по какому процессу прорабатывать макеты в продуктовой команде: с чего начинать задачу, чем заканчивать, какие этапы, роли и взаимодействие с ними, ведь в этом приходится жить каждый рабочий день. И, как намекает заголовок, что-то здесь не так.
Опыт участия в процессах проектирования
Вот крупные базовые фреймворки, по которым я работала. Не в чистом виде, конечно.
- Product Backlog Refinement в Scrum
Коротко, согласно ему Scrum-команда итеративно создает ценность для пользователя за короткий промежуток времени, или спринт. Во время спринта команда не только, собственно, пилит фичу, но и прорабатывает последующие инкременты в рамках процесса Product Backlog Refinement. Роли в команде разработки не детализированы - Discovery в Dual-Track Agile
В нем процесс поставки ценности уже конкретно делится на Discovery и Delivery. В Discovery собирают требования, проводят исследования и проектируют функционал. Результат этого процесса — команда понимает задачу настолько хорошо, что может предсказуемо сделать её за следующий спринт, в рамках процесса Delivery (как, впрочем, и в Scrum) . Роли чаще всего — Product Owner, UX-исследователь, дизайнер и data-аналитик - Waterfall
Это, конечно, не Agile, но куда без него, любимого — сначала всё проектируем, потом всё разрабатываем. Спринтов нет, до поставки ценности может пройти значительное количество времени. Зато, кстати, процесс чаще всего расписан весьма детально - Double Diamond
Основан на конвергентно-дивергентной модели: сужаемся и расширяемся. Исследуем проблему, локализуем ее, придумываем массу решений и выбираем лучшее. И передаем в разработку - Кастомные дизайн-процессы
Такие тоже были, их разрабатывали внутри дизайн-комьюнити, обычно на основе Double Diamond и… Waterfall, ограниченного в небольшой промежуток времени. Исследуем, генерим гипотезы, проверяем, валидируем с командой и, опять же, передаем в разработку
Вроде звучит довольно стройно… Но
Естественно, проблемы возникали тогда, когда начиналась практика. Куда бы я ни приходила, нигде не было такого процесса проработки фичи, который бы у меня, как у дизайнера, не вызывал вопросов — приходилось договариваться с нуля или жить по принципу Вовки из Тридевятого Царства.
- В Scrum-гайде особо не написано как именно нужно строить PBR-процесс — он просто должен быть, а дальше команда договаривается сама. Как получилось, так получилось
- В Dual-Track есть хотя бы что-то — вариации блок-схем, даже весьма детальные. Однако, акцент смещен в сторону стартапов: исследование рынка, валидация бизнес-модели, поиск product-market fit и так далее. А на проектирование решения обычно отводится один мааленький блочок, который так и называется — проектирование решения. Что внутри — одному Богу известно. Роли тоже смещены в сторону стартапов (это можно понять) , но что-то ни одного технического специалиста на горизонте…
- От Waterfall в IT в последнее время отказываются из-за турбулентности и неопределённости мира, поэтому в чистом виде я его нигде пока не встречала. Так что не будем о нём
- В кастомных дизайн-процессах, которые я видела, вроде бы всё хорошо, но выглядит так, будто дизайнер (Product Designer) — главный Dungeon Master в проектировании фичи: сам всё делает, собирает все-все требования, смотрит метрики, проводит исследования… А к техникам приходит только в самом конце, когда фича уже почти готова. К чему это приводит? Правильно — «мы не сможем это реализовать». Тонкая душевная организация не одного молодого дизайнера сломалась об эту фразу
В общем и целом — UX отдельно, техника отдельно. Проектируем идеальное решение, а потом разработка пускай думает как это приземлять
Несмотря на это, серьезных последствий не возникало. Понятно, что у каждого из этих фреймворков свои цели и задачи: системы были относительно простые, а требований не особо много (теперь я понимаю, что это было действительно «не особо») .
Что было дальше
И вот я, преисполненная ванильными фреймворками, прихожу в зубодробительный энтерпрайз, где у продукта куча стейкхолдеров, требований, зависимостей и монолитного наследия.
Проектирование сложной системы вскрывает все слабые места процесса. Как в космолёте — нагрузка настолько высокая, что любая плохо прикрученная гайка может вылететь и всё сломать
Но кажется решение всё равно есть: если задача сложная — давайте набросаем специалистов! В погоне за качеством проработки решений команда заимела UI-дизайнера, UX-дизайнера, UX-исследователя, бизнес-аналитика, бизнес-эксперта, системного аналитика, дата-аналитика, архитектора и редактора. А суть процессов осталась та же самая — UX отдельно, техника отдельно. Вот к чему это привело.
- Много участников
Мммм, какие у нас получались балаганы, сколько споров, мнений, времени на поиск слотов в календаре, встречи, погружение, убеждение, синхронизацию… А сколько ошибок было допущено из-за разного видения в голове… - Размытые границы ответственности
Экспертов много, а чем занимаются — не всегда понятно. На примере системных и бизнес-аналитиков, мне было неясно что это за птицы и чем они могут мне, дизайнеру, помочь. И все хотят проектировать функционал, представляете? А ты, дизайнер, просто красиво нарисуй (на этой ноте наверняка где-то в мире сгорел один дизайнер, и стало чуточку теплее) - Мелкие процессные трения
Кто начинает? Кто заканчивает? Мне на встречу брать аналитика? А почему аналитик не позвал меня? Казалось, бы это мелочи, но они похожи на угол шкафа, об который мизинец на ноге ударяется каждый раз. Непередаваемые ощущения - Недостаток компетенций
Да, даже когда специалистов много, такое может получиться — есть все, а того, кто нужен — нету. Например, когда функционал огромного сервиса пытаются спроектировать дизайнер и продакт, это обычно приводит к любимому разработчиками «мы не сможем это реализовать» - Слабая синхронизация ролей
Все живут как-будто в разных мирах — РО проверяет гипотезы, дизайнер дизайнит, аналитик аналитит. В итоге выясняется, что макеты одни, идеи у аналитика другие, а продакт вообще хотел третьего
Вот такая боль. Нашли в этом списке что-то знакомое? Многие дизайнеры, с кем я общалась, в жизни встречали подобное. Но, как показала практика, об этом не так много говорят, как про процесс разработки. Так вот, знайте — вы не одни! Мы собрали целый сборник проблем во взаимодействии UX-дизайнера и системного аналитика, и даже разработали решение, опишем в следующих постах.
Может у вас было что-то еще? Поделитесь в комментариях, дополним наш справочник болезней :)
Наш Telegram-канал — Проектируем космолёты