Джефф Сазерленд - Scrum. Революционный метод управления проектами

Личная ответственность командира не зависит от его звания, то есть от степени его узаконенной власти…

Далее Шук пишет:

Я собираюсь сделать этот принцип отправной точкой, чтобы и дальше отстаивать свое мнение: причиной многих организационных язв стало глубоко укоренившееся заблуждение, будто ответственность руководителей должна быть соразмерна их полномочиям. Я полагаю, что существующее по этому вопросу серьезное недопонимание переросло в опасную проблему; это недоразумение уже овладело нашим сознанием настолько, что мы даже не отдаем себе отчета в его угрожающих последствиях1.

Осмысляя опыт, полученный мною в Вест-Пойнте и на Вьетнамской войне, я независимо от кого-либо пришел к выводу, что управление коллективом не имеет ничего общего ни с властным статусом руководителя, ни с полномочиями, которыми он наделен. Пожалуй, прежде всего прочего руководящая роль человека определяется личным профессиональным опытом и умением быть лидером, готовым отдавать себя служению людям и делу. Главный инженер Toyota не может просто отдать распоряжение кому-то что-то сделать так, а не иначе. Он должен отстоять собственную точку зрения, привлечь на свою сторону не только высшее руководство, но и исполнителей, убедительно доказывая, что предложенный им путь — самый лучший и единственно верный . Естественно, подобное по силам лишь профессионалу, накопившему несколько десятилетий опыта. Я обдумывал варианты, как вписать в систему Scrum работника, который сумел бы вытянуть столь сложную роль, но довольно быстро понял, что не смогу найти человека с нужным мне уровнем мастерства и опыта — слишком узок круг таких специалистов. Поэтому пришлось разбить эту функциональную обязанность на две разные. Таким образом получилось, что скрам-мастер несет ответственность за ту часть проекта, которая отвечает на вопрос как делать , а владелец продукта — за ту часть, которая отвечает на вопрос что делать .

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

Заметьте, «клиентом» может быть кто угодно: непосредственный заказчик проекта; массовый потребитель; крупный банк; кто-то из вашей семьи; люди, ожидающие вакцину от ротавирусной инфекции, — и от вас зависит, получит ли каждый то, в чем нуждается. Другими словами, клиент — это тот, кто получает пользу от вашей деятельности.

Хочу уточнить: я не искал управляющего. Мне нужен был человек, на кого группа будет во всем полагаться и кому сможет доверить расстановку приоритетов в бэклоге. Помню, что я тогда решил позвать на это место самого большого умника из отдела маркетинга программного продукта. Обратите внимание: не из отдела разработки, а из отдела маркетинга. Именно так Дон Роднер стал первым, кто взял на себя роль владельца продукта. Он знал программное обеспечение, над которым мы работали, — не с технической стороны, хотя он понимал достаточно для того, чтобы взаимодействовать с инженерами и программистами, — а с точки зрения клиента. Что понадобится людям от этого программного обеспечения, когда они начнут им пользоваться? Подбирая кандидата на роль владельца продукта, найдите того, кто сможет буквально залезть в мысли любого потребителя, который заинтересован в том, что вы делаете. По словам моего одного приятеля, его жена является идеальным владельцем продукта — она точно знает, чего хочет, а ему остается лишь исполнять ее желания.

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