Счастливы сегодня, счастливы завтра

⇐ ПредыдущаяСтр 9 из 13Следующая ⇒

Психологи, в том числе и профессор из Гарварда Тал Бен‑ Шахар, утверждают, что один из способов проанализировать отношение человека к миру – задать ему вопрос, делает ли его счастливым то, чем он сегодня занимается, а также сделает ли это его счастливее завтра. Мне их совет показался полезным. Через призму этих вопросов и ответов на них можно взглянуть на людей в их рабочей обстановке.

По Бен‑ Шахару люди делятся на четыре типа.

Первый тип – гедонисты. Это люди, занимающиеся только тем, от чего они получают максимальное наслаждение. Понятие «завтра» для них не существует. Беспокоиться о завтра мы будем завтра. Я же буду получать удовольствие сейчас. Такой подход мне часто случается видеть в стартапах: группа людей в условном гараже делает что‑ то невиданное, потому что это круто и забавно. Они не задумываются над созданием долгоиграющего продукта, рационального и нужного людям. Слишком мало умственных усилий тратится на то, чтобы предусмотреть, как их штуковина будет работать через месяц, не говоря уж о годе. Потом происходит самое обычное. Инвесторы этих ребят начинают беспокоиться. Нанимают толпу управляющих, чтобы они пасли наших гениев, в прошлом хакеров. Тут гении обнаруживают, что мир, который им так нравился, стал полным отстоем. Появились всевозможные правила, проверки и отчеты. «Но если сегодня наступил отстой, – думают они, – то он останется отстоем навсегда».

Так появляется второй тип – нигилисты, в которых превратились наши гении.

Третий тип – любители крысиных бегов. Это парни, которых обычно зовут, когда надо разрулить ситуацию. Они из тех, кто в надежде на будущие повышения готовы вкалывать по 80 часов в неделю (и заставляют это делать других). Конечно, парни мечтают, что когда‑ нибудь и они станут счастливыми. Когда они наконец получают повышения и превращаются в руководящих лиц, то естественным образом у них появляется новый уровень забот и проблем, требующих еще больше времени. И они ныряют в работу с прежним рвением. Им по душе крысиные бега.

Четвертый тип – это люди того склада, которых Scrum пытается выявить и поддержать. Люди, работающие над тем, что доставляет удовольствие сегодня, но пристально смотрящие в более прекрасное будущее. Люди, убежденные, что удовольствие будет вечным. Они редко сгорают на работе и почти никогда не разочаровываются в ней. Им неведомы негативные эмоции, которые испытывает гедонист, вдруг задумавшийся о завтрашнем дне, или нигилист, или любитель крысиных бегов, стремящийся заставить всех ходить строем. Scrum воспитывает в этих людях самостоятельность и живое мировоззрение. Благодаря совместной работе такие команды помогают гедонисту без страха смотреть вперед, убеждают нигилиста, что возможно будущее без страданий, а застрявшим в бесконечной крысиной гонке управляющим наглядно показывает, что работать можно иначе.

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

Многие из нас изучали в университете «иерархию потребностей» американского психолога Абрахама Маслоу. В ней человеческие потребности представлены в виде пирамиды: те, которые мы стремимся удовлетворить в первую очередь, и те, которые становятся более актуальными, когда базовые потребности удовлетворены. У основания пирамиды расположены физиологические потребности: воздух, пища, вода, одежда и укрытие. Если у нас нет этого, мы не можем даже и думать о чем‑ то еще. Следующий слой – безопасность. Не только физическая и финансовая, но и уверенность в здоровье. Необходимо иметь доступ к медицинской помощи. Интересно, что многие люди на этом останавливаются, несмотря на то что следующий слой содержит потребности, совершенно необходимые людям, но часто игнорируемые обществом: любовь и чувство причастности – та самая взаимосвязь, которая культивируется, говорит Zappos. Над ней находится потребность в самоуважении и уважении со стороны окружающих. А на самой вершине пирамиды – потребность в достижении всей полноты своего потенциала. Маслоу больше всего интересовал верхний слой, и именно на него нацелен Scrum: помочь людям достичь личностного роста и самореализации. Люди на вершине пирамиды не только счастливее и более реализованы, они эффективнее и открыты новому. И они способны достичь величия.

Я вижу, как вы закивали головами, потому что мы все инстинктивно ощущаем эту пирамиду, даже если кто‑ то из нас никогда ее не видел. Дело в том, чтобы подняться на эти величественные высоты и суметь точно отследить то влияние, которое мы оказываем. Если вы руководите бизнесом, то величие вы, скорее всего, измеряете в прибыли и росте дела. Если вы пытаетесь помочь больным, то величие вами измеряется в количестве сохраненных жизней. Если вы пытаетесь изменить мир, то произошедшие перемены будут служить лучшим доказательством вашего величия. Если вы просто пытаетесь выполнить все, что вам поручила сделать по дому жена, то измеряете свое величие в том, сколько свободных выходных у вас осталось, чтобы пойти на рыбалку.

Недостаточно просто быть счастливым. Чтобы счастье приносило результаты, нужно его использовать. Все элементы Scrum, собранные вместе, существуют ради того, чтобы помочь человеку это сделать. В чем хитрость? В приоритетах. Об этом мы поговорим в следующей главе.

Подведем итоги

• Это путешествие, а не пункт назначения. Истинное счастье можно найти в пути, а не в его завершении. Мы обычно награждаем только за результаты, но что больше всего нужно укреплять в людях – их стремление к величию.

• Счастье – хит сезона. Счастье помогает вам принимать лучшие решения. Когда вы счастливы, вы становитесь созидателями, не бегаете из компании в компанию и наверняка сделаете намного больше того, чем сами рассчитывали.

• Измерить счастье. Просто быть счастливым недостаточно. Нужно измерить чувство счастья и полученный результат сопоставить с результатами вашей деятельности. Все традиционные показатели берутся из прошлого. Счастье – это показатель, который всегда смотрит в будущее.

• Становитесь лучше каждый день – и измеряйте улучшения. В конце каждого спринта команда должна выбрать маленькое улучшение, или кайдзен, которое сделает их счастливее. Это должно стать самой важной вещью, которой они добьются в следующем спринте.

• Секретность – яд. Ничто не может держаться в тайне. Все должны знать всё, включая финансовые данные. Запутывание следов нужно только тем, кто ищет собственной выгоды.

• Работа должна быть прозрачной. Сделайте доску, которая будет показывать, какую работу нужно выполнить, над чем вы сейчас работаете и что уже сделано. Ее должны видеть все и все должны обновлять информацию на ней.

• Счастье – это независимость, мастерство и целеустремленность. Каждый человек хочет управлять своей судьбой, совершенствоваться в том, что делает, и служить большой цели.

• Заставьте «пузырь счастья» лопнуть. Не становитесь счастливыми до такой степени, чтобы начать верить в придуманную вами же чепуху. Всегда измеряйте счастье результатами деятельности, и если заметите нестыковки, будьте готовы вмешаться. Удовлетворенность и самонадеянность – враги успеха.

Глава восьмая

Приоритеты

Со Скоттом Максвеллом я впервые встретился в кафе Johnny’s Luncheonette в городе Ньютоне пару лет назад. Я уже рассказывал вам о нем. Он основатель OpenView Venture Partners, и именно ему когда‑ то пришла в голову светлая мысль, что изнурительный многочасовой труд лишь создает больше дополнительной работы, но не приводит к реальным результатам, не повышает производительности и не приносит прибыли.

Я проработал с OpenView и ее портфельными компаниями более восьми лет, и каждый год мы наблюдали потрясающий рост продуктивности. Но к Scrum нельзя относиться только как к способу, дающему возможность работать быстрее. Прежде всего, наша методология позволяет повысить и укрепить внутренние стимулы и мотивы; в случае с ребятами из OpenView это выразилось в простой формуле, название которой «годовой доход». Если ваша компания не делает деньги, значит вы не преуспевающий предприниматель, а дилетант.

Трудно передать, сколько мне пришлось на своем веку видеть компаний с прекрасными идеями и по‑ настоящему замечательной продукцией, от которой все сходят с ума. По всем признакам она должна пользоваться успехом и обязательно отыщет свою нишу на рынке. Ведь их вещи такие классные. Но люди, создающие эти вещи, – невзирая на избыток воображения, вдохновения и упорного труда – так никогда и не приходят к пониманию, как на своей продукции зарабатывать деньги.

В чем разница между такими компаниями, как Pets.com и Zappos? И та и другая увидели каждая свой сегмент рынка, на котором люди ежегодно тратят миллиарды долларов. И та и другая нашли очень простой и дешевый способ – заказ и доставка через интернет. Но первая стала олицетворением кризиса доткомов и разбазаривания многих миллионов долларов, а другая оценивается в миллиард с лишним долларов. У обеих компаний был замысел. Однако в деловой политике Pets.com не хватало одной детали – правильно расставленных приоритетов. Основатели Pets.com не знали, что и когда делать.

Я люблю диаграмму Венна и всегда стараюсь демонстрировать такой ее вариант.

Каждый предприниматель обязан обратить внимание на эту диаграмму. Если на первый план будет выдвигаться лишь то, что вы можете предложить рынку, вы рискуете остаться с никому не нужным продуктом на руках; вам остается с не меньшим пылом трудиться дальше и продолжать восхищаться собственными изделиями. Если делать акцент только на желании завоевать рынок, то подстерегает другая опасность: вы можете не успеть выпустить обещанный продукт, и вашу нишу займет кто‑ то другой. Если вы выпускаете продукт только ради продаж, но производите его, не испытывая любви к своему делу, то в результате напряженный труд оборачивается весьма посредственным товаром. Как всегда, нужно искать золотую середину – на мой взгляд, она заключена в сбалансированной концепции, которая соотносится исключительно с реальным состоянием дел. Если вы воспримете предложенную концепцию правильно, то сможете использовать свой шанс стать прибыльной и интересной компанией. Предыдущие главы были посвящены тому, как трудиться и лучше, и быстрее. Эта глава немного о другом: как сделать, чтобы «и лучше, и быстрее» начало работать на вас; другими словами, как достичь великих побед.

По словам Скотта Максвелла, самой сильной и привлекательной составляющей Scrum стал заранее подготовленный бэклог проекта, в котором перечислены все задания, отсортированные по их приоритетности. Наличие такого документа окончательно повлияло на решение Максвелла внедрить Scrum в OpenView; и по сей день он считает нашу методику залогом своей конкурентоспособности.

Бэклог. Что и когда делать

Первое, что полагается делать, когда приступаешь к проекту по методике Scrum, – создать список требований к функциональности продукта; список должен быть упорядочен по степени важности задач, подлежащих реализации. Традиционно такой список называется «бэклог»[42]. Иногда он содержит сотни заданий, иногда – всего несколько задач, о которых нужно думать в первую очередь. Само собой, требуется иметь четкое представление, что вы хотите получить в конце своего проекта. Задание может быть любым: программное обеспечение; свадебная церемония; услуга, новая вакцина, перекрашенный дом. Желательно без промедления – едва только сложится концепция замысла – детально продумать все, что потребуется для нормального хода работ.

Недавно я консультировал компанию, которая выпускает системы автоматизации зданий. Отопление, вентиляция, электричество, водоснабжение, кондиционирование – в общем, «все в одном». Один из их новых продуктов представлял собой программное обеспечение для домашней автоматизации, управляющей важнейшими системами в жилом помещении: открыванием входной двери; включением осветительных приборов; расходами на отопление и многим другим – причем все осуществляется с мобильного устройства. Перед началом проекта разработчики, собравшись за одним столом, составили большой список: переключатели, контроллеры, интерфейсы, сенсоры, протоколы коммуникаций и прочее в таком же духе – то есть в нем были перечислены детали, которые понадобятся для нормально функционирующей системы. Не ее принципы, не этапы рабочего процесса, а именно пожелания пользователя. Например, следующее пожелание: «Мне как хозяину надо видеть, кто звонит в дверь, чтобы открывать только тем, кого я хочу впустить в свой дом». Были записаны истории об открывании ворот гаража, включении систем отопления и вентиляции, контроле за состоянием электросети. Разработчики продолжали писать до тех пор, пока не зафиксировали все функции системы. Список оказался длинный – в несколько сотен пунктов. Система обещала быть большой, сложной и весьма привлекательной для пользователей.

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

Основной момент, нас интересующий, – принцип расстановки приоритетов. Для этого нужно выяснить, какие пункты списка:

• имеют самое большое значение для хода работ над проектом;

• важнее всего для заказчика или будущего потребителя;

• принесут максимальный доход;

• проще всего осуществить.

Следует сразу уяснить простую вещь: в списке полно заданий, до которых у вас никогда не дойдут руки, но вам требуется выбрать те, что принесут наибольшую пользу при наименьшем риске. Поскольку Scrum придерживается поступательной модели разработки и поставки – на языке программистов эта модель называется инкрементальной, – надо начать с такого набора возможностей продукта, который немедленно принесет доход; тем самым вы снизите риски, связанные с проектом. Потому сначала советую отбирать основные функциональности. Хотите оказать быструю услугу заказчику? Тогда берите требование с наивысшим приоритетом, выполняйте его – и, полностью сделав, демонстрируйте клиенту. Это может быть лишь небольшая часть крупного проекта, но ее нужно исполнить до готовности, чтобы не было стыдно показать всем заинтересованным лицам. Перекрашивая дом, начните в первую очередь с обновления гостиной и доведите работу до конца (вплоть до того, что уберете оттуда грязные тряпки и банки с краской) – это будет часть вашего проекта, выполненная целиком.

В первой главе я уже говорил о непреложном правиле, не раз подтвержденном на практике: 80 процентов успеха и ценности продукта заложены в 20 процентах его функциональных возможностей. На минутку задумайтесь. Что бы вы ни приобрели, основная ценность товара или услуги, то есть самое необходимое, содержится в пятой части того, что было сделано. Этот универсальный принцип, естественно, касается и любой проектной разработки программного обеспечения. Вернемся к нашей компании, выпускающей системы автоматизации зданий. Разработчики, составив перечень требований, предъявляемых к функциям продукта, принялись внимательно его перечитывать, причем они прекрасно понимали – действительно понимали, – что из всего огромного списка потребитель заинтересуется лишь 20 процентами предложений. Секрет мастерства методики Scrum заключается в том, что с ее помощью вы докопаетесь до истины и определите эти 20 процентов. При традиционном подходе к производству исполнители работают вслепую, не зная, в каких глубинах проекта закопаны таинственные 20 процентов. Однако они сразу находятся, когда готовый продукт становится собственностью потребителя. Из чего мы делаем вывод: целых 80 процентов усилий работников совершаются впустую. Мое отношение к потерям вам хорошо известно.

Вы никогда не думали о таком беспроигрышном варианте, как выпускать новую продукцию в пять раз быстрее своих конкурентов, при этом впятеро повысив ее рыночную ценность? А вот разработчики из компании по автоматизации – они задумалась. И опять сели за свой бесконечный список, но на сей раз не для того, чтобы его перечитывать, а чтобы решить ряд вопросов. Им предстояло разобраться, за какой участок работы они возьмутся завтра, установить, какие функции системы нужнее всего для потребителя, и понять, как повысить эффективность системы и вывести ее на рынок быстрее всех. По утверждению Скотта Максвелла, сложность не в том, чтобы решить, чего ты хочешь достичь, – намного труднее понять, что ты можешь выполнить. Это относится к любому виду деятельности, независимо от того, строите ли вы дом или собираете автомобиль, пишете ли книгу или производите компьютерную игру, боретесь ли с преступностью или убираете мусор. Попытайтесь установить, как принести наибольшую пользу в кратчайший срок с наименьшими усилиями, – и немедленно принимайтесь за дело. Затем, с каждым следующим этапом, продолжайте наращивать ценность проекта. Таким образом, довольно быстро – быстрее, чем могли подумать, приступая к работе, – вы создадите продукт, который можно будет представить заказчику или выпустить на рынок. Иными словами, вы довольно скоро достигнете реального результата. Только и нужно, что правильно расставить приоритеты.

Как это сделать? Рассказываю. Для начала вам понадобится человек, который сможет определить концепцию проекта, сформулировать требования заказчика и установить необходимые пользователю основные функциональности продукта. В скрам‑ команде человека с такими обязанностями мы называем владельцем продукта.

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

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

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

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

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

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

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

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

Осмысляя опыт, полученный мною в Вест‑ Пойнте и на Вьетнамской войне, я независимо от кого‑ либо пришел к выводу, что управление коллективом не имеет ничего общего ни с властным статусом руководителя, ни с полномочиями, которыми он наделен. Пожалуй, прежде всего прочего руководящая роль человека определяется личным профессиональным опытом и умением быть лидером, готовым отдавать себя служению людям и делу. Главный инженер Toyota не может просто отдать распоряжение кому‑ то что‑ то сделать так, а не иначе. Он должен отстоять собственную точку зрения, привлечь на свою сторону не только высшее руководство, но и исполнителей, убедительно доказывая, что предложенный им путь – самый лучший и единственно верный. Естественно, подобное по силам лишь профессионалу, накопившему несколько десятилетий опыта. Я обдумывал варианты, как вписать в систему Scrum работника, который сумел бы вытянуть столь сложную роль, но довольно быстро понял, что не смогу найти человека с нужным мне уровнем мастерства и опыта – слишком узок круг таких специалистов. Поэтому пришлось разбить эту функциональную обязанность на две разные. Таким образом получилось, что скрам‑ мастер несет ответственность за ту часть проекта, которая отвечает на вопрос как делать, а владелец продукта – за ту часть, которая отвечает на вопрос что делать.

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

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

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

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

1. Владелец продукта должен обладать всей полнотой знаний о том, что входит в круг его обязанностей. Подразумевается следующее: во‑ первых, он должен быть абсолютно компетентен во всем, что делается в процессе разработки, и уметь оценивать возможности команды – то есть с чем она справляется, а с чем не очень; во‑ вторых, довольно хорошо разбираться в сути продукта и понимать, как довести разработку проекта – а это может быть и компьютерная система ФБР, и метод обучения учащихся средних школ – до результата, имеющего действительную стоимость. Кроме того, владелец продукта должен великолепно знать рынок, чтобы уметь анализировать его состояние: какая продукция имеет значение сегодня и как может измениться ситуация завтра.

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

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

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

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

⇐ Предыдущая 4 5 6 7 8910 11 12 13 Следующая ⇒