Люди vs процессы. Как работает agile на заводе?

Откуда берется интерес

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

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

Большое значение имеет командная работа вокруг продукта. Не каждый по отдельности (один – кусочек интерфейса, другой – бэкэнда и так далее), но все вместе работают над продуктом и каждый понимает, зачем он нужен и кому принесет пользу. Наши разработчики регулярно ездят в командировки на завод, наблюдают, как и кто использует их продукт, проводят интервью с пользователями, погружаются в повседневную работу.

Это не конвейер. Сейчас людям очень важно понимать смысл того, что они делают. И задача владельца продукта – постоянно рассказывать команде, зачем и что делается, откуда мы знаем, что нужно, что и как мы исследовали, какую обратную связь собрали с пользователей. Здорово, когда команда подрастает до определенного уровня и начинает задавать встречные вопросы: а ты уверен, что это нужно? А как мы это измерим? Давай посмотрим на статистику, этим действительно пользуются?

Традиционная картина мира

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

Команда. Фото из архива компании.

И вот уже каждый старается сделать свой кусочек как можно быстрее, при этом не важно, как он ложится в «пазл» конечного продукта и что с ним будет дальше. Общий смысл начал ускользать. А если в работе, на которую ты тратишь большую часть своей жизни, нет смысла, то что получается?    

Что еще важно, когда работа и есть основная мотивация?

Любая область становится знакомой и наскучивает. Интерес – огромный источник энергии. К примеру, у меня был такой опыт: мы как-то выбрали неделю перед новым годом (когда никто уже толком не работает) и организовали hackaweek. Команды собрались и реализовали то, что давно хотелось им самим, но не являлось приоритетом в бэклоге, – распознавание голоса, биометрию.

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

Как agile работает у нас

Надежность оборудования обеспечивает непрерывность производства. Необходимо постоянно контролировать его работу: совершать обходы и осмотр, обслуживание и ремонт. Для этих задач мы создаем систему приложений, несколько веб и одно мобильное – мобильные обходы и ремонты или мобильный ТОИР.

Снабжаем персонал смартфонами. В них есть связь с bluetooth-маячками, которые расставлены на территории завода: человек проходит и датчик отмечает, что именно этот сотрудник был в данном месте.

Затем информация выводится на карту в интерфейсе, который видит начальник смены. А сотрудник тем временем получает задачи, фиксирует дефекты, консультируется с коллегами – все через мобильное приложение.

А как это будет выглядеть именно на этом телефоне? А что надо сделать, чтобы телефон не садился в сибирских холодах? Имел связь с датчиком? Чтобы им было комфортно пользоваться при минусовых температурах? Масса вопросов.

Фото из архива компании.

Над этим продуктом работает на сегодня самая большая (больше 12 человек) команда моего направления: владелец продукта, скрам-мастер, команда разработки, дизайнер, недавно появился менеджер проектов. А также с нами коллеги из производства, минимум владелец процесса. Без общей команды едва ли можно добиться успеха. Это и есть agile на заводе.

Общение строится по горизонтали.

Если говорить про скрам, то я бы сказал, что семь человек в команде – это предел. Например, часовая встреча на 10+ участников – это обычно ужасная трата времени. А замотивированные люди не любят тратить время. Поэтому команда делится на две или три. Наш целевой процесс – строить любой продукт так, чтобы маленькие команды одновременно могли заниматься разработкой продукта, не мешая друг другу.

Фото из архива компании.

Другой пример – электронные наряды-допуски. Этот продукт тоже делает кроссфункциональная команда с теми же ролями. На производстве есть ряд работ повышенной опасности – огневые, газоопасные, работы на высоте и так далее. Для их выполнения нужен наряд-допуск со списком рабочей бригады, видом работ, всеми согласованиями – бумажный документ на 4-5 листов.

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

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

Цифровая химия: взаимодействие аналога и цифры

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

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

Как помочь команде улучшаться?

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

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

Роль скрам-мастера

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

Фото из архива компании. 

В работе скрам-команд много психологических историй: динамика результативности команды постоянно меняется, все внутренние перипетии в команде очень влияют на процесс. Хорошие скрам-мастера – разные. А вот плохие похожи – пришел и говорит: stand up у вас в десять, ретроспектива по пятницам в четыре, до встречи.

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

Один из принципов agile: люди важнее процессов

Люди и взаимодействия важнее процессов и инструментов. Что важнее: всегда заполнять все поля в Jira или обсудить и прояснить задачу, чтобы сделать правильно? Мы с командами не делаем никаких лишних шагов в виде формирования техтребований за полгода, а садимся и обсуждаем вместе с пользователями, что нужно.

Конечно, это важно документировать, но фокус смещен: сначала общаемся, понимаем друг друга, потом создаем продукт, потом документацию. Кстати, в обновленном agile-манифесте этот пункт теперь звучит так: командная работа и ответственность важнее процессов и инструментов.

Как измерить эффективность в свободной среде?

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

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

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

Звучит неубедительно? Тогда вспомните, сколько раз ваша команда занималась не той задачей, решала не ту проблему. А потом приходилось переделывать. Если вы не работали с командой в течение всего дня, вы можете даже не знать об этом. В таких ситуациях 10 минут правильных коммуникаций, что называется, make a difference.