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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сравнительная табличка исследованного софта

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

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

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

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

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

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

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

Как выглядит автоматизатор. Как календарь, только не календарь

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кубик-рубик

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

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

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

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

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

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

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

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

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

Аномалии

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

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

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

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

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

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

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

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

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

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

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

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

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

В этом режиме можно отсмотреть изменения по потокам

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Екатерина

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

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

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

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

Дина

руководитель проектов

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

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

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

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

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

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


Оставить комментарий

Ваш email нигде не будет показан
Обязательные для заполнения поля помечены *

*

x

Ещё Hi-Tech Интересное!

Microsoft победила Intel, Tencent и садоводов в конкурсе на лучший ИИ для выращивания огурцов

Microsoft победила Intel, Tencent и садоводов в конкурсе на лучший ИИ для выращивания огурцов — Будущее на vc.ru Свежее Вакансии Написать Уведомлений пока нет Пишите хорошие статьи, комментируйте,и здесь станет не так пусто Войти Технологии искусственного интеллекта помогали «умным» теплицам ...

«Хуже проекта, сделанного одними технарями, бывает только проект, сделанный одними маркетологами»

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