Перевод оригинальной статьи Ceзарио Рамоса Do not provide the answer before knowing the question
Я общался с компанией, которая внедряла модель Spotify и попросила меня помочь. Они хотели понять, в чем разница между моделью Spotify и LeSS. Сначала мы обсудили, что такое LeSS. Я объяснил, что LeSS — это организационный дизайн, оптимизационные цели которого скорость, адаптивность и обучение. LeSS для организации то же самое, что Скрам для одной команды.
С этого ответа началась интересная дискуссия о различиях между двумя моделями. Я не эксперт по Spotify, но видел достаточно внедрении этой модели, чтобы вести интересную дискуссию. Ниже я кратко опишу три основных момента из нашего обсуждения:
HR
Возможное отличие версии Spotify, которую внедряла эта команда, от LeSS заключалась в том, что у них есть руководитель («лид») чаптера («отдела»), который отвечает за кадровый состав чаптера. Например, у них может быть центр передового опыта — чаптер Тестирования, и в этом чаптере лид отвечает за тестировщиков. Это монофункциональный организационный элемент. В LeSS мы стараемся избегать таких структур. Напротив, нам больше нравятся кросс-функциональные менеджеры, которые отвечают за состав кросс-функциональных команд. Это способствует мультифункциональному обучению и, как следствие, повышает гибкость организации.
Непрерывное улучшение
Ещё одно отличие заключается в том, что LeSS базируется на принципе Эмпирического Контроля Процессов, тут нет модели, которую можно бы было скопировать. Копирование модели других организаций опасно, так как контексты отличаются, и очень вероятно, что скопированная модель не обеспечивает те же преимущества в другом контексте. Основная ценность заключается не в копировании модели как таковой, а в самом процессе выработки такой модели, которая будет работать именно для вас, и в обучении, сопутствующем этому процессу.
Но ещё хуже то, что копирование модели не даёт ощущения, что эта модель — ваша. Почувствовать, что у вас есть собственная модель, получается только тогда, когда вы создаете что-то самостоятельно. И если члены вашей команды чувствуют, что обладают чем-то, то выше вероятность, что они сами будут стремиться это улучшать. А это главное условие непрерывного совершенствования. Сложно почувствовать это, просто копируя чужие действия. Это скорее, как взять в долг — совсем не то же самое, как создать самостоятельно. Я отношусь к машинам из проката совсем не так, как к своим собственным.
Кроме того, с точки зрения непрерывного улучшения, будет не очень хорошо, если вы достигнете конечного состояния, которого вы действительно можете достичь. Потому что вот придёте вы в конечную точку. А потом что? Что произойдет, когда вы внедрите модель? Всё, миссия выполнена?
Компания понимает этот момент, они очень серьёзно относятся к непрерывному улучшению.
Становление модели
Получается, что внедрять модель в качестве конечного решения без учета особенностей конкретной организации — это как отвечать, не узнав вопрос. На мой взгляд, это глупо. Не делайте так. Вместо этого вы можете начать с самого простого процесса, который будет работать. А потом вы выстроите свою модель с помощью Эмпирического Контроля Процессов и фреймворка, который поможет всем чётко увидеть, что надо улучшать. Этот фреймворк называется Скрам. Как мы любим говорить, лучше создать свой метод, чем пытаться подогнать под себя чужой. Вы добавляете что-то только тогда, когда ваша команда видит в этом необходимость.
Насколько я понял, в этой компании они делают именно так. И весьма успешно.
Сезарио занимается широкомасштабными Аджайл-трансформациями по всему миру. Автор книг «Emergent» и «Scrum Patterns». Он также является сертифицированным тренером LeSS, профессиональным тренером по Скраму (Professional Scrum Trainer™) и сертифицированным коучем.
