В первой главе я уже говорил о непреложном правиле, не раз подтвержденном на практике: 80 процентов успеха и ценности продукта заложены в 20 процентах его функциональных возможностей. На минутку задумайтесь. Что бы вы ни приобрели, основная ценность товара или услуги, то есть самое необходимое, содержится в пятой части того, что было сделано. Этот универсальный принцип, естественно, касается и любой проектной разработки программного обеспечения. Вернемся к нашей компании, выпускающей системы автоматизации зданий. Разработчики, составив перечень требований, предъявляемых к функциям продукта, принялись внимательно его перечитывать, причем они прекрасно понимали — действительно понимали, — что из всего огромного списка потребитель заинтересуется лишь 20 процентами предложений. Секрет мастерства методики Scrum заключается в том, что с ее помощью вы докопаетесь до истины и определите эти 20 процентов. При традиционном подходе к производству исполнители работают вслепую, не зная, в каких глубинах проекта закопаны таинственные 20 процентов. Однако они сразу находятся, когда готовый продукт становится собственностью потребителя. Из чего мы делаем вывод: целых 80 процентов усилий работников совершаются впустую. Мое отношение к потерям вам хорошо известно.
Вы никогда не думали о таком беспроигрышном варианте, как выпускать новую продукцию в пять раз быстрее своих конкурентов, при этом впятеро повысив ее рыночную ценность? А вот разработчики из компании по автоматизации — они задумалась. И опять сели за свой бесконечный список, но на сей раз не для того, чтобы его перечитывать, а чтобы решить ряд вопросов. Им предстояло разобраться, за какой участок работы они возьмутся завтра, установить, какие функции системы нужнее всего для потребителя, и понять, как повысить эффективность системы и вывести ее на рынок быстрее всех. По утверждению Скотта Максвелла, сложность не в том, чтобы решить, чего ты хочешь достичь, — намного труднее понять, что ты можешь выполнить. Это относится к любому виду деятельности, независимо от того, строите ли вы дом или собираете автомобиль, пишете ли книгу или производите компьютерную игру, боретесь ли с преступностью или убираете мусор. Попытайтесь установить, как принести наибольшую пользу в кратчайший срок с наименьшими усилиями, — и немедленно принимайтесь за дело. Затем, с каждым следующим этапом, продолжайте наращивать ценность проекта. Таким образом, довольно быстро — быстрее, чем могли подумать, приступая к работе, — вы создадите продукт, который можно будет представить заказчику или выпустить на рынок. Иными словами, вы довольно скоро достигнете реального результата. Только и нужно, что правильно расставить приоритеты.
Как это сделать? Рассказываю. Для начала вам понадобится человек, который сможет определить концепцию проекта, сформулировать требования заказчика и установить необходимые пользователю основные функциональности продукта. В скрам-команде человека с такими обязанностями мы называем владельцем продукта.
ВЛАДЕЛЕЦ ПРОДУКТА
В методологии Scrum предусмотрено три роли: группа, или скрам-команда, — каждый исполнитель конкретного проекта является частью этой команды; скрам-мастер — следит за ходом проекта и помогает команде в ее проблемах, и владелец продукта. Все роли и их функции будут подробно рассмотрены в приложении. Владелец продукта решает, какой быть концепции проекта, и отвечает за его разработку; несет ответственность за составление и ведение бэклога; собирает и формулирует пользовательские требования, определяя их приоритетность.
Когда я начинал работать со своей первой скрам-командой в 1993 году, роль владельца продукта мною еще не была сформулирована. Я входил в группу управления проектом, и помимо принятия решений, что делать команде в процессе каждого спринта, у меня было множество других обязанностей. Передо мной стояли и организационные, и маркетинговые задачи, я поддерживал отношения с заказчиками и продумывал стратегию работ. Когда наступил первый спринт, у меня возникла мысль заняться и бэклогом. Требовалось лишь написать достаточное количество потребительских историй и идентифицировать основные функции проекта — то, что будет выполнять команда в следующем спринте. Проблема возникла во время второго спринта, когда мы ввели ежедневные собрания на ходу. Динамика производительности увеличилась на 400 процентов, и команда за неделю выполняла тот объем работ, на который, как мы предполагали, уйдет месяц. Естественно, они выбрали все задания из составленного мною списка. Они лишились своего бэклога, а ведь с его помощью так удобно было работать! Честно говоря, я надеялся, что у меня в запасе еще целый месяц для создания новых историй. Перед нами выросла огромная реальная проблема, и ее следовало немедленно решить. Именно в тот момент пришло осознание: нужен отдельный человек, который возьмет на себя ответственность за ведение бэклога. Я серьезно задумался над тем, какова будет его роль в скрам-команде, какими качествами он должен обладать и как мы его назовем.
Вдохновение я черпал все в той же Toyota — великой компании, давшей миру лучшие образцы такого действующего лица, как главный инженер. В корпоративной культуре Toyota решающая роль отводится главному инженеру, поскольку он полностью отвечает за процесс создания новой модели автомобиля: от разработки до ее выпуска. Он работает в теснейшем контакте с управляющими, ведущими специалистами, талантливыми инженерами и дизайнерами, принимающими непосредственное участие в конструировании и сборке очередной модели. Опираясь на основных участников проекта — специализированные технические группы, он выстраивает многофункциональную команду, способную создавать лучшие автомобили. Главные инженеры Toyota (в прошлом их величали сюса[43]) стали для всего мира легендарными фигурами как всесильные лидеры Dao Toyota (Путь Toyota) — особой системы управления и производства. Отчасти так оно и есть, хотя в контексте системы принципов компании подобное определение не очень уместно. «Всесильный» главный инженер Toyota ни в коей мере не является абсолютным властителем, более того — его статус руководителя крайне низок. Огромный коллектив ему не подотчетен, главный инженер не руководит теми, кто непосредственно участвует в реализации проекта, — скорее, он сам служит их интересам. Главные инженеры обязаны всегда быть на высоте и соответствовать строжайшим требованиям, поскольку любой специалист компании может сказать им в глаза, что они не правы. Они не дают никаких аттестаций сотрудникам, не оценивают эффективность деятельности производственного персонала, никого не поощряют и не повышают. Однако главные инженеры отвечают за составление концепции проекта — основного документа, в котором изложена идея нового автомобиля, и управляют — не принуждением, а убеждением — многоуровневой системой всего производственного процесса. Именно этот замысел я решил воплотить в Scrum.
