Автор статьи: Дмитрий Курдюмов

Участвовал в Аджайл-трансформациях в крупнейших компаниях в России (Альфа банк, МТС, Х5 retail group), с международным опытом в стартапе зарубежом.

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

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

Первая причина — вы принимаете абсолютно все задачи и обещаете их выполнить, называя неоправданные сроки. То есть любую задачу, которую приносит клиент, вы принимаете и начинаете строить план и прогноз по ее выполнению. И, таким образом, создаете ложные ожидания. Это все равно, что пообещать спустутиться на лифте через 3 минуты, при том, что перед лифтом очередь из 100 человек, постоянно приходят новые люди и проходят без очереди. Разве при таком раскладе можно гарантированно сказать, когда вы спуститесь? То же самое обычно происходит и в бэклоге задач — приоритеты меняются, очередь растет. Только с бэклогом задач еще сложнее — больше неопределенностей в ходе выполнения (техническая сложность, трудоемкость, риски и прочее).

Вторая причина — вы часто бросаете задачу незавершенной и приступаете к новой. Как правило, такое происходит, когда заказчик или менеджер и просит «срочно» сделать еще одну задачу. Я нередко наблюдал, как в процессе выполнения команда переключается на другую задачу, которая внезапно становится «более» срочной. Потом появляются задачи еще более срочные, и количество недоделанной работы растет. Также когда отсутствует сквозной поток создания ценности, задачи попросту простаивают в очередях. Например, разработчик сделал задачу, она ждет тестирования, а тестировщики в это время занимаются другими задачами, и когда дойдет до этой — неизвестно. В этот момент задача просто ждет, а это потеря времени.

Третья причина — не вы управляете работой, а она вами. Действительно ли по всем задачам в данный момент времени выполняется «полезная работа»? Сколько задач в «статусе ожидания», сколько заброшенных? Кто ответственен за разблокировку таких задач? Я в своей практике находил у команд задачи, остающиеся в ожидании от нескольких месяцев до года. Поставили на hold, ждали ответа, и поскольку никто не отвечал за разблокировку, то про задачу забывали, так как ушли в другие задачи.

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

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

Как с этим бороться?

Отличным инструментом по улучшению процессов служит Kanban метод. С одной стороны, он делает все процессы и всю работу явной, прозрачной, а с другой — вносит ограничения в процесс (в виде одновременно выполняемой работы), которые контролируют количество задач в работе и фокусируют команду на завершении. То есть, условно, если две из трех задач подвисли в колонке «тестирование», то пока мы их не доделаем, следующую задачу из разработки мы не берем. Также Kanban метод дает отличные инструменты для прогнозирования на основе объективных данных.

Какие ключевые мысли несет метод?

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

2. Выстраивайте заказчиков в очередь. Невозможно все задачи принять и пообещать сделать и выполнить это обещание. Если заказчики внутренние, дайте им возможность договориться, какие задачи следующими пойдут в работу на основе вашей пропускной способности и бизнес-ценности каждой задачи. Дайте им инструмент приоритизации — например: «влияние на бизнес-результат х уверенность в том, что вы достигните его с помощью этой задачи / трудоемкость».

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

3. Запомните, что чем больше задач в работе, тем больше занимает время их выполнения. Поэтому не стремитесь взять больше (это объясняет Закон Литтла). Для этого в Kanban методе зашиты WIP лимиты (ограничение одновременно-выполняемой работы), которые выставляются на основе пропускной способности этапов и всей системы в целом. Также важно учитывать, что пропускная способность системы равна ее самому узкому месту в системе. То есть лимиты выставляйте исходя из пропускной способности ее самого узкого места, иначе задачи будут простаивать в очередях и их количество будет расти, увеличивая общее время выполнения целиковый задачи.

4. Начните управлять работой. Чтобы управлять, нужно понимать, что в работе, поэтому стоит всю работу визуализировать (например, с помощью доски) и далее каждый день собираться и смотреть: «Что подвисло?» «Что выполняется?», «Где нужна помощь?» и так далее.

5. Начните считать метрики поставки. Достаточно будет считать время выполения каждой задачи и пропускную способность, чтобы получить распределение и дать объективные прогнозы по времени выполнения новых задач. По распределению времени выполнения вы сможете увидеть, за какое количество времени завершалось 90% задач, и это вам даст данные для прогнозирования. То есть вы сможете дать объективную оценку заказчику, сказав, что задача будет выполнена до Х дней с 90% вероятностью. Точность такого прогнозирования будет зависеть от того, какое количество данных вы успели накопить, поэтому дайте этому время.

6. Договоритесь о том, что запустите процесс регулярных улучшений, изменений, на основе ретроспектив и объективных метрик. Увидели проблему — собрались, подумали, как ее решить, как минимизировать простои, как расширить узкое горлышко. Не стоит улучшать все подряд. Сфокусируйтесь на самом узком месте в системе и начинайте планировать шаги по его расширению.

А если вам понравилась статья, жду в своем телеграмм-канале и на сайте.

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