Автор: магистр компьютерных наук, экс-руководитель отдела разработки продуктов B2C в Yandex Андрей Мещеряков
Гибкие методологии широко применяются в разработке программного обеспечения. Согласно 15-му опросу State of Agile Report, их используют до 86% разработчиков ПО, тогда как в аппаратной сфере этот показатель составляет всего 10%. В этой статье я расскажу, почему Agile необходимо активнее внедрять и в hardware-разработку.
Что за зверь такой Agile?
Agile — это подход, основанный на итеративной разработке и постоянной обратной связи. Он не только ускоряет создание устройств, но и позволяет эффективно управлять затратами, особенно при работе с чипами и другими компонентами. Благодаря этому компании могут тестировать гипотезы на ранних стадиях, а затем снижать себестоимость, переходя от дорогостоящих прототипов к массовым аналогам.
Agile-команды работают в коротких итерациях (период времени, в течение которого происходит разработка), которые обычно не превышают четырех недель. В среднем итерация длится от одной до двух недель. В течение этого времени проводится тестирование, вносятся корректировки, а затем цикл повторяется.
Ведущие консалтинговые агентства подтверждают эффективность внедрения Agile. Так, согласно исследованию McKinsey, гибкая модель:
— повышает операционную эффективность на 30%;
— ускоряет работу организации в 5–10 раз;
— реагирует на новые продукты конкурентов в течение одной недели, а не нескольких месяцев,
— может сократить время выхода на рынок не менее чем на 40%,
— стимулирует инновации;
— повышает удовлетворенность клиентов.
Например, новозеландская телекоммуникационная компания Spark после перехода на Agile повысила клиентоориентированность, сократила количество жалоб на 30–40% и увеличила долю рынка.
Почему Agile важен для hardware-разработки?
Классическая модель разработки аппаратного обеспечения часто опирается на Waterfall подход — последовательный процесс, где каждая стадия строго следует за предыдущей, а возможность отклониться от заданного маршрута минимальна. Перед началом проектирования необходимо согласовать ключевые параметры проекта, включая объем, стоимость, сроки и возможные риски. Затем идет проектирование, производство и тестирование. Каждый из этих этапов может затянуться на полгода, и любое отклонение от первоначального плана и корректировки требуют дополнительного согласования. В итоге выпуск продукта на рынок отодвигается.
Но это только полбеды. Самое «интересное» начинается, когда во время производства или уже после него выявляются недочеты или новые обстоятельства. Допустим, после завершения проектирования электромобиля заказчик узнает, что машина, которую разрабатывает его конкурент, способна на одном заряде проехать 1500 км, а его только 1000 км. Чтобы внести изменения в уже утвержденную конструкцию, нужно пройти весь процесс с самого начала, то есть с момента согласования концепции дизайна, а затем по-новому провести испытания. Это, конечно, не только задержит выход электрокара на рынок, но и приведет к дополнительным финансовым потерям.
Agile тем и удобен, что продукт можно сначала выпустить на рынок, а затем доработать его. Например, если команда еще не до конца проработала идею и не уверена в ее эффективности, нет смысла сразу инвестировать в масштабное производство. На этапе мелкосерийного выпуска можно использовать более дорогие, но удобные в разработке компоненты, а по мере масштабирования перейти на массовые и более экономичные решения. В 2016 году Tesla начала оснащать свои автомобили системой автономного вождения, построенной на базе платформы NVIDIA Drive PX 2. Позднее, исходя из своих потребностей, компания Илона Маска разработала собственный специализированный чип для автопилота, который быстрее чипов Nvidia в семь раз. Или же возьмем iPhone. В первой модели использовался процессор Samsung S3C6400 и только потом Apple разработала собственные процессоры серии A, которые улучшили производительность устройств и снизили зависимость от сторонних поставщиков.
Скептики скажут, что гибкая модель не будет так же эффективна в hardware-сфере, как в разработке программного обеспечения. Однако она уже показала хорошие результаты. К примеру, все та же Tesla, внедрившая Agile в проектирование и производство своих автомобилей, на основе обратной связи быстро тестирует новые идеи и оперативно устраняет возникающие проблемы. Если инженеры Tesla разработают более легкую, безопасную и экономичную дверь, завод сможет адаптироваться под ее производство, интегрируя изменения в текущий производственный процесс. А на заводе Porsche в Штутгарте новые производственные процессы сначала моделируются в виртуальной реальности (Autodesk VRED), что позволяет тестировать изменения перед внедрением, минимизируя риски. Тем самым продукт или процесс постоянно улучшается на основе экспериментов и обратной связи.
И так, в чем преимущество гибкой модели в разработке аппаратного обеспечения?
- Минимизирует финансовые риски за счет раннего тестирования.
- Быстро адаптируется к изменяющимся требованиям рынка.
- Ускоряет вывод продукта на рынок благодаря итеративному подходу.
- Оптимизирует себестоимость, переходя от гибких компонентов к массовым.
- Повышает вероятность успеха за счет постоянного взаимодействия с пользователями.
Эти преимущества Agile особенно ярко проявились во время пандемии. Исторически IT-проекты в основном строились по модели Waterfall, но кризисные условия выявили ее ключевые недостатки: негибкость, слабую адаптацию к удаленной работе и недостаточное внимание к обратной связи. Waterfall в значительной степени зависит от предварительного планирования, последовательного выполнения этапов и обширной документации, включая синхронизацию между фазами. Когда COVID бросил вызов бизнесу и устоявшимся моделям, Waterfall не смог подстроиться под них, не смог похвастаться быстрым тестированием гипотез и внесением изменений.
Как следствие, в период пандемии и после нее внедрение Agile ускорилось. В командах разработчиков программного обеспечения оно увеличилось с 37% до 86%, а в командах, не связанных с информационными технологиями, удвоилось. Однако в аппаратной разработке эти цифры все еще ничтожно малы. Я считаю, что необходимо это исправить и активнее внедрять в hardware-сферу.