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

Чтобы лучше и проще донести до читателя информацию об отзывах я решил попробовать формат интервью с менеджментом:

Интервью с СЕО компании ООО “Дефан” Юрием Поздняковым
Интервью с СТО компании ООО “Дефан” Евгением Левиным

Первое получилось довольно лаконичным, привожу полный текст, а второе - очень подробное (для скрупулезных читателей!).

______________________________________________

Юрий Поздняков, СЕО компании ООО “Дефан”

**Юрий Поздняков, СЕО компании ООО “Дефан”**

Собеседник:

Юрий, что является наибольшим преимуществом внедрения agile (scrum) на ваш взгляд?

Юрий:

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

Собеседник:

Как изменилась скорость внедрения новых направлений разработки?

Юрий:

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

Собеседник:

Как изменился удельный результат работы команд?

Юрий:

Сейчас, по каждому разработчику можно сказать, что конкретно он сделал за каждый спринт. Вся работа на виду, в режиме здоровой конкуренции. Хочется подчеркнуть, что именно здоровой, поскольку скрам задает поведенческие рамки.

Собеседник:

Какие изменения произошли во взаимодействии фаундеров и разработчиков?

Юрий:

Если коротко, то раньше прослеживались настроения типа: “ты начальник, я дурак”, “а это всё менеджер проекта так решил, я тут ни при чем” или были желания поменять менеджера проекта или повлиять на него через топ-менеджмент, поскольку он задавал “неправильный” курс. Теперь каждый разработчик отчетливо ощущает свою ответственность и видит свой вклад в будущее, все вопросы только к себе, а не к менеджеру проекта. С таким подходом тяжелее жить с точки зрения ежедневных ощущений, но в стратегическом плане легче гораздо!

Собеседник:

Изменилось ли то, как видят разработчики главный продукт компании?

Юрий:

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

Собеседник:

Какова разница в усилиях, требуемых со стороны менеджмента по управлению процессом разработки?

Юрий:

Усилий теперь надо меньше, поскольку не нужен микроменеджмент и в коллективе появилась более здоровая атмосфера – у разработчиков есть общая цель, это объединяет.

Собеседник:

Благодарю, Юрий, за уделенное время и желаю процветания вашей компании!

Юрий:

Всего доброго!

______________________________________________

Евгений Левин, СТО компании ООО “Дефан”

**Евгений Левин, СТО компании ООО “Дефан”**

Собеседник:

Евгений, я хотел бы пригласить вас на интервью, в котором мы глубоко рассмотрим процесс agile трансформации в вашей компании. Будет около 10 вопросов. Они будут в основном открытые. Иногда они будут состоять из нескольких подвопросов. Возможно, мы раскроем еще более широко этот опыт. Итак, Евгений, могли бы рассказать пару слов о продукте очень коротко и вашей роли в этом продукте.

Евгений:

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

Собеседник:

Спасибо. И следующий вопрос у меня уже непосредственно касается процессов организационных. Хотел бы вам предложить переместиться в декабрь 2021 года. Могли бы вы вспомнить момент, когда вы впервые встретились с agile коучем и он сделал первую презент��цию agile и scrum. Какие тогда у вас были ожидания, а возможно даже опасения от внедрения этого нового подхода?

Евгений:

Давайте я коротко перемещусь еще на десяток лет назад, поскольку команда, с которой я работаю уже больше 20 лет, это команда, которая, вообще говоря, образовалась из лаборатории Физического Института Академии Наук (ФИАН). И некоторое время мы работали в качестве научной команды, исследуя тематику нестационарных лавинных процессов в кремнии и в каком то смысле не были нацелены на работу с рынком. После чего действительно произошли некоторые преобразования, стало понятно, что идея, которую придумали наши фаундеры имеет очень хорошие коммерческие перспективы, и команда немного переориентировалась на реальную работу с рынком, на попытку создать некоторый продукт, вывести его на рынок. И, в общем то, из научной лаборатории мы в перешли в режим коммерческой организации, стартапа, можно сказать. Тем не менее, определенный образ мыслей коллег, особенно старших коллег, он сформировался еще в советские времена. И это был подход такой научной группы, решающей научную задачу. И когда компания столкнулась с необходимостью работать с рынком, который очень динамично развивается и на котором очень существенная конкуренция всегда присутствует, возникли некоторые сложности в организации работы команды и в целом компании. И подход, который изначально использовался в управлении и планировании оказался не совсем жизнеспособным. Это первопричина того, почему мы обратили внимание на какие то другие фреймворки. Вторая причина в том, что у нас в команде достаточно большое количество очень продвинутых специалистов с огромным опытом. И их подход к работе их видение продукта и пути достижения целей может сильно отличаться. Поэтому возникла сложность с тем, какой из путей выбирать. Причем все люди умудренные опытом специалисты высокого класса, и не слушать кого-то было бы неправильно. И при этом возникла сложность с выбором, каким путем все-таки пойти.

Это второй момент. Третий момент заключается в том, что производственные циклы, циклы разработки в нашей компании, поскольку компания работает над так называемым hardware-продуктом, эти циклы очень большие. И цена ошибки в плане выбора неправильного пути, неправильного вектора разработки, она может быть очень существенной, поскольку после выбора этого вектора может пройти полгода до получения какого-либо измеримого результата. Здесь достаточно трудно планировать какими-то короткими промежутки времени и приходится планировать достаточно далеко и ошибиться здесь очень опасно. Это были три основные фактора. И путь, который компания прошла с момента образования, показывал, что таких ошибок "выбора пути" становится слишком много, и идти дальше таким же способом просто опасно. Тут и возникла мысль о том, что, может быть, надо рассмотреть какие-то другие способы достижения результата и движения к конечному продукту, в отличие от вертикального управления, жесткого планирования и так далее. И вот тут мы обратились к специалисту в этой области, который представил себя как agile коуч и познакомил команду с принципиально новым подходом, абсолютно незнакомым никому из нас. Абсолютно никто из нашей команды не знал про такой способ управления. Он называется scrum. Сергей представил этот фреймворк, расписал его особенности и нам показалось (большинству членов команды, наверное), что что-то в этом есть. И вот этот подход, когда нет какого-то "прямого" управления со стороны руководства а формируется некоторая самоорганизующаяся структура, нам показалось, что это именно тот способ, который может решить массу внутренних конфликтов, как раз связанных с разными мнениями по поводу выбора правильной стратегии развития. И ещё нам показалось, что это может встряхнуть команду и немного перенастроить ее для более эффективной работы на реальном конкурентном рынке. Наверное, так. Что еще можно добавить?

Собеседник:

Спасибо за такое подробное погружение. А был какой-то триггер? Что-то, что прямо заставило посмотреть по-другому. Может быть, какое-то особенное событие?

Евгений:

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

Собеседник:

Спасибо. Евгений, теперь я предлагаю переместиться в настоящее и посмотреть на то, как сейчас, на ваш взгляд, обстоят дела в команде разработчиков и компании в целом? Спустя эти полтора года вашего сотрудничества с agile -коучем.

Евгений:

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

То есть мы с Юрием (прим. СЕО) увидели продуктивность и эффективность этого подхода и стали в определенном смысле защитниками и проводниками этого подхода, поскольку на разных этапах, так или иначе возникало сопротивление со стороны членов команды. Мало того, могу сказать, что до сих пор оно периодически возникает, и некоторые люди предпочитают работать в другом формате, им так более комфортно, но, тем не менее, мы продолжаем имплементировать этот подход и видим эффективность результатов. И большая часть команды тоже видит эффективность этих результатов, эффективность этого подхода. Вернее одна из команд. У нас компании сейчас две команды, которые работают в новом формате. И одна из команд, которая как раз занимается ключевым продуктом - практически полностью перестроилась и работает почти в классическом формате scrum. На мой взгляд, им удается очень эффективно использовать всех специалистов, которые входят в эту команду для оперативного движения к результатам. Кроме того, важный момент, который очень привлекает и меня, и Юрия, заключается в том, что результаты работы команды - прямо на виду. То есть почти в любой момент времени понятно, над чем работают люди, какие у них есть сложности в этой работе и есть возможность достаточно оперативно вносить какие-то коррективы в соответствии с меняющейся внешней конъюнктурой. Поскольку раньше процесс разработки конструкций, это было нечто похожее на пушечное ядро, которое выпускается и летит в течение полугода. И совершенно непонятно, куда оно попадет, в цель - не в цель. Куда-то, наверное, попадет, но результат был достаточно непредсказуем. Сейчас, в этом смысле, работа стала гораздо прозрачнее и это, несомненно, огромный плюс. Вторая команда пока работает в гибридном режиме, используя классический фреймворк скрам лишь от части. Но это - вопрос времени, как мне кажется.

Собеседник:

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

Евгений:

Я попробую. У меня есть некоторая аналогия, приходящая в голову. Когда работа команды или группы людей организована в формате вертикали власти, можно сказать, вертикали управления, всегда есть человек, который берет на себя всю ответственность, и движется к цели понятным и удобным ему путем, при этом остальные люди, участвующие в процессе, сотрудники они... ну, как бы их ответственность ограничена. И они могут критиковать результат или путь, но при этом за результат или выбор пути ответственность они не берут. Как бы возлагают ее на некоего человека, который главный. Наличие главного человека, особенно если люди, которые с ним работают, достаточно продвинутые, крутые специалисты - оно может порождать конфликты внутри, поскольку специалист, если он хороший специалист, то он видит свой путь и начинает критиковать этого главного за то, что он идет неправильным путем. И вот это порождает недопонимание, конфликты, споры. А в случае со скрамом (прим. scrum-фреймворк) такого главного человека просто нет. И здесь получается ситуация, в которой каждый участник процесса/команды берет на себя ответственность, ну, можно сказать, в полном объеме. То есть все отвечают за результат над которым работают. И вот это вот отсутствие, можно сказать, "козла отпущения" - оно позволяет эффективно двигаться вперед, не создавая спорных конфликтных ситуаций. Поскольку каждый отвечает за результат и критиковать в каком то смысле может только себя. А самокритика она штука такая... ))) Гораздо проще критиковать кого-нибудь другого, чем себя. Потому что все мы молодцы, а вот он "плохой". И вот в скраме такой подход не работает, потому что если мы все не молодцы, то результата не будет. Если все будут молодцы, результат будет. И нет, кого-то, кто берет на себя всю ответственность, и на которого можно потом свалить неудачу. Вот это вот то, что убирает конфликт, убрало в нашем случае, и думаю, что, в принципе, такой подход позволяет избежать конфликтов между специалистами, у которых свое видение результата.

Собеседник:

Благодарю Евгений за такой образный ответ, очень глубоко. Вы несколько раз уже упомянули термин "результат". И чтобы читателям было более понятно о чем идет речь, могли бы вы немного развернуть, что для команды является вот этим самым результатом, который стал "более на виду", как вы сказали, более часто появляющимся, и что он физически из себя представляет?

Евгений:

Ну, тут ответ на этот вопрос очень сильно зависит от специфики. Тут универсального ответа нет, поскольку понятно, что команда, которая занимается разработкой чего-либо - например, хардверного какого-то решения, в зависимости от того над чем она работает, создает результат, который может быть очень разным. Тут, наверное, имеет смысл какой-то конкретный пример приводить. Например, команда, которая в нашей компании занимается разработкой дизайна/конструкции фотодетектора, для этой команды конкретный результат в определенный момент времени может быть разным. Но этот результат так или иначе связан с этой конструкцией. Это может быть подготовка материалов технического задания для полупроводниковой фабрики, которая будет изготавливать этот дизайн. Это может быть разработка модели, ее теоретическая и экспериментальная проработка. Это может быть, например, предварительная спецификация на очередное поколение фотоприемников, с которой команда взаимодействующая с рынком, может идти и на этот рынок, и спрашивать, выяснять, получать обратную связь от потенциальных клиентов, интересна ли им такая спецификация, или эта спецификация может быть использована внутри компании, другой командой, которая занимается разработкой устройства на основе этого фотоприемника для того, чтобы под предполагаемую спецификацию разрабатывать некоторую дополнительную электронику, некое решение, которое будет на нее опираться и позволит прийти к какому-то более законченном продукту, какой-то системе на базе нового поколения фотодетектора. Это может быть результат анализа какого-то технологического эксперимента, когда запускается некая тестовая партия, в нее закладываются предположения о поведении тех или иных параметров структуры, основанные на моделировании, после чего проводится экспериментальная проверка этих предположений и калибруется модель, которая используется для расчета электрофизики, к примеру. Т.е. масса может быть результатов. Это все связано со спецификой того, над чем работает команда. Что можно назвать результатом в широком смысле - это то, что можно показать куда-то наружу, продемонстрировать внешнему миру. Это может быть как внешний заказчик, так и внутренний внутренний заказчик, это может быть маркетолог, человек, занимающийся развитием бизнеса, команда разработки электроники, еще кто-то. Главное - получить обратную связь, которая покажет, что этот результат или цель, к которой команда идет, она правильная или неправильная, и может быть её надо скорректировать. И так далее. То есть пока команда ничего не выдает наружу, получить обратную связь невозможно. Как только есть некий промежуточный результат, сразу можно получить обратную связь. Например, команда разработала конструкцию, разработала технологию производства и показала ее каким-то внешним технологам, каким-то технологам, которые с фабрики, например. Они на нее посмотрели и сказали: "Ребята, так сделать невозможно. Вы все классно придумали, но реальная фабрика так сделать не сможет, но сможет вот так". Команда получает эту обратную связь, вносит коррективы, и в итоге, когда дизайн будет готов к производству, мы сможем его быстро запустить и получить "структуры" по разработанной технологии. Потому что набирая эту обратную связь в процессе разработки, мы адаптировали технологию под реальную фабрику. И не возникнет ситуации, что мы вырастили какого-то "коня сферического в вакууме", который очень красиво и подробно описан, но абсолютно нежизнеспособен.

Собеседник:

Благодарю, Евгений. Очень, очень глубоко. Мы нырнули сейчас достаточно в детали и я думаю, это будет исчерпывающий ответ для наших читателей. У меня осталось буквально несколько вопросов, и я хотел бы подняться немного выше и посмотреть на, так называемое, видение продукта. На ваш взгляд, как сейчас видят продукт разработчики и изменилось ли что-то в их видении продукта за эти полтора года? Именно разработчики.

Евгений:

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

Собеседник:

Спасибо. Очень объемно. Я услышал, в вашем рассказе прозвучали слова про генерального директора, который в свое время был заинтересован и вдохновлен результатами. Следующий вопрос будет на уровне стратегического управления. Как, на ваш взгляд, внедрение agile подхода за эти полтора года отразилось на скорости развития компании, на скорости принятия стратегических решений и на скорости внедрения нового? Как вы считаете?

Евгений:

Ну, как я говорил, и цикл разработки и цикл производства, когда мы говорим о полупроводниковой технологии, достаточно длинный. Поэтому существенно ускорить процесс не удается, потому что просто это невозможно. То есть фабрика не может изготовить приборы за месяц, ей для этого нужно условно полгода. Поэтому быстрых изменений в стратегическом планировании не произошло. Это планирование все равно всегда оперируют большими периодами времени и тут трудно ждать какого-то существенного ускорения процесса. Единственное, что какой-то промежуточный результат, я уже про него говорил можно получить и в процессе разработки. Менеджменту компании стало гораздо понятнее над чем работает команда, когда можно ждать тех или иных результатов, какие есть варианты развития событий в случае отрицательного или положительного результата. Гораздо проще стало взаимодействовать с инвестором, поскольку когда у менеджмента в голове четкая картина разработки, гораздо проще и увереннее можно разговаривать с теми, кто дает на это деньги. Потому что когда ты говоришь инвестору, что у нас там идет RnD, оно еще будет идти полтора года, и когда-нибудь будет результат - это никого не впечатляет. А когда ты понимаешь четко, что необходимо работать над этим, потом над этим, а затем будет то-то, и ещё есть такой-то запасной вариант, это гораздо эффективнее позволяет объяснять людям, которые дают деньги, особенно деньги на разработку, что нужно именно столько денег, столько времени и так далее. Поскольку когда компания производственная, ну, понятно, там взял деньги, произвел продукт, продал, получил прибыль. В случае со стартапом, с RnD, с разработкой, тут ситуация существенно другая. Результата-то нет, который можно было бы монетизировать. Надо как-то объяснять, что разработка идет, идет правильным путем, вот будут такие-то перспективы. И вот когда ситуация понятна, прозрачна и структурирована, конечно, намного проще взаимодействовать с инвестором.

Собеседник:

Спасибо. И у меня последний вопрос. Он, возможно, еще более открытый, чем предыдущие. Если мы посмотрим на сам термин agile трансформация, которая, как известно, может быть, начата, но она не может быть закончена. Это процесс, который идет в будущее и улучшения идут постоянно. Что, на ваш взгляд, можно было бы сделать еще лучше? И какие ваши пожелания на будущее в плане вот этой самой agile трансформации вашей компании?

Евгений:

Я не очень люблю формулировку "еще лучше". Я предпочитаю просто "лучше". Тем не менее, безусловно, если мы формируем новый подход, то понятно, что здесь нет какого-то конечного результата. Подход, он не подразумевает достижение конечного результата: достигли и все, теперь у нас все хорошо. Особенно подход, который подразумевает в принципе постоянное улучшение, модификацию, адаптацию и так далее. Понятно, что специфика классического фреймворка scrum не всегда может быть эффективно реализована в той или иной компании, поскольку все компании разные, у них внутри разные бизнес процессы и разные внешние связи. Грамотное внедрение подхода, помощь сотрудникам в адаптации и поощрение движения навстречу друг к другу, позволяют сделать лучшее из возможного. То есть, грубо говоря, нельзя внедрять некий фреймворк просто по лекалам, которые жестко заданы, и мы просто натягиваем эти лекала на реальных людей, на реальные процессы. Эти лекала должны быть тоже гибкими, подстраиваться ��од специфику. А люди должны иметь желание подстраиваться под фреймворк. Тогда это и есть эффективное внедрение. Безусловно, есть куда расти, не расти, вернее - есть, что улучшать. Есть люди, которым надо не навязывать этот фреймворк, а просто объяснять, показывать его преимущества. Тогда они будут охотнее в него встраиваться. И есть, естественно, желание адаптировать этот фреймворк под конкретных людей, чтобы им было комфортно в нем работать. То есть, с одной стороны, надо и сознание людей менять, с другой стороны, надо и фреймворк подстраивать под людей, потому что некоторые вещи просто людям комфортны, и очень трудно их сдвинуть с этого комфортного состояния. А если человек работает и ему комфортно, интересно - он тогда максимально эффективен, надо стараться это не забывать. Если что-то ему жестко навязать, он просто потеряет эффективность и все. Или вообще уйдет, что совсем плохо. Хотя и это бывает необходимо. Но, тем не менее, тут надо искать баланс.

Собеседник:

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

Евгений:

До свидания!

______________________________________________

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

Отзывы от клиентов об agile-трансформации hardware стартапа