Заказал Boeing, а получил кукурузник: почему так случается и при разработке приложения
Рассказывает Софья Мухина, Lead of Business Analytics в Heads and Hands
Привет! Это Heads and Hands.
Помогаем создавать сервисы, которые нравятся пользователям и приносят прибыль бизнесу.
👉🏻 В блоге анализируем UX/UI и рассказываем, как сделать круто.
👉🏻 В Telegram разбираем супераппы и их обновления.
В сети много мемов на тему «ожидание VS реальность». Вроде заказчик и IT-компания обо всем договорились, а результат не соответствует первоначальным требованиям.
Всему виной ментальные модели: люди по-разному воспринимают информацию из-за прошлого опыта.
Как мы организовали коммуникации в Heads and Hands, чтобы не было искажений — расскажу я, Софья Мухина, Lead of Business Analytics.
Техническая документация не устраняет эффект испорченного телефона
У каждого человека свое восприятие, которое накладывается в момент приема и передачи информации. Из-за этого возникает эффект испорченного телефона.
Когда информация передается один раз между двумя людьми, отклонение незначительное. Но если она идет по цепочке, отклонение увеличивается с каждым новым посредником. А еще часть информации может просто потеряться.
Считается, что полный пакет технической документации должен закрыть этот риск. Но информацию из документации мы тоже воспринимаем по-разному: из-за прошлого опыта, убеждений и предположений.
Как мы решили проблему в Heads and Hands
Информацию от заказчика собирают два специалиста — менеджер проекта и бизнес-аналитик. Чтобы убрать эффект испорченного телефона, они лично брифуют дизайнеров, разработчиков и тестировщиков при их подключении на проект. А затем проверяют, насколько результат соответствует заданным требованиям.
Распределение ролей выглядит так:
Например, начинается этап дизайна:
- Менеджер проекта рассказывает дизайнеру про заказчика, философию и айдентику бренда, какие ощущения должен вызывать цифровой продукт. Это помогает определиться с направлением и стилистикой.
- Бизнес-аналитик рассказывает про целевую аудиторию, ее потребности и то, как мы хотим их закрывать. Здесь появляется видение UX.
Далее оба специалиста проводят ревью макетов и корректируют, если видят расхождение с заданием.
Такая коммуникация в команде помогает нам корректно передавать информацию и убрать разрыв между ожиданием заказчика и исполнением. Также важно, что разработка продукта проходит внутри одной команды, а не в распределенных: там искажения точно будут возрастать.
Спасибо за внимание!
О, так вот почему заказчики иногда получают кукурузники вместо Боингов! Виноваты ментальные модели, ага. Ну, да, конечно, это точно не связано с некомпетентностью или непониманием требований. Теперь я все понял! 🌽🛩️
Получается надо было Шатл просить, как раз может быть боинг бы и получился, он бы не летал ибо заказчик забыл предупредить о том что самолет должен летать....