Роль дискавері-фази в успішній розробці hardware. Ключові умови та фактори успіху

Усім привіт! Мене звати Артем, я працюю CEO у компанії «Контракт електроніка Україна». Нижче чергова стаття від мене, присвячена огляду глобальних змін в hardware-галузі.

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

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

Hardware — це не software

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

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

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

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

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

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

Тут є два принципово різні підходи до розробки на ранніх етапах:

• перший — це використання вже готових налагоджувальних плат і цілих середовищ розробки, як, наприклад, Raspberry Pi, Arduino, Nvidia, LabVIEW;
• альтернатива йому — повна розробка з нуля.

Це два різні підходи, вибір між ними залежить від того, в якому домені проєкт (Medical care або IoT, наприклад), які вимоги до NDA і багато іншого.

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

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

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

Важливі особливості дискавері-фази для hardware

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

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

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

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

Для всіх тих, хто ніколи не працював з hardware, терміни постачання мікропроцесора в 30-40 тижнів звучать трохи дико, але це нормальні терміни постачання зараз. До речі, ексклюзивні або ж, навпаки, деякі найзатребуваніші рішення можуть йти від виробника з заявленим терміном поставки 79 тижнів ;)

Таким чином, під час підбору елементної бази й майбутніх партнерів, як мінімум важливо враховувати:

• last time buy основних компонентів (можливість купівлі компонентів має перевищувати очікуваний час життя виробу, з урахуванням часу розроблення, звісно);
• можливість фізичного ввезення в країну, де знаходиться команда розробки;
• необхідність технічної підтримки від виробника;
• динаміку зміни ціни (інфляція на компоненти крайній рік іноді перевищувала 100% за рік);
• фінансовий стан компанії виробника (раптом збанкрутує).

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

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

Це комплексна задача, її рішення лежить на рівні власників та загальної стратегії компанії.

Приклади з практики

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

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

Але за тиждень до старту ми отримали лист від компанії постачальника основних компонентів про те, що у зв’язку з M&A угодою, проведеною нещодавно, компанію купив великий консорціум, стратегія якого полягає в максимальній інженерній та RnD підтримці своїх фокусних клієнтів, а саме Cisco і Nortel Networks.

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

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

Приклад номер два. До мене звернулася компанія, в якій виникла така ситуація: протягом двох років команда розробки створила надскладний продукт з розгалуженою архітектурою, процесори на який були доступні з терміном поставки від 50 тижнів. Проєкт успішно пройшов випробування і викликав інтерес у покупців, які захотіли отримати «N» систем максимально швидко.

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

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

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

«Важливо не те, кого знаєте ви, а те, хто знає Вас!» (Карл Ров)

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

Як використовувати дискавері-фазу з користю

Обидва приклади, на мою думку, ілюструють, наскільки сильно змінюється ринок hardware зараз і наскільки успіх розробки пов’язаний з ретельно проведеною дискавері-фазою.

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

• наявні ресурси та можливості компанії (усі);
• поточні вимоги ринку збуту (технічні та сертифікаційні);
• тренди розвитку ринку збуту (економічні, які можуть вплинути на купівельну поведінку до моменту виходу продукту на ринок);
• портрет клієнта і його вимоги до продукту;
• вимоги компанії до постачальників і стейкхолдерів;
• вимоги постачальників і стейкхолдерів до компанії;
• умови, за яких компанія може виконати отримані запити (наприклад, критична вимога — це термін постачання зразків для команди розробки у 2-3 дні, це можливо тільки поруч з глобальним складом компонентів за умови використання компонентів, які не потребують проєктної реєстрації).

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

Резюме

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

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

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

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

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