Одной из опасных штук, незаметно съедающей время офисного работника, является параллельность операций. К примеру, на совещании обсуждают десять задач. По каждой есть движение: запросили данные, начали согласование, подготовили черновик. На вопрос «Что готово?» ответить труднее. В перечне всё начато, но для получателя ещё ничего не изменилось. То есть показать просто нечего.

Похожую разницу между активностью и результатом описывали в исследовании одной британской медиакомпании. Авторы наблюдали за девятью разработчиками и их Kanban-доской. За год время от начала работы до поставки сократилось на 37%, стабильность поставок выросла на 47%, а число клиентских дефектов снизилось на 24%. Для улучшения их работы одновременно применялись несколько практик. Получается, что смотреть только на число начатых задач недостаточно, нужно видеть, когда результат дошёл до получателя и какого он качества.

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

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

Стоит спросить заказчиков не только о сроке, но и о решении, для которого нужна каждая справка. Одна может требоваться завтра, две другие - в конце месяца. Тогда порядок определяется договорённостью, а не частотой напоминаний или важностью заказчика.

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

Ожидание не стоит называть выполнением: «мы уже начали» создаёт другие ожидания, чем честное «возьмём после текущей задачи». Если срок изменился, сообщить лучше до напоминания заказчика.

Полезно заранее договориться и о слове «готово». Снова ссылаюсь на Scrum Guide - результат не считается готовым приростом продукта, пока не соответствует согласованному Definition of Done - описанию состояния, отвечающего требованиям качества. Только лишь для подготовки служебной справки нет необходимости внедрять Scrum, но можно задать простой вопрос: может ли получатель уже использовать результат или пока готова только часть работы?

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

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

Оценивать работу по занятости опасно: команда может быть загружена, а результаты будут приходить позже. Полезнее смотреть на завершённые и принятые задачи, срок от запроса до результата и возраст незавершённой работы. Сложность разная, но вопрос «Почему задача открыта месяц?» обнаруживает скрытую задержку.

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

С ИИ этот вопрос становится ещё острее: запустить несколько прототипов до MVP можно быстро, а довести их до продуктива - совсем другая работа. О ней - в следующей публикации.