Скорее всего, что нет! :-) Но акценты рынка слегка поменялись. Пару десятилетий назад...
Прогресс когда-то сместился от железа к софту, и всё самое передовое, то что называется “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-й закон Лармана)
Как ни странно, между этими берегами довольно много живого пространства, если смотреть под правильным углом, верить в людей а также в перемены к лучшему.
>> Кто хочет принять активное участие во внедрении гибких подходов в сферу разработки электроники - пишите в личку, будем вместе создавать активности.
**-речь идёт исключительно об RnD, производство тут пока не рассматриваем.
Комментарии (16)
mikkrob
25.04.2023 12:02+8Когда в компанию по разработке электроники приходит agile-коуч/тренер/консультант/волшебник,
То обычно это означает, что в компании бардак, как раз в административной и менеджерской части, и эффективные менеджеры решили, что они сейчас всё за месяц быстренько наладят с помощью модной фишки, даже не задумываясь, как это работает и для чего это нужно.
И кстати, почему именно скрам? Чем плох тот же канбан, который, как раз таки, чаще применяют на производстве и в хардвэр РнД?
scrum4rnd Автор
25.04.2023 12:02-1Насчёт "за месяц быстренько наладят с помощью модной фишки " - вероятно, это ваш личный опыт наблюдения. Очень интересно было бы узнать подробнее о деталях.
Мой кейс внедрения занял около 6 месяцев.
Чем плох тот же канбан? - а он не плох. Он подходит для других применений: сервис, RnD с уклоном на Development либо производство.
RnD с уклоном на Research лучше подходит именно скрам так как мы максимально быстро получаем обратную связь в конкретные сроки.
kkuznetzov
25.04.2023 12:02Можно как в разработке ПО максимально быстро лепить продукт и запускать в серию.
Потом патч накатим.
scrum4rnd Автор
25.04.2023 12:02Каждый спринт запускать в серию даже для ПО это частный случай (хотя в РФ сложилось мнение, что это единственная возможность), так как скрам предназначен в первую очередь для получения быстрой обратной связи от рынка/внешнего мира. В случае hardware, за спринт возможно получить часть функционала MVP (проверено на практике) либо применение моделирования физических процессов (у меня целая команда сейчас работает над одной моделью, в конце каждого спринта - демо для стейкхолдеров с получением уточнений).
Flammmable
25.04.2023 12:02+4Несмотря на то, что НИР действительно могут некоторые общие черты с современной разработкой ПО и, следовательно, к ним могут быть в определённой мере применены гибкие методологии, сам стиль повествования крайне отталкивающий:
1) провокационный заголовок
2) хлопок по плечу грандов индустрии - "Илон Маск, Гугл и Я"
3) обильно применяемая стильная-модная (на момент года эдак 2013) терминология
4) "ценные" практические рецепты вида "Создать современную организационную структуру/Собрать команду и выстроить в ней атмосферу доверия"
4) и... И ничего. Никакой конкретики, никакого анализа реальных случаев (помог скрам/не помог скрам/сильно помог/сделал только хуже - и желательно с метриками). Претенциозная статья просто обрывается пошловатым "заходите на мой ТГ-канал". Хорошо, хоть обошлось без "А что думаете вы? Пишите в комментариях. И обязательно шерьте, ставть лайк и подписывайтесь"
Полагаю, многие из читателей восприняли форму и стиль вашего текста, как разновидность инфоцыганства.
c_kotik
Ох уж эти эффективные эффективщики. Зачем то СЕО приплели к хадварям... печатать метатеги на шелкографии плат, что б лучше индексировалось? и далее булшит на булшите...
Hidden text
mayorovp
СЕО тут — Chief Executive Officer, а вовсе не Сёрч Енжин Оптимизатион :-)
scrum4rnd Автор
100%
scrum4rnd Автор
Если есть вопрос, как связаны разработчики и СЕО :
Разработчики hardware живут не в "сферическом вакууме", а в компании, где СЕО (ТОП-менеджмент в целом) задаёт правила. Если СЕО (ТОП-менеджмент в целом) решает, что в структуре компании назрели перемены - это коснется и разработчиков.
" эффективные эффективщики" - что это значит в вашем понимании? В статье об этом ничего не говорится.
c_kotik
Ага. а статья получилась про сферический
вакуумAgile в вымышленной команде. Примеры про гугл, маска - ни о чем. Что бы понять их, надо там поработать, а не пару слов черкануть и готово.Сколько хороших команд похоронили "гугл-яндекс смогли, чем мы хуже"!