Больше с помощью меньшего

Принцип Больше с помощью меньшего - ключевой в LeSS [в оригинале игра слов: “more with less”, прим. переводчика]. Это осознание того, что недостатки сложных организационных решений, которые используются для комплексного развития продукта, часто хуже, чем проблема, которую они пытаются решить. Он требует глубокого понимания сущности проблем, которые могут быть решены более простыми способами.

LeSS может быть рассмотрен как каркас масштабирования для продуктовой разработки, но также может быть рассмотрен как каркас упрощения для организаций. LeSS пытается убрать организационную сложность с помощью решения проблем в развитии продукта по-другому, более простым способом. Заметим, что простой путь - не равно легкий путь, особенно в краткосрочной перспективе. Не смотря на то что LeSS прост - его исключительно трудно полноценно внедрить в организации.

LeSS пытается определить тот минимум, который необходим для разработки на больших масштабах. Он избегает добавления дополнительных ролей, артефактов или процессов поскольку понимает недостатки этого действия.

Роль - это набор обязанностей или задач, назначенных на человека. Обычно это существующие, а не вновь изобретенные обязанности или задачи. Таким образом, появление новых ролей означает переход в них обязанностей из задач от кого-либо. В продуктовой разработке они обычно забираются у команд.

Большее количество ролей ведет к менее ответственным командам.

Процесс - это описание того как должна происходить работа. Это способ обмена знаниями. Но! … это также ведет к тому что люди перестают думать. Толкование установки процесса заключается в том, что больше не нужно думать о том, как выполнять работу, поскольку об этом подумал кто-то другой - тот, кто разработал этот процесс. Это про то, что следование становится важнее изменений (и обучения), а также арендование важнее владения знаниями. Таким образом определение большого количества процессов убирает возможность командам определять то, как они делают свою работу. И команды без владения своим процессом не будут улучшаться.

Большее количество установленных процессов ведет к меньшему владению процессом командой разработки и отсутствию постоянного улучшения.

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

Больше артефактов ведет к меньшему количеству клиентоориентированных команд.

Держа в памяти, что можно иметь Больше с помощью меньшего позволяет нам мыслить по-разному в продуктовой разработке. Вместо того чтобы спрашивать “Как мы можем сделать X в согласии с Agile?” где Х - текущая практика или организационная структура, нам сначала нужно задуматься о том “Почему мы вообще делали Х?” и увидеть можем ли мы найти лучшее решение для изначальной проблемы. Например, “Как вы управляете программой в Agile?” это обычный вопрос при масштабировании, в то время как мы держим в голове принцип Больше с помощью меньшего мы спросим “А зачем нам вообще управление программой?”. Это ведет нас к осознанию того, что программа (большие проекты) это метод организации работ, который может быть организован иначе. Например, с бОльшим продуктовым фокусом, организовывая работу так, чтобы постоянно доставлять ценность, и с гибким планированием. Такой подход ведет к тому, что мы можем управлять разработкой продуктов без программ.

Этот же образ мышления применяется и к остальным организационным сложностям, постепенно упрощая организацию.

Ссылки:

Перевод статьи осуществлен Дмитрием Емельяновым