Мои коллеги, профессиональные Скрам-тренеры, провели интересный эксперимент, в котором стейкхолдеры начинают работать рядом со Скрам-командами. В одном физическом пространстве. Устанавливается неформальное и тесное общение между разработчиками и пользователями продукта. Что в итоге?
Разработчики получают обратную связь часто и без искажений. Они проводят пользовательское тестирование в Спринте незамедлительно. Разработчики наблюдают за тем, как продукт используется в реальной жизни. Это приводит к лучшему пониманию потребностей и более качественному продукту!
Это неудивительно. Ведь результаты эксперимента легко объясняются интерпретацией закона Конвея:
“насколько разработчики удалены от пользователей продукта, настолько и сам продукт далек от закрытия реальных потребностей клиента”.
А как часто ваши разработчики общаются с пользователями и стейкхолдерами? Ответьте себе честно на этот вопрос. Думаю, нечасто.
В мире больших организаций разработчик привычно отделен от рынка рядом промежуточных подразделений и ролей. Например: маркетинг, поддержка, продажи, связка Chief Product Owner (CPO)-> PO -> BA. Часто это реализовано через концепцию разделения front-end (рыночных) и back-end (технических) подразделений (см. Картинку 1).
(Картинка 1: разделение рыночных и технических подразделений)
И вот почему организации так делают.
Большие организации привычно следуют принципам Тейлоризма. В этой парадигме голова отделяется от рук. Есть люди думающие (менеджеры) и исполнители, выполняющие работу руками (рабочие), задача которых фокусироваться на рутинных задачах и максимизировать продуктивность. Почему? Да потому что среда предсказуемая. Больше угля или больше произведенных гвоздей автоматически значит больше коммерческой выгоды. Между утилизацией ресурса и экономическим результатом прямая связь.
В производственная парадигма работает, когда можно найти наилучший способ выполнения задачи. Сто лет назад Тейлор понял это, наблюдая за тем, как рабочие разгружают уголь и переносят тяжелые свинцовые болванки на американской железной дороге. Если ваш контекст простой и вы занимаетесь добычей угля, производством мебели, веников и других типичных изделий, пожалуйста, работайте так и дальше.
Но тейлоризм в продуктовой разработке это дорого и контрпродуктивно. Окружение комплексное и нет прямой связи между продуктивностью (количеством произведенных командой фич) и коммерческим результатом. Отделяя голову от рук, вы получаете тяжелые побочки. Все потому, что в продуктовой разработке мы делаем то, что еще никогда не существовало. Уникальный продукт или уникальный рецепт. В Creating Agile Organizations мы пишем о том, что настоящий продукт удовлетворяет нескольким условиям:
- У него есть пользователи и покупатели за пределами организации
- Он закрывает потребности клиентов
- Имеет уникальную функциональность!!!
- Есть собственный поток прибыли и бизнес-модель
Разработчику тяжело написать код, удовлетворяющий потребности клиентов, если они далеко. Ведь код—отображение понимания бизнес-домена. Если между разработкой и пользователями цепочка из промежуточных лиц, получается эффект испорченного телефона. Вы будете вынуждены заходить на новый круг и постоянно переделывать, прогоняя работу через длинную цепочку координаторов. Но зато локально все будут продуктивны: разработчики, аналитики, маркетологи, продажники и т.д.
Долго работая в производственной парадигме, разработчиков приучили к тому, что их задача—написание кода. Но это в корне неверно! Задача разработчика в контексте продуктовой разработки другая—решать задачи бизнеса, помогая максимизировать бизнес-ценность. Код—это лишь побочный эффект интеллектуального труда.
Отделение разработчиков от рынка—дорого и контрпродуктивно.
