Є щось дуже потужне у роботі в міждисциплінарних командах для створення та розвитку цифрових продуктів. Так ми працюємо у Spotify! У цій статті ми зосередимося на співпраці між дизайнерами та розробниками. Ми почали з питання: "Як виглядає успішна співпраця між цими двома напрямками?" і вирішили поговорити з розробниками та дизайнерами по всій компанії, щоб почути про їх досвід того, що працює, що може піти не так і що команди роблять, щоб зробити співпрацю успішною.
Продуктові команди Spotify
У Spotify ми маємо п'ятиетапний процес, який дозволяє різним дисциплінам згуртуватись та виконувати завдання. Ми називаємо його "Масштаб" (The Scale), і він по суті є перебудовою класичної системи дизайн-мислення.
П'ять етапів, п'ять цілей
- Ми розуміємо потенційні потреби, бажання та проблеми користувачів.
- Ми міркуємо та генеруємо ідеї рішень.
- Ми будуємо продукт, інструмент або послугу та...
- Доставляємо ці рішення максимально спрощеними, щоб швидко дізнатися від наших користувачів, що працює та що ні.
- Ми беремо до уваги отриманий аналіз випущеного продукту та коригуємо рішення, щоб продовжувати досягати кращих результатів.
В ідеальному світі всі дисципліни задіяні на всіх етапах проекту, але їхня участь на кожному етапі різна. Іншими словами, різні дисципліни мають різну вагу впливу на різних етапах процесу створення продукту. Це, безумовно, виходить за рамки дизайну та розробки, але в цій статті ми зосередимося саме на цих дисциплінах.
🤤 Підписка на shelest в Telegram →
Наприклад, Дизайн може мати провідну роль на етапах «Зрозумій» та «Подумай», залучаючи точки зору користувачів, проводячи сесії генерації ідей та досліджуючи якомога більше рішень. Продукт та Розробка приєднуються, щоб переконатися, що те, що досліджується, має комерційну цінність і технічну здійсненність. Коли команда продукту узгодила рішення для тестування, а дизайнери склали схему взаємодії користувача з продуктом, розробники починають працювати над втіленням рішення в реальність. Коли провідна роль змінюється, це не повинно розглядатися як передача керма; натомість змінюється ваги впливу. Коли Дизайн відіграє провідну роль, Розробка займає пасажирське місце на передньому сидінні, і навпаки, але співпраця має завжди продовжуватися.
Процес "Масштаб" не є одноразовим циклом. Дизайн та Розробка будуть взаємодіяти як у танці, де експертиза дисциплін визначає, хто керує. Цей танець є ДНК (DNA) будь-якої успішної технічної команди. Ми називаємо це DNE (Design and Engineering) технічної команди - Дизайн та Розробка - зміщення ваги впливу та співпраця протягом усього життєвого циклу продукту або функціоналу.
Як ми можемо поєднати Дизайн та Розробку?
Як досягти успіху в цьому танці? Як ми можемо забезпечити взаємодію наших дисциплін так, щоб не перешкоджати одне одному? Які існують секрети?
Розмовляючи з нашими колегами в Spotify, виявилось, що багато речей добре працюють в танці між розробниками та дизайнерами. В загальному, обидві сторони дійсно цінують та насолоджуються спільною роботою! Дизайнери високо оцінюють, коли розробники беруть участь у дизайн процесах та пропонують свої ідеї, спільно створюють та проводять мозкові штурми. Технічна перспектива дозволяє поглянути на проблему під іншим кутом зору, що є життєво важливим для будь-якого успішного проектування продукту, і також дозволяє розробникам взяти на себе лідерство на етапі виведення продукту на ринок. Дизайнери також стверджують, що вони захоплються здатністю розробників втілювати ідеї в реальність, чарівним чином перетворюючи концепцію на стікерах на працюючу функцію.
З іншого боку, наші колеги розробники також висловили задоволення від співпраці з дизайнерами. Розробники цінують те, що дизайн як дисципліна може сприяти створенню простору для ідей, творчості та організованого мозкового штурму. Їм подобається знаходити рішення колективно, і вони впевнені, що дизайн може і буде нести факел потреб користувачів, освітлюючи шлях до прийняття складних рішень щодо продукту. На папері Дизайн і Розробка - чудова пара, і коли речі йдуть добре, вони дійсно чудові разом. Однак, як у всіх відносинах, вони не завжди бачать все однаково.
Будь-які хороші стосунки стикаються з проблемами! Давайте подивимося, що ми дізналися з історій команд, які працюють у Spotify.
Дизайнери та розробники: чотири основні причини непорозумінь
1. Недостатня співпраця
Розробники найчастіше називали роботу в ізоляції однією з найпроблемніших моделей поведінки у шлюбі між дизайном та розробкою.
Один з розробників розповів:
"На минулому проекті, де у нас були проблеми, ми працювали в силосах (Це коли окремі люди та команди працюють над однією метою, але недостатньо спілкуються між собою. Сам термін «силоси» відноситься до контейнерів, які використовуються для зберігання зерна. Тож це все одно, що люди, замкнені в контейнерах та виконують свою роботу окремо без координації.). Дизайн та Продукт почали створювати ідеї без Розробки, і вони придумали таке, що не булу життєздатним з технічної точки зору. Ми (розробники) виділили трохи часу, а потім почали розповідати Дизайну, що ми можемо, а що ні."
Інший розробник:
"Найгірший процес — отримати готові дизайни проекту, а потім сказати: ні, ми не можемо цього зробити, це не працює з технологічної точки зору."
Чому це трапляється?
Однією з причин є те, що багато дизайнерів та дизайн команд в Spotify працюють по моделі агентства. Це означає, що вони мають більше ніж одну команду, яка займається дизайном і що вони залучаються на різних етапах проекту для виконання дизай роботи. Навіть коли дизайнери працюють в одній команді, вони іноді працюють в іншому темпі, ніж розробники. Ми всі хочемо бути ефективними та швидкими, і це може призвести до того, що працюємо в силосах.
2. Проблеми з комунікацією
Як ми знаємо, недоліки у комунікації можуть зруйнувати будь-який взаємини! Наші колеги розповіли, що терміни та термінологія, типові для кожної дисципліни, можуть призвести до непорозумінь у довгостроковій перспективі. Крім того, якщо дизайнери та розробники працюють у різних темпах, є велика ймовірність, що вони зацикляться на своїх завданнях і комунікація стане менш частою.
Конкретний приклад, який ми почули від розробника, полягає в наступному:
"Розробка працює над A, а Дизайн працює над Б. Дизайнер не хоче забирати час розробників і тому працює над рішенням самостійно. Пізніше ці рішення можуть бути відхилені розробниками, оскільки вони не брали участі в їх прийнятті. У результаті дизайнеру часто доводиться починати все з нуля. А ніхто не хоче додаткової роботи."
Крім того, незрозумілий жаргон може стати перешкодою:
"Приклад моєї команди. Дизайнери розуміли MVP (мінімально життєздатний продукт) як всі необхідні опції та функціональні можливості продукту для повноцінного досвіду користувача, тоді як розробники сприймали MVP абсолютним мінімумом продукту, який може бути запущений у першій ітерації, тобто лише один варіант з кількома необхідними функціями."
Чому це відбувається?
При роботі в паралельних потоках добрі наміри не заважати один одному можуть мати шкідливі наслідки для команди. Крім того, дизайнери та розробники іноді тяжіють до різних способів роботи або конфліктуючих пріоритетів, що може призвести до того, що кожна дисципліна просуватиметься вперед у процесі таким чином, який не буде зрозумілим або оціненим партнером.
3. Відчуття блокування
Наші колеги розповіли нам, що спільна робота може призвести до того, що один з партнерів відчуває блокування від іншого.
Один з розробників сказав:
"Хотілося б, щоб дизайнери знали, що отримати задачу, а потім чекати на дизайн є дуже незручно."
З іншого боку, дизайнер:
"Хотілося б, щоб розробники розуміли, що коли ми, як команда, разом проектуємо і досліджуємо концепцію, то вони (розробники) також працюють. На цьому етапі вони не знаходяться в режимі кодингу, а приймають участь у дизайні. Це також є роботою!"
Чому це відбувається?
Існують відмінності в мисленні та методології, які посилюють це відчуття. Обидві дисципліни прагнуть вирішити проблему і запустити рішення в роботу. Дисципліна дизайну вчить нас досліджувати і тестувати, перш ніж вибрати одне рішення, яке можна розробити і випустити на ринок. Розробників вчать розробляти та релізити, і вони можуть відчувати, що їм не дають розпочати роботу, поки триває проектне дослідження і ще не прийнято рішення щодо єдиного рішення, яке потрібно розробити.
Як сказав один з дизайнерів:
"Я хотів би, щоб розробники знали, що перед тим, як розробити щось, ми повинні провести дослідженння, щоб виконати свою належну роботу як дизайнери."
4. Різниці в поглядах щодо того, що є важливим, а що - другорядним
Ми почули від розробника:
"На практиці, розробники часто відмовляють дизайнерам у їхніх ідеях. Я сам в минулому був більш фокусований на функціональності, але деталі в інтерфейсі та в користувацькому досвіді (UI/UX) дійсно мають значення."
Чому це відбувається?
Різні погляди та підходи до проекту з боку дизайнерів та розробників мають різні пріоритети.
Для дизайну важливо, щоб користувацький досвід використання продукту був достатньо продуманий до запуску, оскільки це важливо для успішного освоєння. З іншого боку, розробники хочуть якнайшвидше реалізувати функціонал і випустити його, щоб користувачі змогли скористатися ним якнайшвидше.
Ця потенційна розбіжність пріоритетів може насправді створити ідеальний баланс між двома дисциплінами, якщо її ретельно опрацювати!
Як зробити ці відносини успішними?
1. Тісно співпрацювати
Майже всі непорозуміння можна вирішити, якщо всі дисципліни будуть на одній стороні. Під час спілкування зі зацікавленими сторонами проекту, тісна командна співпраця була згадана знову і знову як ключ до успіху!
Один з розробників зазначив:
"Найкращі співпраці, які у мене були з дизайнерами, відбувались тоді, коли я міг звернутися до них за допомогою у будь-який момент, а дизайнери знали, що це нормально - аналогічно звертатися до мене/технічної команди. Взаємно розуміння - ключ до успішної співпраці!"
Дії:
- Створіть ритуали для збору фідбеку. Щотижня збирайтеся, щоб зібрати відгуки щодо користувацького досвіду продукту та прийміть рішення щодо наступних кроків.
- Беріть участь в роботі та зустрічах один одного. Робіть спільні презентації, беріть участь у демо-версіях, коментуйте документацію та спілкуйтеся у Slack.
- Сидіть в одному приміщенні і працюйте разом! Дизайнерам подобається спостерігати, як розробники чарівним чином втілюють рішення в життя, а розробники цінують зворотній зв'язок від дизайнерів.
- Створіть спільний канал у Slack, щоб підтримувати активне спілкування.
- Включайте Дизайн та Розробку з самого початку роботи та уникайте класичних передач роботи на різних етапах. Натомість розподіліть вагу впливу між дисциплінами.
2. Мати інтерес та думку щодо роботи колеги з іншої спеціальності
Як виявилося, обидві дисципліни б хотіли, щоб їхні колеги знали більше про їхню власну роботу та методи.
Дизайнер сказав:
"Хотілося б, щоб розробники знали більше про дизайн-мислення - зосереджуватися на потребах/проблемах, а не тільки на рішеннях."
А один з розробників зазначив:
"Хотілося б, щоб дизайнери краще розуміли деякі технічні обмеження та складнощі реалізації тих чи інших дизайн рішень."
Знайомство з роботою один одного допомагає розвивати емпатію, а також краще взаємодіяти на всіх етапах розробки продукту. Це також забезпечує кращий зворотній зв'язок!
Дії:
- На початку проекту організуйте робочу мітинг, щоб з'ясувати, який внесок кожна дисципліна хотіла б зробити у проект і чого вона очікує від інших.
- Не припускайте, що ваші колеги співпрацювали з вашою дисципліною раніше. Якщо ні, навчіть їх основам того, як ви виконуєте свою роботу і як вони можуть зробити свій внесок. Заодно навчіть їх деякої специфічної термінології, притаманної вашій дисципліні!
3. Будьте добрі один до одного
Пам'ятаєте, ми згадували про проблему, пов'язану з розчаруванням, коли доводиться чекати, поки хтось інший завершить свою роботу? Для цього скористайтеся порадою колеги-розробника:
"Вам потрібно постійно нагадувати собі, що сповільнюватися - це нормально. Ви не хочете, щоб ваш центральний процесор працював на 100% весь час, тому що тоді ви не зможете нічого робити з комп'ютером. Це стосується і команди. Постійне нарощування темпів не обов'язково призведе до найкращого результату."
Для того, щоб пережити важкі моменти, коли співпраця стикається зі стресом або конфліктуючими пріоритетами, спробуйте пам'ятати, що кожен вносить унікальний вклад у проект, а доброта є ключем до подолання складних моментів.
Дії:
- Познайомтеся один з одним як люди та колеги. Заплануйте зустріч 1:1 з найближчими колегами по проекту, щоб познайомитися з ними ближче. Особистий зв'язок завжди допомагає, коли на робочі зв'язки впливає стрес або суперечливі пріоритети.
- У шведській мові (бо Spotify, звісно ж, шведський) існує поняття snälltolka, що буквально перекладається як "люб'язне тлумачення". Якщо ви відчуваєте роздратування або стрес щодо свого колеги, спробуйте розтлумачити ситуацію люб'язно та сприймайти дії колеги як найкращу спробу вирішити проблему та зрушити все з мертвої точки.
Підсумовуючи
Отже, що ми вивчили про взаємини між дизайнером та розробником?
Проблеми взаємин виникають через те, що дисципліни працюють у власних силосах, відсутність комунікації, колеги по обидва боки відчувають блокування та недостатньо знають про робочі процеси та приорітети інших. Як це подолати? У більшості випадків, це полягає в тому, щоб співпрацювати більш продумано. Цього можна досягти, дізнавшись про улюблені способи роботи один одного, беручи участь у вдумливому спілкуванні, бути добрими один до одного і стаючи друзями.
Тому що, як ми всі знаємо, дружба є основою будь-яких хороших взаємин.
Текст Spotify
👉 Більшe в Telegram →
Топ коментарі (3)
Доволі актуальна тема, дякую за переклад
Трішки більше ніж 1хв читати)
та. всюди обман)