С раннего возраста нас учили «МЫСЛИТЬ МАСШТАБНО», чтобы высоко держать планку, полностью раскрывая личный потенциал, и достигать поставленных перед собой целей. Компании поступают так же, преследуя одну цель на грани возможного за другой.
Однако у масштабного мышления с выбором дерзких и захватывающих дух целей есть и оборотная сторона. Дело в том, что в работе могут оказаться слишком крупные задачи, с которыми команды не в состоянии справиться. Результаты таких напряженных и регламентированных усилий проявляются медленно, практически не создавая инкрементной ценности для клиентов или пользователей. Или наоборот, команды увязают в деталях, выполняя слишком много мелких заданий, и теряют из вида долгосрочные цели.
Для достижения успеха командам и компаниям часто нужно найти баланс между масштабным мышлением и детализацией задач. Таково мнение Джона Катлера, руководителя отдела исследований продуктов и обучения в компании Amplitude, которое он озвучил в беседе с Atlassian:
Не работаете ли вы слишком масштабно?
Характеристика «работать слишком крупномасштабно» означает, что команды берутся за большие проекты, которые не создают инкрементной ценности и не подразумевают экспериментов и частых интеграций. Команды застревают в крупном проекте и продвигаются к его завершению черепашьими темпами.
Среди явных признаков того, что команда работает со слишком крупными задачами, — недостаточная осведомленность о клиентах, а также о текущих рыночных реалиях и новейших технологиях. Такое незнание приводит к тому, что компании отстают от рынка при запуске продукта. Область проекта расширяется, поглощая доступное время, при этом дорожная карта требует все больше внимания, поскольку команды не справляются с обширными изменениями в планах.
Но зачем компании или команде работать в избыточном масштабе? Тому есть много причин, например стремление угодить руководству и получить финансовые ресурсы. Крупный план проекта с четко определенными целями привлекателен для руководителя, поскольку сулит ощутимые результаты.
Не работаете ли вы слишком детально?
На противоположном конце спектра находятся команды, которые «работают слишком детально». Это значит, что они занимаются мелкими фрагментами большого проекта, но при этом не видят, как их работа согласуется со стратегией и миссией. При таком подходе сначала может показаться, что команды внедряют методы Agile. Но негативные шаблоны неизбежно начнут проявляться из-за избыточного планирования. Например, компания с сотнями историй в бэклоге может расходовать слишком много времени на их анализ. Кроме того, даже если команда ощущает динамизм в своей работе, при ее анализе 6 или 12 месяцев спустя трудно установить, как она продвигала бизнес вперед. Участники видят лишь разрозненную, реактивную работу.
Еще одну проблему Катлер видит в командах, которые определяют большую работу в терминах мелких деталей. Работая на детализированном уровне, команде может быть сложно реагировать на обратную связь. Здесь, как при сборке конструктора Lego, легко увлечься самим процессом соединения фрагментов. Но что, если 20 процентов работы обеспечивают 80 процентов ценного результата?
Мыслите масштабно, работайте детально
Как избежать слишком масштабной или слишком детальной работы? По словам Катлера, правильный баланс достигается, когда вы «мыслите масштабно и работаете детально», то есть у вас есть «захватывающая миссия в сочетании с последовательной стратегией». Когда команды понимают общее видение компании, они ставят и решают задачи, которые поддерживают и реализуют это видение. Нужно мыслить стратегически с точки зрения воздействия и результатов, формируя горизонт планирования за пределами ближайшего квартала или полугодия, при этом оставляя достаточное пространство для экспериментирования и проверки.
Если вы работаете только в крупном масштабе, Катлер предлагает попробовать работу на детальном уровне с сохранением контекста больших целей. Если вы работаете только на детальном уровне, полезно определить стратегическую инициативу и с ней согласовать конкретную работу. Если вы работаете на уровне деталей и при этом определяете крупные блоки путем регламентации, попробуйте ослабить регламентирование и сосредоточиться на миссиях и стратегиях.
По словам Катлера, команды могут создавать обучающие бэклоги, которые начинаются с вопроса «зачем?» о рабочих усилиях. Важно узнать саму новую информацию, а не «способ» обучиться ей. Начать с «зачем» — значит привнести контекст в каждое задание. Команды должны заниматься ведением бэклога и периодически пересматривать свой список работ. Это гарантирует правильную расстановку приоритетов с учетом обратной связи. Это также поможет командам избежать реактивного ответа на вызовы в работе.
Когда команды начинают с обучающего бэклога, они делают акцент на том, что необходимо узнать, будь то путем обширных исследований или в ходе многочасовой разработки. Такое начало также способствует формированию общего для всей компании языка, поскольку систематизация работы помогает лучше описывать ее различные формы и типы.
Заключение
