Читаем Scrum полностью

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

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

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

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