Як взаємодіяти з розробниками: «виживальник» для неінженерів

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

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

Мене звуть Дарина, я — продакт-дизайнерка в команді Applab в Spalah. До цього працювала з різними командами розробників та бачила на власні очі, як дрібні непорозуміння між технічними та нетехнічними спеціалістами можуть перетворювати робочий процес на хаос, який так довго і ретельно створював наш менеджер. Цього завжди можна було уникнути, але до певного періоду ми не знали, як.

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

Домовтеся про базові речі

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

Термінологія: як саме ви називаєте те, з чим працюєте? З кожною новою людиною потрібно починати саме з того, як ви називаєте речі, з якими ви працюєте, і постійно покращувати порозуміння в процесі роботи. Про терміни, яких ви не знаєте, варто запитати. Памʼятайте, що не знати чогось — це окей. Втратити можливість знати — ось тут вже є питаннячка.

Умови роботи: які в розробників задачі, як вони їх пріоретизують? Які є обмеження в часі? Які є технічні обмеження? Як передавати матеріали, щоб пришвидшити роботу? Коли краще текстом, а коли краще зідзвонитися і проговорити?

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

⛔ «Ми робимо mvp, тому треба все дуже просто і швидко»
✅ «Наша задача — розробити mvp застосунку якомога швидше, тому загалом рішення мають бути простими в розробці. При цьому головні функції мають відрізнятися від функцій конкурентів і бути максимально класно продуманими з погляду UX»

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

Ми всі різні. В кожного з нас є інструкція користування, якою варто поділитися на початку співпраці.

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

Залучайте розробників на стадії концепту задачі

Наступна історія — з геймдеву. Знайомий розробник описував робочий процес короткою фразою «Вся влада у художників ігор». Нескладно здогадатися, що розробники бачать готові рішення вже тоді, коли їх затвердили на всіх рівнях в сусідній команді. Адекватні дедлайни й менеджмент дозволяють ці рішення реалізувати якомога точніше, але така ситуація не в усіх командах, особливо продуктових. Тож було б корисно не ставити розробників перед фактом задачі, а робити її з ними спільно.

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

В багатьох компаніях десь між дизайном і розробкою заведено зробити довгий дзвінок, який може називатися hand off. На ньому ви розповідаєте розробнику, що ви задизайнили, а він (чи вона) дивиться, тяжко зітхає і каже, що половина з того, що ви зробили, — неможлива в принципі, а інша половина — неможлива найближчим часом.

Робіть дзвінки з розробниками одразу після того, як були зроблені перші концепти дизайну.

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

Наприклад, на один з перших таких дзвінків я принесла прототип декількох екранів застосунку і розповіла, що ще плануємо робити в ньому. Щоб вкластися в невеликі строки на розробку MVP продукту, ми прибрали 50% складних в розробці рішень по дизайну.

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

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

Що менший час до дедлайну, то раніше розробники (і тестувальники) мають побачити концепти дизайну.

Якщо ви дизайнер, звітуєте проджект-менеджеру/ліду/хеду і влаштовуєте дизайн-ревʼю, як мінімум один раз на ньому має звучати фраза «поговорили з розробниками, вони сказали оце і оте». Якщо дизайн-ревʼю відбулося, а розробники в очі не бачили дизайни, то одразу закладайте собі в роботу час на кола правок і нових затверджень.

Ставте запитання і не бійтеся отримати «ні»

Завжди задавайте конкретні запитання. Наприклад, запитання «Чи є ще якісь питання?» насправді не спонукає до обговорення. Це те саме, якби ви просто сказали «Ну якщо питань вже немає, то... (чао!)».

Якийсь час я дивувалася, чому після передачі дизайну в розробку все одно спливають деталі, про які ніхто не згадував на дизайн-рев’ю — або ж щось здавалося простим, а виявилося, що ні.

Отже, тепер наприкінці кожного дизайн-рев’ю, коли ніхто не має запитань щодо прототипів, я ставлю розробникам ще одне, останнє: «Чи є в цьому дизайні щось, що виглядає простим і зрозумілим, але може викликати проблеми під час розробки?». Завжди знаходиться таке «щось», і ми заздалегідь обговорюємо, що робитимемо, якщо реалізація таки виявиться складною.

Наступними моїми улюбленими питаннями є:

• «Можеш, будь ласка, ще раз пояснити?»
• «А що таке (слово, яке сказав розробник)?»

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

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

Слово «ні» — найкращий фідбек, бо ви вийшли на щось дійсно важливе.

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

Наслідки поганої комунікації з розробниками

Погана комунікація з розробниками має наслідки на всіх рівнях:

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

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

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

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

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

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

Є люди, з якими будь-яка ефективна співпраця в принципі неможлива. Мова йде про токсичну поведінку та про зовсім інші методи справлятися з цим явищем. Але часто командам не вистачає вирішити декілька питань, щоб домовитися і прибрати постійну напругу з робочих процесів. Сподіваюся, ця стаття дала вам необхідні відповіді на питання, як ці процеси покращити.

Замість висновку розвиваємо емпатію

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

Нелегко бути командою, задачі якої знаходяться найближче до дати головного дедлайну.

Бути такою командою означає час від часу зіштовхуватися з наступними ситуаціями:

1. Періоди очікування задачі змінюються періодами, коли всім від вас різко і терміново все потрібно. Це виснажує.

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

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

Сподіваюся, тепер ваша комунікація з розробниками стане кращою, бо ви маєте конкретні інструкції для її налаштування і розуміння контексту, в якому працюють колеги.

У підсумку все зводиться до простих речей:

• домовлятися про термінологію та цілі;
• залучати команду розробників ще на концептах;
• ставити конкретні запитання й не боятися чути «це неможливо»;
• не кидати задачу в розробників з посилом «розбирайтеся, як хочете».

А як у вас з комунікацією в команді? Поділіться порадами й вашим досвідом в коментарях.