Владелец продукта
В методологии Scrum предусмотрено три роли: группа, или скрам-команда, – каждый исполнитель конкретного проекта является частью этой команды; скрам-мастер – следит за ходом проекта и помогает команде в ее проблемах, и владелец продукта. Все роли и их функции будут подробно рассмотрены в приложении. Владелец продукта решает, какой быть концепции проекта, и отвечает за его разработку; несет ответственность за составление и ведение бэклога; собирает и формулирует пользовательские требования, определяя их приоритетность.
Когда я начинал работать со своей первой скрам-командой в 1993 году, роль владельца продукта мною еще не была сформулирована. Я входил в группу управления проектом, и помимо принятия решений, что делать команде в процессе каждого спринта, у меня было множество других обязанностей. Передо мной стояли и организационные, и маркетинговые задачи, я поддерживал отношения с заказчиками и продумывал стратегию работ. Когда наступил первый спринт, у меня возникла мысль заняться и бэклогом. Требовалось лишь написать достаточное количество потребительских историй и идентифицировать основные функции проекта – то, что будет выполнять команда в следующем спринте. Проблема возникла во время второго спринта, когда мы ввели ежедневные собрания на ходу. Динамика производительности увеличилась на 400 процентов, и команда за неделю выполняла тот объем работ, на который, как мы предполагали, уйдет месяц. Естественно, они выбрали все задания из составленного мною списка. Они лишились своего бэклога, а ведь с его помощью так удобно было работать! Честно говоря, я надеялся, что у меня в запасе еще целый месяц для создания новых историй. Перед нами выросла огромная реальная проблема, и ее следовало немедленно решить. Именно в тот момент пришло осознание: нужен отдельный человек, который возьмет на себя ответственность за ведение бэклога. Я серьезно задумался над тем, какова будет его роль в скрам-команде, какими качествами он должен обладать и как мы его назовем.
Вдохновение я черпал все в той же Toyota – великой компании, давшей миру лучшие образцы такого действующего лица, как главный инженер. В корпоративной культуре Toyota решающая роль отводится главному инженеру, поскольку он полностью отвечает за процесс создания новой модели автомобиля: от разработки до ее выпуска. Он работает в теснейшем контакте с управляющими, ведущими специалистами, талантливыми инженерами и дизайнерами, принимающими непосредственное участие в конструировании и сборке очередной модели. Опираясь на основных участников проекта – специализированные технические группы, он выстраивает многофункциональную команду, способную создавать лучшие автомобили. Главные инженеры Toyota (в прошлом их величали сюса
[43]) стали для всего мира легендарными фигурами как всесильные лидеры Dao Toyota (Путь Toyota) – особой системы управления и производства. Отчасти так оно и есть, хотя в контексте системы принципов компании подобное определение не очень уместно. «Всесильный» главный инженер Toyota ни в коей мере не является абсолютным властителем, более того – его статус руководителя крайне низок. Огромный коллектив ему не подотчетен, главный инженер не руководит теми, кто непосредственно участвует в реализации проекта, – скорее, он сам служит их интересам. Главные инженеры обязаны всегда быть на высоте и соответствовать строжайшим требованиям, поскольку любой специалист компании может сказать им в глаза, что они не правы. Они не дают никаких аттестаций сотрудникам, не оценивают эффективность деятельности производственного персонала, никого не поощряют и не повышают. Однако главные инженеры отвечают за составление концепции проекта – основного документа, в котором изложена идея нового автомобиля, и управляют – не принуждением, а убеждением – многоуровневой системой всего производственного процесса. Именно этот замысел я решил воплотить в Scrum.
Джон Шук из Lean Enterprise Institute (Институт бережливых предприятий) открывает свою статью о роли главного инженера в производственном процессе Toyota одним постулатом, почерпнутым из весьма неожиданного источника. Это «Руководство для командного состава Корпуса морской пехоты США»:
Личная ответственность командира не зависит от его звания, то есть от степени его узаконенной власти…
Далее Шук пишет:
Я собираюсь сделать этот принцип отправной точкой, чтобы и дальше отстаивать свое мнение: причиной многих организационных язв стало глубоко укоренившееся заблуждение, будто ответственность руководителей должна быть соразмерна их полномочиям. Я полагаю, что существующее по этому вопросу серьезное недопонимание переросло в опасную проблему; это недоразумение уже овладело нашим сознанием настолько, что мы даже не отдаем себе отчета в его угрожающих последствиях
{38}.
Осмысляя опыт, полученный мною в Вест-Пойнте и на Вьетнамской войне, я независимо от кого-либо пришел к выводу, что управление коллективом не имеет ничего общего ни с властным статусом руководителя, ни с полномочиями, которыми он наделен. Пожалуй, прежде всего прочего руководящая роль человека определяется личным профессиональным опытом и умением быть лидером, готовым отдавать себя служению людям и делу. Главный инженер Toyota не может просто отдать распоряжение кому-то что-то сделать так, а не иначе. Он должен отстоять собственную точку зрения, привлечь на свою сторону не только высшее руководство, но и исполнителей, убедительно доказывая, что предложенный им путь – самый лучший и единственно верный. Естественно, подобное по силам лишь профессионалу, накопившему несколько десятилетий опыта. Я обдумывал варианты, как вписать в систему Scrum работника, который сумел бы вытянуть столь сложную роль, но довольно быстро понял, что не смогу найти человека с нужным мне уровнем мастерства и опыта – слишком узок круг таких специалистов. Поэтому пришлось разбить эту функциональную обязанность на две разные. Таким образом получилось, что скрам-мастер несет ответственность за ту часть проекта, которая отвечает на вопрос как делать, а владелец продукта – за ту часть, которая отвечает на вопрос что делать.
В тот же самый период я уже вынашивал идею пригласить отдельного человека, который осуществлял бы нашу взаимосвязь с клиентом. Поэтому я сразу решил отдать эту функцию в ведение владельца продукта, предполагая, что после каждого спринта он будет обеспечивать группу информацией о критических замечаниях, пожеланиях и настроениях клиента. Половину своего рабочего времени владелец продукта должен посвящать встречам с теми, кто собирается приобретать продукт, рассказывать, как продвигается его разработка; узнавать, отвечают ли их ожиданиям последние внесенные изменения и довольны ли они его новыми возможностями. Другую половину рабочего дня он проводит с командой, занимается бэклогом и объясняет членам группы, что клиент оценил в продукте, что воспринял как недоделку и каковы его ожидания.
