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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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