Создайте команду разработчиков продукта, создайте продукт, который любят ваши пользователи

В июле 2016 года меня пригласили на самый амбициозный проект в OutSystems Engineering: присоединиться к группе людей, увлеченных UX, и сформировать то, что сегодня известно как команда разработчиков продукта. Эта команда повлияла на то, как инженерия строит продукт до такой степени, что пользовательский опыт укореняется в нашей культуре. Позвольте мне рассказать вам историю о том, как мы сюда попали.

Моя история

Я инженер-программист, который присоединился к OutSystems Engineering в 2007 году. С тех пор я занимаюсь и изучаю много технических вещей. Я стал руководителем группы, и по пути я открыл для себя практичность и дизайн. Я всегда был одним из тех людей, которые действительно заботятся о наших пользователях, парнем, который экспериментировал с макетами и прототипами и проводил юзабилити-тесты перед выпуском продукта.

Январь 2015: клиент был так доволен работой моей команды,
что они послали нам счастливое новогоднее письмо.

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

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

OutSystems предлагает платформу с низким кодом для создания мобильных и веб-приложений. Наша конечная цель - улучшить жизнь разработчиков, сделав разработку быстрее и проще. Чтобы понять этих разработчиков, выяснить их потребности, разработать и проверить лучшие решения, нам нужны как инженеры, так и дизайнеры UI / UX. Я был бы инженером, а также руководителем этой новой команды, и это было серьезной задачей!

Ноябрь 2016 года - команда разработчиков продукта.

Ранние стадии: определение нашей цели и нашего видения

Первым важным решением, которое мы приняли, было присвоение команды «Product Design». Мы хотели отделиться от прошлых команд, занимающихся только дизайном. К сожалению, они были ограничены более поздними стадиями проектов, работая только над визуальным дизайном (изображения и значки) и другими элементами дизайна, которые инженеры не могут сделать, такими как футболки и кружки, и другими удивительными удачами.

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

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

Этим мы определили наше вдохновляющее видение:

Видение команды разработчиков продукта.

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

  1. Сделайте продукт простым в использовании.
  2. Сделайте изделие красивым и желанным.
  3. Помогите нашим пользователям понять ценность продукта.

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

Запуск Premortem

В прошлом мы успешно применяли полезную технику, называемую премортором (подробнее здесь), которая помогает нам прогнозировать риск в наших проектах. В преддверии мы представляем гипотетическую будущую неудачу проекта. Мы просим каждого человека, участвующего в проекте, указать, какие риски могли способствовать этому провалу. Затем мы адаптируем наши планы, чтобы избежать этих гипотетических рисков, и избежать ошибок. Так просто и мощно, правда? Это; поверь мне!

Проект Premortem

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

Оценивая наши навыки

Одним из выявленных нами рисков был междисциплинарный характер нашей команды. Дополнение наших разнообразных навыков может быть сложной задачей, и в то время у нас может не быть навыков, необходимых для нашей работы. Мы приняли вызов как прекрасную возможность для нас расти! И мы все зашли так далеко.

Мы изучили определение продукта. Мы нашли это:

Product Design выявляет, исследует и проверяет проблему, а также разрабатывает, проектирует, тестирует и доставляет решение.

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

Диаграмма, демонстрирующая навыки команды дизайнеров продукта на 2016 год.

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

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

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

Диаграмма, демонстрирующая набор навыков команды разработчиков продукта на 2018 год.

Работа с командами продукта

С нашей командой, нашим видением и поставленными целями, а также с определением и ясностью наших навыков, как мы можем реально повлиять на будущее продукта? В OutSystems Engineering есть несколько групп разработчиков, по одной для каждой области продукта: интерфейсная часть, фоновая часть, жизненный цикл приложения и т. Д.

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

  1. Мы работаем с командами, а не с командами
  2. Мы всегда стремимся добавить максимальную ценность и наименьшие накладные расходы для команд.

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

Мы определили процесс в четыре этапа: обнаружение, создание прототипа, доставка и настройка.

Четыре этапа дизайна продукта

Стадия Открытия

На данном этапе цель состоит в том, чтобы понять все о проблеме. Мы проводим собеседования, собираем отзывы из разных источников, проводим юзабилити-тесты с текущим решением, анализируем конкурентов и запускаем процесс разработки идей, чтобы найти как можно больше решений. Мы провели по-настоящему крутые эксперименты в процессе разработки идей, и сегодня мы запускаем разновидность Google Design Sprint, которую мы называем «Дизайн-сессия». Это один из самых важных этапов процесса, главным образом потому, что он объединяет всех с проблемой. мы пытаемся решить.

Ноябрь 2016: Испытание спринта Google Design.Декабрь 2016 года - продукт нашей самой первой дизайнерской сессии для полнофункционального визуального отладчика.

Стадия прототипа

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

Январь 2017: Полнофункциональные прототипы Visual Debugger.Март 2017: Бумажный прототип редактора стилей.

Этап доставки

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

Март 2017: Один из членов команды родил ребенка, вау!Сентябрь 2017 г. - последний пользовательский интерфейс диалога настройки мобильного устройства полнофункционального визуального отладчика

Этап твика

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

Эта информация помогает нам упростить дизайн.

Декабрь 2017: - Анализ показателей использования для редактора стилей.

Вспенить, промыть, повторить

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

Где мы находимся сегодня; Куда нас направляют?

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

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

Вернуться к моей истории

Это, безусловно, самый сложный и полезный проект, в котором я принимал участие за время работы в OutSystems. Проблемы постоянны; команда потрясающая! Спасибо, OutSystems, за такую ​​исключительную возможность.

Коллектив дизайнеров продуктов в 2018 году