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

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

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

Владимир Завертайлов, scrum-студия «Сибирикс», директор
Владимир Завертайлов, scrum-студия «Сибирикс», директор

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

«Автоматизатор» — очень продвинутый планировщик внутренних процессов студии. С душой. И программистским дизайном
«Автоматизатор» — очень продвинутый планировщик внутренних процессов студии. С душой. И программистским дизайном

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

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

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

  • Аналитика: агрегация требований, прототипирование, формирование бэклогов или ТЗ.
  • Дизайн: от формирования концепции проекта до проработки сотен внутренних страниц.
  • Спринты разработки. Хорошо и легко планируемые этапы работ. Ты просто назначаешь команду на проект и нарезаешь производственный календарь на одну-две недели (в зависимости от опыта команды).
  • Гигантская техническая поддержка. В ней есть все признаки полноценных проектов. От аналитики, дизайна и вёрстки до разработки.
  • Мелко-срочная техподдержка. Либо что-то рухнуло в продакшне, либо менеджер клиента срочно и громко просит поменять ссылки на сайте с серого на золотой прямо сейчас, иначе ему не дадут звезду (а его босс топает ногами и люто негодует).
  • Разношёрстная техническая поддержка с искусственно завышенной срочностью и важностью. В ней нет падения серверов, но клиент не хочет ждать. При этом на полноценный подпроект она не тянет. С ней, кстати, было сложнее всего. Очень высокие транзакционные издержки, сумбурные требования, разносортные задачи, скачущие приоритеты, нервы, крушение головного мозга. Это как раз то, что ломало (и иногда даже сейчас ломает) отлаженную систему.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Режим отчёта наглядно показывает плановые и фактические затраты для менеджера и заказчика
Режим отчёта наглядно показывает плановые и фактические затраты для менеджера и заказчика

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

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

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

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

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

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

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

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

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

Шаблон задачи упрощает постановку менеджерам-новичкам
Шаблон задачи упрощает постановку менеджерам-новичкам

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

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

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

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

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

В поисках подходящего софта для управления портфолио проектов я как-то перебрал более сотни разных приложений и 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. Мы используем канбан-доски для спринтов. Каждый поток можно связать с канбан-доской.

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

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

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

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

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

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

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

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

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

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

Разные приоритеты в разные дни для «длинных задач». Этого мне всегда не хватало в «Google Календаре»

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

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

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

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

Достаточно перетащить задачу в списке — приоритеты для каждой присваиваются автоматически

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

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

Задачи можно перетаскивать как угодно

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

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

Варьирование границ потока для разных сотрудников

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

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

Ключевые статусы по задачам всегда на виду
Ключевые статусы по задачам всегда на виду

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

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

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

Почасовое расписание менеджера на день. Ну это и в Google было...
Почасовое расписание менеджера на день. Ну это и в Google было...

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

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

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

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

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

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

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

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

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

За один раз можно создать сразу несколько потоков, просто нажав нужные галочки
За один раз можно создать сразу несколько потоков, просто нажав нужные галочки

Автоматическое выравнивание границ потоков

Нажатием кнопки выравниваются границы потока

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

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

Кубик-рубик

Цветные индикаторы показывают нагрузку сотрудников по рабочим дням на ближайшие пять недель
Цветные индикаторы показывают нагрузку сотрудников по рабочим дням на ближайшие пять недель

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

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

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

Как выглядит карта компетенций каждого сотрудника
Как выглядит карта компетенций каждого сотрудника

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

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

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

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

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

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

Аномалии

Всплывашка сигнализирует о том, что что-то пошло не так
Всплывашка сигнализирует о том, что что-то пошло не так

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

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

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

Система подбирает оптимальных сотрудников для проекта с учётом их скилов
Система подбирает оптимальных сотрудников для проекта с учётом их скилов

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

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

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

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

Ревью потоков и еженедельные базовые планы

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

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

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

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

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

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

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

Наглядный список всех изменений вместе с аномалиями
Наглядный список всех изменений вместе с аномалиями

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

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

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

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

Как выглядит дневное расписание сотрудника
Как выглядит дневное расписание сотрудника

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

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

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

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

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

Центрирующие парадигмы висят в нашем офисе на видном месте
Центрирующие парадигмы висят в нашем офисе на видном месте

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

Как «закакашить» задачу
Как «закакашить» задачу

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

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

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

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

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

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

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

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

Например, расстановка приоритетов для всех исполнителей студии на следующий день раньше занимала час. Основное время — это просто ручные операции. Пять часов в неделю. Сейчас можно «резать колбаски» и сортировать drag’n’drop кусочки задач без проблем. Занимает в три-четыре раза меньше времени. Выглядит просто, но «за спиной» этой фишки не один десяток часов — поиск решений, тесты и отладка на сложных кейсах. И это только один из примеров.

Практически всеми опциями я пользуюсь сама. Это помогает фокусироваться на важном и замечать недочеты.

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

Я искренне горжусь системой, которую мы разработали. Оглядываясь назад, хочется сказать «Ого!». Потрачено невероятное количество часов, но оно того стоило.

Екатерина, исполнительный директор

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

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

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

Дина, руководитель проектов

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

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

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

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

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

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

3030
20 комментариев

Надо было сразу вот такие скриншоты выкладывать.

11
Ответить

Учтём )

Ответить

Пока читал, словил управленческий оргазм=)

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

Жду SaaS

3
Ответить

Спасибо )

1
Ответить

"При этом рабочий день разработчика мы планировали из расчёта утилизации в 80%" - сколько часов берете за базу? 6? 8?

1
Ответить

8h — база. 6h — основной проект. 2h — Мёрфи / обучение / срочняки / всякое такое себе.

1
Ответить

Огромная работа выполнена, круто! И жаль что не SAAS.

Portfolio для Jira не пробовали? https://ru.atlassian.com/software/jira/portfolio
Если щупали, то что в нем не подошло?

Ответить