Гнучкі підходи були винайдені в області програмного забезпечення та добре себе зарекомендували у цій галузі. Однак чи можна цей досвід накласти на команди, що займаються проєктування електроніки (Electronics Design)?
Останні пів року Agile.Live займався застосуванням гнучких підходів для британської компанії, яка виробляє електроніку для транспортних підприємств – готові рішення безконтактного зчитування різного виду карток під час користування пасажирами громадського транспорту (автобуси, метро, човни, трамваї тощо).
Це був для нас перший досвіт роботи з командою, що відповідає за проектування електроніки.
Команди, які займаються розробкою електроніки стикаються із наступними проблемами:
1) Прозорість процесів – відсутність розуміння, де знаходяться команди механіків, електронників, розробників. Команди, які проектують девайс, здійснюють планування і розробку за водоспадною моделлю (waterfall model), що передбачає проходження усіх фаз по черзі.
Складність полягає у тому, що електроніка сьогодні не існує сама по собі – вона інтегрована з софтом. Тому запуск нового продукту або апгрейт девайса займаємо 1-2 роки (в залежності від складності пристрою): необхідно зробити механіку (зовнішній вигляд, наявність механічних компонентів) та електроніку (плати) продукту, інтегрувати із програмним забезпеченням.
Кожна команда діє окремо від інших. На першій фазі роботи збирають вимоги до девайсу (requirement), розробляється прототип. А через 3-4 місяці на стадії розробки електроніки команда усвідомлює, що вимоги до девайсу були жахливі.
Що відрізняє hardware від software: при розробці девайсу маленький баг, що був пропущений на перших фазах, перетворюється на величезну проблему, оскільки вже є дизайн продукту, замовлені компоненти, з яких виробляються електронні плати. Ціна помилки дуже велика. Часто простіше закрити проект і почати новий, ніж фіксити проблему.
Процес розробки електроніки більш нервовий і вимагає більше документації. У цій галузі не вийде застосувати Scrum для команд, як це можливо для розробників програмного забезпечення. Бо вже на стадії друку плат, прототип має бути ідеальним і максимально протестованим. Якщо є дефекти, то компанія втрачає великі гроші і страждає репутація.
2) Друга проблема характерна для long-lead items (матеріали з тривалим терміном виробництва) – передзамовлення. Для запуску продукту у масове виробництво необхідно запланувати друк плат. Від моменту коли є готовий прототип до готового продукту на полицях у магазинах мине ще 6 місяців – час на виробництво.
Чи допоможе Agile компаніям з високотехнологічною продукцією скоротити лід-тайм та отримати конкурентну перевагу?
Розробка продукту починається командою механіків зі створення корпусу та визначенням переліку інших елементів (наприклад, кнопки, сенсори тощо) на основі вимог та дизайну. Це робиться за допомогою 3D-принтера. Далі команда електронників інтегрує плати та інші компоненти в механічну частину. Потім продукт передають команді розробників для створення софту. Але такий підхід сильно розтягує час на створення прототипу та лінійний запуск продукту до 24 місяців.
Запровадження Agile для подібних компаній дозволить запустити «паралельний інжиніринг». Під час розробки концепції корпусу, паралельно команда електронників збиратиме швидкі прототипи за допомогою 3D-принтерів без доведення елементів до «механічного перфекціонізму». Ці прототипи далі передавати наступній команді, що відповідає за написання софту.
Вже за місяць такої роботи механіків та електронників може створитися інженерний зразок (engineering sample). Команда розробників під свій софт може просити в електронників збільшити оперативну пам’ять. А електронники, у свою чергу, замовляти в механіків теплостійкіші матеріали корпусу та/або потужніші системи охолодження через вище нагрівання плати.
Постійний фідбек між командами дозволить швидше отримати не тільки зрілий прототип електроніки та механіки, але й написаний і протестований софт. Такий підхід паралельного інжинірингу (механіки, електроніки, розробники) надаватиме величезну конкурентну перевагу.
Варто зазначити, що застосування Agile-підходу під час коучінгу команд нашого клієнти проходило доволі важко: спеціалісти звикли працювати за вотерфолом та не бажали скорочувати лід-тайм. Але був великий запит у топ-менеджменту компанії. За 6 місяців нам вдалося підготувати команди до частішого випуску інженерних зразків, які будуть використані на ранніх стадіях для написання софту.
Подібний стан речей є цілком природнім: універсального рішення виправляти багі не існує; реальність гальмує впровадження agile-підходу у компаніях з проектування електроніки.
Які недоліки застосування Agile-підходу в Electronics Design
1) Витрачаються додаткові зусилля (effort). Ми даємо не ідеальну електроніку. Команда розробників пише софт не на ідеальній електроніці.
2) Підвищується інтенсивність роботи. Команда електроніки мусить частіше продукувати плати, частіше виправляти помилки. Однак у цьому недоліку є і перевага – частину цих помилок було б знайдено під час тестування за 2-3 місяці.
3) Здорожчується процес створення прототипу. Компанії приходиться частіше купувати компоненти. Запровадження Agile-підходу збільшить ціну розробки прототипу до 30% (закупівля компонентів та додаткові часові витрати спеціалістів усіх рівнів).
Який фреймоврк варто обрати для подібних випадків
Впроваджуючи Agile-підхід для компаній подібного типу краще використовувати SAFe (Scaled Agile Framework). SAFe – ідеальне рішення для команд, які створюють комбінований продукт (той, що складається з механічної, електронної та програмної частин).
Оптимальність SAFe полягає у тому, що він не вимагає безперервної доставки (Continuous delivery). Так, SAFe багато критикується у компаніях, що здійснюють розробку програмного забезпечення, але є ідеальним рішенням для бізнесів з галузі електроніки.
Завдяки своїм практикам він дозволяє ефективно координувати взаємодію між компонентами команди: дивитись за взаємозалежністю і контролювати залежності між командами. Також SAFe дозволяє контролювати складність взаємодії між командами.
SAFe здорожчує створення продукту, бо треба: частіше виробляти 3D-деталі, замовляти більше матеріалів та мікросхем; електронникам більше збирати інженерних зразків, щоб розробники швидше писали софт.
Але у підсумку це дозволить компанії скоротити лід-тайм. Якщо готовий продукт випустити у масове виробництво не через 24 місяців, а за 9-12, то витрати на розробку окупляться тим, що він швидше вийде на ринок, ніж у конкурентів.
P.S. Докладніше цей кейс буде розглянуто під час міні-конференції “Agile тренди 2023: віддалена робота та гнучкі підходи у нових галузях” 08.02.2023 о 19:00. Реєстрація та участь безкоштовні.
Автор: Слава Москаленко, співзасновник Agile.Live
ДОЛУЧИТИСЯ ДО AGILE.LIVE
Підписатися на сторінку у LinkedIn
Підписатися на Telegram-канал Agile.Live
Підписатися на You-канал Agile.Live