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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что такое «единичное изделие» для компании, которая делает софт на заказ? Это проект целиком? Это какой-то этап (например, дизайн, вёрстка, или аналитика)? Это спринт? Это одна 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), как правило — постоплата. Срочные задачи возможны, но их стало меньше, и клиентам они обходятся дороже.

В поисках готового решения управления портфолио проектов (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С и вуаля.

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

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

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

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

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

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

ТОНКИЙ МОМЕНТ: часто затраты из доски Scrumban сильно расходятся с затратами, которые мы получаем из отчетов. Это, по факту, аномалия, связанная с некоторой неаккуратностью данных по затратам (когда разработчик закрывает задачу, зачастую он довольно небрежно или оптимистично проставляет затраченное время;, но когда нужно в конце дня раскидать своё рабочее время по выполненным проектам, если он у него не один — вылезает небольшой лаг).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кубик-рубик

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

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

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

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

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

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

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

Аномалии

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

©  vc.ru