Вводная

Привет! Я Лера Черепанова, руковожу UX-лабораторией в Контуре.

UX-лаборатория — одно из подразделений Бюро разработки Контура. Это такое внутреннее агентство, состоящее из множества маленьких команд: дизайн-бюро, бюро тестирования, бюро аналитиков, бюро технических писателей, бюро разработчиков и даже бюро менеджеров разработки. Мы подключаемся к разным командам Контура на «контракты» и решаем поставленные задачи: от проведения UX-исследования до написания кода.

Проблема

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

Получается, что с результатом нашей работы команда остается один на один, и мы не знаем, что происходит дальше: что из сделанного нами пойдет в работу и как будет использоваться в дальнейшем. Заказчик может интерпретировать результаты UX-исследования по-своему или в принципе не учитывать их при формировании решения, может переписать код разработчика или не взять в работу аналитику по фиче. А нам в Бюро очень хотелось понимать, что происходит с результатами нашей работы, какую пользу они приносят, какую бизнес-ценность дают. 

Здесь может возникнуть закономерный вопрос: а зачем сотруднику проектного формата, даже во внутреннем агентстве, понимать, что происходит с результатом его работы? Это ведь его осознанный выбор — работать в таком формате. Но на самом деле эта информация важна как минимум на трёх уровнях.

Уровень сотрудника

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

Руководитель сотрудника 

Руководитель, в свою очередь, убеждается, что сотрудник работает корректно и приносит пользу. Кажется, что это и без подобных измерений очевидно, но на практике не всегда получается измерить качество работы, например, UX-исследователя. Исследование может быть методологически верным, не подкопаешься. Но если погрузиться глубже, может оказаться, что его не нужно было проводить или нужно было, но вообще на другую тему и с другими гипотезами. Довольно легко сделать классное исследование по ненужной пользователю фиче и не получить никакой пользы. А вот отловить это гораздо сложнее.

Уровень руководителя Бюро

Руководителю бюро важно обеспечить управляемость и эффективную работу всего бюро.

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

На основе знания о таких кейсах мы меняли внутренние процессы:

• Пересмотрели регламент брифинга заказчика,

• Определили, в каких ситуациях нужно вовремя эскалировать вопросы на более высокий уровень,

• Договорились, когда лучше остановить работу совсем и разобраться с корректностью запроса,

• Изменили процесс планирования задач и приоритизацию.

Всё это помогает повышать уровень компетенций как конкретного сотрудника, так и всего Бюро в целом.

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

• Крупных команд с разветвлённой структурой. 

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

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

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

• Команд, работающих по принципу каскадной модели (вотерфол), где, по сути, каждый следующий этап разработки как заказной. 

• Ролей, не работающих с кодом и с разработкой напрямую.

  • Технические писатели. Можно написать тонны документации, но как убедиться, что это было нужно команде? Это не видно напрямую из самого факта наличия документации или запроса на неё. Можно измерить количество заходов на страницы с документацией, но даст ли это информацию о том, насколько работа была полезной?

  • Дизайнеры. Часто уже реализованный макет можно увидеть на тестовом стенде — когда поздно что-либо менять и не понятно, почему часть работы была проделана впустую.

  • Такие же проблемы могут быть и у UX-исследователей, менеджеров разработки и т.д.

Но вернемся к Бюро. Чтобы научиться измерять пользу и приносимую бизнес-ценность, мы организовали рабочую группу.

Рабочая группа

Первая итерация эксперимента

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

Критерии такого инструмента:

• Один инструмент, например, анкета, одинаковый для всех ролей.

• Одна метрика и единообразная оценка.

• Можно сравнивать и собирать статистику.

• Можно выделить неудачные кейсы и работать с ними прицельно.

• Это не оценка работы конкретного человека.

Изначально задача звучала как «Научиться измерять бизнес-успешность Бюро разработки».

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

Ответы были такими:

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

• Результатами работы Бюро пользуются, нет работы «в стол». Если есть случаи, когда артефакты не были использованы, то важно понимать, почему это произошло, как это может повлиять на планирование следующих задач.

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

Обдумывая эти ответы, мы столкнулись с первой проблемой:

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

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

Например, было непонятно, как измерять бизнес-успешность работы UX-исследователя. Собирать пользовательские метрики после внедрения результатов юзабилити-тестирования? А если они не настроены в продукте? А если дизайнер взял в работу не все рекомендации?

А как измерять бизнес-пользу после глубинного интервью? По объёму результатов, ушедших в аналитику? Или ждать, когда фича зарелизится, и собирать метрики там? А если ничего не ушло в разработку по результатам?

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

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

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

Мы решили собрать MVP возможного решения и пойти экспериментировать, чтобы «на боевой» собрать отзывы и выявить проблемы.

MVP

Поскольку нам важно было получить конкретную оценку и при этом учесть специфику задач, за основу мы решили взять измерение по методике CSI (Customer Satisfaction Index).

CSI рассчитывается так:

• Определяется набор параметров, которые «клиент» должен оценить, 

• Далее предлагается оценить важность каждого из параметров по шкале от 1 до 10, 

• Затем оценивается удовлетворённость каждым из параметров тоже по шкале от 1 до 10. 

Например, мы спрашиваем клиента:

Оцените важность каждого из критериев нашего обслуживания от 1 до 10:

• Удобство мобильного приложения;

• Стоимость тарифов;

• Быстрота ответа техподдержки.

Эти оценки мы складываем, делим на их количество, величину переводим в проценты, а дальше просим оценить удовлетворённость каждым из критериев:

• Оцените удобство нашего мобильного приложения,

• Оцените стоимость наших тарифов,

• Оцените быстроту ответа тех поддержки. 

Снова оценки складываем, делим на количество, величину переводим в проценты.

Итоговый CSI получаем усреднением оценок всех факторов:

(X%+Y%+Z%)/3 = A%

• Показатель CSI 80% и выше считается отличным для продукта,

• 60-80% — средним,

• ниже 60% — не очень.

Как мы приземлили CSI на свой формат

Мы хотели измерить удовлетворённость заказчика работой Бюро по трём параметрам:

• Скорость работы;

• Качество работы;

• Применимость результата.

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

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

• Самый важный — 10;

• Наименее важный — 1;

• Посередине — 5.

• Разные заказчики (если их несколько) дают разную оценку одной и той же задаче.

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

• Без чётко определённой шкалы (что значит оценка 1, 2, 3 и т.д.) сложно получить объективный и единообразный результат.

• Местами не хватает частных вопросов про особенности работы каждой роли, чтобы можно было делать более релевантные выводы.

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

А ещё мы не понимали, как мы будем работать с результатами в 93%, 80%, 85%, нужна ли нам такая точность, на что она вообще повлияет?

Вторая итерация эксперимента

В итоге мы пришли к выводу, что придуманное решение слишком сложное, детализированное и субъективное.

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

Шкала Лайкерта — это психометрическая шкала для измерения отношения, мнения или чувства респондентов путём предложения им оценить степень согласия/несогласия с утверждениями (например, от «Совершенно не согласен» до «Полностью согласен»). Это универсальный инструмент в опросах, позволяющий превратить качественные данные в количественные.

Мы стали ориентироваться на применимость результата нашей работы, хотя и про качество не забыли тоже:

Итого

Мы провели уже 4 итерации эксперимента с новой анкетой. Раз в квартал пока что руками рассылаем анкеты заказчикам позапрошлого квартала — считаем, что это оптимальный срок, за который можно успеть внедрить результаты.

Выводы:

• На анкету уходит в среднем от 1 до 5 минут — заказчики отмечают, что работать с ней легко и удобно.

• Мы стали получать больше информации о том, что происходит с результатами нашей работы, а это то, ради чего все и задумывалось. 

• Стали находить мелкие проблемы в процессах, над которыми разные роли могут точечно работать.

• Из 176 задач, по которым удалось собрать ответы, результат работы только по 4 (!) не использовался командой совсем.

• Появился дополнительный инструмент мотивации сотрудников.

Сотрудники Бюро узнают о том, как результат их работы повлиял на развитие продукта, и получают такие отзывы:

— «Внесли вагон правок после исследования. Было очень полезно»
— «Использовали результат работы разработчика в смежной задаче продакта по построению пирамиды метрик. Такого результата изначально не предполагали».
— «Сделали мигратор, который при выкатке делает жизнь проще. Выкатывать стало релизы проще».
— «Результаты исследования помогли сделать вывод, что текущую функциональность НЕ нужно развивать».

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

Как вам такой способ измерения применимости результатов работы? Делитесь в комментариях.

Больше интересного про UX-исследования в телеграм-канале «Сдоба»?