Как проложить универсальные рельсы рабочих процессов и запустить по ним большую компанию?
Привет, Хабр! На связи Т1 Цифровая Академия из Холдинга Т1. Сегодня мы порассуждаем о едином производственном процессе в большой компании: почему он нужен и как его внедрить, если все команды уже работают по-своему.
Проектный менеджмент в больших компаниях: почему необходим единый подход?
Управление проектами — это фрагмент сложной и постоянно меняющейся головоломки, которая во многом завязана на структуру компании. А эти структуры очень разнообразны: функциональные, дивизиональные, матричные, гибридные. Такая вариативность делает невозможным безоглядное перенимание лучших решений по управлению проектами. То, что сработало у лидера рынка, может оказаться неэффективным для вас чисто из-за другой организации отделов, департаментов и зон их ответственности.
При этом вне зависимости от конкретной организационной структуры, ее элементы (или организационные единицы) неизбежно взаимодействуют между собой. Например, в компании, где есть несколько продуктовых «вертикалей» и поддерживающих их функциональных «горизонталей» (от юристов до HR), «горизонтали» часто становятся якорем, тормозящим бизнес-процессы, которые продуктовые команды выстраивают у себя по Agile.
Банальный пример: продуктовая команда использует свою систему управления проектами и задачами, которая лучше всего отвечает сформировавшимся процессам и потребностям. Внутри команды все работает, как часы. Но как только возникает необходимость взаимодействовать с другими подразделениями — начинаются проблемы. Время уходит на передачу информации и задач, на созвоны и переписки, что-то неизбежно теряется в процессе. И вот уже часть сотрудников в команде и смежных подразделениях перегружена, сроки растягиваются, а гибкость и эффективность остались только на словах.
Такие ситуации встречаются во всех сферах, в том числе в ИТ — и на это есть минимум две причины. Во-первых, существует множество методик, фреймворков, подходов и инструментов — и все они обладают своими плюсами и минусами. То есть выбор большой, а очевидных критериев выбора нет. И, во-вторых, трансформация бизнес-процессов всей компании (особенно если в компании тысячи сотрудников) — это задача со звездочкой, за которую не всегда решаются браться.
А теперь давайте поговорим об этих двух причинах подробнее.
Кто в лес, кто по дрова: Agile, Waterfall и гибриды — тысячи их
Что мы знаем о Waterfall? Что разработка при таком подходе происходит последовательно и линейно — это классический пример каскадного метода. То есть каждый этап проекта начинается только после выполнения предыдущего и реализуется строго по порядку: от определения требований до тестирования и внедрения. Его основные минусы — недостаточная гибкость и высокая стоимость внесения изменений. В ответ на них появилась философия Agile: люди и взаимодействие вместо процессов и инструментов, короткие циклы, готовность к изменениям.
На практике оказалось, что и эти принципы применимы не везде. Или везде, но только если их применять правильно — дискуссии на эту тему продолжаются до сих пор. О том, где применим Agile, подробнее почитать можно тут, а о признаках, что вы применяете его неправильно — здесь.
Так или иначе, Agile взялись дорабатывать. Во всемирном Институте управления проектами (PMI) предложили дисциплинированный Agile — Disciplined Agile (DA). В нем уже нет готовых правил, универсальных на все случаи проектной жизни, зато есть два базовых принципа: «хорошо иметь возможность выбора» и «уникальность конкретной ситуации имеет значение». По сути, DA — это большой набор инструментов и инструкция, как их выбирать.
А если сделать шаг назад и заглянуть «внутрь» Agile, окажется, что у этой философии есть как минимум 3 основные методологии: Scrum, Kanban и Lean. Причем Scrum появился даже раньше, чем был сформулирован Agile. История методов проектного управления — это вообще отдельная тема, представление о которой можно получить, например, из этой статьи.
Конечно, само по себе наличие множества методик, фреймворков и инструментов (а мы выше привели всего лишь несколько примеров) — это не проблема. Сложности начинаются при переходе от теории к практике. В руководстве по Scrum 2017 года написали очень точно: «легок для понимания, сложен для освоения». Эта фраза применима не только к Scrum — внедрение и налаживание любой методологии требует усилий и — в идеале — хорошего эксперта. А без него трудности могут начаться еще раньше: при попытке глубоко погрузиться в теорию. Во множестве вариантов того, как организовать управление проектами, легко потеряться — поток информации о них бесконечен, при этом значительная его часть сгенерирована людьми, которые имеют не так много реального опыта.
В итоге многие команды вообще не выбирают конкретную методику, а создают что-то свое, смешав гибридные подходы с каскадными и внедрив собственные метрики по своему уникальному процессу. И мы снова попадаем в пример из первой части блога: все по отдельности делают как лучше, а в сумме получается общее снижение эффективности компании.
Так давайте внедрим единый производственный процесс!
Любая трансформация на уровне компании, будь то внедрение новых управленческих подходов или формирование новой корпоративной культуры, предполагает кардинальное изменение почти всех бизнес-процессов. Чаще всего изменения начинаются с продуктовых отделов и команд, но следом обязательно должны меняться практически все аспекты работы компании, включая юридические и HR-процессы.
И тут важно подобрать темп и способ внедрения изменений, который снизит сопротивление разных отделов, команд и функций, поднимет мотивацию сотрудников и при этом позволит завершить трансформацию в адекватные сроки, а не увязнуть в бесконечном переходном периоде. Чтобы подобрать такой темп, нужен либо опыт уже реализованных изменений, либо внутреннее исследование, которое позволит определить готовность сотрудников «жить по-новому» и выявить барьеры и потребности.
Второй залог успеха — активное участие топ-менеджмента. Необходимо не только утвердить дорожную карту трансформации. Внедрение изменений — это тоже проект, а значит необходимо заранее определить его цели, задачи, ожидаемые результаты и метрики, которые позволят их измерить. Но и это еще не все. Руководителям необходимо держать руку на пульсе трансформации и уделять достаточное количество времени коммуникации с сотрудниками, менеджерами, экспертами — и зачастую проблемы возникают именно с вовлечением топ-менеджмента в такие рутинные процессы.
От теории к практике: кейс ГК «Иннотех»
Мы помогали с внедрением единого производственного процесса нашим коллегам по холдингу — ГК «Иннотех».
За 3 года команда «Иннотех» сильно выросла и стала насчитывать более 10 000 сотрудников. И потребность в едином процессе, чтобы тысячи разработчиков могли эффективно работать над общими продуктами, стала не просто очевидной, но и острой.
Разработку такого процесса взяли на себя руководители и Agile-тренеры «Иннотех», но на следующем этапе — при внедрении изменений во все команды, у коллег возникли сложности. 10 Agile-экспертов «Иннотех» вынуждены были обучать всех коллег новому процессу, но ресурсов команды на это не хватало. И к задаче подключились мы.
В первую очередь мы исследовали опыт подобного внедрения в крупнейших мировых ИТ-компаниях: внедрение через чемпионов, профессиональные сообщества, субкультурное обучение и т.д. Также мы подробно изучили производственный процесс, который требовалось внедрить. И стали двигаться по шагам:
Мы провели аудит текущих рабочих процессов в командах. Ожидаемо, что у каждого продукта были свои подходы. Waterfall, Scrum, Kanban, Safe, Scrumban, самодельные подходы со своим workflow, специфичными артефактами, метриками, ролями…
Собрали все требования, предложения, барьеры и возражения от HR, ИТ, руководителей и бизнеса.
Предложили шаги для эффективного внедрения нового процесса:
Отобрать лидеров для внедрения нового процесса в роли Scrum-мастеров
Обучить кандидатов новому процессу и нюансам внедрения
Разработать массовый курс для всех ролей по новому процессу
Запустить сообщество для помощи и консультаций
После финализации общего плана мы приступили к проектированию образовательного решения для внедрения целевого процесса. Agile-тренеры «Иннотех», разработавшие единый производственный процесс, выступили экспертами-консультантами. Вместе с ними мы выбрали метрики, на которые требуется повлиять, и разработали систему отслеживания этих метрик в реальном времени.
После — адаптировали программу обучения под рабочие задачи «Иннотех» и разработали недостающие курсы и инструменты. Например, подготовили мотивационные мероприятия с руководством: как очные, так и в формате вебинаров. Также запустили интерактивные мотивационные мероприятия с «чемпионами изменений». Это формат, при котором сотрудники на практике показывают, как они внедряют новый процесс у себя в командах и что это им дает. А еще разработали короткий курс, состоящий из небольших видео. Мы загрузили его на обучающую платформу и открыли всем сотрудникам для массового прохождения. В нем мы заложили геймифицированные механики и интерактивные тренажеры.
Первое обучение Scrum-мастеров проводили непосредственно создатели единого производственного процесса из «Иннотех». А наши преподаватели переняли опыт, после чего взяли обучение лидеров на себя, оптимизируя нагрузку на коллег.
В итоге:
Число сотрудников, поддерживающих работу по новому процессу, выросло с 31% до 92%
Число прошедших тестирование и успешно выполнивших первую рабочую задачу своей роли по новому процессу увеличилось с 12% до 100%
Число выпускаемых Scrum-мастеров в месяц увеличилось с 15 до 50
Число Scrum-мастеров, которые впоследствии отказались работать по этой роли уменьшилось с 36% до 4%
Экономия времени Agile-экспертов на преподавание и консультации составила 100 часов в месяц
93% сотрудников получают ответ от центра компетенций на запрос по производственному процессу в течении 1 часа.
Вывод прост: не отказывайтесь от идеального для вашей компании производственного процесса по причине »легко понять, но сложно освоить». Провести трансформацию бизнес-процессов в большой компании с ощутимым и измеримым результатом — возможно!
