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

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

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

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

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

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

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

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

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

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

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

3. Запомните, что чем больше задач в работе, тем больше занимает времени их выполнение. Поэтому не стремитесь взять больше (это объясняет Закон Литтла).

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

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