Организация по Ценности для Клиента

В маленьком продукте, состоящем из одной команды, организация по клиентской ценности тривиальна. Чем больше команд, тем они более они становятся похожими на шестерёнки в большой машине разработки. Как Чарли Чаплин в фильме “Новые Времена”, их работа состоит в том, чтобы закручивать гайки, не имея представления, как потребитель будет пользоваться их продуктом… или кто на данный момент является потребителем. Как масштабировать продукт и при этом сохранить ориентацию на клиента?

Кросс-функциональные Команды

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

Фиче-Команды

Как и кросс-функциональные команды, фиче-команды концентрируются на клиенте и сами по себе являются способом организации вокруг ценности для клиента. Фиче-команды берут новую функциональность, ориентированную на клиента, и “делают их полностью.” Это позволяет командам разговаривать на том же языке, что и клиенты, и убирать барьеры между клиентами и настоящими пользователями… снижая потери при передаче.

Специализируйтесь по клиентской проблематике

Распространённое непонимание концепции фиче-команд в том, что она якобы означает полный отказ от какой-либо специализации вообще. Часть этого непонимания происходит из ложной дихотомии между либо специализации на одном компоненте, либо её полном отсутствии — о чем мы подробно писали в наших статьях о фиче-командах. Другая часть этого непонимания происходит из убеждения, что специализация является одномерной—в рамках компонента. Но специализация многомерна.

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

Банки создают мобильные приложения для предоставления своих услуг с помощью мобильных устройств. Продуктовые группы обычно организованы по платформам: (1) команды iOS и (2) команды Android. Такие команды являются фиче-командами и они специализированы в технической плоскости — а именно, по платформе. Но в качестве альтернативы, они могут быть организованы и по клиентским областям, таким как (1) мобильные платежи, (2) администрирование, (3) отчётность. Это приводит к командам, которые разрабатывают одну и ту же пользовательскую функциональность на нескольких платформах вместо разработки различных видов функциональности на одной.

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

В традиционных организациях существует убеждение, что специализация вокруг технологий ‘лучше’. Но так ли это, особенно при взрослении (и старении) индустрии, и когда владение несколькими языками программирования становиться нормой? И так ли это с точки зрения клиента? Скрам и LeSS имеют тенденцию отдавать предпочтение специализации по клиентской проблематике.

Перевод статьи осуществлён Кротовым Артёмом и Романом Лапаевым.