Всем привет! На связи Сергей Гончарук, менеджер проектов компании «Флант». 30 ноября и 1 декабря 2023 года прошла конференция TeamLead++ Conf 2023. Ниже — текстовый вариант моего доклада с конференции про опыт «Фланта» в построении процессов управления задачами для Dev-части нашей DevOps-работы.
В этом докладе я рассмотрел, как можно применить ценностную модель, чтобы построить идеальный фреймворк для команды, и как приносить изменения в компанию через создание профессионального сообщества, в нашем случае — гильдии.
Устройство «Фланта» и проблемы в командах
«Флант» — это всё, что связано с DevOps: мы умеем строить высоконагруженную инфраструктуру, удобную среду для разработки и разрабатываем много продуктов для DevOps. Нашей основной «боевой» единицей является команда. Ее основа — DevOps-инженеры под управлением тимлида и менеджеров проектов. Тимлид больше отвечает за техническую реализацию и архитектуру проектов, менеджер проектов — за планирование, сроки и коммуникации. Команд у нас несколько, и у каждой есть свой пул проектов:
Когда мы задумались о выборе управленческого фреймворка, в командах был ряд проблем с планированием. Например, входящая задача от клиента либо назначалась инженеру, либо попадала в бэклог. Мы не задумывались, сколько «карточек» будет попадать в «день» каждого инженера. В итоге иногда всё это превращалось в настоящую «стену задач»:
У такой «стены задач» есть ряд проблем:
Непрозрачность. Создавалась иллюзия, что в работе много задач. При огромном числе задач на доске каждого инженера нам и клиенту было невозможно понять, какие из них будут в работе сегодня и на какой стадии каждая из них находится. Также это увеличивало нагрузку на менеджера проекта: именно у него клиенты постоянно уточняли, взята ли задача в работу и каковы сроки ее выполнения.
Неравномерные нагрузки. У инженеров было разное количество задач в индивидуальном плане на день. На тот момент мы не учитывали производительность каждого инженера, и разное количество задач в плане только усложнило проблему прозрачности для менеджмента команды.
-
Перегруз инженеров. Задач почти всегда было больше, чем инженер мог сделать за день. У этого имелись два негативных эффекта:
Инженер чувствовал себя «вечным должником».
Возникала проблема «подвала» — до задач внизу плана почти никогда не добирались.
Помимо «стены задач», была вторая — не менее сложная — проблема. Как говорилось ранее, у большинства команд есть пул разных проектов. Сложность здесь состоит в том, чтобы правильно распределить вовлечение инженеров команды в проекты согласно данным обещаниям. При этом нужно равномерно распределить нагрузку с учетом того, что у инженеров различный профессиональный уровень. Нам было непонятно, что может служить универсальной единицей измерения и для вовлечения, и для нагрузки.
Фреймворк, который мы хотели выбрать, должен был решить эти проблемы.
Ценностная модель для выбора фреймворка
В настоящее время в Agile-практиках предлагается большой выбор фреймворков. И нам предстояло понять, какой из них подойдет нам. Для решения этой задачи мы решили базироваться на ценностной модели, то есть нужно было отталкиваться от того, какую ценность мы приносим нашим клиентам. Получился следующий список:
-
Инструменты:
Предлагаем набор высокоэффективных инструментов, таких как Deckhouse, werf и Okmeter, которые ускоряют решение всех DevOps-задач и снижают time to market.
Практически с первого дня мы покрываем мониторингом сервисы клиента и реагируем 24/7.
-
Поддержка:
Если что-то пошло не так, мы гибко эскалируем, в том числе в команду клиента.
Поддерживаем команды разработки, в том числе консультируем в чате или видеоконференциях.
-
Развитие:
Делаем плановые задачи по развитию и модернизации инфраструктуры.
Так как с проектом работает постоянная команда инженеров, они накапливают экспертизу и знания по нему.
-
Риски:
Менеджмент команды обеспечивает достижение результата. Здесь речь про разницу между «мы делали» и «мы сделали», управление сроками и объемами вовлечения команды в проект.
Нивелируем кадровые риски, которые есть у инженера в штате: bus factor, отпуск, ошибки найма и так далее.
Уже на этом этапе стало понятно, что для каждой из этих групп существует свой фреймворк:
Разработку каждого инструмента делала отдельная команда разработки. Поэтому только она могла выбрать оптимально подходящий фреймворк. Три оставшихся фреймворка мы решили реализовать в рамках одной и той же DevOps-команды.
Получается, если мы выбираем один фреймворк, то он должен иметь внутри себя инструменты, которые покроют сразу три области: задачи развития, оперативной поддержки (в том числе аварий) и управления рисками. Также выбранный фреймворк должен решать проблемы, которые уже существуют в командах:
Мы не были специалистами по всем существующим Agile-фреймворкам, но были наслышаны о Scrum и Kanban-методе. Некоторые из нас даже читали актуальную версию их руководств.
Scrum
Посмотрим, может ли Scrum закрыть все группы и проблемы. В ходе изучения фреймворка мы поняли, он может закрыть кластер «Развитие», так как был создан для таких задач. И еще он справится со стеной задач и управлением рисками. Хотя в Scrum есть механизмы оценки задач (например, в сторипоинтах), он не подойдет для задач нашей поддержки, так как это скорее про важность задачи, а не про объем ресурсов вовлечения команды в проект.
В итоге использовать Scrum в чистом виде в нашем случае не получится.
Kanban-метод
Кажется, что Kanban-метод оптимальнее всего подходит к задачам поддержки. Также он закрывает вопросы с развитием и стеной задач: это решается ограничением работы в работе (Work in Progress). Еще Kanban-метод предлагает и единицу измерения — карточку-задачу.
Мы даже на практике попробовали пожить в такой парадигме. По историческим данным мы посчитали, сколько в среднем задач делает каждый инженер в день, и определили лимит в задачах на человека в день. Далее мы сделали MVP в Google-таблице, где учитывали задачи в работе и количество возможных задач, которые можно было отдать инженеру. В итоге мы быстро поняли недостатки этого решения:
Все задачи были разные, и для клиента было неочевидно, что такое «одна задача в работе одновременно».
Навыки инженеров отличались и менялись со временем: инженеры росли, лимиты необходимо было пересматривать.
Получается, что предлагаемая по умолчанию единица измерения подходила на роль универсальной меры с очень большой натяжкой. Также у нас были вопросы и к поддержке. Kanban-метод не ограничивает нас, но и не формализует механизмы, необходимые для решения входящих в наше понимание поддержки задач. Например, как обеспечить 24/7, как организовать эскалацию, каков регламент поддержки для команды разработки. Эти элементы нужно доработать самостоятельно и встроить в Kanban-метод дополнительно.
В итоге мы пришли к мнению, что в прямом — «книжном» — варианте Kanban-метод нам не подходит. Поэтому мы снова оказались в самом начале выбора фреймворка, только уже с четко сформулированными потребностями: мы поняли, что нам необходимо делать гибрид, который основывается на нашем опыте.
Построение гибрида
Scrum и Kanban-метод закрывали почти все наши ценности и выявленные проблемы:
Нам оставалось доработать фреймворк для поддержки и единицы измерения. Последнюю мы выбрали в качестве ключевого элемента и начали построение флоу.
Гибрид для единицы измерения
Большая часть сервиса, такая как мониторинг, инструменты, поддержка 24/7, менеджмент и управление знаниями, является примерно одинаковой для стандартного проекта, в отличие от нестандартных больших проектов или с особенными договоренностями. Эта часть обслуживается менеджментом, shared-командой L1, внутренней разработкой и дежурным команды. И только работа с плановыми задачами по развитию и модернизации инфраструктуры существенно изменялась по ресурсам, которые необходимо было выделить из команды на ее обслуживание. То есть эта деятельность являлась переменной от проекта к проекту.
По этой причине нам нужно было разработать универсальную единицу измерения нагрузки и вовлечения команды в плановую деятельность. На первый взгляд казалось, что это было время: рабочий час инженера легко измерим и принят в отрасли как стандарт де-факто. С другой стороны, рабочий час senior-инженера с точки зрения результата — это не то же самое, что рабочий час middle- или junior-инженера:
Из-за этого противоречия мы отказались от «часов инженера» как универсальной единицы измерения вовлечения и нагрузки. Нам требовалось сделать так, чтобы клиент получал приведенное вовлечение в зависимости от профессионального уровня инженера.
Осталось только определиться, каким именно должен быть базовый размер этой единицы измерения:
Должен быть достаточно большим, чтобы за него можно было произвести существенное изменение по задаче.
Должен быть не настолько большим, чтобы инженер выгорел, занимаясь одной задачей долгое время.
Все взвесив, мы определили, что WIP-слот (это условное название единицы измерения, которое мы ей дали) — это два часа работы опытного инженера «Фланта». При этом новичок мог сделать аналогичную задачу за три часа. Но для клиента базовой единицей измерения и оплаты все равно остается WIP-слот:
Такая единица измерения решала следующие вопросы:
Помогала равномерно распределять нагрузку на инженеров с учетом их профессионального уровня.
Обеспечивала клиенту равные вовлечения, независимо от того, какого уровня инженер работал над его задачей, и помогала измерять емкость всей команды в WIP-слотах и строить бюджетирование на его основе.
Фреймворк поддержки
Фреймворк и особенности процесса обработки алертов оказались отдельным миром. Поэтому мой коллега Дмитрий Столяров посвятил ему отдельный доклад «10 лет on call». В нем он рассказал, как эволюционировали наша служба технической поддержки и система обработки инцидентов в целом: от понимания того, что является инцидентом и какие инциденты бывают, до выработки эффективного рабочего фреймворка для задач поддержки. Рекомендую ознакомиться с этим докладом.
Гибрид на практике
Прежде чем всем командам перейти на новый фреймворк, мы внедряли его частично: в одних командах флоу был использован без изменений, в других он изменился. Например, в части команд все еще не перешли на использование WIP-слотов, в некоторых не использовали или перестали жестко следить за лимитированием работы.
Встала задача сделать так, чтобы флоу управления задачами во всех командах стал одинаковым, а процессы непрерывно развивались и адаптировались к новым вызовам. Для этого во «Фланте» сформировалась гильдия менеджеров.
Объединение в гильдию и определение ценностей
В сентябре 2022 года мы объединились в гильдию менеджеров проектов «Фланта». Это наше профессиональное сообщество, куда вошли на равноправной основе все менеджеры проектов направления DevOps as a Service (на сегодня это 11 человек).
Первое, что сделала гильдия для внедрения общего флоу управления задачами, — сформулировала набор ценностей «Фланта». Это стало своего рода манифестом проджектов, который отражает нашу корпоративную культуру и помогает нам принимать решения:
Перечисленные ценности помогают нам определять, в какую сторону идти в развитии. Они упрощают процесс взаимодействия команд, помогают находить быстрые пути решения, ведут компанию в одну сторону.
Поясним каждую из них:
Член команды — главная ценность и главный ресурс. Это практически прямая калька из Agile Manifesto про «Люди и взаимодействие важнее процессов и инструментов». Agile Manifesto был одним из источников нашего вдохновения.
Сотрудничество с клиентом всегда должно быть взаимовыгодным.
Нагрузка на команду должна распределяться равномерно: в день, в месяц, в год, а также на инженера и любого члена команды. Это конкретизирует первую ценность о членах команды и напрямую указывает на легко измеряемую метрику «распределение нагрузки» при принятии решений. Эта ценность родилась из нашего опыта поисков идеальной единицы измерения и решения проблем нагрузки в командах.
Мы не обманываем не только свою команду, но и клиентов, и партнеров.
Планирование должно быть совместным и прозрачным для команд и клиента. Еще одна практическая ценность, родившаяся из предыдущего опыта. Она конкретизирует пути достижения ситуации win-win с клиентами и отражается на принятии любых решений об изменении фреймворка и инструментов.
Мы должны понимать, ради каких бизнес-целей и «Фланта», и клиента команда тратит свои усилия. Мы не работаем с клиентом, если не приносим ему ценность.
Мы находимся в процессе постоянного улучшения: каждый недостаток, который мы нашли и исправили, делает нас лучше и ценнее.
Мы не каждый сам по себе, а команда. На всех уровнях — команды, гильдии, компании.
Наши клиенты — наши коллеги. Мы работаем сообща ради единого дела.
Несмотря на то, что мы с клиентом коллеги, мы — не «команда клиента», мы — «команда “Фланта”» со своим управлением, ценностями, процессами и механизмами принятия решений.
Эти ценности мы представили в компании и получили позитивную обратную связь. Они помогли настроить общий флоу по управлению задачами в командах, а также еще больше сплотили нас. Подробнее об этих ценностях и их применении на практике можно прочитать в статье «Ценности, которые делают нашу компанию лучше каждый день».
Устройство гильдии
Как же работает механизм управления задачами и принятия решений на базе гильдии? Для начала посмотрим, как устроена сама гильдия. Она состоит из нескольких рабочих групп:
Каждая рабочая группа владеет тем или иным направлением деятельности, например Product или HR.
Обычно в работе каждой группы участвуют 3–5 членов гильдии и приглашенные участники, например HR-директор в группе HR и так далее:
Состав группы определяется на добровольной основе. В каждой выбирается руководитель группы, который берет на себя обязанности по организации и ведению церемоний группы, определению повестки встреч:
При этом в рабочих вопросах групп у всех членов равные права, и решения принимаются коллегиально. Собрания обычно проводятся один раз в неделю. На встречах обсуждаются рабочие вопросы, распределяются задачи между членами группы, формируется повестка для общегильдейской встречи — вопросы, требующие участия всех членов гильдии.
На еженедельной встрече всей гильдии формируется повестка работы на основе требований от команд или необходимости улучшения процессов, также обсуждаются состав групп и результаты их работы. Все это нужно, чтобы обеспечивать процесс донесения изменений, который можно описать так:
Формирование списка требуемых изменений.
Формирование и распределение задач.
Работа и получение результатов выполненных задач.
Принятие изменений командами.
Схема процесса донесения изменений
Рассмотрим подробнее каждый процесс.
1. Формирование списка требуемых изменений
В любом правильном Agile команды и стейкхолдеры компании являются основным источником запросов на изменения, также требования и пожелания поступают и от клиентов. При этом рынок и конкурентная среда обязывают нас меняться, становиться лучше, привлекательнее для клиентов и экономически эффективнее.
Изменения от всех источников в гильдию приносят менеджеры проектов. Они владеют делами в командах, общаются с менеджментом компании и другими командами, общаются с клиентами и принимают участие в продажах. Они же и формируют список требуемых изменений.
2. Формирование и распределение задач
Далее необходимо определить, кто будет заниматься реализацией сформированного списка. Если уже существует рабочая группа, которая может решить такую задачу,
задача ей и передается. Еще часто вопрос можно решить простым обсуждением на общегильдейской встрече. Мы — приверженцы разумного подхода, поэтому вопросы, которые можно решить здесь и сейчас, предпочитаем решать сразу.
Если же вопрос требует глубокой проработки и для него еще нет готовой рабочей группы, мы ее создаем. В этом случае гильдия выбирает состав участников, и они забирают задачу в проработку.
Рабочие группы внутри гильдии — образования временные. Они создаются и распускаются в зависимости от текущих приоритетов для команд и компании в целом.
3. Работа и получение результатов выполненных задач
Итак, мы определили рабочую группу и задачу. Например, рабочей группе по планированию дали задачу по внедрению общего фреймворка, который решит проблему с разным флоу планирования задач для всех команд «Фланта». Она формализует этот фреймворк и оформляет его в рамках документа. В таком виде группа презентует решение гильдии на еженедельном собрании. Если изменения принимаются, результаты презентуют тимлидам и менеджменту DevOps-направления.
4. Принятие изменений командами
Когда новый фреймворк принимается на уровне тимлидов и менеджмента, он передается в команды. Они обсуждают его и пробуют на практике. Далее собирается обратная связь, по которой ведется доработка фреймворка. Когда решение принято и опробовано всеми уровнями, формируется ТЗ на доработку наших внутренних инструментов для команды внутренней разработки «Фланта», которая адаптирует инструментарий под требования нового фреймворка.
Но на этом цикл процесса донесения изменений не заканчивается. Менеджеры и дальше собирают обратную связь, по которой снова могут вноситься изменения. Поэтому такой процесс становится зацикленным:
С помощью такого процесса мы постоянно улучшаемся.
Вместо заключения
Анализ и оценка проблем с планированием и применение ценностной модели помогли понять и сформулировать требования к создаваемому фреймворку. За основу мы взяли Kanban-метод, элементы Scrum, а также учли нашу специфику. Из этих составляющих мы и создали свой фреймворк.
Механизмом, движущим эти изменения в компании, стала гильдия менеджеров проектов, которая и внедрила в рабочие процессы сформированный нами фреймворк. Выработанные гильдией ценности определили границы и базовый курс всего направления DaaS, позволили нам оперативно создавать изменения и добиваться их принятия в командах.
Видео и слайды
Видео с выступления (~43 минуты):
Презентация доклада:
P. S.
Читайте также в нашем блоге: