Владелец продукта

В методологии Scrum предусмотрено три роли:

· группа, или скрам- команда, — каждый исполнитель конкретного проекта является частью этой команды;

· скрам-мастер — следит за ходом проекта и помогает команде в ее проблемах;

· и владелец продукта.

Все роли и их функции будут подробно рассмотрены в приложении.

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

Когда я начинал работать со своей первой скрам-командой в 1993 году, роль владельца продукта мной еще не была сформу­лирована. Я входил в группу управления проектом, и помимо при­нятия решений, что делать команде в процессе каждого спринта, у меня было множество других обязанностей. Передо мной стояли и организационные, и маркетинговые задачи, я поддер­живал отношения с заказчиками и продумывал стратегию работ. Когда наступил первый спринт, у меня возникла мысль заняться и бэклогом. Требовалось лишь написать достаточное количество потребительских сценариев и идентифицировать основные функ­ции проекта — то, что будет выполнять команда в следующем спринте. Проблема возникла во время второго спринта, когда мы ввели ежедневные собрания на ходу. Динамика производи­тельности увеличилась на 400 процентов, и команда за неделю выполняла тот объем работ, на который, как мы предполагали, уйдет месяц. Естественно, они выбрали все задания из состав­ленного мной списка. Они лишились своего бэклога, а ведь с его помощью так удобно было работать! Честно говоря, я надеялся, что у меня в запасе еще целый месяц для создания новых сце­нариев. Перед нами выросла огромная реальная проблема, и ее следовало немедленно решить. Именно в тот момент пришло осознание: нужен отдельный человек, который возьмет на себя ответственность за ведение бэклога. Я серьезно задумался над тем, какова будет его роль в скрам-команде, какими качествами он должен обладать и как мы его назовем.[337]

Вдохновение я черпал все в той же Toyota — великой компа­нии, давшей миру лучшие образцы такого действующего лица, как главный инженер. В корпоративной культуре Toyota реша­ющая роль отводится главному инженеру, поскольку он полно­стью отвечает за процесс создания новой модели автомобиля: от разработки до ее выпуска. Он работает в теснейшем контакте с управляющими, ведущими специалистами, талантливыми инженерами и дизайнерами, принимающими непосредствен­ное участие в конструировании и сборке очередной модели. Опираясь на основных участников проекта — специализиро­ванные технические группы, он выстраивает многофункцио­нальную команду, способную создавать лучшие автомобили. Главные инженеры Toyota (в прошлом их величали сюса[338]) стали для всего мира легендарными фигурами как всесильные лидеры Dao Toyota (Путь Toyota) — особой системы управления и произ­водства. Отчасти так оно и есть, хотя в контексте системы прин­ципов компании подобное определение не очень уместно. «Всесильный» главный инженер Toyota ни в коей мере не является абсолютным властителем, более того — его статус руководителя крайне низок. Огромный коллектив ему не подотчетен, главный инженер не руководит теми, кто непосредственно участвует в реализации проекта, — скорее, он сам служит их интересам. Главные инженеры обязаны всегда быть на высоте и соответ­ствовать строжайшим требованиям, поскольку любой специалист компании может сказать им в глаза, что они не правы. Они не дают никаких аттестаций сотрудникам, не оценивают эффективность деятельности производственного персонала, ни­кого не поощряют и не повышают. Однако главные инженеры отвечают за составление концепции проекта — основного до­кумента, в котором изложена идея нового автомобиля, и управ­ляют — не принуждением, а убеждением — многоуровневой системой всего производственного процесса. Именно этот за­мысел я решил воплотить в Scrum.[339]

Джон Шук из Lean Enterprise Institute (Институт бережливых предприятий) открывает свою статью о роли главного инженера в производственном процессе Toyota одним постулатом, почерп­нутым из весьма неожиданного источника.[340] Это «Руководство для командного состава Корпуса морской пехоты США»:

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

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

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

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

Я обдумывал вари­анты, как вписать в систему Scrum работника, который сумел бы вытянуть столь сложную роль, но довольно быстро понял, что не смогу найти человека с нужным мне уровнем мастерства и опыта — слишком узок круг таких специалистов. Поэтому пришлось разбить эту функциональную обязанность на две разные.[341] Таким образом, получилось, что скрам-мастер несет ответственность за ту часть проекта, которая отвечает на во­прос как делать, а владелец продукта — за ту часть, которая отвечает на вопрос что делать. [342]

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

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

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

По словам моего одного приятеля, его жена является идеаль­ным владельцем продукта — она точно знает, чего хочет, а ему остается лишь исполнять ее желания.

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

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

во-первых, он должен быть абсолютно компе­тентен во всем, что делается в процессе разработки, и уметь оценивать возможности команды — то есть с чем она справ­ляется, а с чем не очень;

во-вторых, довольно хорошо разби­раться в сути продукта и понимать, как довести разработку проекта — а это может быть и компьютерная система ФБР, и метод обучения учащихся средних школ — до результата, имеющего действительную стоимость;

кроме того, владе­лец продукта должен великолепно знать рынок, чтобы уметь анализировать его состояние: какая продукция имеет зна­чение сегодня и как может измениться ситуация завтра. [344]

2. Владелец продукта должен быть наделен полномочиями для принятия решений. Дирекции компании не следует вме­шиваться в действия владельца продукта (как она не вме­шивается в действия и решения группы). Напротив, руко­водителям, отвечающим за проект, полагается оказывать ему всяческое содействие, когда он трудится над концепци­ей продукта и когда в процессе разработки выполняет свои обязанности, помогая команде добиваться нужной цели. Помощь со стороны управленческого аппарата — весьма ценный фактор, поскольку владелец продукта испытывает давление со стороны многочисленных заинтересованных групп, как внутренних, так и внешних. Перед лицом такого мощного натиска он не мог бы сдерживать удар без админи­стративной поддержки. Надо добавить, что владелец про­дукта несет ответственность за результат, отбирает и фор­мулирует для команды все требования на текущий спринт, при этом он не вправе давать задания отдельным участни­кам и вмешиваться в решения команды.[345]

3. Владелец продукта должен быть всегда доступен для ко­манды, поскольку в любой момент может потребоваться его объяснение, почему то или иное задание нужно делать в первую очередь. По сути, владелец продукта несет полную ответственность за ведение бэклога, по этой причине необ­ходим налаженный обмен мнениями между ним и коман­дой. Бывает так, что участники группы в силу своего опы­та и квалификации советуют владельцу продукта, какие требования наиболее важны в данный момент. Владелец продукта должен быть надежным, последовательным и до­ступным. Не имея возможности связаться с ним, команда может принять неверное решение. Участники группы це­ликом полагаются на владельца продукта: на его концеп­цию продукта и знание ситуации на рынке. Поэтому нуж­на постоянная взаимосвязь владельца продукта и команды, иначе весь рабочий процесс может развалиться. Кстати, это одна из причин, почему я редко рекомендую на роль вла­дельца продукта руководящих работников, например СЕО компаний, — у них просто нет столько времени посвящать себя нуждам команды.[346]

4. Владелец продукта должен нести ответственность за полез­ность продукта. Если речь идет о бизнес-структуре, в рам­ках которой работает скрам-команда, — значит показателем полезности является прибыль. Таким образом, деятельность самого владельца продукта соответственно оценивается из расчета, сколько прибыли приносит один выполненный пункт из его списка требований. Например, когда команда за неделю справляется с сорока пунктами, я всегда требую, чтобы обязательно измеряли, сколько конкретно прибыли приносит каждое выполненное требование. Однако скрам- команды работают в самых разных областях деятельности, и необязательно это должна быть бизнес-среда. Поэтому критерием полезности может быть, например, объем удач­но завершенных дел. Мне известна следственно-оперативная группа из правоохранительных органов, измеряющая принесенную обществу пользу количеством осуществленных за не­делю арестов находящихся в розыске преступников. Я знаю несколько церковных приходов, применяющих методологию Scrum, которые выбрали собственное мерило ценности: они измеряют популярность среди людей с помощью подсчета своей паствы и контроля ее роста. Смысл в том, что каждая команда — над чем бы она ни работала — должна сама для себя определить критерий полезности и спрашивать резуль­тат с владельца продукта, поскольку именно он в ответе за то, чтобы ценность и стоимость продукта постоянно росли. По­стулируемый в системе Scrum принцип прозрачности дает возможность легко отслеживать такого рода показатели.[347]

Действительно огромная зона ответственности для одного чело­века, поэтому на больших проектах обычно работает бригада вла­дельцев продукта, которая должна обслуживать все обязательные требования как скрам-команд, так и заказчиков. Несколько позже я вернусь к этой бригаде. Но сейчас мне хотелось бы проиллю­стрировать все сказанное выше небольшой историей, а чтобы вы прочувствовали, чем должен заниматься человек, выполняющий обязанности владельца продукта, я предложил бы вам пересесть (исключительно в своем воображении) в кабину реактивного истреби­теля F-86 «Сейбр», которым управляет Бешеный Майор Джон Бойд.[348]