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

Я говорю о ситуации, когда в уже запланированную работу прилетает ad-hoc. Мелкий баг, срочная просьба, быстрый PoC, небольшая доработка - буквально на один вечер.

И ты думаешь: “Блин, сейчас же надо будет план перекраивать, кого-то из разработчиков погружать в новый контекст, объяснять, почему это важно, потом еще проверять результат. Ладно, я сам быстро сделаю”.

Самое неприятное, что часто это правда.
Ты действительно сделаешь быстрее. Особенно если ты технический руководитель, хорошо знаешь систему и еще не до конца отпустил роль сильного исполнителя. В моменте это выглядит как самое рациональное решение: не дергать команду, не ломать план, не тратить время на объяснения, а просто взять и закрыть вопрос.

Разве Agile не говорит, взаимодействие важнее процессов? Разве не важнее быстро отреагировать на изменение, чем строго следовать плану?Да, говорит. Но это не индульгенция на хаос. Agile лишь предостерегает от подмены живого взаимодействия бюрократией. Поэтому сам по себе факт, что руководитель иногда сделал задачу руками, не является проблемой. Конечно, иногда можно сделать самому. Иногда это правда дешевле, быстрее и разумнее, чем разворачивать полноценный процесс. А иногда это и вовсе делается специально, чтобы не терять технический навык.

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

Во-первых, команда перестает видеть реальную нагрузку.
На планировании у нас есть capacity команды. Есть задачи. Есть сроки. Все вроде бы сходится. Но потом часть незапланированной работы внезапно растворяется в руководителе.
Снаружи система выглядит лучше, чем она есть. Команда как будто справляется. План как будто не пострадал. Ad-hoc как будто ничего не стоил. Но он стоил, это не бесплатная работа - просто ее стоимость никто не увидел.

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

В-третьих, у бизнеса появляется иллюзия, что ad-hoc бесплатны.
Если срочная просьба просто сделалась, значит, можно принести еще одну. Потом еще одну. Потом еще десять. И каждый раз это будет выглядеть как маленькая задачка, которую почему-то сложно встроить в план.
И в бизнесе нет проблемы. Бизнесу нормально хотеть быстро. Проблема в том, что мы не показываем цену этой скорости.
Если ad-hoc съел день руководителя, это тоже цена. Если из-за него не состоялась нормальная подготовка к 1-1, не была продумана архитектурная развилка, не был разобран системный риск - это тоже цена. Просто ее сложнее положить в таск-трекер.

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

1/2