{"id":14287,"url":"\/distributions\/14287\/click?bit=1&hash=1d1b6427c21936742162fc18778388fc58ebf8e17517414e1bfb1d3edd9b94c0","title":"\u0412\u044b\u0440\u0430\u0441\u0442\u0438 \u0438\u0437 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u0447\u0438\u043a\u0430 \u0434\u043e \u0440\u0443\u043a\u043e\u0432\u043e\u0434\u0438\u0442\u0435\u043b\u044f \u0437\u0430 \u0433\u043e\u0434","buttonText":"","imageUuid":""}

Разработчики электроники хуже, чем программисты?

Скорее всего, что нет! :-) Но акценты рынка слегка поменялись. Пару десятилетий назад...

Прогресс когда-то сместился от железа к софту, и всё самое передовое, то что называется “Research” в слове RnD оттянули на себя разработчики софта. Это видно по крайней мере по объему вакансий и зарплате разработчиков.

Это в среднем - в основном. При этом по-прежнему можно видеть такие жемчужины - отрасли, где электроника (а также механика и прочая физика) имеют очень важное значение. Приведу несколько наиболее очевидных примеров:

  • Космические аппараты (SpaceX, Blue Origin, etc.)
  • Квантовые компьютеры (Q-Ctrl, Google, etc.)
  • Лидары для беспилотного транспорта (Velodynelidar, Dephan-москва*, etc.)

*- кстати, именно в компании ООО "Дефан" мы смогли успешно внедрить scrum фреймворк для RnD разработки конструкции высокочувствительного датчика.

В чем сходства и отличия разработки электроники от разработки ПО? Приведу наиболее поверхностные:

  • Различается в первую очередь скорость обратной связи от рынка/заказчиков - софтверное MVP делается быстрее. Впрочем, Илон Маск показал нам на примерах двигателя “Merlin 1А” и корпуса корабля “Starship”, что это не такая уж и великая проблема :-) Плюс, CAD моделирование и 3D печать сильно сокращают это различие.
  • А что между разработчиками ПО и железа общего - так это командная работа. И там и там мы получаем существенный прирост продуктивности, если над RnD проектом работает кросс-функциональная команда разработчиков.

Как нам сократить системное отставание RnD** электроники от RnD ПО?

  • Создать современную организационную структуру (см.: agile, scrum, OKR, management 3.0, etc.)
  • Собрать кросс-функциональную команду и выстроить в ней атмосферу доверия между участниками

Разумеется, проще сказать чем сделать. Реальная орг. структура будет сильно зависеть от негласных ожиданий руководства, а в команде должны быть мотивированные профессионалы.

И эти вопросы постепенно решаются, когда в компании есть воля к изменениям (как минимум СЕО должен быть глубоко привержен идее перемен к лучшему).

Реалии перемен.

Когда в компанию по разработке электроники приходит agile-коуч/тренер/консультант/волшебник, то он всегда работает как бы между двумя берегами:

  • Рассказать о scrum, OKR и много чего нового, которое прекрасно себя зарекомендовало в разработке ПО. И столкнуться практически сразу с сопротивлением коллектива, мол это у нас не применимо, у нас особая специфика работы - и вообще, уйдите, пожалуйста (см. 3-й закон Лармана)
  • Почти тоже самое, что и в п.1, только пообещать разработчикам и руководству, что мы просто адаптируем эдакую «заморскую невидаль» (scrum, kanban, OKR) к нашим державным реалиям. Разумеется, тем самым полностью нивелируя ценность новых идей и подходов (см. 1-й закон Лармана)

Как ни странно, между этими берегами довольно много живого пространства, если смотреть под правильным углом, верить в людей а также в перемены к лучшему.

>> Кто хочет принять активное участие во внедрении гибких подходов в сферу разработки электроники - пишите в личку https://scrum4rnd.ru, будем вместе создавать активности.

**-речь идёт исключительно об RnD, производство тут пока не рассматриваем.

0
Комментарии
-3 комментариев
Раскрывать всегда