Комментарии 18
Ох уж эти эффективные эффективщики. Зачем то СЕО приплели к хадварям... печатать метатеги на шелкографии плат, что б лучше индексировалось? и далее булшит на булшите...
Hidden text
![](https://habrastorage.org/getpro/habr/upload_files/e6c/f6b/819/e6cf6b819488b4e1bf939b1422e949e8.png)
СЕО тут — Chief Executive Officer, а вовсе не Сёрч Енжин Оптимизатион :-)
Если есть вопрос, как связаны разработчики и СЕО :
Разработчики hardware живут не в "сферическом вакууме", а в компании, где СЕО (ТОП-менеджмент в целом) задаёт правила. Если СЕО (ТОП-менеджмент в целом) решает, что в структуре компании назрели перемены - это коснется и разработчиков.
" эффективные эффективщики" - что это значит в вашем понимании? В статье об этом ничего не говорится.
Ага. а статья получилась про сферический вакуум Agile в вымышленной команде. Примеры про гугл, маска - ни о чем. Что бы понять их, надо там поработать, а не пару слов черкануть и готово.
Сколько хороших команд похоронили "гугл-яндекс смогли, чем мы хуже"!
Уважаемый котик (к сожалению, не знаю вашего имени) благодарю, что уделяете время нашей беседе!
" Сколько хороших команд похоронили "гугл-яндекс смогли, чем мы хуже"! "
- полностью с вами согласен. Мне известно множество неуспешных попыток бездумно перенять чужой опыт в погоне за мифической "скоростью поставки". Часто это было по причине недостаточного внимания со стороны менеджмента, когда команде давали прочесть гайд, тимлида переименовывали в скрам-мастера, проджект менеджера во владельца продукта и наблюдали за лютым штормом и отторжением.
Мой подход совершенно отличается. Сперва я выясняю у руководителя - насколько он готов учиться думать и работать по-новому. И лишь убедившись, что он готов к эксперименту - пробую предлагать команде современные практики самоорганизации.
Когда в компанию по разработке электроники приходит agile-коуч/тренер/консультант/волшебник,
То обычно это означает, что в компании бардак, как раз в административной и менеджерской части, и эффективные менеджеры решили, что они сейчас всё за месяц быстренько наладят с помощью модной фишки, даже не задумываясь, как это работает и для чего это нужно.
И кстати, почему именно скрам? Чем плох тот же канбан, который, как раз таки, чаще применяют на производстве и в хардвэр РнД?
Насчёт "за месяц быстренько наладят с помощью модной фишки " - вероятно, это ваш личный опыт наблюдения. Очень интересно было бы узнать подробнее о деталях.
Мой кейс внедрения занял около 6 месяцев.
Чем плох тот же канбан? - а он не плох. Он подходит для других применений: сервис, RnD с уклоном на Development либо производство.
RnD с уклоном на Research лучше подходит именно скрам так как мы максимально быстро получаем обратную связь в конкретные сроки.
Можно как в разработке ПО максимально быстро лепить продукт и запускать в серию.
Потом патч накатим.
Каждый спринт запускать в серию даже для ПО это частный случай (хотя в РФ сложилось мнение, что это единственная возможность), так как скрам предназначен в первую очередь для получения быстрой обратной связи от рынка/внешнего мира. В случае hardware, за спринт возможно получить часть функционала MVP (проверено на практике) либо применение моделирования физических процессов (у меня целая команда сейчас работает над одной моделью, в конце каждого спринта - демо для стейкхолдеров с получением уточнений).
если оно "волшебный дым" не испустит "до", или "во время"
Несмотря на то, что НИР действительно могут некоторые общие черты с современной разработкой ПО и, следовательно, к ним могут быть в определённой мере применены гибкие методологии, сам стиль повествования крайне отталкивающий:
1) провокационный заголовок
2) хлопок по плечу грандов индустрии - "Илон Маск, Гугл и Я"
3) обильно применяемая стильная-модная (на момент года эдак 2013) терминология
4) "ценные" практические рецепты вида "Создать современную организационную структуру/Собрать команду и выстроить в ней атмосферу доверия"
4) и... И ничего. Никакой конкретики, никакого анализа реальных случаев (помог скрам/не помог скрам/сильно помог/сделал только хуже - и желательно с метриками). Претенциозная статья просто обрывается пошловатым "заходите на мой ТГ-канал". Хорошо, хоть обошлось без "А что думаете вы? Пишите в комментариях. И обязательно шерьте, ставть лайк и подписывайтесь"
Полагаю, многие из читателей восприняли форму и стиль вашего текста, как разновидность инфоцыганства.
Благодарю! Очень рад видеть первый осмысленный и структурированный комментарий с начала публикации.
Насколько я понял, вы провели анализ моей статьи и построили ряд гипотез о восприятии статьи другими читателями. Благодарю за проделанную работу, это ценная обратная связь для меня как автора.
Попробую прокомментировать тезисы:
Работы по НИР и RnD сравнивать несколько некорректно, они относятся к сильно разным онтологиям. Я писал именно про RnD, с уклоном на Research.
провокационный заголовок - почему бы и нет? В начале статьи приводятся примеры в hardware отраслях, где электронщики по-прежнему высоко ценятся. Далее, говорится о возможности построения самоорганизованных agile-команд даже в не IT-отрасли. Заголовок + первая строка текста отражают суть статьи.
"Хлопок по плечу грандов" - соглашусь, в статье тема не раскрыта. Исправляюсь, отсылка к Гуглу и Маску не в нынешнем состоянии, а к тому времени когда они были малыми Research стартапами (и это про Agile, scrum, OKR)
В 2013 терминология была модная, сейчас это практически стандарт менеджмента (имею в виду успешные компании: в мире это Tesla, BMW*, Boeing ; в РФ это например ГРАСС, Комус, Авито)
Данный текст не преследовал цель исчерпывающе описать кейс или практику. Это скорее лёгкое упоминание о том, что в hardware возможна самоорганизация команд и т.д. НО - благодаря комментариям почтенной публики, мне удалось раскрыть некоторые нюансы. Например, связанные с "запуском в серию" (см. комментарий вашего коллеги - https://habr.com/ru/articles/731454/#comment_25486954)
"Хорошо, хоть обошлось без "А что думаете вы? Пишите в комментариях." - а это и не нужно. Вы видите, как много людей готовы писать комментарии и высказывать свои мысли? Вполне хорошая дискуссия!
термин "инфоцыганство" сейчас девальвирован, так как под этим словом можно понять практически что угодно, осветив под выгодным углом (вернее очернив собеседника).
В любом случае, данный текст привлекает большое количество неравнодушных управленцев. Я не ожидал, что мне будет писать столько людей через адрес сайта который указал. Прошу обратить внимание, что я предлагаю НЕ коммерческие услуги, а возможность обменяться опытом о внедрении гибких практик.
*о BMW скоро выйдет моя новая статья, где я расскажу об их опыте (успешном) внедрения скрам-Less в RnD AD департамента.
Если "коуч" не может внятно изложить свою идею, это не очень хорошо.
И, видимо, без особого опыта, обещать, что "сейчас любую электронную разработки переведу в (...), только бы противников перехода сразу подавить" - это тоже не очень хорошо.
Выглядит, как саморекламная статья и "не ждите результатов ранее 6 мес".
Извините, если резко. Попробуйте переписать статью.
Благодарю за комментарий. Согласен, над внятностью и четкостью мне ещё нужно много работать.
" И, видимо, без особого опыта " - явный заход сверху. Это не очень хорошо!
Раньше 6 месяцев ждать результаты действительно не нужно. Если Agile-коуч обещает другое, надо быть осторожным.
Благодарю за совет, но переписывать - не в моих правилах. Это мысли as is. Следующие статьи будут другими, с учетом комментариев сообщества.
Вы видите, как много людей готовы писать комментарии и высказывать свои мысли? Вполне хорошая дискуссия!
Очень рад видеть первый осмысленный и структурированный комментарий с начала публикации.
Как будто здесь есть какое-то противоречие )
Работы по НИР и RnD сравнивать несколько некорректно, они относятся к сильно разным онтологиям. Я писал именно про RnD, с уклоном на Research.
Гугл-переводчиком и Википедией аббревиатура "НИОКР" переводится как R&D. Соответственно, R&D с уклоном в Research - это НИОКР с уклоном в НИР. Что означает "сравнивать несколько некорректно, они относятся к сильно разным онтологиям"?
провокационный заголовок - почему бы и нет?
Технически, действительно, почему бы и нет. Если вы хотите расширить аудиторию и донести свою мысль не только до "большого количества неравнодушных управленцев", но и до разработчиков электроники, можно привлечь их внимание и таким образом. Вы его привлекли. Что дальше? Дальше вы решили "не преследовать цель исчерпывающе описать кейс или практику". Кроме этого, не-преследование данной цели было выполнено в терминологии являющейся "практически стандартом менеджмента успешных компаний", по которой "R&D и НИР относятся к сильно разным онтологиям". На ваш взгляд, как привлекаемая вами аудитория оценила данную попытку?
Я бы сказал, что структура вашей статьи отталкивающе-нескромная. Представляется, что нескромность в написании статьи на Хабре может сойти с рук если:
1) автор - состоявшаяся и хорошо известная в индустрии личность
2) статья является исчерпывающим описанием насущного кейса или практики
3) автор написал много других статей, качественных по содержанию и скромных по стилю
Проблема agile в электронике во многом заключается в том, что при обнаружении бага, софт выкатывает новую версию на следующий день.
В микроэлектронике изготовление новой партии фотошаблонов и пластин это милионные затраты и месяцы работы.
Изготовление фотошаблонов - финальная стадия. До этой стадии разработка микросхемы сопровождается многократными симуляциями цифровой модели микросхемы. И, в теории, здесь есть где разгуляться гибким методологиям.
Проблема в том, что сама по себе вышеуказанная мысль умещается в две фразы и не тянет на полноценную статью. Описание же реализации гибких методологий для НИР в рамках статьи - со всеми плюсами и со всеми неизбежными минусами - возможно и было бы интересно (в рамках своего опыта или пускай даже в рамках пересказа деятельности условного Маска). Но увы.
Разработчики электроники хуже, чем программисты?