“Почему в нашей ситуации ролевая модель не работает?” Старая культура не дает хода молодой динамичной модели. Конфликт старой и новой парадигм составляет один из самых больших рисков во внедрении Scrum-подхода в целом и формировании скрам-команд в частности.

АКТУАЛЬНОСТЬ ПРОБЛЕМЫ

Главная причина успеха разработки продукта – команда. Она же является главной причиной провалов.

О команде, командном духе, командном игроке, командной игре, командном единстве (перечень “корпоративной командности” можете продолжить самостоятельно) написаны сотни книг и проведено множество тренингов. Почему в таком случае одни компании выводят продукт на рынок быстрее, чем другие?

Очевидно, что понятие “команды” каждый понимает по-своему. Однако в Scrum существует четкая концепция команды, возникшая не на ровном месте. (О пути скрам-команд см. В нашей предыдущей статье “Ролевая модель Scrum: как возникла и почему важна”).

Поэтому в данной статье рассмотрим гениальную, минималистическую и удивительно эффективную модель команды в Scrum, какой она является сегодня. Ее также называют ролевой моделью, ведь речь идет об определенных ролях, которые обязательно должны быть в каждой скрам-команде. Отсутствие хотя бы одной свидетельствует об отсутствии Scrum. Речь может идти о “подобии” скрама, его имитации, гибридной или скрамоподобной модели, однако не Scrum.

КАК БЫЛО РАНЬШЕ

Итак, в 1980-х научились производить user-friendly товары с кнопочками, в 1990-х расплодилось разнообразие вспомогательных профессий, позволявших программистам сосредотачиваться на кодировании. Однако разнообразна свита, отовсюду окружавшая разработчиков, а также сложные многоуровневые структуры организационного менеджмента, стали серьезной проблемой в 2000-х.

Бизнес-аналитики, специалисты по обработке данных, дизайнеры, копирайтеры, менеджеры высшего звена, менеджеры среднего звена, операционные менеджеры, другие менеджеры – все имели дело к разработке, не хватало разве что танцоров.

КВЕСТ “НАЙДИ ВИНОВАТОГО”

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

Целый ряд экспертов и высокопоставленных лиц “имели глаза, и не видели, имели уши, и не слышали”. Взрослые люди с дипломами и регалиями передавали друг другу обвинения, как футболисты киевского “Динамо” мяч, оставаясь на своем же поле.

ДВЕ ЛИЧНОСТИ

Это надоело двум личностям, чьи имена стоит надолго запечатлеть на доске почета – Кен Швабер и Джефф Сазерленд. Эти ребята:

Понимали специфику разработки продукта.
Слышали голос конечного потребителя.
Понимали сущность бизнеса и разницу между его старой и новой парадигмами.
Обожали оптимизацию процессов.
Понимали новые требования времени, в котором оказался мир в начале третьего тысячелетия.

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

Тогда-то Кен и Джефф прекратили слушать нытье горе-специалистов, замкнув их в офисе на ключ – пока совместно не договорятся и не вынесут (буквально) решение!

На самом деле Кена Швабера и Джеффа Сазерленда интересовали не точечные решения технической проблемы еще одного проекта. Они стремились изобрести новый системный подход, который:

привел бы в себя участников разработки – вернул способность слышать голос конечного потребителя (желательно не после завершения проекта);
помог бы защитить команду от вмешательства должностных лиц и других внешних воздействий, которые могли блокировать или замедлять работу.

К тому же, никто не собирался снимать с повестки дня вопрос ответственности. Кто будет отвечать за конечный продукт?

ВЛАДЕЛЕЦ ПРОДУКТА

Так возникла роль, известная ныне как владелец продукта. Конечно, никаким “владельцем” он на самом деле не является. Им есть конечные бенефициары и стейкхолдеры. Речь идет о роли владельца, которую он выполняет как уполномоченный представитель компании, и персонально отвечает за продукт, а потому имеет высокий мандат доверия, полномочий и право принимать решения.

Часто владелец продукта имеет более широкие полномочия по продукту, чем его непосредственный руководитель. В Scrum-подходе решение владельца продукта отменять или изменять нельзя. Это защищает команду от деструктивных вмешательств или капризов руководителей высшего звена.

Кроме высокой ответственности, владелец продукта – это мостик коммуникации между всеми участниками разработки, а также голос пользователей и заказчиков для кроссфункциональной команды.

Уникальным образом одна особа (владелец продукта) заменила суетную деятельность около двадцати чиновников различного типа.

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

Отсутствие этой роли порождает хаос, отвлечение, промедление, потерю концентрации, путаницу – в конце концов, убытки.

Формирование ролевой модели

Гениальным решением ввести роль владельца продукта, Кен Швабер и Джефф Сазерленд сразу почувствовали разницу, а именно:

Упрощение процессов;
Экономия времени;
Сохранение энергии сотрудников;
Повышение сосредоточенности на цели, что улучшило качество работы;
Экономия средств.

К тому же, это позволяло быстрее реагировать на потребности потребителей и создавать ценность и для бизнеса, и для клиентов.

Вместе с владельцем продукта, было введено обязательную роль скрам-мастера (см. Далее) и конкретизировано понятие “команда разработчиков”. Так ролевая модель Scrum была сформирована окончательно.

ВОЗНИКАЮЩИЕ РИСКИ И ЧТО С НИМИ ДЕЛАТЬ

“Почему в нашей ситуации ролевая модель не работает?” – одно из самых актуальных и острых вопросов, мы слышим в Agile.Live, консультируя компании в банковской сфере, ИТ, телекоммуникациях, авиации, даже в добывающей промышленности, стремящиеся внедрить цифровые технологии.

Главная причина для всех одна: старая культура не дает хода молодой динамичной модели. Конфликт старой и новой парадигм (речь идет не о возрасте людей, а о мировоззрении) составляет один из самых больших рисков во внедрении Scrum-подхода в целом и формировании скрам-команд в частности.

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

Скрам-мастер

Эту роль выполняет скрам-мастер. В его задачи также входит:

Помогать команде оценивать и прогнозировать;
Управление временем (time-box)
Самоорганизация и самоуправление команды (скрам-мастер должен “вырастить” такую команду, помогать ей стать “командой пятого уровня” – см. Подробнее в статье “Пять уровней перехода на Agile: самоуправляемые команды“)
Обеспечение автономности (привести команду к уровню самостоятельности, инициативности и ответственности по соответствующим критериям и ценностями Scrum)
Трансформация культуры;
Управление самим фреймворком Scrum;
Устранение препятствий и помех на пути команды (обычно вмешательства со стороны руководителей разного уровня, отсутствие данных, потребность в дополнительной экспертизе и т.п.).