Успешный кейс применения Scrum в аппаратной разработке

Наш клиент — компания, которая занимается сразу двумя направлениями разработки — программных и аппаратных продуктов, включая собственное производство последних. В частности, это планетарные и книжные сканеры, которые обычно используются в библиотеках или, например, для оцифровки печатных материалов большого формата. 

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

С какими сложностями столкнулась компания

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

Но затем генеральный директор задался вопросом — а можно ли применить метод Scrum к аппаратной разработке? 

У компании было несколько задач по улучшению в аппаратной разработке:

• Отсутствовала прозрачность в R&D: руководство не понимало, на какой стадии разработки находится каждый из продуктов. Статусные отчеты были формальными и не давали реальной картины прогресса.

По словам одного из руководителей: «Мы постоянно находились в ситуации, когда на вопрос о готовности получали ответ "почти готово", а потом еще месяцами ждали готового к производству результата».

• Невозможно было спрогнозировать сроки: генеральный директор не мог получить ответ от разработчиков, когда будет доработана и выпущена новая модель. Это создавало серьезные проблемы для отдела продаж, который не мог формировать долгосрочные планы и давать реалистичные обещания клиентам. В некоторых случаях это приводило к потере контрактов на значительные суммы.
• Замечания от заказчиков медленно исправлялись: было много обратной связи, и новые требования вносились слишком долго. Средний срок реакции на замечания от клиентов составлял несколько месяцев, что существенно усложняло управление ожиданиями заказчиков.
• Срочно требовался поиск новых решений: из-за введения санкций возник дефицит комплектующих. Большая часть критических компонентов для сканеров стали недоступны, что поставило под угрозу все производство. Инженерам приходилось в срочном порядке искать альтернативы, попутно разрабатывая собственные решения.
• Отсутствие кросс-функционального взаимодействия: отделы разработки железа и программного обеспечения для него работали изолированно, что приводило к проблемам совместимости и дополнительным итерациям.

Руководитель программистов отмечал:  «Мы часто узнавали об изменениях в аппаратной части постфактум, когда уже нужно было срочно адаптировать ПО под новые параметры.»

Изменения в сторону Agile и Scrum

Мы сформировали три команды для работы над основными линейками сканеров, каждая из которых включала в себя несколько моделей. Для начала мы провели базовое обучение Agile и Scrum для всех сотрудников R&D подразделения, разобрали с ними новый подход к организации процессов и его особенности в hardware контексте. Было видно, как "загораются глаза" у большинства участников обучения — им было действительно интересно, как новые подходы могут помочь в работе.

При этом мы столкнулись с серьезным сопротивлением со стороны нескольких опытных инженеров, которые работали в компании более 10 лет и не видели смысла в изменениях. 

«Железо — это не код, его нельзя просто переписать за спринт», — говорил один из них. 

Было не просто, но в конечном итоге, обсудив еще раз текущую проблематику и приведя примеры успешного внедрения Agile в hardware-компаниях, нам удалось показать, что опыт этих сотрудников не обесценивается, а становится еще более востребованным в новой системе работы.

Чтобы изменить текущие процессы, мы предприняли несколько важных шагов. Давайте рассмотрим каждый из них в отдельности.

Шаг 1. Формирование команд

В конце этого обучения мы провели важную сессию, которая называется «Самодизайн команд». Раньше сотрудники работали одним большим отделом в 15–20 человек, но в Scrum-командах должно быть не более 10 участников. Необходимо было разделиться на несколько небольших команд, чтобы у каждой из них был свой понятный фокус и зона ответственности за финальный результат.

Вместо того, чтобы назначать «сверху» составы групп, мы предложили участникам самим разделиться на команды. Каждый из них написал своё имя на стикере и приклеил его на доске рядом с той командой, где хотел бы работать. Небольшое обсуждения результата, внесение правок — и решение принято. Так они самостоятельно организовались в Scrum команды и распределили между собой зоны ответственности.

Это решение вызвало неожиданный эффект — люди группировались не только по функциональному признаку, но и по личным предпочтениям в работе.

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

Шаг 2. Единый Product Owner

Получилось, что команды сами органично распределили свои силы. Две группы сосредоточились на разных линейках сканеров, а третья — на разработке ПО для них. При этом они выбрали единого Product Owner'а. Но почему только одного?

Потому что сканеры — это один тип продукта, и некоторые модели просто технологически отличаются друг от друга. Поэтому показалось разумным, что за это должен отвечать один человек. Тем более, что объем работы позволял ему с этим справиться.

На эту роль выбрали Александра, он был тимлидом и отлично разбирался в разработке, поэтому именно на него мы сделали большую ставку — и не прогадали. Он взял все в свои руки и сумел мотивировать команду.

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

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

Шаг 3. Синхронизация спринтов 

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

Для визуализации работы каждая команда создала физические Scrum-доски со следующими колонками: «Бэклог спринта», «В работе», «На проверке», «Готово». Ежедневно проводились 15-минутные стендапы, где команды синхронизировались и обсуждали выявленные проблемы, которые могли помешать достижению результата в конце спринта.

Одна из особенностей применения Scrum в hardware-разработке заключалась в том, что «готовый» результат спринта не всегда означал функционирующий продукт. В условиях жестких ограничений на комплектующие, команды двигались через наборы гипотез, результаты которых и являлись поставкой в конце спринта — например, готовый прототип компонента, успешное тестирование альтернативного поставщика или завершенный эксперимент с новым материалом.

Шаг 4. Открытые спринт-ревью

Обычно ревью спринта проводится только для команды (включая Скрам-мастера и Владельца продукта) и стейкхолдеров. Но мы сделали его открытым для всех сотрудников компании, чтобы каждый мог прийти и увидеть, как ведется работа. Многие заходили просто из интереса, посмотреть, как продвигаются команды.

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

Во всех встречах директор принимал активное участие в обсуждениях и давал свои комментарии: «Попробуйте вот такой вариант» или «А что, если сделать так? Какое здесь входное напряжение на контроллер?».

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

Результаты внедрения Scrum

1. Прозрачность

Первое и самое важное, что у нас появилось в результате применения Scrum — это прозрачность. Команды начали работать слаженно, и теперь каждые 2 недели был виден четкий результат. Сотрудники не занимались бесконечными исследованиями, а всей командой брали в работу конкретную модель сканера и ставили перед собой цель на ближайший спринт — улучшить какое-то одно свойство, например, качество изображения.

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

На спринт-ревью стало видно, над чем сейчас работает команда, какой результат мы ожидаем, и в каком направлении будем двигаться дальше.

Руководство получило четкую картину статуса разработки всех продуктов. Уже после 2 месяцев работы по новой методологии генеральный директор отметил: 

«Раньше я не понимал, что происходит в R&D отделе, теперь я точно знаю, на какой стадии находится каждый продукт и могу принимать обоснованные решения о дальнейших инвестициях».

2. Общий фокус

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

Интересно, что один из скептически настроенных инженеров, который изначально сопротивлялся изменениям, позже признал:

«Я думал, что Scrum — это просто модное слово, но сейчас вижу, как это работает. Мы перестали разбрасываться и начали доводить дела до конца».

3. Взаимодействие с заказчиками и ускорение разработки

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

Компания начала практиковать ранние показы прототипов ключевым клиентам, получая обратную связь еще до финальных стадий разработки. Это значительно снизило риски и стоимость исправлений.

Долгосрочные перспективы

Теперь B2B-продавцы могут формировать у клиентов более реалистичные ожидания, опираясь на предсказуемые сроки, которые им дает R&D-подразделение. У всех участников процесса появилась уверенность, что с высокой долей вероятности компания выполнит эти обещания в кратчайшие сроки. Такие изменения положительно скажутся на развитии компании — увеличится количество довольных клиентов и доля рынка.

Внедрение Scrum помогло компании не только преодолеть текущие трудности, но и заложить фундамент для долгосрочного успеха.

Генеральный директор компании подвел итог первого полугодия работы в новом процесс:

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