![](https://habrastorage.org/getpro/habr/upload_files/410/aa2/3ae/410aa23ae59f2fe4e32310bdce027b80.png)
Скорее всего, что нет! :-) Но акценты рынка слегка поменялись. Пару десятилетий назад...
Прогресс когда-то сместился от железа к софту, и всё самое передовое, то что называется “Research” в слове RnD оттянули на себя разработчики софта. Это видно по крайней мере по объему вакансий и зарплате разработчиков.
Это в среднем - в основном. При этом по-прежнему можно видеть такие жемчужины - отрасли, где электроника (а также механика и прочая физика) имеют очень важное значение. Приведу несколько наиболее очевидных примеров:
Космические аппараты (SpaceX, Blue Origin, etc.)
Квантовые компьютеры (Q-Ctrl, Google, etc.)
Лидары для беспилотного транспорта (Velodynelidar, Dephan-москва*, etc.)
*- кстати, именно в компании ООО "Дефан" мы смогли успешно внедрить scrum фреймворк для RnD разработки конструкции высокочувствительного датчика.
В чем сходства и отличия разработки электроники от разработки ПО? Приведу наиболее поверхностные:
Различается в первую очередь скорость обратной связи от рынка/заказчиков - софтверное MVP делается быстрее. Впрочем, Илон Маск показал нам на примерах двигателя “Merlin 1А” и корпуса корабля “Starship”, что это не такая уж и великая проблема :-) Плюс, CAD моделирование и 3D печать сильно сокращают это различие.
А что между разработчиками ПО и железа общего - так это командная работа. И там и там мы получаем существенный прирост продуктивности, если над RnD проектом работает кросс-функциональная команда разработчиков.
![Как считаете - это команда? Как считаете - это команда?](https://habrastorage.org/getpro/habr/upload_files/b77/be8/1c3/b77be81c3e8668340c0a30fa5758bc4f.jpg)
Как нам сократить системное отставание RnD** электроники от RnD ПО?
Создать современную организационную структуру (см.: agile, scrum, OKR, management 3.0, etc.)
Собрать кросс-функциональную команду и выстроить в ней атмосферу доверия между участниками
Разумеется, проще сказать чем сделать. Реальная орг. структура будет сильно зависеть от негласных ожиданий руководства, а в команде должны быть мотивированные профессионалы.
И эти вопросы постепенно решаются, когда в компании есть воля к изменениям (как минимум СЕО должен быть глубоко привержен идее перемен к лучшему).
![](https://habrastorage.org/getpro/habr/upload_files/31b/719/df8/31b719df870743be1fbf0930373ad99b.jpg)
Реалии перемен.
Когда в компанию по разработке электроники приходит agile-коуч/тренер/консультант/волшебник, то он всегда работает как бы между двумя берегами:
Рассказать о scrum, OKR и много чего нового, которое прекрасно себя зарекомендовало в разработке ПО. И столкнуться практически сразу с сопротивлением коллектива, мол это у нас не применимо, у нас особая специфика работы - и вообще, уйдите, пожалуйста (см. 3-й закон Лармана)
Почти тоже самое, что и в п.1, только пообещать разработчикам и руководству, что мы просто адаптируем эдакую «заморскую невидаль» (scrum, kanban, OKR) к нашим державным реалиям. Разумеется, тем самым полностью нивелируя ценность новых идей и подходов (см. 1-й закон Лармана)
Как ни странно, между этими берегами довольно много живого пространства, если смотреть под правильным углом, верить в людей а также в перемены к лучшему.
>> Кто хочет принять активное участие во внедрении гибких подходов в сферу разработки электроники - пишите в личку https://scrum4rnd.ru, будем вместе создавать активности.
**-речь идёт исключительно об RnD, производство тут пока не рассматриваем.