Эпос про нейронные сети и автоматизацию управления — на примере scrum-студии «Сибирикс»

Меня зовут Владимир Завертайлов, я руководитель и главный бармалей scrum-студии «Сибирикс». Три года назад мы подробно описали принципы планирования нагрузки в студии (ресурсного планирования).

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

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

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

С какими задачами мы имеем дело:

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

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

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

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

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

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

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

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

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

Понятие «поток» — это именно то, в чём стало понятно, как измерить нагрузку на менеджера. Оказалось, что измерять нагрузку (Work In Progress) в количестве проектов на человека — некорректно: по одному проекту могут идти параллельно дизайн, вёрстка, программирование и аналитика, и для менеджера по ощущениям это будет как четыре проекта.

А вот «поток» в активной фазе довольно точно показывает, будет ли дым из ушей у менеджера (подсказка: пять-семь потоков — и дым будет; 12 — будет с искрами, чёрный, но очень недолго).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Всё должно быть в одной системе. И самый главный минус — в нём нереально работать с мультипроектной средой, в которой нужно динамически планировать оперативную загрузку по срочным задачам технической поддержки. Можно, конечно, попробовать жить в Sharepoint, но это довольно тяжёлые наркотики.

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

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

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

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

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

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

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

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

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

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

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

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

Бюджет в часах. От оценки этот показатель отличается тем, что данные для него берутся из контракта. По понятным (надеюсь) причинам, оценка, которую видит разработчик, может значительно отличаться от бюджета, который был заложен в контракте. Речь идёт в первую очередь про заложенные риски, подстраховку и трансакционные издержки. Мы долго экспериментировали и в итоге смогли связать этот показатель с «1С».

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

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

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

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

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

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

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

Тонкий момент: часто затраты из доски Scrumban сильно расходятся с затратами, которые мы получаем из отчётов. Это аномалия, связанная с некоторой неаккуратностью данных по затратам.

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

Кроме того, затраты времени в Scrumban не включают затрат на тестирование и зачастую на багфикс или другие активности, которые были по потоку работ (например, ретроспективы, демонстрации проекта клиенту и так далее).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ещё одна удобная фишка — в момент создания потока или добавления проекта можно создать сразу типовой набор потоков по разработке простого проекта, подразумевающего одну итерацию. Агрегация требований → прототип → ТЗ → Главная → Внутренние → Верстка → Сборка — всё это типовые потоки, которые часто идут друг за другом.

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

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

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

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

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

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

Также мы собираем:

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

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

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

Режим подсветки аномалий довольно вырвиглазный. Как вы, наверное, заметили, у нас довольно аскетичный «программистский» дизайн. Пока это так и останется, потом что-нибудь с этим придумаем.

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

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

Мы построили и обучили нейросеть на основе:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#инструменты