Всем привет. Мы давно не писали на тему менеджмента команд и проектов. Начнем с краткой вводной. Помимо продуктовой разработки, которой мы занялись около 5 лет назад, основным направлением деятельности «Фланта» остается DaaS (DevOps as a Service). Мы помогаем клиентам с обслуживанием инфраструктуры. И эта деятельность накладывает большой отпечаток на наш внутренний процесс управления проектами, так как у нас много специфичных процессов и практик: у команды может быть несколько разноплановых проектов, ей необходимо обеспечить SLA по каждому из них. Важно и то, что наши команды на 100% удаленные. 

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

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

Как было раньше

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

И выросла стена задач 

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

У «стены задач» было много недостатков и для наших инженеров, и для клиентов:

• Инженеры чувствовали себя вечными должниками. Когда в твоем плане 10 и более задач, из которых ты доберешься максимум до 3-4, появляется ощущение вечного долга. Это демотивировало инженеров. 

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

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

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

• А еще появилась проблема «подвала». Задачи, которые находились ниже третьей или четвертой позиции в списке, часто были обречены на забытье. 

Мы решили избавиться от этих проблем и стали искать варианты решения. 

Что мы поменяли: WIP-лимиты или ограничение работы в работе

Естественно, все давно было придумано за нас и шаг, который сам собой напрашивался, — это ввести WIP-лимиты (Work in Progress Limits), то есть ограничить число задач в работе у каждого инженера. Но тут мы столкнулись со сложностью: мы не могли оценить емкость команды, так как, во-первых, инженеры работали с разной скоростью, во-вторых, задачи были разными и по сложности, и по длительности их выполнения. 

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

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

Как мы рассчитали WIP-лимиты и попробовали применить их на практике 

У нас были исторические данные по работе каждого инженера. На их основе мы посчитали, сколько задач в день в среднем закрывает инженер. Это значение, по сути, и стало индивидуальным WIP-лимитом. В первый день работы по новой методике мы оставили каждому инженеру в плане то количество задач, которое получили при расчете WIP-лимитов. Кроме того, сделали простую Google-таблицу: в нее внесли  лимит, число назначенных задач и свободных слотов по каждому инженеру.  Дежурных в команде мы отмечали цветом и новых задач им, естественно, не назначали.

Первые сложности: понимание приоритетов и элементы вытягивающей модели

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

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

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

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

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

Так у нас появились элементы вытягивающей модели.

Работа с блокировками, или при чем тут груминг

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

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

Час тимлида и «миты у кулера»

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

Решение было очевидным: назначить в середине дня дополнительную ежедневную встречу на 30-60 минут — чтобы обсудить возникшие блокировки по задачам.

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

Обе эти практики довольно эффективно решали вопрос блокировок по задачам, в особенности для новичков. 

Чего не хватало в модели с WIP-лимитами

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

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

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

Эти недостатки побудили нас к дальнейшему развитию системы планирования.  

Этап первый: что дает клиентам «Флант» или поиск баланса

На первом этапе требовалось понять, какую ценность мы приносим клиентам. Мы расписали всё по пунктам и получили следующий список:

• готовый к production кластер Kubernetes на базе нашей платформы Deckhouse;

• мониторинг «из коробки» с первого дня;

• техническая поддержка production 24/7 с SLA на реакцию в 5 минут;

• настраиваемая система эскалации, в том числе в команду клиента;

• постоянная команда инженеров для обслуживания проекта — следовательно, они накапливают экспертизу и знания по нему;

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

• выполнение задач по развитию и модернизации инфраструктуры;

• менеджмент команды и обеспечение достижения результата (это про разницу между «мы делали» и «мы сделали»);

• нивелирование различных рисков, которые есть у инженера в штате: bus factor, отпуск, ошибки найма.

Ого! После минуты гордости и самолюбования мы все же вспомнили, ради чего этот список создавался, и перешли к следующему этапу.

Этап второй: в поисках универсальной единицы

Итак, список приносимой ценности есть, но тут мы столкнулись с проблемой героев небезызвестного мультфильма: в чем измерять? Нужен был кандидат на роль универсального «попугая», в котором можно измерять и емкость команды, и объем проданных услуг. 

Часть ценностей, которые мы приносили, требовала одинаковых или почти одинаковых ресурсов команды для проектов разного размера. Здесь речь идет как об использовании наших продуктов (Deckhouse, werf, Okmeter), так и о других ценностях из категории постоянных: менеджмент, дежурный инженер, служба L1. Стоит оговориться, что с определенных объемов это правило не работает и нужно выделять на проект либо отдельного дежурного, либо целую команду с менеджментом — но это нестандартные случаи, обычно в больших или особенных проектах. Мы решили, что надо сделать универсальное решение, а нетипичные проекты просто будут рассматриваться в частном порядке. 

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

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

Следующий очевидный кандидат на универсальную единицу измерения — это время работы инженера. С одной стороны, в отрасли все понимали, что такое 10 часов инженера. С другой стороны, час Senior-инженера — это совсем не то же самое, что час Junior-инженера. А нам хотелось оставить за собой право определять, какой инженер будет работать с задачей в проекте, и при этом распределять ресурсы согласно договоренностям. Поэтому мы отказались от почасовой единицы измерения и решили создать свою, универсальную. 

Перед тем как мы к ней перейдем, подсветим один важный момент. Опыт работы с большим количеством технологий, на который позитивно обречена сильная инженерная команда, а главное — возможность его переиспользовать в разных проектах — дают мощный синергетический эффект. Самый яркий пример: с нашей платформой Deckhouse мы за считанные часы получаем готовый к боевой эксплуатации кластер Kubernetes с набором необходимых модулей. Без подобных инструментов автоматизации квалифицированный инженер будет выполнять аналогичную задачу несколько недель, а затем потратит еще много сил и времени на доводку и поддержку такого решения. Такой синергетический эффект сильно повышает ценность часа инженера «Фланта» в глазах клиента. 

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

Такой единицей стал слот WIP — 2 часа работы опытного инженера «Фланта». При этом новичок мог сделать аналогичную задачу за 3 часа, но для клиента базовой единицей измерения и оплаты все равно остается слот WIP.  

Как это выглядит для клиента: он приобретает WIP-лимит на определенное количество задач, одновременно находящихся в работе. Этот лимит определяет, какое количество слотов WIP будет ежедневно выделяться для задач проекта. 

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

Этап третий: изменения в планировании команды

Когда мы начали оперировать слотами определенной продолжительности, мы стали по-другому оценивать количество задач, которые назначали инженеру в работу на день. Так, для опытного инженера это было 3 задачи в индивидуальном плане на день, каждой из которых инженер уделял около 2 часов своего рабочего времени, а для джуниора — 2 задачи по 3 часа каждая. Если какая-то задача явно должна была занять менее 2 часов, это учитывалось в планировании дня.

Почему и откуда взялись 3 задачи? Все просто: у нас во «Фланте» семичасовой рабочий день (мы понимаем, что необходимо время на переключение между задачами или дополнительные коммуникации, которые никак не учитываются), еще 1 час уходит на ежедневный командный митинг. Итого на работу по плановым задачам остается 3 двухчасовых слота. 

Этап четвертый: делать именно то, что нужно

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

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

По сути, теперь все планирование на еженедельных встречах с клиентами сводится к 4 этапам:

1. Сначала мы обсуждаем прошедшую неделю: что из запланированных задач было выполнено, что еще в работе, какие изменения в плане произошли и по каким причинам.

2. На втором этапе мы собираем бэклог спринта: набираем из бэклога задачи, по которым требуется поработать на текущей неделе. Задачи, важные для развития бизнеса заказчика, приоритезирует клиент, а инфраструктурные изменения, которые требуют внимания, подсвечиваем мы. 

3. На третьем этапе мы совместно планируем задачи: прогнозируем в слотах срок, за который выполнится задача, и проставляем слоты прямо в диаграмме. Ограничением служит пропускная способность (WIP-лимит).

4. Когда лимит исчерпан, оставшиеся незапланированными задачи убираются в бэклог.

Любой человек, взглянув на эту идеальную картинку, сразу задается парой вопросов:

• Что будет, если более срочная задача появится между планированиями? Конечно, такие истории случаются. В этих случаях по просьбе клиента мы поменяем задачи, и в работе окажется нужная.  

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

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

Наследие? Наследство!

Мы забрали много элементов из предыдущих моделей планирования:

• мы все так же планируем работу команды каждый день на ежедневных командных митингах;

• мы проводим груминг бэклога и статуса Blocked;

• у нас сохраняется практика «часов тимлида» и «митов у кулера»; 

• в некоторых командах мы по-прежнему формируем списки помеченных флагами задач.

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

P.S.

Читайте также в нашем блоге:

• «Управление распределенной командой в режиме многопроектности»