Недавно я общался со Стивом Портером из scrum.org о дисфункциональных взаимодействиях между Владельцем Продукта и Командой Разработки в Скраме. Этот разговор напомнил мне об идее Джордана Питерсона: настоящее доверие - это акт мужества. В этой статье я попытался раскрыть эту идею применительно к Скрам-команде. 

Часто человек, только что прошедший тренинг для Владельцев Продукта, вдохновлён идеями самоорганизации и считает, что Скрам - самый лучший способ решения сложных проблем и что самоорганизующаяся Команда Разработки - лучший способ сделать правильные вещи правильно (и быстро). Как истинный евангелист Agile он старается продвигать Agile-подходы всеми доступными способами. Вдохновлённый и уверенный в эффективности самоорганизующейся команды, он доверяет Команде Разработки: они сделают всё необходимое, чтобы выполнить Бэклог Спринта и достичь Цели Спринта. Многие считают, что наличие такого вдохновенного Владельца Продукта - ключ к успеху Скрама. 

Что неизбежно происходит дальше? Команда Разработки терпит неудачу. Рано или поздно это случается с каждой командой (даже если они крайне пессимистичны в прогнозах и сверхвысокопроизводительны). Такая неудача вызывает вопросы у Владельца Продукта. Почему они потерпели неудачу? Достаточно ли я им доверял? Или, может быть, я слишком доверял? Почему они не оправдали мое доверие? Велика вероятность, что у Владельца Продукта были обязательства перед стейкхолдерами, которые недовольны результатами Спринта. Владелец Продукта расстроен (и, возможно, чувствует обиду). 

Но доверял ли он Команде Разработки? 



Если это доверие было основано на наивном представлении, что команда сможет сделать все, если ей доверяют, можем ли мы считать это доверием. Или это просто наивность? Доверие является необходимым условием для достижения командой максимальной производительности и вовлечённости, но оно само по себе не гарантирует успех. Мы живем в сложном мире и трудимся над созданием ценности, решая комплексные проблемы. Всегда есть что-то, чего мы не знаем. Всегда есть изменения. Всегда чего-то не хватает. А это значит, что иногда мы неизбежно терпим неудачу. 

Владельцу Продукта теперь надо решить, как действовать дальше. Он может подумать "Как я могу предотвратить повторение такой истории?". Он хочет узнавать плохие новости заранее, чтобы подготовиться (и подготовить своих стейкхолдеров). Он может решить регулярно проверять Команду Разработки, чтобы убедиться, что они делают, и делают ли они то, что от них ожидается.

Работают ли они над наиболее ценным элементом Бэклога? 

Не превысили ли трудозатраты первоначальные оценки? 

Решают ли разработчики проблему так, как она должна быть решена? 

Это создает тенденцию к микроменеджменту, и в конечном итоге такие проверки превращаются в ежедневные (или ежечасные) совещания о статусе проекта. 

Как это отразится на Команде Разработки? Во-первых, подобные вопросы, даже если они выглядят невинными с точки зрения Владельца Продукта, с большой вероятностью воспринимаются Командой Разработки не как вопросы, а как указания. Владелец Продукта наделён властью и полномочиями, а люди склонны слушать все, что говорит лицо, наделённое властью, как будто это требование, а не вопрос. Во-вторых, Команда Разработки будет чувствовать, что им не доверяют, и это чувство приведет к тому, что команда будет все больше и больше избегать принятия решений. Более того, команда теряет способность к самоорганизации: разработчики перестанут принимать собственные решения, потому что последнее слово всё равно будет за Владельцем Продукта. Таким образом, Владелец Продукта становится узким местом, в котором сходятся все информационные потоки и который принимает все решения. И в то время как он принимает всё больше решений, у команды остаётся всё меньше полномочий, поэтому он вынужден решать ещё больше. Меньшее доверие приводит к меньшему количеству решений, что снижает качество решений, а это, в свою очередь, уменьшает доверие. Замкнутый круг. Некоторые владельцы продукта застревают в этом порочном круге, думая: ”Им нельзя доверять — они слишком незрелые". Но это ошибка! Команда не может набраться опыта и достичь зрелости, потому что у них нет возможности ошибаться и учиться на своих ошибках. Дело вовсе не в команде. Владелец Продукта - вот кому не хватает зрелости. 

Что можно противопоставить такому ходу событий? Мужество. Это одна из пяти ценностей Scrum, и я бы сказал, что эта самая важная. Если у Владельца Продукта достаточно мужества, он думает примерно так: “Если я доверю им делать всю работу самостоятельно, они иногда будут терпеть неудачу. Это будет больно для меня (и, возможно, для Команды Разработки). Но доверие позволит нам двигаться быстрее, создавать больше ценности и предлагать наилучшие решения”. Поэтому он решает проявить мужество и доверять Команде Разработки, зная, что время от времени они не оправдают этого доверия. 

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