Как можно запустить процесс эволюции IT в промышленной компании
Привет, Хабр!
Хочу поделиться опытом довольно непростой, но интересной трансформации в промышленной компании и моим участием в проекте автоматизации производства. Мы не только помогали внедрить систему, которая начала развиваться на предприятии, , но и меняли культуру разработки, учили работать по-новому и, в конце концов, создали эффективные и самостоятельные команды. Всего было 5 продуктовых и две сервисные команды, которые участвовали в трансформации или образовались в ходе неё.
Ну что ж, обо всем по порядку.
Представьте себе сложный технологический цикл, расписанный в ГОСТах и регламентах — от выплавки металла до его отгрузки клиенту. Именно этот цикл автоматизировался проектом, к которому мы подключились.
Главная цель автоматизации — минимизировать утечки, как финансовые, так и материальные, а также унифицировать систему контроля на всем производстве. На каждом предприятии использовалось свое собственное ПО со своими отчетами и особенностями, а это неудобно и создает множество рисков. Наша задача была создать единую систему для всех.
И в проект, где я работал, входило все, начиная от выплавки и заканчивая отгрузкой. Как выглядит цикл: металл плавят, далее он стекает вниз, шлак поднимается вверх, потом металл из чанов выкачивают и везут на выплавку. Заправляют в миксеры, там смешивают различные сплавы, разливают их в слитки, нарезают нужными партиями, отправляют это все на склад, маркируют, клеят сертификаты, QR-коды и, наконец, отгружают заказчику — все это входило в технологическую цепочку, которую автоматизировала система.
У меня была возможность побывать на самом производстве и увидеть: как работает миксер, переливая расплавленный металл, и как отливаются огромные слитки, и как их потом поднимает кран. Вживую это очень впечатляющее зрелище. А также поработать в офисе, общаясь с IT-специалистами предприятия.
Когда я пришел в компанию, привычного IT-процесса там не было. Общение шло через письма, телефонные звонки, личные разговоры и чаты. Представьте себе пол сотни человек, передающих друг другу задачи таким образом. Аналитики, естественно, вели учет в Excel, а разработчики работали над отдельными задачами, поставленными аналитиками. Команды были разрозненными, и многие этапы просто пропускались, а времени тратилось очень много.
В первую очередь нужно было настроить таск-трэкер в DevOps Azure. Он был в компании уже некоторое время, но не был настроен и не использовался для ведения задач и работы. Документация либо отсутствовала, либо устарела. Команды не были разделены, ребята работали как одна большая группа. Никакой формализации рабочих процессов — все решалось ситуативно, в авральном режиме. Инструмент DevOps Azure использовался только для развертывания ПО. Цикл CI/CD был настроен, а все остальное отсутствовало.
Пришлось выстраивать все с нуля. Создавать буферы между отделами, потому что аналитики не привыкли работать с разработчиками в одной команде. Вводить критерии качества кода, определять, когда задача считается выполненной, внедрять ревью кода и соглашения о стиле. Мы фактически составили полноценный плейбук, описывающий все аспекты нашей работы: что такое API, как происходит разработка, как принимается код, какие критерии качества мы проверяем и как это делаем. Также мы полностью описали релизный цикл: как готовим релизы, как работаем с ветками, как используем GitFlow (который тоже пришлось внедрять). В общем, работы было много.
Самой сложной задачей было превратить группы в настоящие команды по выработанным нами правилам и продуктовой экспертизе. Здесь была обычная иерархия с классическим управлением и руководителями. Пришлось разделять людей на команды, внедрять обучение, формировать общие цели, развивать личную ответственность. Добавили наставничество, тет-а-теты, индивидуальную поддержку и планы развития.
В подчинённой мне группе, которая была авангардом трансформации, сначала было 12, а потом 15 человек, и все организационные вопросы, включая обучение, я взял на себя. Это и организация мероприятий, и подготовка к ним, и фасилитация встреч, и работа с выступающими. Мы с ребятами подбирали темы для докладов, работали над ними индивидуально, они готовили презентации, мы проводили пробные прогоны, а затем они выступали перед коллегами. Все это записывалось и архивировалось. Получился полноценный цикл обучения, и ребята им активно пользовались. Надеюсь, продолжают и сейчас. А опыт авангарда мы масштабировали на все остальные команды проекта.
Мой принцип — «проверяй, но доверяй». Я считаю, что доверие — базовая ценность, его легко потерять и очень сложно вернуть. В классическом энтерпрайзе часто пытаются все контролировать, закручивая гайки, но это не вызывает доверия ни у руководства, ни у сотрудников. Поэтому следующим шагом после формирования команд стало возвращение доверия бизнеса и руководства, которое было очень низким. Руководство не понимало, когда и что будет сделано. Переработки, инциденты, работа в выходные — это было нормой.
Через три месяца после моего подключения к проекту на первом крупном внедрении руководитель департамента, сначала покритиковавший нас за некоторые недоработки, после удачного запуска системы на заводе позвонил и сказал:
«Передай ребятам, что без помощи разработчиков мы не справились бы. Молодцы!».
Конечно, были ошибки и доработки, но благодаря фокусу на критически важных задачах мы добились значительного прогресса. Мы быстро улучшили доверие, и это очень помогло, потому что директор стал основным спонсором всех дальнейших изменений.
Через год мы свели переработки к минимуму. Для этого пришлось сделать расписание, кто и когда доступен по какой части системы, чтобы распределить нагрузку сопровождения. Мы внедрили инструменты контроля результатов решения инцидентов и снизили риски их возникновения.
Следующим шагом было обеспечение прозрачности. Без этого руководство не понимало, что происходит, и в кулуарах ходили слухи о возможном откате всех изменений. Мы создали публичную матрицу RACI, чтобы четко обозначить зоны ответственности. Полноценно описали процесс работы и регламенты по каждой роли. Описали подробные инструкции новичков, что сократило онбординг новых сотрудников с месяца до недели. Пришлось преодолевать внутреннее сопротивление, терпеливо и честно объясняя пользу изменений для всех. Все это делалось публично.
Вместе с командой мы почти два года работали над улучшением процессов. Первый год ушел на изменение основных процессов, а второй — на формирование полноценных продуктовых команд.
Потихоньку мы запустили эволюцию процесса и сверху, получив поддержку руководства, и снизу, вовлекая рядовых сотрудников (аналитиков, разработчиков, поддержку). Отдельно стоит отметить усилия по отказу от «исторически сложившегося», потому что это не всегда означает «хорошо работающее». Мы начали создавать свою историю. Долго пришлось убеждать ребят, что они сами могут определять, как им работать.
Следующая задача — добиться лояльности. Нужно было сформировать ядро команды, готовое продвигать изменения. Этого мы добивались через поддержку лидеров, делегирование ответственности и признание ценности вклада каждого. Работа строилась на доверии: доверии заказчика к нам, команды к руководству, и наоборот. Мы честно показывали, что хорошая работа и ориентация на результат приводят к профессиональному росту и повышению зарплаты.
Текучка была практически нулевая. За два года мы потеряли всего двух разработчиков по причинам, не зависящим от нас. И ротации не было, только набор новых специалистов.
Изначальное задание — внедрить микросервисную архитектуру, трансформировалось в нечто гораздо большее. Мы понимали, что делать это не на чем и не с кем, поэтому предложили сначала наладить процессы. Заказчик согласился, и нам предстояло: возвращать доверие, запускать обучение, формировать кросс-функциональные команды, настраивать рабочий процесс и распределять ответственность. Только после этого мы смогли заняться архитектурой: разработать концепцию, создать примеры, проводить обучение.
В общем, автоматизация производства получилась не просто технической историей, а полноценной перестройкой всей разработки. Команда стала эффективнее, а бизнес снова нам поверил. Даже в сложных условиях, даже с ограниченными ресурсами можно добиться значительных результатов, если сосредоточиться на людях и процессах.
Не бойтесь менять устоявшиеся подходы, инвестируйте в развитие своих сотрудников и стройте работу на доверии. Желаю вам успехов в ваших проектах!
