“..Можно, конечно, попробовать..” да, agile подход как раз и предполагает путь непрерывных проб и корректировок. В следующей публикации я уже привел интервью с менеджментом российской hardware компании (стартапа), где этот подход себя хорошо зарекомендовал - https://habr.com/ru/articles/747290/
не всем комментариям можно одинаково верить, потому что у авторов книг и публикаций есть немало конкурентов и просто откровенных троллей/хейтеров.
Если говорить о “впустую потраченных деньгах за книгу”, могу привести тот пример, что соавтор книги Joe Justice в 2023 году проводит agile-тренинги в японской компании Тойота (ранее он их проводил в Tesla, Boeing, SpaceX, etc.) эти компании вряд ли будут впустую тратить деньги. Ссылки на эти примеры приводить не буду, чтобы это не было сочтено админами за рекламу. Кому интересно - могу прислать в личку.
В следующей публикации я уже привел интервью с менеджментом российской hardware компании (стартапа), где этот подход себя хорошо зарекомендовал - https://habr.com/ru/articles/747290/
Мир людей прекрасно себя балансировал во все времена. Можно ожидать появления технологии, которая функционирует поверх существующего AI интернета - например тот же DAO (реальный web 3.0)
Уважаемый котик (к сожалению, не знаю вашего имени) благодарю, что уделяете время нашей беседе!
" Сколько хороших команд похоронили "гугл-яндекс смогли, чем мы хуже"! "
- полностью с вами согласен. Мне известно множество неуспешных попыток бездумно перенять чужой опыт в погоне за мифической "скоростью поставки". Часто это было по причине недостаточного внимания со стороны менеджмента, когда команде давали прочесть гайд, тимлида переименовывали в скрам-мастера, проджект менеджера во владельца продукта и наблюдали за лютым штормом и отторжением.
Мой подход совершенно отличается. Сперва я выясняю у руководителя - насколько он готов учиться думать и работать по-новому. И лишь убедившись, что он готов к эксперименту - пробую предлагать команде современные практики самоорганизации.
Благодарю! Очень рад видеть первый осмысленный и структурированный комментарий с начала публикации.
Насколько я понял, вы провели анализ моей статьи и построили ряд гипотез о восприятии статьи другими читателями. Благодарю за проделанную работу, это ценная обратная связь для меня как автора.
Попробую прокомментировать тезисы:
Работы по НИР и 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 департамента.
Каждый спринт запускать в серию даже для ПО это частный случай (хотя в РФ сложилось мнение, что это единственная возможность), так как скрам предназначен в первую очередь для получения быстрой обратной связи от рынка/внешнего мира. В случае hardware, за спринт возможно получить часть функционала MVP (проверено на практике) либо применение моделирования физических процессов (у меня целая команда сейчас работает над одной моделью, в конце каждого спринта - демо для стейкхолдеров с получением уточнений).
Насчёт "за месяц быстренько наладят с помощью модной фишки " - вероятно, это ваш личный опыт наблюдения. Очень интересно было бы узнать подробнее о деталях.
Мой кейс внедрения занял около 6 месяцев.
Чем плох тот же канбан? - а он не плох. Он подходит для других применений: сервис, RnD с уклоном на Development либо производство.
RnD с уклоном на Research лучше подходит именно скрам так как мы максимально быстро получаем обратную связь в конкретные сроки.
Если есть вопрос, как связаны разработчики и СЕО :
Разработчики hardware живут не в "сферическом вакууме", а в компании, где СЕО (ТОП-менеджмент в целом) задаёт правила. Если СЕО (ТОП-менеджмент в целом) решает, что в структуре компании назрели перемены - это коснется и разработчиков.
" эффективные эффективщики" - что это значит в вашем понимании? В статье об этом ничего не говорится.
Благодарю за историю о подводниках! Хорошо, образно дополняет концепцию.
Много раз рассказывал новым командам о групповой динамике Такмана, всякий раз заходило хорошо и практично.
Также интересно слышать советы от реального менеджера deep tech компании.
Знаю не по наслышке, как непросто создавать самоорганизованная (agile) команды в области хардвера.
“..Можно, конечно, попробовать..” да, agile подход как раз и предполагает путь непрерывных проб и корректировок.
В следующей публикации я уже привел интервью с менеджментом российской hardware компании (стартапа), где этот подход себя хорошо зарекомендовал - https://habr.com/ru/articles/747290/
не всем комментариям можно одинаково верить, потому что у авторов книг и публикаций есть немало конкурентов и просто откровенных троллей/хейтеров.
Если говорить о “впустую потраченных деньгах за книгу”, могу привести тот пример, что соавтор книги Joe Justice в 2023 году проводит agile-тренинги в японской компании Тойота (ранее он их проводил в Tesla, Boeing, SpaceX, etc.) эти компании вряд ли будут впустую тратить деньги. Ссылки на эти примеры приводить не буду, чтобы это не было сочтено админами за рекламу. Кому интересно - могу прислать в личку.
Приведу обзорные ссылки:
1. об agile, scrum в Тойота - https://www.infoq.com/articles/scrum-the-toyota-way/
2. об agile, scrum в BMW company (там больше о software, но тоже показательно для гигантского автоконцерна) - https://less.works/case-studies/bmw-group-autonomous-driving
3. очень интересный пример из довоенного российского Яндекса - https://habr.com/ru/companies/yandex/articles/585444/
В следующей публикации я уже привел интервью с менеджментом российской hardware компании (стартапа), где этот подход себя хорошо зарекомендовал - https://habr.com/ru/articles/747290/
Мир людей прекрасно себя балансировал во все времена. Можно ожидать появления технологии, которая функционирует поверх существующего AI интернета - например тот же DAO (реальный web 3.0)
Благодарю за комментарий. Согласен, над внятностью и четкостью мне ещё нужно много работать.
" И, видимо, без особого опыта " - явный заход сверху. Это не очень хорошо!
Раньше 6 месяцев ждать результаты действительно не нужно. Если Agile-коуч обещает другое, надо быть осторожным.
Благодарю за совет, но переписывать - не в моих правилах. Это мысли as is. Следующие статьи будут другими, с учетом комментариев сообщества.
Уважаемый котик (к сожалению, не знаю вашего имени) благодарю, что уделяете время нашей беседе!
" Сколько хороших команд похоронили "гугл-яндекс смогли, чем мы хуже"! "
- полностью с вами согласен. Мне известно множество неуспешных попыток бездумно перенять чужой опыт в погоне за мифической "скоростью поставки". Часто это было по причине недостаточного внимания со стороны менеджмента, когда команде давали прочесть гайд, тимлида переименовывали в скрам-мастера, проджект менеджера во владельца продукта и наблюдали за лютым штормом и отторжением.
Мой подход совершенно отличается. Сперва я выясняю у руководителя - насколько он готов учиться думать и работать по-новому. И лишь убедившись, что он готов к эксперименту - пробую предлагать команде современные практики самоорганизации.
Благодарю! Очень рад видеть первый осмысленный и структурированный комментарий с начала публикации.
Насколько я понял, вы провели анализ моей статьи и построили ряд гипотез о восприятии статьи другими читателями. Благодарю за проделанную работу, это ценная обратная связь для меня как автора.
Попробую прокомментировать тезисы:
Работы по НИР и 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 департамента.
Каждый спринт запускать в серию даже для ПО это частный случай (хотя в РФ сложилось мнение, что это единственная возможность), так как скрам предназначен в первую очередь для получения быстрой обратной связи от рынка/внешнего мира. В случае hardware, за спринт возможно получить часть функционала MVP (проверено на практике) либо применение моделирования физических процессов (у меня целая команда сейчас работает над одной моделью, в конце каждого спринта - демо для стейкхолдеров с получением уточнений).
100%
Насчёт "за месяц быстренько наладят с помощью модной фишки " - вероятно, это ваш личный опыт наблюдения. Очень интересно было бы узнать подробнее о деталях.
Мой кейс внедрения занял около 6 месяцев.
Чем плох тот же канбан? - а он не плох. Он подходит для других применений: сервис, RnD с уклоном на Development либо производство.
RnD с уклоном на Research лучше подходит именно скрам так как мы максимально быстро получаем обратную связь в конкретные сроки.
Если есть вопрос, как связаны разработчики и СЕО :
Разработчики hardware живут не в "сферическом вакууме", а в компании, где СЕО (ТОП-менеджмент в целом) задаёт правила. Если СЕО (ТОП-менеджмент в целом) решает, что в структуре компании назрели перемены - это коснется и разработчиков.
" эффективные эффективщики" - что это значит в вашем понимании? В статье об этом ничего не говорится.