Как стать автором
Обновить

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

Уровень сложностиПростой
Время на прочтение2 мин
Количество просмотров11K
Всего голосов 30: ↑7 и ↓23-13
Комментарии18

Комментарии 18

Ох уж эти эффективные эффективщики. Зачем то СЕО приплели к хадварям... печатать метатеги на шелкографии плат, что б лучше индексировалось? и далее булшит на булшите...

Hidden text

СЕО тут — Chief Executive Officer, а вовсе не Сёрч Енжин Оптимизатион :-)

100%

Если есть вопрос, как связаны разработчики и СЕО :

Разработчики hardware живут не в "сферическом вакууме", а в компании, где СЕО (ТОП-менеджмент в целом) задаёт правила. Если СЕО (ТОП-менеджмент в целом) решает, что в структуре компании назрели перемены - это коснется и разработчиков.

" эффективные эффективщики" - что это значит в вашем понимании? В статье об этом ничего не говорится.

Ага. а статья получилась про сферический вакуум Agile в вымышленной команде. Примеры про гугл, маска - ни о чем. Что бы понять их, надо там поработать, а не пару слов черкануть и готово.

Сколько хороших команд похоронили "гугл-яндекс смогли, чем мы хуже"!

Уважаемый котик (к сожалению, не знаю вашего имени) благодарю, что уделяете время нашей беседе!

" Сколько хороших команд похоронили "гугл-яндекс смогли, чем мы хуже"! "

- полностью с вами согласен. Мне известно множество неуспешных попыток бездумно перенять чужой опыт в погоне за мифической "скоростью поставки". Часто это было по причине недостаточного внимания со стороны менеджмента, когда команде давали прочесть гайд, тимлида переименовывали в скрам-мастера, проджект менеджера во владельца продукта и наблюдали за лютым штормом и отторжением.

Мой подход совершенно отличается. Сперва я выясняю у руководителя - насколько он готов учиться думать и работать по-новому. И лишь убедившись, что он готов к эксперименту - пробую предлагать команде современные практики самоорганизации.

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

То обычно это означает, что в компании бардак, как раз в административной и менеджерской части, и эффективные менеджеры решили, что они сейчас всё за месяц быстренько наладят с помощью модной фишки, даже не задумываясь, как это работает и для чего это нужно.

И кстати, почему именно скрам? Чем плох тот же канбан, который, как раз таки, чаще применяют на производстве и в хардвэр РнД?

Насчёт "за месяц быстренько наладят с помощью модной фишки " - вероятно, это ваш личный опыт наблюдения. Очень интересно было бы узнать подробнее о деталях.

Мой кейс внедрения занял около 6 месяцев.

Чем плох тот же канбан? - а он не плох. Он подходит для других применений: сервис, RnD с уклоном на Development либо производство.

RnD с уклоном на Research лучше подходит именно скрам так как мы максимально быстро получаем обратную связь в конкретные сроки.

Можно как в разработке ПО максимально быстро лепить продукт и запускать в серию.

Потом патч накатим.

Каждый спринт запускать в серию даже для ПО это частный случай (хотя в РФ сложилось мнение, что это единственная возможность), так как скрам предназначен в первую очередь для получения быстрой обратной связи от рынка/внешнего мира. В случае hardware, за спринт возможно получить часть функционала MVP (проверено на практике) либо применение моделирования физических процессов (у меня целая команда сейчас работает над одной моделью, в конце каждого спринта - демо для стейкхолдеров с получением уточнений).

если оно "волшебный дым" не испустит "до", или "во время"

Несмотря на то, что НИР действительно могут некоторые общие черты с современной разработкой ПО и, следовательно, к ним могут быть в определённой мере применены гибкие методологии, сам стиль повествования крайне отталкивающий:
1) провокационный заголовок
2) хлопок по плечу грандов индустрии - "Илон Маск, Гугл и Я"
3) обильно применяемая стильная-модная (на момент года эдак 2013) терминология
4) "ценные" практические рецепты вида "Создать современную организационную структуру/Собрать команду и выстроить в ней атмосферу доверия"
4) и... И ничего. Никакой конкретики, никакого анализа реальных случаев (помог скрам/не помог скрам/сильно помог/сделал только хуже - и желательно с метриками). Претенциозная статья просто обрывается пошловатым "заходите на мой ТГ-канал". Хорошо, хоть обошлось без "А что думаете вы? Пишите в комментариях. И обязательно шерьте, ставть лайк и подписывайтесь"

Полагаю, многие из читателей восприняли форму и стиль вашего текста, как разновидность инфоцыганства.

Благодарю! Очень рад видеть первый осмысленный и структурированный комментарий с начала публикации.

Насколько я понял, вы провели анализ моей статьи и построили ряд гипотез о восприятии статьи другими читателями. Благодарю за проделанную работу, это ценная обратная связь для меня как автора.

Попробую прокомментировать тезисы:

  1. Работы по НИР и RnD сравнивать несколько некорректно, они относятся к сильно разным онтологиям. Я писал именно про RnD, с уклоном на Research.

  2. провокационный заголовок - почему бы и нет? В начале статьи приводятся примеры в hardware отраслях, где электронщики по-прежнему высоко ценятся. Далее, говорится о возможности построения самоорганизованных agile-команд даже в не IT-отрасли. Заголовок + первая строка текста отражают суть статьи.

  3. "Хлопок по плечу грандов" - соглашусь, в статье тема не раскрыта. Исправляюсь, отсылка к Гуглу и Маску не в нынешнем состоянии, а к тому времени когда они были малыми Research стартапами (и это про Agile, scrum, OKR)

  4. В 2013 терминология была модная, сейчас это практически стандарт менеджмента (имею в виду успешные компании: в мире это Tesla, BMW*, Boeing ; в РФ это например ГРАСС, Комус, Авито)

  5. Данный текст не преследовал цель исчерпывающе описать кейс или практику. Это скорее лёгкое упоминание о том, что в hardware возможна самоорганизация команд и т.д. НО - благодаря комментариям почтенной публики, мне удалось раскрыть некоторые нюансы. Например, связанные с "запуском в серию" (см. комментарий вашего коллеги - https://habr.com/ru/articles/731454/#comment_25486954)

  6. "Хорошо, хоть обошлось без "А что думаете вы? Пишите в комментариях." - а это и не нужно. Вы видите, как много людей готовы писать комментарии и высказывать свои мысли? Вполне хорошая дискуссия!

  7. термин "инфоцыганство" сейчас девальвирован, так как под этим словом можно понять практически что угодно, осветив под выгодным углом (вернее очернив собеседника).

В любом случае, данный текст привлекает большое количество неравнодушных управленцев. Я не ожидал, что мне будет писать столько людей через адрес сайта который указал. Прошу обратить внимание, что я предлагаю НЕ коммерческие услуги, а возможность обменяться опытом о внедрении гибких практик.

*о BMW скоро выйдет моя новая статья, где я расскажу об их опыте (успешном) внедрения скрам-Less в RnD AD департамента.

Если "коуч" не может внятно изложить свою идею, это не очень хорошо.

И, видимо, без особого опыта, обещать, что "сейчас любую электронную разработки переведу в (...), только бы противников перехода сразу подавить" - это тоже не очень хорошо.

Выглядит, как саморекламная статья и "не ждите результатов ранее 6 мес".

Извините, если резко. Попробуйте переписать статью.

Благодарю за комментарий. Согласен, над внятностью и четкостью мне ещё нужно много работать.

" И, видимо, без особого опыта " - явный заход сверху. Это не очень хорошо!

Раньше 6 месяцев ждать результаты действительно не нужно. Если Agile-коуч обещает другое, надо быть осторожным.

Благодарю за совет, но переписывать - не в моих правилах. Это мысли as is. Следующие статьи будут другими, с учетом комментариев сообщества.

Вы видите, как много людей готовы писать комментарии и высказывать свои мысли? Вполне хорошая дискуссия!

Очень рад видеть первый осмысленный и структурированный комментарий с начала публикации.

Как будто здесь есть какое-то противоречие )

Работы по НИР и RnD сравнивать несколько некорректно, они относятся к сильно разным онтологиям. Я писал именно про RnD, с уклоном на Research.

Гугл-переводчиком и Википедией аббревиатура "НИОКР" переводится как R&D. Соответственно, R&D с уклоном в Research - это НИОКР с уклоном в НИР. Что означает "сравнивать несколько некорректно, они относятся к сильно разным онтологиям"?

провокационный заголовок - почему бы и нет?

Технически, действительно, почему бы и нет. Если вы хотите расширить аудиторию и донести свою мысль не только до "большого количества неравнодушных управленцев", но и до разработчиков электроники, можно привлечь их внимание и таким образом. Вы его привлекли. Что дальше? Дальше вы решили "не преследовать цель исчерпывающе описать кейс или практику". Кроме этого, не-преследование данной цели было выполнено в терминологии являющейся "практически стандартом менеджмента успешных компаний", по которой "R&D и НИР относятся к сильно разным онтологиям". На ваш взгляд, как привлекаемая вами аудитория оценила данную попытку?

Я бы сказал, что структура вашей статьи отталкивающе-нескромная. Представляется, что нескромность в написании статьи на Хабре может сойти с рук если:
1) автор - состоявшаяся и хорошо известная в индустрии личность
2) статья является исчерпывающим описанием насущного кейса или практики
3) автор написал много других статей, качественных по содержанию и скромных по стилю

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

В микроэлектронике изготовление новой партии фотошаблонов и пластин это милионные затраты и месяцы работы.

Изготовление фотошаблонов - финальная стадия. До этой стадии разработка микросхемы сопровождается многократными симуляциями цифровой модели микросхемы. И, в теории, здесь есть где разгуляться гибким методологиям.

Проблема в том, что сама по себе вышеуказанная мысль умещается в две фразы и не тянет на полноценную статью. Описание же реализации гибких методологий для НИР в рамках статьи - со всеми плюсами и со всеми неизбежными минусами - возможно и было бы интересно (в рамках своего опыта или пускай даже в рамках пересказа деятельности условного Маска). Но увы.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории