У світі розробки цифрових продуктів співпраця між UX та розробкою часто є радше ідеалом, ніж реальністю. Однак саме з цієї синергії народжуються найефективніші продукти — ті, які не лише задовольняють потреби користувачів, але й надають сенсу роботі тих, хто їх створює. Ця стаття є тематичним дослідженням того, як посилена співпраця між UX та розробниками може трансформувати продукт, що зазнає труднощів, і вдихнути нове життя в команду.

Відправна точка: Продукт у небезпеці та команда під тиском

Наша історія починається з важливого цифрового інструменту для керівників магазинів та керівників відділів у Decathlon. Розроблений для оптимізації економічних показників та ефективності використання часу, цей інструмент використовують приблизно 20 000 людей у ​​78 країнах.

З 2017 року команда, яка працювала над цим продуктом, працювала ізольовано, з поверхневою agile-культурою. Спеціалізовані розробники (фронтенд, бекенд, дані) працюють над мікрозавданнями без загального бачення, що призводить до нескінченних затримок у розробці та накопичення технічного боргу. Як приклад, і один із тригерів для подальшого, функція, на розробку якої, за оцінками, знадобилося три тижні, зайняла майже рік (і навіть тоді вона була нестабільною!). 

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

Стратегія трансформації: Автономія та знання

Зіткнувшись із цією критичною ситуацією, втрутилася команда Mayday, внутрішня ініціатива Decathlon, відома своїм прагматичним підходом. 

Рішення не могло бути суто технічним. Потрібен був поворотний момент, цілісний підхід для відновлення балансу. Команда підтримки, що складалася з чотирьох розробників та UX-дослідника, втрутилася. Стратегія оберталася навколо двох основних напрямків: покращити автономію команди et підвищити знання користувачів та продукту.

1. Розвивайте автономність команди через гнучкість та майстерність розробки програмного забезпечення

Метою було перейти від культури «проекту» до культури «продукту», де команда відчувала б повну відповідальність за цінність, яку вона створює.

• Новий склад команди: Команді потрібно розвиватися в напрямку культури повного виконання завдань та виконання всіх завдань. Ідея полягає в тому, щоб зруйнувати взаємозалежність, заохочуючи універсальність та здатність керувати проєктами від проектування до виробництва. 
• Зміцнення командної співпраці та сприяння розвитку навичок: Сесії парного програмування організовуються для обміну знаннями та передовим досвідом. Спільні перевірки коду допомагають стандартизувати конвенції та покращити якість коду.
• Самоорганізація командних ритуалів: Agile-ритуали переглядаються, щоб відновити їхню мету. Щоденні зустрічі стають скоріше оновленням прогресу у виробництві, ніж простим звітом про завдання. Регулярно проводяться ретроспективи для виявлення та вирішення проблем команди. Щотижня планується семінар з уточнення беклогу, щоб уточнити та оцінити зрілість тем, що потребують розробки.
• Інтеграція власника продукту (PO) з оглядом на 360 градусів: До команди приєднався новий Власник Продукту, який привносить цілісне бачення, що враховує потреби користувачів, регуляторні обмеження та корпоративну стратегію. Його роль стала вирішальною у спрямуванні та арбітражі запитів, навчанні говорити «ні», коли це необхідно, та визначенні пріоритетів розробки разом з командою.
• Фактори, що сприяють потоку: Такі практики, як обмеження незавершеної роботи (WIP) та підхід «припини починати, почни закінчувати», дозволяють зосередитися на виконанні завдань. Як згадувалося раніше, парне програмування сприяє обміну навичками та їх взаємодоповнюваності.
• Безперервна доставка: Спрощення розгалужень коду (розробка на основі магістральних кодів) та автоматизація тестів (перехід від ручного до майже повністю автоматизованого) значно скоротили час виходу на ринок, що дозволяє за потреби випускати кілька щоденних релізів. Це «доставка без подій», коли інструменти забезпечують безперешкодне розгортання з робочої станції розробника до користувача.

2. Підвищення знань користувачів та продукту

Роль UX-дослідника була центральною у тому, щоб занурити команду в реальність користувачів та зрозуміти продукт зсередини.

• Безпосереднє занурення у взаємодію з користувачами: Першим кроком було організувати інтерв'ю з користувачами, на які запросили розробників. Таке безпосереднє слухання допомогло створити зв'язок і надати сенсу роботі кожного.
• Впровадження аналітики використання: До втручання не було жодних аналітичних інструментів. Для розуміння фактичної поведінки користувачів у продукті були задіяні трекери. Було проведено семінар з питань іменування, щоб усі, включаючи розробників, могли переглянути та інтерпретувати ці дані.
• Моніторинг стану виробництва: Окрім аналітики використання, спільно було створено панель інструментів для відстеження помилок та показників доступності продукції. Це дозволило команді зрозуміти стан продукту та приймати обґрунтовані рішення, такі як визначення того, чи виникли проблеми всередині команди, чи у зовнішніх партнерів.
• Удосконалений підхід до дизайн-мислення: Підхід базувався на вдосконаленій моделі дизайн-мислення, що інтегрувала всю команду на кожному етапі:
  • Розуміння потреб: Інтерв'ю, аналітика.
  • Валідація та визначення обсягу: Формалізація висновків, обмін ними з усією командою.
  • Ідея та конструкція: Спільні семінари з командою (найгірші ідеї, божевільна вісімка, мозковий штурм, цінності функцій тощо).
  • Безперервне моделювання та тестування: A/B-тестування було впроваджено для порівняння двох версій продукту та спостереження за статистикою використання. Прапорець функції дозволив запропонувати певну версію продукту вибірці користувачів для отримання якісного відгуку. Тут важлива співпраця між командами UX та розробників, де розробники вносять зміни до інтерфейсу, а UX-дизайнери керують цими змінами та керують взаємодією з користувачами.

Мета UX полягає не в тому, щоб стати незамінним, а в тому, щоб сприяти отриманню зворотного зв'язку з практики та забезпечити, щоб пошук відповідей від користувачів став другою натурою для всіх розробників. Йдеться про те, щоб забезпечити те, що життєздатність (зацікавленими сторонами), доцільність (розробниками) та бажаність (за UX) враховуються з самого початку процесу.

Початкові результати: Трансформований продукт і команда

Вжиті дії мали глибокий вплив на команду та продукт.

Від команди, яка просто виконує завдання, ми переходимо до команди, яка приносить цінність і надає сенсу своїй щоденній роботі. Вона безпосередньо взаємодіє зі своїми користувачами та має можливості реагувати на нові потреби, а не просто бути виконавцем. Час виходу на ринок значно скоротився. Команда — це вже не просто кілька людей, які працюють пліч-о-пліч, а люди, які щодня спілкуються та співпрацюють, щоб приймати обґрунтовані рішення. 

Від продукту, який не міг впоратися з навантаженням великої кількості користувачів, ми перейшли до продукту, доступного постійно. Якщо раніше ми намагалися звернутися до широкої аудиторії, зрештою не надаючи цінності кожній з них, то тепер ми пропонуємо певну цінність визначеним пріоритетним цільовим групам. Продукт став набагато зрозумілішим як для розробників, так і для користувачів. 

Співпраця UX-Dev: важіль для арбітражу та визначення сенсу

На завершення, трансформація інструменту та його команди є результатом спільних зусиль. Дії з боку розробників посилили їхню автономію (визначення ритуалів, покращення журналу обробок, підтримка користувачів, безперервна доставка, перемикання функцій). Дії з боку UX розширили знання (аудити, спостереження, інтерв'ю, персони, шляхи користувачів). Але це... тісна та постійна співпраця між UX та розробниками, через спільні семінари, спільний аналіз та тестування аналітики (A/B-тестування, прапорці функцій), що дозволило надати сенсу всім цим діям.

Ця співпраця є важливою для арбітражіЙдеться не про те, щоб «робити все», а про те, оберіть свої битви з повним розумінням проекту та продукту. Чи то адаптація рівня підтримки, визначення якості коду чи визначення пріоритетів помилок, ці рішення приймаються з взаємним розумінням технічних, користувацьких та бізнес-завдань.

Ми нічого не винайшли, але впровадили найкращі практики Agile та Software Craftsmanship. Найголовніше, що ми зосередилися на фон і не лише на формаНадання сенсу кожному рішенню, кожному рядку коду, кожній взаємодії з користувачем – це те, що перетворює проєкт на високопродуктивний продукт, а команду – на двигун інновацій. Зробивши пошук відповідей у ​​польових умовах другою натурою для всіх розробників та інтегрувавши технічну доцільність з етапу проектування, UX та розробка можуть по-справжньому співпрацювати для створення продуктів, які мають значення.

Флорін Офре, дослідник UX в UX-Republic