Джефф Сазерленд - Scrum. Революционный метод управления проектами
Джон Шук из Lean Enterprise Institute (Институт бережливых предприятий) открывает свою статью о роли главного инженера в производственном процессе Toyota одним постулатом, почерпнутым из весьма неожиданного источника. Это «Руководство для командного состава Корпуса морской пехоты США»:
Личная ответственность командира не зависит от его звания, то есть от степени его узаконенной власти…
Далее Шук пишет:
Я собираюсь сделать этот принцип отправной точкой, чтобы и дальше отстаивать свое мнение: причиной многих организационных язв стало глубоко укоренившееся заблуждение, будто ответственность руководителей должна быть соразмерна их полномочиям. Я полагаю, что существующее по этому вопросу серьезное недопонимание переросло в опасную проблему; это недоразумение уже овладело нашим сознанием настолько, что мы даже не отдаем себе отчета в его угрожающих последствиях1.
Осмысляя опыт, полученный мною в Вест-Пойнте и на Вьетнамской войне, я независимо от кого-либо пришел к выводу, что управление коллективом не имеет ничего общего ни с властным статусом руководителя, ни с полномочиями, которыми он наделен. Пожалуй, прежде всего прочего руководящая роль человека определяется личным профессиональным опытом и умением быть лидером, готовым отдавать себя служению людям и делу. Главный инженер Toyota не может просто отдать распоряжение кому-то что-то сделать так, а не иначе. Он должен отстоять собственную точку зрения, привлечь на свою сторону не только высшее руководство, но и исполнителей, убедительно доказывая, что предложенный им путь — самый лучший и единственно верный. Естественно, подобное по силам лишь профессионалу, накопившему несколько десятилетий опыта. Я обдумывал варианты, как вписать в систему Scrum работника, который сумел бы вытянуть столь сложную роль, но довольно быстро понял, что не смогу найти человека с нужным мне уровнем мастерства и опыта — слишком узок круг таких специалистов. Поэтому пришлось разбить эту функциональную обязанность на две разные. Таким образом получилось, что скрам-мастер несет ответственность за ту часть проекта, которая отвечает на вопрос как делать, а владелец продукта — за ту часть, которая отвечает на вопрос что делать.
В тот же самый период я уже вынашивал идею пригласить отдельного человека, который осуществлял бы нашу взаимосвязь с клиентом. Поэтому я сразу решил отдать эту функцию в ведение владельца продукта, предполагая, что после каждого спринта он будет обеспечивать группу информацией о критических замечаниях, пожеланиях и настроениях клиента. Половину своего рабочего времени владелец продукта должен посвящать встречам с теми, кто собирается приобретать продукт, рассказывать, как продвигается его разработка; узнавать, отвечают ли их ожиданиям последние внесенные изменения и довольны ли они его новыми возможностями. Другую половину рабочего дня он проводит с командой, занимается бэклогом и объясняет членам группы, что клиент оценил в продукте, что воспринял как недоделку и каковы его ожидания.
Заметьте, «клиентом» может быть кто угодно: непосредственный заказчик проекта; массовый потребитель; крупный банк; кто-то из вашей семьи; люди, ожидающие вакцину от ротавирусной инфекции, — и от вас зависит, получит ли каждый то, в чем нуждается. Другими словами, клиент — это тот, кто получает пользу от вашей деятельности.
Хочу уточнить: я не искал управляющего. Мне нужен был человек, на кого группа будет во всем полагаться и кому сможет доверить расстановку приоритетов в бэклоге. Помню, что я тогда решил позвать на это место самого большого умника из отдела маркетинга программного продукта. Обратите внимание: не из отдела разработки, а из отдела маркетинга. Именно так Дон Роднер стал первым, кто взял на себя роль владельца продукта. Он знал программное обеспечение, над которым мы работали, — не с технической стороны, хотя он понимал достаточно для того, чтобы взаимодействовать с инженерами и программистами, — а с точки зрения клиента. Что понадобится людям от этого программного обеспечения, когда они начнут им пользоваться? Подбирая кандидата на роль владельца продукта, найдите того, кто сможет буквально залезть в мысли любого потребителя, который заинтересован в том, что вы делаете. По словам моего одного приятеля, его жена является идеальным владельцем продукта — она точно знает, чего хочет, а ему остается лишь исполнять ее желания.
Владелец продукта, в отличие от скрам-мастера, не только владеет более прочными и разнообразными профессиональными навыками, но и его деятельность носит принципиально другой характер. Скрам-мастер и команда отвечают за то, каков будет темп их труда и как быстро они закончат проект. Владелец продукта ответствен за то, чтобы результативная командная работа превратилась в результат, приносящий прибыль. Долгие годы я создавал функциональный портрет владельца продукта, из которого выбрал для вас самые существенные его обязанности, сгруппировав их в четыре группы.
Владелец продукта должен обладать всей полнотой знаний о том, что входит в круг его обязанностей. Подразумевается следующее: во-первых, он должен быть абсолютно компетентен во всем, что делается в процессе разработки, и уметь оценивать возможности команды — то есть с чем она справляется, а с чем не очень; во-вторых, довольно хорошо разбираться в сути продукта и понимать, как довести разработку проекта — а это может быть и компьютерная система ФБР, и метод обучения учащихся средних школ — до результата, имеющего действительную стоимость. Кроме того, владелец продукта должен великолепно знать рынок, чтобы уметь анализировать его состояние: какая продукция имеет значение сегодня и как может измениться ситуация завтра.
Владелец продукта должен быть наделен полномочиями для принятия решений. Дирекции компании не следует вмешиваться в действия владельца продукта (как она не вмешивается в действия и решения группы). Напротив, руководителям, отвечающим за проект, полагается оказывать ему всяческое содействие, когда он трудится над концепцией продукта и когда в процессе разработки выполняет свои обязанности, помогая команде добиваться нужной цели. Помощь со стороны управленческого аппарата — весьма ценный фактор, поскольку владелец продукта испытывает давление со стороны многочисленных заинтересованных групп, как внутренних, так и внешних. Перед лицом такого мощного натиска он не мог бы сдерживать удар без административной поддержки. Надо добавить, что владелец продукта несет ответственность за результат, отбирает и формулирует для команды все требования на текущий спринт, при этом он не вправе давать задания отдельным участникам и вмешиваться в решения команды.
