Event driven management

Как ни странно, это продолжение темы "как всё успевать". Я этого не планировал, но по сути вкусно так получается.

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

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

Зачем тут, спрашивается руководитель? Развивать сотрудников и решать конфликты? Ну так это коуч какой-то. Оценивать перфоманс и назначать зарплаты? Можно заменить кем-то из HR. Следить за тем, что процессы соблюдаются? Надзиратель.

Мы знаем, что руководитель здесь нужен для этого всего тоже, но в основном для того, чтобы работа в итоге была сделана. Это вообще как бы основная функция начальства — доводить до результата.

Можно поконкретнее?
В хорошо отлаженной системе основная задача руководителя — не мешать людям работать. Но есть один нюанс: сотрудникам может мешать что-то, кроме руководителя! И вот именно эти вещи и должны привлекать внимание начальства. То есть вам, как управленцу, нужно устранять препятствия на пути к цели и не создавать новых.

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

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

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

Расскажу, что есть у меня, а что я бы хотел, чтобы было ещё.

1. Я стараюсь коммуницировать, что при затыках, проволочках и потере темпа _нужно_ идти и эскалировать в меня. Это вообще первый и главный сигнал к включению
2. Колонка "запланировано" всегда должна содержать не менее X задач (X, очевидно, разнится). Здесь мы хотим не менее пяти задач, а если их становится меньше трёх, то это повод прямо сейчас разобраться, что ещё нужно докинуть. Иначе следующий освободившийся сотрудник не будет знать, за что взяться и случится бесполезный простой в лучшем случае. В худшем сотрудник будет делать задачу, которая важна _по_его_мнению_. С другой стороны, если в колонке слишком много задач, то это тоже какой-то нездоровый признак — явно что-то сломалось с приоритетами и планированием (если ты планируешься в среднем раз в неделю на команду из пяти человек, а задач в запланированном больше 20-ти штук, то скорее всего вы их не сделаете)
3. Колонка "готово к работе" тоже должна всегда содержать некоторый буфер задач. Если задач в ней становится меньше Y, нужно озаботиться тем, чтобы кто-то уже взялся за запланированное и начал готовить задачу к взятию в работу (у нас это значит выполнить DoR: по чек-листу проверить, что в задаче есть вся нужная инфа, DoD, проведена декомпозиция, учтены и обработаны все внешние зависимости и т.д.). В противном случае мы рискуем оказаться в ситуации, когда код никто не пишет, а все заняты высокими материями типа общения со смежниками или декомпозиции задач. Я уже молчу о том, что не каждый сотрудник одинаково хорошо может с такими задачами справляться, тут нужно всё-таки давать что-то посильное (пусть и с челленджем).
4. Диаграммы DORA. Беглого взгляда на них обычно достаточно, чтобы увидеть какие-то аномалии: слишком быстро или слишком медленно стали делать задачи (на новогодние отлично видно, как релизы откладываются, например). Здесь у нас в трекере есть вьюшка, отображающая цикл тайм по статусам. По ней можно попробовать понять, в какой именно части процесса произошла проблема (релизы, ревью ПРов, декомпозиция или сама разработка и т.п.) — тут либо будет ожидаемо, либо надо копать дальше, но уже ясно направление.
5. Диаграмма потока задач. Здесь просто следим за тем, что решается задач не меньше, чем заводится новых — рост бэклога это не хорошо, это "запасы".
6. Длина очереди обращений в поддержку. Ну тут всё ясно, кажется. Если очередь выросла, надо бы разобраться, что к этому привело и разгрести хвост.
7. Доска с задачами в разбивке по людям. Здесь следим за тем, что у каждого есть задача и в работе только одна в один момент времени.

Этого всего лишь три вкладки в браузере, которые нужно проверять раз в день, некоторые, раз в неделю. И если там всё нормально, то можно заниматься планами развития, глубинными 1-1, написанием постов в каналы в телеге...

Для операционного менеджмента ещё не хватает одной диаграммы:

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

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

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