Три года назад мы подробно описали принципы планирования нагрузки в студии (ресурсного планирования). На тот момент основными инструментами были Google-календарь, Scrumban, общая тетрадь и песочные часы. С тех пор я разбил песочные часы, исписал общую тетрадь и избавился от google-календарей (сразу, как только увидел их новый дизайн).

Но теперь все проекты у меня под рукой, а прозрачности и порядка стало в разы больше. Хотя, признаюсь, это было непросто. Материал большой, с рассказом по шагам, как мы шли к текущей степени автоматизации, с нашими взлетами и провалами. Искренне надеюсь, что будет полезен не только digital-агентствам, но и всем тем, кто считает, что вкладываться в улучшение системы управления компании — правильно.

Горизонт планирования

Итак, горизонт планирования в студии — порядка 5 недель.

Что было не так с нашей старой системой

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

Со временем у нас все больше и больше клиентов оставалось на технической поддержке. Это нормально. Мы сознательно исходили из парадигмы «свои проекты не бросаем» (клиенту нужно изрядно покапризничать, чтобы мы поняли, что совместное будущее не очень уж светлое). Но, как я уже говорил, именно разношерстная техническая поддержка ломает нам конвейер. Чем её больше, тем больше турбулентности и тем более рваный поток работ.

С ростом количества человек в компании и ростом количества проектов недельное планирование занимало все больше и больше времени, и в итоге дошло до 8 часов. При этом любое изменение в команде (банально, заболел человек) ломало недельный план и дальше эффектом домино накрывало несколько соседних проектов.

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


Lean: что говорит теория

Я буду опираться на Lean (Бережливое производство) и местами на ТОС (теорию ограничений Элияху Голдратта), упрощая картину мира до безобразия. Итак.

1. Создать равномерный поток единичных изделий.
   
2. Сделать все возможное для ускорения прохождения единичного изделия (от момента поступления заказа до момента отгрузки), устраняя муду и мудаков (см. 7 сортов муды в вашей студии)

Больше всего проблем было с первым пунктом — равномерным потоком единичных изделий.

Что такое «единичное изделие» для компании, которая делает софт на заказ?
Это проект целиком? Это какой-то этап (например, дизайн, верстка, или аналитика)? Это спринт? Это одна user story в спринте? Это тикет, прилетевший на техподдержку?

Реально непонятно. Я ломал над этим голову несколько дней, в итоге пришел к очевидному выводу: единичное изделие студии — это то, что можно закрыть актом. То есть, любой атомарный объем работ, после выполнения которого подписывается акт сдачи-приемки. Эту сущность мы назвали «потоком».

По одному клиенту или проекту у нас параллельно может идти несколько потоков (например, аналитики аналитят что-то на 2 спринта вперед, дизайнеры рисуют на 1 спринт вперед, а программисты параллельно в одном потоке пишут новые фичи, а во втором саппортят проект). Есть способы реализовать параллельную работу аналитиков, дизайнеров и программистов, но если вы недостаточно опытный менеджер, вам точно не надо пробовать такие ходы.

Понятие «поток» — это именно то, в чем стало понятно, как измерить нагрузку на менеджера. Оказалось, что измерять нагрузку (Work In Progress) в количестве проектов на человека — некорректно: по одному проекту могут идти параллельно дизайн, верстка, программирование и аналитика, и для менеджера по ощущениям это будет как 4 проекта. А вот «поток» в активной фазе довольно точно показывает, будет ли дым из ушей у менеджера (подсказка: 5−7 потоков, и дым будет; 12 — будет с искрами, черный, но очень недолго).

Под потоки нам пришлось переделать все договоры. Эта работа заняла примерно полгода от момента «идеи» до момента «можно поделиться в интернете». Описание, как это организовать с точки зрения документооборота и договорных отношений, и сами шаблоны договоров для scrum и многопоточной работы можно найти тут. Судя по откликам, наши договоры становятся стандартом отрасли. Неудивительно, учитывая сколько времени, сил и здравого смысла мы в них вложили.


ТОС: Голдратт говорил, что в обслуживании все сложно

Что нам говорит теория ограничений (я, опять же, упрощаю все до безобразия): в любой организации есть одно узкое звено (максимум — два). Его нужно найти, максимально раздуплить и подчинить весь конвейер темпу слабого звена (с учетом разумных/необходимых для мёрфи буферов). Если вы экспедируете (проталкиваете под личным контролем) больше 5% задач, у вас явно какие-то косяки. Если сильно меньше 5% — у вас избыток мощностей.

Однако Голдратт предупреждает, что организовать барабан-буфер-канат для изготовления продукции еще можно (хотя никто не говорит, что это просто), но в сфере обслуживания это ад.

Дело в том, что буферы, необходимые для нормальной работы и защиты от Мерфи в производстве, обеспечиваются складированием некоего количества деталей. А в сфере обслуживания буферы обеспечиваются за счет очередей из клиентов и из задач. Понятно, что никто не любит ждать и стоять в очереди. И, выбирая размер буфера, нужно также учитывать репутационные риски. Кого обслужить первым: того, чьи задачи распланированы и понятны, или того, кто громче кричит? Управляется ли рабочий поток здравым смыслом или децибелами? Та еще дилемма…


Контур технической поддержки: организуем единичные изделия

Мы перевели большую часть технической поддержки на отгрузку задач недельными спринтами. Дали возможность разработчикам самим расставлять оценки — у менеджера нет необходимости погружаться в каждую задачу поддержки, если клиент привык ставить задачи адекватно. Только в самые глубинные, глобальные задачи (такие лучше ловить на корню и пристально контролировать).

При этом система еще и знает, с какой статистикой этот разработчик в среднем не укладывается в свои оценки и как часто его настигает Мерфи. Все это мы можем использовать. Грубо говоря, мы знаем прогноз, на сколько оценка именно этого разработчика именно для этого проекта будет неточной, прежде чем показывать её клиенту, чтобы не вылететь в трубу.

Мы автоматизировали подбивку затрат по технической поддержке. Теперь все стало четко:

Один поток техподдержки = 1 канбан-доска (спринт) = 1 счет = 1 акт

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

Около 85% задач технической поддержки превратились в спокойную работу по спринтам, с нормальными циклами планирования -> тестирования -> внедрения. Еще около 12% — срочные хотелки, которые пытаются поломать нам конвейер, но мы к этому готовы.

Рабочее время разработчиков мы планируем из расчета 6 часов в день для работы по основному проекту (спринту). Еще 2 часа — буфер на форс-мажоры или мелкосрочные задачи техподдержки, которые надо сделать вот прямо сейчас. Такие задачи клиенту обходятся финансово дороже, но и экспедировать (проталкивать вручную) их сложнее. Что за срочность нужно платить — воспринимается адекватно и дисциплинирует.

Нет форс-мажоров — отлично, можно заниматься основным проектом. Ну и все мы прекрасно понимаем (надеюсь, вы тоже), что вот прямо продуктивно «работать-работать» по 8 часов в день без перерывов — нереально (см. метод Pomodoro). Здесь речь идет о распределении рабочего дня между проектами и задачами (то есть, выделение ресурсов), а не про глупую попытку сидеть с секундомером у всех над душой.

Еще около 3% — наши косяки, которые нужно поправить (желательно до того, как клиент про них узнал) и извиниться.

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

Как только требования становятся некорректными, делегирование идёт на уровне идей («А нехреново было бы сократить показатель отказов на этой страницы на 5−7%…»), на их разбор нужно подключать уже менеджера, а иногда еще и аналитика. Причем формализация таких требований, генерация гипотез по их решению, согласование мер — это отдельная большая задача, зачастую занимающая больше времени, чем программирование. Чаще всего это seo-требования, и по ним у нас выстроен отдельный рабочий контур с seo-компаниями (см. -> Сайты, готовые к продвижению).

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

В сухом остатке: большая часть саппорта идет спринтами, T&M (Time And Material), как правило — постоплата. Срочные задачи возможны, но их стало меньше, и клиентам они обходятся дороже.


В поисках готового решения управления портфолио проектов (Portfolio Project Managment, PPM, мультипроектной средой).

В поисках подходящего софта для управления портфолио проектов я как-то перебрал более сотни разных приложений и saas-решений (включая Oracle Primavera). Это довольно редкий софт и, в основном, ОЧЕНЬ дорогой. Моему разочарованию не было предела. Софт, в основном, был тяжелый, плохо под нас заточенный и, повторюсь, чертовски дорогой.

Мне нравится MS Project за его простоту и гибкость в настройках (я про десктопную версию; online-версия — кусок глючного неповоротливого г-на). Однако из коробки он не умеет собирать затраты, в нем всего 11 базовых планов. Да, я знаю, что можно написать экспорт/импорт для синхронизации, и многие так и живут, но у многих проектное управление — отдельно, планы в MS Project — отдельно, а это меня категорически не устраивает. Всё должно быть в одной системе. И самый главный минус: в нем нереально работать с мультипроектной средой, в которой нужно динамически планировать оперативную загрузку по срочным задачам технической поддержки. Можно, конечно, попробовать жить в Sharepoint, но это довольно тяжелые наркотики.

Софт по планированию проектов, в который я влюбился с первого взгляда — Merlin Project. Я был в восторге, и если бы у меня был только один проект, я бы «жил» в нём. Однако, у него те же недостатки, что и у MS Project — он не подходит для мультипроектной, мультикомандной динамичной среды.

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

Зато в итоге я смог составить контур нашей будущей системы, собрать «фишки», которые есть в разных системах, и фишки, которые нам нужны, но которых нигде нет.


Автоматизатор. Из чего он состоит

Первое, что мы сделали — убрали Google Календарь из нашего механизма планирования ресурсов. Мы просто реализовали свой производственный календарь (взяв за основу платные компоненты от dhtmlx, поскольку относительно успешно работали с ними ранее).

У нас есть список сотрудников, разбитых по командам (он подтягивается из нашего корпоративного портала). Все задачи, которые мы ставим в календарь, тут же попадают исполнителям в виде задач портала. Об этом чуть позже. Пока важно, что есть полная синхронизация между планами и тем, как реально с задачами работают конкретные сотрудники.

Далее. Мы сделали таблицу наших проектов с разбивкой по каждому менеджеру — таблица в виде дерева, где по каждому проекту можно смотреть потоки работ. В производственный календарь можно ставить как сами Потоки работ, так и отдельные задачи. Обычно, привязанные к конкретному Потоку.

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

Потоки работ. Основные метрики

Для тех, кто использует MS Project, все описанные ниже метрики довольно очевидны и понятны. Мы использовали очень похожие показатели.

Итак. Поток работ — это часть проекта, которая, как правило, закрывается отдельным актом. Для нее мы храним статус («в работе», «в архиве», «работаем, не получив оплаты» (на опережение), а также, есть ли по потоку подписанные документы и деньги и т. д.). Статус потока нужен для адекватного планирования и прогнозирования очередности потоков.

Потоки могут быть связаны между собой (какой-то должен начаться раньше, какой-то может начаться только после того, как завершен предыдущий; например, сначала нужно закончить аналитику, а затем уже стартовать дизайн). Что-то похожее есть в диаграммах Гантта.

Есть план в часах: сколько часов, как планирует менеджер, будет необходимо команде на работу. Оценки могут быть предварительными (аналогично в MS Project — в этом случае перед оценкой стоит знак вопроса) и уверенными.

Даты начала и окончания потока (также могут быть предварительными и «устаканившимися»). Кроме того, наша система позволяет хранить разные даты начала и окончания потока для разных членов команды: бывает, что кто-то стартует раньше, а после кто-то присоединяется, но это, скорее, исключение из общего правила. Обычно от начала до конца на проекте одновременно работает стабильная команда.

Бюджет в часах. От оценки этот показатель отличается тем, что данные для него берутся из контракта. По понятным (надеюсь) причинам, ОЦЕНКА, которую видит разработчик, может значительно отличаться от БЮДЖЕТА, который был заложен в контракте. Речь идет, в первую очередь, про заложенные риски, подстраховку и трансакционные издержки. Мы долго экспериментировали и в итоге смогли связать этот показатель с 1С.

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

Дедлайн. Берем из контракта или указывается менеджером, исходя из того, когда он планирует закончить поток. Обычно это неделя от даты готовности потока — 3−5 дней стабильно уходит на приемку клиентом.

Затраченное время. Собирается из ежедневных отчетов исполнителей. Суммируется по исполнителям и дням.

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

Затрачено всего. Сумма по затратам.

План в Scrumban / затрачено в Scrumban. Мы используем канбан-доски для спринтов. Каждый поток можно связать с канбан-доской.

Для оценок спринтов команды используется классический Planning Poker (мы сделали физические карты, которые можно купить тут). Соответственно, затраты по спринту также собираются из тех данных, которые ребята выставляли по каждой конкретной задаче.

Кроме того, затраты времени в Scrumban не включают затрат на тестирование и, зачастую, на багфикс или другие активности, которые были по потоку работ (например, ретроспективы, демонстрации проекта клиенту и т.д.). И хотя в целом эти цифры должны быть близки к друг другу, выявленные аномалии для нас — это точка роста. Мы ни в коем случае не ругаем и не компостируем мозги разработчикам из-за этой аномалии — это, скорее, наш управленческий лаг и показатель того, что нам есть над чем работать.

Закончено, часов. Сколько мы уже выполнили из запланированного. Собираются автоматически, как только разработчик перетаскивает задачу по канбан-доске в «проверку». Кто использует в своей работе Метод освоенного объема или Burndown Chart — поймет сходу, про что эти показатели.

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


Фишки Автоматизатора

Разрезание потока по дням («Резать колбаски»)

Этой фишки мне не хватало в гугл-календаре. Допустим, есть задача на несколько дней. Я бы хотел, чтобы в разные дни она стояла у меня с разными приоритетами. Google Calendar такого не позволял. В MS Project есть нечто подобное — возможность «разрезать» задачу в диаграмме Гантта на части и распланировать каждую часть отдельно по разным дням.

Примерно такую же штуку мы сделали в своем календаре. Можно посмотреть весь план по потоку, можно нарезать поток по дням и работать с ежедневным планом, просто тыкая мышкой. Если кто-то сталкивался с необходимостью приостановить задачи по одному потоку, чтобы сделать что-то другое, или поменять приоритеты у задач в течении дня, смогут понять, какой восторг был у меня при внедрении этой функции. Скажу сразу, что пользуемся мы этим крайне аккуратно. У каждого разработчика как правило, ОДИН основной поток (спринт) и, ВОЗМОЖНО, несколько задач техподдержки (обычно не более 2-х часов в день — наша система следит за этим и ругается, если мы нарушаем это правило, но об этом чуть позднее).


Приоритезация задач внутри дня с помощью D&D

То, чего мне не хватало в календарях всегда: возможность менять приоритеты задач в течение дня. Мы взяли и сделали это.


Перетаскивание потоков между днями и исполнителями

Фишка, скорее, нужна для планирования. Я могу таскать задачи и потоки не только внутри дня, но и между днями. Я могу перетаскивать задачу с одного исполнителя на другого. Невероятно удобно для планирования. Кроме того, зажав SHIFT, я не перенесу задачу с одного исполнителя на другого, а просто добавлю его в этот поток.


Немножко разные потоки для каждого исполнителя

Физически это один поток. Но, например, даты начала или даты окончания у каждого из исполнителей будут свои. Так иногда бывает. Наша система умеет и такое.


Статус задачи и план/факт прямо в календаре

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


Режим дня менеджера и логирование его рабочего времени в поток

Календарь для менеджера. Менеджеру необходимо планировать свои задачи на конкретное время. Во сколько позвонить, во сколько — провести демонстрацию клиенту и т. д. Для программистов такое распределение задач по времени почти бессмысленно и в некоторых ситуациях даже вредно (ибо раздражает жутко: программист или дизайнер гораздо продуктивнее и охотнее работает в потоке, когда его не дергают; к сожалению менеджеры, за редким исключением, лишены такой радости).

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

Еще одна «фишечка», которой мне всегда не хватало в Google-календаре— возможность взять и перетащить задачи из списка «на день» на конкретное время. У нас она реализована)


Связанные потоки

Все просто. Есть зависимые по логике потоки работ. Когда по каким-то причинам сдвигается старт (или окончание) первого, нужно передвинуть второй. В таблице потоков зависимые изменения будут подсвечены (аналогично тому, как это делает MS Project). Ничего военного, но удобно, если вдруг не согласовали какой-то дизайн, и нужно сдвинуть всю работу на пару недель.

Прорабатывая функцию связанных потоков, мы больше всего мучились с учетом выходных и праздничных дней при перемещении потоков вперед и назад, хотя изначально казалось, что это довольно тривиальная задача. Например, если поток начинается в четверг и заканчивается в понедельник, его длительность равна 5 календарным дням, хотя рабочих дней охватывается только 3. Если старт этого же потока сдвинуть на понедельник — получится уже 5 рабочих дней, хотя до этого уже запланировали всего 3. А ещё есть праздничные дни, рабочие субботы… Пришлось поломать голову, чтобы сделать адекватный алгоритм смещений.

Ещё одна удобная фишка — в момент создания потока или добавления проекта можно создать сразу типовой набор потоков по разработке простого проекта, подразумевающего одну итерацию.

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

На поток может быть назначено несколько исполнителей. Аналогично MS Project, можно выровнять поток (то есть, найти дату завершения) в зависимости от назначенной команды — дата завершения автоматически выравнивается для всех членов команды. Рассчитывается так: оставшееся по потоку время (план минус текущие затраты) разделяется на количество членов команды, исходя из их 80%-ной загрузки этим потоком в рабочие дни. Получаем количество рабочих дней, необходимое команде для завершения потока, дата рассчитывается и выравнивается. Мелочь, но время экономит здорово.


Кубик-рубик

Рядом с каждым разработчиком и дизайнером можно вывести индикатор его загруженности на ближайшие 5 недель. Кубик 5×5 (пять дней, пять недель), где сразу видно, хватает ли на него задач, не слишком ли их много, где есть недогрузка, или человек вообще в отпуске. Цвета что-то да значат (зеленый — все ОК с нагрузкой, желтый — слишком много, красный — слишком мало и т. д.) Удобно, когда надо понять текущее состояние дел до того, как погружаться в детали ресурсного планирования. Мне это экономит примерно час рабочего времени в неделю.


Компетенции, карма и рейтинг

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

Карма — синтетический показатель, рассчитываемый по специальной формуле в зависимости от того, насколько успешно человек решал такого рода задачи. Рейтинг — выставляется менеджером в момент завершения ПОТОКА простым голосованием. Можно обнулять карму.

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


Аномалии

Режим подсветки аномалий довольно вырвиглазный. Ну да, как вы, наверное, заметили, у нас довольно аскетичный «программистский» дизайн. Пока это так и останется, потом что-нибудь с этим придумаем. Суть режима подсветки аномалий — показать, не загрузили ли мы человека сверх меры, например, мелочёвкой. Наша система способна выявлять десятки аномалий и предупреждать о них. Что с ними делать (и делать ли вообще что-либо, либо смириться) — это уже управленческий вопрос. В данном случае важна сама индикация, что мы про это в курсе.


Компетенции и подбор разработчика на проект

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

В итоге нейросеть подсказывает, какую из команд разработчиков оптимальнее всего назначить на проект. Итоговое решение все равно остаётся за человеком (это дополнительно обучает нейронку). Пока что мы не научились учитывать загрузку этого человека и плановые дедлайны по потоку работ, но это вопрос нескольких месяцев. Потом директор будет не нужен :) Шутка.


Ревью потоков и еженедельные базовые планы
Базовый план — это очень удобная штука. Вы что-то спланировали, а потом можете посмотреть, как оно пошло на самом деле. И создать новый план. Самое интересное — смотреть как сильно вы отклонялись от вашего базового плана. В MS Project у вас может быть 11 базовых планов — в нашей системе базовые планы создаются прозрачно, раз в неделю, по окончании процедуры планирования ресурсов. Их может быть сколько угодно.

Кроме того, есть режим «ревью потоков». Раз в неделю нужно пробежаться по списку активных потоков, актуализировать статусы, возможно — даты старта/финиша. Рядом с каждым потоком поставить чашечку кофе (мол — отсмотрено).

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


Автоматические запросы ресурсов. Поиск аномалий в запросах ресурсов

Запросы ресурсов в каком-то виде есть в MS Project Online, но я бы не сказал, что там это сделано удобно. Суть процедуры: раз в неделю менеджер актуализирует свои потоки (появляется что-то новое, что-то изменяется, прилетают новые задачи) и примерно расставляет новые потоки, исходя из того, как бы ему ХОТЕЛОСЬ это запустить в работу. Система на ходу генерирует лог таких изменений относительно предыдущего базового плана.

Далее автоматизатор выявляет десятки аномалий, которые могли возникнуть. Например, если на проект изначально планировалось 80 часов, а вдруг стало 30 — это повод поговорить. Или если слишком оптимистично / пессимистично проставлены даты завершения потока — тоже нужно понять, почему это так. Запросы ресурсов мы обсуждаем с менеджерами голосом еженедельно, устаканивая наш реальный план. Обычно занимает по 20−30 минут на каждого менеджера.

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

Еще год назад процедура планирования ресурсов занимала не менее 1 часа у менеджера в одиночестве, затем около 4-х часов на все потоки у меня, и затем еще примерно 40−50 минут на разбор аномалий с каждым менеджером. Сейчас это время сократилось примерно вчетверо, и большая часть аномалий устраняется менеджером прямо во время планирования.


Режим исполнителя: важные новости, сокращаем WIP (Work in progress) и ежедневная отчетность

Исторически так получилось, что для хранения задач мы используем корпоративный портал Bitrix24, на который для работы по Scrum установлен модуль Scrumban. До этого мы использовали Jira, но поскольку возникала задача тестирования Scrumban в реальных условиях, мы мигрировали на Bitrix24 (да, было больно, но принцип «жрать собачий корм» в разработке софта никто не отменял). Модуль довольно старый, уже просит переделки на современные технологии, наверное займемся. Но я отвлекся.

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

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

Прямо в списке задач можно указывать, сколько она заняла у тебя времени сегодня (логировать время, не уходя в дебри). Режим просмотра деталей задачи — стандартный B24-й. Тут же можно добавить себе задач, если вдруг тебя на что-то дернули в течение дня. Да, мы знаем, что это очень плохо, когда тебя дергают, но еще мы реалисты, и знаем, что так бывает. Обычно больше всего дергают нашего технического директора по мелким вопросам, коих может накопиться на пол рабочих дня. У парня железные нервы, надо признать.

Задачи можно «прокакашить». Это принцип «уперся-сообщи» из наших любимых парадигм Фридмана.

Например, задача настроить сервер, а доступы не подходят. Время чуть-чуть потрачено, но решить задачу нельзя. Жмем какашку. Уведомление летит в почту всем заинтересованным.

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

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

Кстати, сам ежедневный отчет — это, по сути, формальность: нажать кнопку «отправить» (можно не нажимать, в этом случае отчет сформируется сам). Ну и возможность написать о каких-то проблемах. Например, тормозном компе или сломанных наушниках. Отчеты наш исполнительный директор Екатерина читает каждое утро и по проблемам обязательно принимает меры (пересадить за другую машину, заказать гарнитуру или, например, провести ретроспективу по какой-то проблеме).


Обновление информации в реальном времени. Push-технология

В системе одновременно работает несколько менеджеров. Естественно, мы предусмотрели обновление информации на их экранах с помощью push-технологии в режиме реального времени. Также предусмотрели блокировки (если какая-то задача кем-то редактируется). Очень хорошо, что мы выбрали React в качестве фреймворка на фронтэнде — эта довольно сложная функция была решена относительно малой кровью.


Выводы и перспективы

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

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

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

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

Работа была проделана гигантская, не только на уровне программирования, но и на уровне документооборота и нашего понимания бизнес-процессов. По сути, мы не только оцифровали наш контур управления, но и значительно его изменили (пересобрали заново). Все это базируется не только на понимании принципов LEAN, TOC, Scrum, проектного управления, нейросетей, анализа программного обеспечения близких аналогов, но и на огромном опыте проектной работы в реальных условиях.

Хочу выразить огромную благодарность своей команде, в первую очередь — Леше, Ване, Кате, Дине, Степану. С вашей помощью можно горы свернуть, и я рад, что с вами у меня это всё получилось.

Огромное спасибо тем, кто дочитал до конца. Надеюсь, наш опыт будет кому-то полезен или вдохновит на какие-то подвиги)) Успехов!