Інженери - ваші найкращі дизайнери

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

Правильно?

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

Конвеєрна лінія - справді диво.

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

Давайте перейдемо до сучасного світу постійних технологічних інновацій. Інновації, за визначенням, передбачають створення чогось нового, загалом дещо на замовлення, унікального цифрового продукту. Тут найпростіше - застосувати ту саму звичну складальну лінію, підхід до водоспаду.

Традиційний підхід водоспаду.

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

Agile-натхненний підхід водоспаду.

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

Кращий підхід, орієнтований на Agile.

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

Однак фактичний робочий процес у спринтах все ще по суті є складальним рядком - часто із результатами роботи, перекинутими з однієї спеціалізованої команди в іншу "через паркан". У той час, як на виробничій фабриці компанії «Форд» робота конвеєра була інкапсульована виключно на етапі виготовлення («впровадження») виробничого процесу - ефективно виробляючи один і той же продукт протягом багатьох років, складність сучасних технологічних інноваційних робіт вимагає того, що Agile підхід справді про. Справа не стільки в плануванні роботи на груди на 1–4 тижні (що, звичайно, дає бажану гнучкість бізнесу), скільки в прийнятті правильних рішень на основі зібраних і внесених даних - по суті правильна робота - спільна робота.

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

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

Зразок спільного Agile підходу. Виділення залежать від проекту до проекту, від продукту до продукту.

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

Переваги додавання розробників до команди дизайнерів на цьому не зупиняються.

Визначте правильний продукт разом

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

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

Побудувати правильно з першого разу

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

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

Працюйте розумніше, не важче. Напишіть правильний код, а не більше коду. У правильному середовищі ці теоретичні принципи стають реалістичною практикою.

Заохочуйте власність та зменшуйте управління накладними витратами

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

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

Підвищити емпатію в колективі

Усуньте вказівку пальцем і надішліть товари через паркан, що часто трапляється, коли розробники застрягли в кінці проекту. Коли ваша команда буде налаштована з першого дня, кожен член буде мати більше співчуття один до одного.

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

Збільшити щастя та утримання працівників

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

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

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

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