Еще в 2014 году соучредитель Tesla Ян Райт сказал мне, что программное обеспечение Big Auto имеет тенденцию напоминать «собачий завтрак». Tesla с ее корнями в Силиконовой долине с самого начала проектировала свои автомобили с унифицированной системной архитектурой. «Это именно то, что Тесла получает прямо во сне, и большие парни действительно борются», — сказал Райт.
Вверху: демонстрация сборки робота FANUC для Илона Маск в Тесле (Flickr: Стив Джурветсон)
Спустя полдесятилетия они все еще борются, как демонстрирует программное обеспечение VW от VW с новым ID.3 EV. Тем не менее, есть некоторые более глубокие уроки, которые можно извлечь из программного мышления Тесла.
Стив Деннинг является авторитетом в области гибкого управления, методологии, которая определяет приоритеты реагирования на потребности клиентов и принятия изменений. В недавней статье в Forbes он утверждает, что разработчики аппаратного обеспечения должны придерживаться принципов Agile, чтобы идти в ногу с темпами инноваций.
Agile Manifesto, созданный семнадцатью разработчиками программного обеспечения в 2001 году, охватывает четыре основных ценности: индивидуальное взаимодействие над процессом и инструментами; рабочее программное обеспечение, а не полная документация; сотрудничество с клиентами; и реагировать на изменения, а не следовать плану. Для Деннинга основным принципом гибкости является «одержимость потребностями клиента». Он пишет, что «инновации начинаются с изменяющихся потребностей клиента и управляются ими».
Это напоминает известную линию Стива Джобса: «Начните с опыта клиентов и вернитесь к технологиям», принцип, которому Тесла следовал с большим успехом. Но какое это имеет отношение к дихотомии между аппаратным и программным обеспечением?
Много. Многие указали на очевидный факт, что атомами труднее манипулировать, чем на нули и нули, и назвали это причиной того, что инновации имеют тенденцию происходить гораздо медленнее в физическом мире. Я сам часто проводил сравнения между интернет-бумом конца 1990-х годов и нынешним переходом к электрической мобильности. Последний играет гораздо медленнее, и заманчиво предположить, что это только потому, что сборка автомобилей («сгибание металла») происходит в физическом мире. Как я уже говорил в более чем одной предыдущей статье, автомобили, в отличие от программного обеспечения, не могут быть построены в комнате в общежитии.
Однако Деннинг утверждает, что «разница между атомами и байтами далеко не вся история. Существующие производственные процессы также являются медленными, потому что они разработаны так, чтобы быть медленными ». Он приводит пример автомобильной двери: инженеры могут придумать лучший дизайн, но если автопроизводитель вложит 100 миллионов долларов в машину, которая делает существующую дверь, новая инновационная дверь вряд ли будет запущена в производство в любое время. скоро. Сегодня, используя методы 3D-печати, можно быстро вносить изменения в аппаратные компоненты при довольно низких затратах. Почему этого не происходит? Это не аппаратная проблема, говорит нам Деннинг, а проблема управления.
Вверху: взгляд на сравнение цены акций Tesla в течение пяти лет с другими OEM-производителями (Источник: Forbes / Steve Denning)
В дни до Теслы вы купили машину у дилера, и это была та машина, которая была у вас до тех пор, пока вы не изнашивались или не продавали ее. Покупатели не ожидали ничего другого от машины. Однако потребители, выросшие на компьютерах и смартфонах, «ожидают того, что уже предлагает Tesla: возможность улучшать свои автомобили каждый месяц или около того после покупки с помощью обновлений программного обеспечения», — пишет Деннинг.
Гибкая разработка программного обеспечения — это разработка продуктов модульным способом, постоянное внедрение инноваций и учет отзывов клиентов и уроков, извлеченных в процессе разработки. Гибкие разработчики «никогда не достигают совершенства», пишет Деннинг. «Они держатся за это. Процесс улучшения никогда не заканчивается ».
Илон Маск привнес часть этого непрерывного совершенствования в мир аппаратного обеспечения. «Тесла [uses] традиционные инструменты САПР, такие как CATIA, но они также вложили средства в комплексную систему трехмерного моделирования, из которой они могут просматривать и моделировать целые сборки и автоматически печатать детали », — пишет консультант Клифф Берг. «Важно то, что программное обеспечение работает быстро, даже при работе со сложными сборками, поэтому инженерам не нужно ждать, что способствует быстрому итеративному подходу к проектированию».
Spacex также демонстрирует аналогичный процесс непрерывной итерации. «Вместо того, чтобы тратить месяцы или годы на разработку, а затем тщательно создавать один идеальный прототип, они строят множество и испытывают их все множеством способов», — пишет Берг. «Они хотят доставить вещь на испытательный стенд, даже если она имеет недостатки. Чтобы снизить стоимость изготовления деталей, дизайн которых постоянно меняется, они используют 3D-печать. Это… позволяет дизайну быстро развиваться ».
Две компании Musk, Tesla и SpaceX, изучают ситуацию с новой точки зрения на производство. Как пишет Деннинг, «они демонстрируют, что можно управлять Agile-компанией, как разработчик программного обеспечения, гибким способом». Может ли старый автопроизводитель (или авиакосмическая фирма) сделать прыжок к этому новому образу мышления?
Как сетуют многие гуру управления, традиционные способы ведения дел глубоко укоренились в корпоративных культурах крупных компаний, а также являются устаревшими определениями их продуктов. «Автомобильные компании все еще рассматривают автомобиль как устройство для транспортировки металла с несколькими электронными устройствами, прикрепленными к нему», — пишет Деннинг, повторяя то, что Ян Райт сказал мне несколько лет назад. Центральная истина о медленном темпе автомобильных инноваций: «Это проблема лидерства и управления, а не проблема атомов и байтов».
===
Автор: Чарльз Моррис; Источник: Форбс
