Book: Управление продуктом в Scrum. Agile-методы для вашего бизнеса



Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Роман Пихлер

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Купить книгу "Управление продуктом в Scrum. Agile-методы для вашего бизнеса" Пихлер Роман

Roman Pichler

AGILE PRODUCT MANAGEMENT WITH SCRUM

Creating Products that Customers Love


Издано с разрешения Pearson (Addison-Wesley Professional)


Книга рекомендована к изданию Лианой Мартиросян и Наталией Юлдашевой


Благодарим за помощь в подготовке издания компанию ScrumTrek в лице Алексея Пименова, Дарьи Рыжковой, Василия Савунова и Александра Тупикова


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


Authorized translation from the English language edition, entitled Agile product management with Scrum: creating products that customers love, 1st edition, published by Pearson, publishing as Addison-Wesley Professional.

© Roman Pichler, 2010

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2017

* * *

Эту книгу хорошо дополняют:

Scrum. Революционный метод управления проектами

Джефф Сазерленд


Deadline

Том Демарко


От хорошего к великому

Джим Коллинз

Посвящается Мелиссе


Предисловие Джеффа Сазерленда

Владелец продукта – новая роль для большинства компаний, и поэтому она нуждается в убедительной презентации, которую и дает эта книга. Когда избирался первый владелец продукта, я был вице-президентом Object Technology и отвечал за разработку первого продукта, созданного по Scrum. Этот продукт должен был стать определяющим для компании, и мне отводилось шесть месяцев, чтобы создать инструмент разработки, который изменит рынок. Помимо работы вместе с небольшой, тщательно подобранной командой мне предстояло перестроить всю компанию вокруг новой схемы деятельности. До поставки продукта оставалось несколько месяцев, и было понятно, что успех определит правильно сформированный набор минимального функционала. Оказалось, мне не хватает времени на разговоры с клиентами и тщательный анализ действий конкурентов, что помогло бы точно расставить приоритеты и разложить функционал на небольшие элементы для команды.

Я уже делегировал свои инженерные обязанности первому scrum-мастеру, Джону Скамниоталесу, но мне был необходим владелец продукта. У меня имелся доступ к любым ресурсам компании, поэтому я избрал на нужную мне роль Дона Реднера, лучшего специалиста из команды менеджеров продукта. Дону как первому владельцу продукта предстояло вести его, сформировав в уме видение перспектив, бизнес-плана и выручки, планов развития и выпуска, а главное – тщательно разработав бэклог[1] продукта с расставленными для всей команды приоритетами.

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

Степень концентрации и мера ответственности хорошего владельца продукта подробно описаны в этой книге, однако редко наблюдаются в реальных компаниях по производству продукта и IT-командах. Нам необходимо описание образцового владельца продукта, а также того, как он исполняет эту роль. Такое руководство и подготовил Роман Пихлер.

Джефф Сазерленд,один из создателей Scrum

Предисловие Бретта Квинера

Сегодня во всей индустрии ПО набирает силу Agile. Последние двадцать лет многие клиенты, партнеры и сотрудники были разочарованы тем, как мы разрабатываем корпоративные технологические решения. Они, к сожалению, часто оказывались низкокачественными, требовали нескольких лет для вывода на рынок, в них нередко отсутствовали инновации, необходимые для решения реальных проблем бизнеса.

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

Мне как главному владельцу продукта в Salesforce.com нужно было найти максимально динамичный способ, при помощи которого менеджеры продуктов сумеют донести желания и потребности клиентов и бизнеса до команд разработчиков, обеспечив к тому же обратную связь. Использование Scrum позволяет возложить на менеджеров продукта ответственность за создание ценности для клиента. Что, в свою очередь, дает возможность направлять команду к разработке в первую очередь наиболее важных для бизнеса функций, чтобы как можно быстрее передать продукт в руки покупателей. Scrum дает нужную гибкость, чтобы быстро реагировать на меняющиеся условия рынка и давление со стороны конкурентов или внедрять новые идеи наших команд. Из этой книги вы узнаете, чем владелец продукта отличается от традиционного менеджера продукта и почему он наделен более высоким уровнем ответственности за успех продукта. Здесь ярко выявлен контраст между поведением специалиста в традиционной и agile-моделях.

Многие пытались объяснить роль владельца продукта, но никому это не удалось так, как Роману Пихлеру. Он убедительно рассказывает о теории и практике гибкого управления продуктом, которые помогают владельцам продукта, членам scrum-команд и руководителям внедрять инновации. Роман приводит множество примеров из деятельности таких конкурентоспособных инноваторов, как Salesforce.com, а также доходчиво объясняет, как создать и обеспечить надежную работу минимальной функциональности при инновациях. Он обращает внимание и на часто встречающиеся ошибки владельцев продукта.

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

Бретт Квинер,старший вице-президент по продукту Salesforce.com

Предисловие

По гибкой разработке ПО и управлению продуктом написано много отличных книг. Однако до сих пор нет исчерпывающего описания того, как оно работает. Кажется, что agile-адепты стараются ускользнуть от ответа на этот вопрос, а специалисты по управлению продуктом до сих пор силятся понять этот дивный agile-мир. Сейчас все больше компаний берут на вооружение Scrum, и вопрос о специфике управления продуктом в scrum-среде становится очень актуальным. В этой книге делается попытка на него ответить.

В 1999 году я познакомился с agile-идеологией, и меня поразило тесное сотрудничество между техническими и бизнес-специалистами и технарями. Я всегда считал, что разработка ПО – это то, что интересует гиков[2], но не бизнесменов. Занимаясь коучингом своего первого agile-проекта в 2001 году, я прежде всего старался помочь менеджерам продукта перейти к миру гибких методологий. С тех пор владение продуктом всегда оставалось самым большим вызовом для компании и определяло успех всего предприятия. Так было во всех компаниях, которые я консультировал, и это помогало не только разрабатывать успешный продукт, но и применять Scrum по назначению. Можно повторить слова Криса Фрая и Стива Грина (Fry, 2007; 139), которые консультировали Salesforce.com по переходу к Agile:

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

Чем отличается agile-управление продуктом

Agile, или гибкое управление продуктом, основанное на Scrum, отличается от традиционных подходов во многих отношениях. В таблице 1 приведено резюме наиболее важных различий.


Таблица 1. Управление продуктом по-старому и по-новому

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Agile-методы, в том числе Scrum, придерживаются старой как мир истины: постоянны только изменения. «Если собственный анализ компании не делает продукт устаревшим, это сделает чей-то еще анализ», – писал Теодор Левитт в своей знаменитой статье «Близорукость маркетинга», опубликованной в 1960 году. Кристенсен добавляет, что прорывные технологии со временем происходят в любой отрасли. Непонятно только, насколько быстро и часто это случается. Компании, неспособные к стремительной адаптации, сойдут с дистанции, даже если в данный момент с их доходами все в порядке. К счастью, эмпирическая природа Scrum отлично приспособила эту методологию к внедрению разных новшеств и инноваций, действий в сложных ситуациях, где преобладают текучесть и непредсказуемость. Если ваш бизнес характеризуется переменами, в Scrum вы, скорее всего, найдете мощного союзника.

Что предлагает эта книга и кто должен ее прочесть

Эта книга для всех, кого интересует гибкое управление продуктом, особенно для владельцев продукта. Она рассказывает о роли владельца продукта и основных методах управления. К ним относятся визуализация продукта, разработка и совершенствование бэклога продукта, планирование и отслеживание релиза продукта, использование scrum-собраний и переход к новой роли. Это практическое руководство позволит эффективно применить scrum-техники управления продуктом. Особое внимание уделяется продуктам, связанным с ПО, – от простого приложения до мобильных телефонов.

Но это не учебник для начинающего менеджера продукта и не пособие по Scrum для новичков. Тем более нельзя считать книгу руководством на все случаи жизни в области управления продуктом. Многие аспекты управления продуктом здесь даже не рассматриваются. Наибольшее внимание уделяется идеям и методам управления продуктом, специфичным для Scrum.

Эта книга предполагает, что вы знакомы со Scrum и обладаете актуальными познаниями в области управления продуктом.

Надеюсь, книга поможет вам создавать продукты, которые полюбят потребители: они будут приносить покупателям пользу и разрабатываться разумно, с расчетом на длительную перспективу.

1. Кто такой владелец продукта?

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

Что же произошло? Где-то по дороге между идеей и запуском концепция заблудилась. Маркетологи провели исследование рынка, сформулировали концепцию продукта и передали ее менеджеру продукта. Он написал спецификацию и вручил менеджеру проекта, который передал ее в разработку. Не нашлось никого, кто бы отвечал за создание успешного продукта, не существовало общего видения продукта и его функциональности. У всех были собственные подходы, своя концепция.

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



Роль владельца продукта

В Scrum Guide Кен Швабер пишет о владельце продукта:

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

Определение звучит вполне безобидно, пока мы не начнем оценивать его последствия. Владелец продукта возглавляет усилия разработчиков по созданию продукта, благодаря которому появляются желаемые преимущества. Это часто подразумевает формулирование концепции продукта, работу с бэклогом продукта, планирование релиза, привлечение клиентов, пользователей и других заинтересованных лиц, управление бюджетом, подготовку запуска продукта, посещение scrum-митингов и сотрудничество с командой. Владелец продукта играет ключевую роль не только в создании новых продуктов, но и в поддержании жизненного цикла продукта. Назначение одного человека ответственным за релизы обеспечивает их непрерывность и снижает количество передаточных звеньев, а также поощряет долгосрочное планирование. Исследование в SAP AG выявило и другие преимущества: сотрудники, работающие владельцами продукта, чувствовали себя уверенно, понимали степень своего влияния и то, что они на виду, были наиболее организованными и мотивированными для новой роли.

Но владелец продукта – это прежде всего член scrum-команды, он тесно сотрудничает с коллегами. Scrum-мастер и команда помогают владельцу продукта, совместно работая над бэклогом продукта, а владелец продукта отвечает за успех необходимых мероприятий.

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

Конкретные задачи владельца продукта зависят от контекста: в частности, от типа продукта, стадии его жизненного цикла и размера проекта. Например, владельцу продукта, который состоит из программного обеспечения, аппаратного обеспечения и механических устройств, потребуются совершенно иные компетенции, чем человеку, возглавляющему работу по созданию веб-приложения. А владелец продукта, участвующий в большом scrum-проекте, должен иметь иные навыки, чем человек, сотрудничающий с одной-двумя командами.

В коммерческих проектах владелец продукта – обычно представитель клиента: менеджер продукта или маркетолог. Сам клиент принимает на себя эту роль, если продукт разрабатывается для конкретной организации. Например, это может быть внешний клиент, которому необходимо новое решение для хранилища данных, или внутренний клиент (в частности, отдел маркетинга), запрашивающий обновление сайта. Мне доводилось работать с клиентами, пользователями, менеджерами бизнес-направлений, менеджерами продуктов, руководителями проектов, бизнес-аналитиками и архитекторами, которые хорошо подходили на роль владельца продукта в конкретных обстоятельствах. Владельцем продукта может стать даже CEO[3]. Например, Ript – визуальный планировщик, позволяющий пользователям копировать и вставлять изображения и тексты из одного приложения в другое, – это плод усилий Джерри Лейборна, CEO компании Oxygen Media, который взял на себя роль владельца продукта для первого релиза программы.

Характеристики правильного владельца продукта

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

Визионер[4] и человек действия

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

Лидер и командный игрок

«Хорошие бизнес-лидеры создают концепцию, формулируют концепцию, страстно ее отстаивают и неумолимо ведут к завершению», – говорит Джек Уэлч, бывший председатель совета директоров и CEO компании General Electric. Владелец продукта – именно такой лидер. Отвечая за успех продукта, он обеспечивает руководство всеми, кто занят разработкой, и готов принимать сложные решения. Например, укажет, отложить дату запуска или ограничиться меньшей функциональностью. В то же время владелец продукта – командный игрок, он вступает в тесное сотрудничество с другими членами scrum-команды и не обладает формальной властью над ними. Мы можем определить владельца продукта как primus inter pares – первого среди равных в том, что касается продукта.

Двойственная природа владельца продукта (как лидера и командного игрока) накладывает свои ограничения. Он ни в коем случае не должен быть диктатором, но в то же время не может себе позволить нерешительности и мягкотелости в управлении.

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

Команда предпринимателей

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

В команде множество партнеров, способных проверить ваши идеи и тем самым стимулировать принятие верных решений. Эд Кэтмалл, президент Pixar, утверждает:

если дать хорошей команде посредственную идею, она либо исправит ее, либо выбросит и придумает взамен что-то получше.

Мудрость многих лучше, чем гений одного.

Пропагандист и переговорщик

Владелец продукта должен быть эффективным пропагандистом и переговорщиком. Этот человек общается с разными сторонами, объединяя клиентов, пользователей, разработчиков, инженеров, маркетологов, сотрудников отдела продаж, операционных сотрудников и руководство. Владелец продукта – это голос клиента, который доносит до исполнителей требования потребителя и заполняет лакуну между «пиджаками» и «технарями». Иногда от него требуется сказать «нет», а иногда – найти компромисс.

Наделенный полномочиями и преданный делу

У владельца продукта должно быть достаточно полномочий, чтобы возглавить разработку и объединить усилия всех заинтересованных лиц. В mobile.de, самом большом немецком онлайн-рынке автомобилей, высшее руководство избирает владельцев продуктов, обеспечивает им поддержку и выступает в роли старшего партнера. Столь тесное сотрудничество позволяет руководителям лучше следить за ходом выполнения конкретных проектов и отказываться от бесперспективных на раннем этапе[5].

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

Доступный и квалифицированный

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

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

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

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

[Владелец продукта] должен быть экспертом в своей отрасли, работать хотя бы пару дней в неделю как врач в одной из ведущих больниц Бостона… техническим специалистом, уже написавшим несколько приложений… экспертом в анализе пользовательских историй, сценариев использования и программных спецификаций, особенно в области здравоохранения… уметь находить общий язык с клиентами и отделом продаж, выяснять требования и набирать специалистов-медиков для тестирования прототипов с новой функциональностью… и при этом вести бизнес, заниматься выручкой, отношениями с клиентами и специалистами по продажам в части, касающейся функционала, создавать пользовательские истории и все дополнительные спецификации продукта, в том числе анализировать ожидания клиента. [Наши владельцы продукта] получают помощь только от разработчиков и членов своей команды. Первые два назначенных специалиста с задачей не справились. Но постоянное обучение, наставничество и верно выбранный сотрудник дали нужные результаты[6].

Работа с командой

Владелец продукта – это такой же член scrum-команды, как и все остальные, он должен полагаться на сотрудничество с ней и со scrum-мастером. Команда представляет собой многофункциональную, самоорганизующуюся и при этом небольшую группу специалистов. В ней должны быть представлены все роли, необходимые для создания продукта. Члены scrum-команды работают в атмосфере доверия и сотрудничества, как равноправные коллеги. Исключается разделение людей на «мы и они». Должно присутствовать только понятие «мы».

Для создания атмосферы успешности в scrum-команде сведите к минимуму изменения в ее составе в течение релизов и между ними. Чтобы группа людей превратилась в сплоченную команду, потребуется время. Необходимо создать тесно спаянный коллектив, члены которого доверяют друг другу, эффективно работают вместе. Если изменить состав команды, процесс построения начинается заново и в результате снижаются продуктивность и самоорганизация. К тому же нужно установить долгосрочное партнерство между scrum-командой и ее продуктом. Каждый продукт должен разрабатываться одной или несколькими преданными ему командами. Это не только облегчает обучение, но и упрощает распределение людей и ресурсов.

Поскольку владелец продукта, scrum-мастер и команда должны постоянно и тесно сотрудничать, желательно разместить всех членов scrum-команды в одном помещении. Рассмотрим пример mobile.de. То, что владельцы продукта, scrum-мастер и команда находились в одном помещении, повысило производительность и боевой настрой команды[7]. Если владелец продукта не имеет возможности постоянно находиться вместе с командой, он должен регулярно встречаться с ее членами. Владельцы продукта, работающие удаленно, могут приходить в офис и оставаться вместе с командой на протяжении нескольких дней при каждом спринте. Если владельцы находятся в том же комплексе, но располагаются далеко от команды, я рекомендую им выполнять «правило одного часа»: проводить как минимум час в день в помещении, где трудится команда.

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

Взаимодействие со scrum-мастером

Чтобы постоянно играть на высшем уровне, спортивной команде необходим тренер, а scrum-команде – scrum-мастер[8]. Он оказывает поддержку владельцу продукта и команде, защищает ее и процесс работы и при необходимости вмешивается, чтобы удостовериться, справляется ли команда с задачей, сохраняет ли здоровую атмосферу и мотивацию и не создает ли технического долга[9].

Роли владельца продукта и scrum-мастера дополняют друг друга. Владелец продукта в первую очередь отвечает за создание нужного продукта. Scrum-мастер в основном несет ответственность за то, «как» правильно использовать практики Scrum. Эти два аспекта проиллюстрированы на рисунке 1.1. Долгосрочный успех достигается, когда правильный продукт создается правильными методами.


Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Рисунок 1.1. Создание правильного продукта правильными методами


Поскольку роли владельца продукта и scrum-мастера призваны дополнять друг друга, выполнять их одному человеку невозможно: это создает чрезмерную нагрузку. Нельзя быть одновременно scrum-мастером и владельцем продукта.

Работа с клиентами, пользователями и другими заинтересованными лицами

Клиент – это тот, кто приобретает продукт, а пользователь – человек, применяющий продукт. Они определяют его успех или неудачу. Продукт будет востребован на рынке, только если достаточное количество клиентов купят его, а пользователи сочтут выгодным приобретением. Заметьте, что клиент и пользователь могут не совпадать, а их потребности – различаться. Рассмотрим в качестве примера электронные таблицы. Пользователи особенно ценят простоту их применения и высокую производительность. В свою очередь, компания, приобретающая продукт, заинтересована в разумной стоимости использования и безопасности данных.

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

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

Помимо клиентов и пользователей производители продукта должны привлекать и других заинтересованных лиц – например, представителей служб маркетинга, продаж и клиентского обслуживания. Их с самого начала следует приглашать на рабочие совещания во время спринтов. Эти встречи позволят заинтересованным лицам увидеть, как создается продукт, наладить контакт со scrum-командой и обменяться мнениями. Брайсон (Bryson, 2004) предлагает обзор методов выявления заинтересованных лиц, анализа их требований и работы с ними.



Менеджеры по продуктовому маркетингу и менеджеры продукта

Некоторые компании разграничивают стратегический и тактический продакт-менеджмент и выделяют отдельные должности для каждого из них: менеджер по продуктовому маркетингу и (технический) менеджер продукта. Деятельность менеджеров по продуктовому маркетингу обычно направлена вовне: в их обязанности входит понимать рынок, управлять планом развития продукта и следить за общими доходами после релизов. А менеджеры продукта смотрят внутрь: их задача – подробное описание функций, расстановка приоритетов и сотрудничество с командой разработчиков. В Scrum владелец продукта совмещает все эти обязанности. По стратегическим вопросам управления продуктом владелец продукта может получить поддержку от управляющего портфелем, вице-президента и даже CEO. Все зависит от размера компании и важности проекта. Помощь по ценообразованию и маркетинговым вопросам ему окажут менеджер по продуктовому маркетингу и руководитель отдела продаж. С точки зрения тактики владелец продукта должен рассчитывать на поддержку scrum-мастера и своей команды. Объединение обоих аспектов управления продуктом обеспечивает сквозное руководство и общую ответственность. Мы стараемся избегать появления лишних звеньев, необходимости ждать согласований и отсрочек, а также проблем, связанных с недопониманием одного работника другим.

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

Моделирование роли владельца продукта

Прежде чем рассказать о методах работы владельца продукта в крупных scrum-проектах, хочу дать совет: избегайте больших проектов! Начинайте с малого и быстро разрабатывайте продукт с минимальной функциональностью. Об этом пойдет речь в главе 2. Если приходится заниматься крупным проектом, увеличивайте объемы медленно. Пусть он растет естественным образом, прибавляя по одной команде за раз. Если работу начинает слишком большое число людей, то проект может стать чересчур сложным, так что последующие обновления потребуют массу времени и денег[10].

Главный владелец продукта

В крупных scrum-проектах принимает участие несколько небольших команд. Каждой из них требуется владелец продукта, но в одиночку он может заниматься лишь ограниченным количеством команд. Сколько команд может быть доверено одному владельцу продукта без сверхурочной работы и пренебрежения своими обязанностями, – зависит от ряда факторов. Среди них новизна и сложность продукта, а также знание предмета командами. Обычно владельцу продукта удается плодотворно работать не больше чем с двумя командами. Если их больше, то должны сотрудничать несколько владельцев продукта. Возникает противоречие: владелец продукта – это один человек, но для крупного scrum-проекта их нужно несколько. Поэтому необходимо назначить ответственного за создание и внедрение концепции продукта. Таким образом, вводится иерархия сотрудничающих владельцев продукта, один из которых – главный. Такая же система существует в ресторанах, где есть несколько шеф-поваров во главе с главным шеф-поваром[11].

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

Иерархия владельцев продукта

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

Организация проекта, изображенная на рисунке 1.2, состоит из трех команд и трех владельцев продукта. Каждый владелец продукта отвечает за свою команду. В свою очередь, владельцы продукта тоже формируют команду, и владелец продукта В выступает в роли главного. Эта иерархия считается горизонтальной, несмотря на наличие главного владельца. Приведу пример, как можно применить такую организацию проекта: клиент нанимает команду владельца продукта, отвечающую за веб-портал и его приложения. Четыре владельца продукта и главный владелец продукта тесно сотрудничают, при этом каждый отвечает за конкретное предложение, а главный владелец продукта – за весь продукт, включающий в себя все приложения и портал.


Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Рисунок 1.2. Простая иерархия владельцев продукта


На рисунке 1.3 представлен другой вариант, подходящий для больших scrum-проектов и заимствованный из книги Кена Швабера (Schwaber, 2007; 70–73).

Организация проекта, частично изображенная на рисунке 1.3, состоит из четырех уровней и девяти владельцев продукта[12]. Каждый владелец продукта руководит своими коллегами, располагающимися на более низком иерархическом уровне, и помогает им. Владелец продукта верхнего уровня является главным владельцем продукта. Он отвечает за всю разработку и успех продукта. В данном случае владельцы продукта образуют непростую иерархию.


Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Рисунок 1.3. Сложная иерархия владельцев продукта


Сложная иерархия владельцев продукта предполагает специализацию деятельности каждого из них. Главный владелец продукта возглавляет общую разработку, координируя свою деятельность с клиентами и другими заинтересованными лицами. Владельцы продукта более низкого уровня сосредоточены на своих функциях или подсистемах и тесно сотрудничают с командами разработчиков. Швабер (Schwaber, 2007; 72) отмечает:

Владелец продукта планирует, расписывает, распределяет и отслеживает работу со своего уровня вниз… Чем выше его уровень, тем сложнее работа. Объем ответственности владельца продукта высшего уровня обычно предполагает, что им становится должностное лицо не ниже вице-президента или CEO.

Как правильно выбрать владельцев продукта

Найти подходящего человека на роль владельца продукта непросто, даже когда нужен только один такой кандидат. По каким же критериям выбирать правильных владельцев продукта для больших проектов? Ответ на этот вопрос дает понимание разных способов организации команд в большом проекте. Существует всего два варианта: функциональные команды и компонентные команды (Pichler, 2008; Larman and Vodde, 2009). Функциональная команда внедряет сквозной набор требований – например, одну или несколько тем или функций. В результате появляется сквозной вертикальный срез, который проходит через основные части программной архитектуры. Компонентная команда выдает компонент или подсистему.

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

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

Распространенные ошибки

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

Владелец продукта с недостаточными полномочиями

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

Перегруженность владельца продукта

Перегрузка на работе пагубно отражается на здоровье и моральном состоянии любого человека. А перегруженные владельцы продукта часто оказываются слабым звеном, ограничивающим прогресс проекта. Симптомы перегрузки владельца продукта – это недостаточная работа над бэклогом продукта, пропуски планирования спринтов или обзорных совещаний, невозможность задать им вопрос и слишком длительное время, требующееся для ответов. Перегруженные владельцы продукта не соответствуют идее agile-манифеста о постоянном темпе. «Agile-процессы подразумевают равномерное развитие. Заказчики, разработчики и пользователи должны постоянно поддерживать один и тот же темп» (Beck et al., 2001).

Перегруженность владельца продукта наступает вследствие двух основных причин: нехватки времени на исполнение своих обязанностей и недостатка поддержки со стороны команды. Доступность владельца продукта оказывается под угрозой, если эта роль – лишь одна из нескольких задач, которые он вынужден выполнять, или если ему приходится следить за большим количеством продуктов и командами. Недостаток поддержки со стороны команды – результат неправильного понимания роли владельца продукта. Хотя он один, большая часть его работы требует коллективного труда. Команда и scrum-мастер должны поддерживать владельца продукта.

Чтобы не перегружать владельца продукта, попробуйте для начала освободить этого человека от всех остальных обязанностей. Ведь он занимается постоянной работой и может отвечать только за один продукт и одну команду. Кроме того, убедитесь, что команда в каждом спринте находит время для сотрудничества с владельцем продукта. Scrum отводит для этого до 10 % действий команды (Schwaber, 2007). Такое сотрудничество не только позволяет более равномерно распределить бремя нагрузки, но и дает возможность использовать коллективное мышление и творческий импульс всей команды.

Частичный владелец продукта

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

Нужно не расщеплять роль владельца продукта, а правильно ее использовать. За тактические и стратегические вопросы управления продуктом должен отвечать один человек. Это может потребовать перемен в организации – например, адаптации служебных обязанностей и путей карьерного роста, увеличения спектра обязанностей отдельных сотрудников, о чем пойдет речь в главе 6.

Удаленный владелец продукта

Удаленный владелец продукта работает отдельно от команды. Слово «удаленный», возможно, вызывает представление, что владелец продукта находится на одном континенте, а команда – на другом. На самом деле удаленность имеет самые разные формы и степени. Так называют и ситуации, когда владелец продукта работает с командой в одном здании, но в разных помещениях, и случаи, когда они находятся на разных континентах и в различных часовых поясах (Simons, 2004). Проблемы, связанные с удаленными владельцами, повсюду одинаковы: недостаток доверия, недопонимание, отсутствие единства и медленный темп работы. И причина понятна: «Самый экономичный и эффективный способ передачи информации команде разработчиков – это личная беседа» (Beck et al., 2001).

Избегайте удаленных владельцев продукта, размещайте всех членов scrum-команды рядом. Как уже говорилось, компания mobile.de резко повысила производительность и боевой настрой, когда владелец продукта, scrum-мастер и команда стали работать в одном помещении. Если это невозможно, то владелец продукта должен проводить как можно больше времени в том же помещении, что и остальная scrum-команда. Удаленным владельцам продукта нужно присутствовать хотя бы при планировании спринтов, на обзорных и ретроспективных совещаниях. Переход от удаленного к присутствующему владельцу продукта нередко требует времени. Иногда это связано с приемом на работу и обучением местного владельца продукта. В некоторых случаях требуется даже переосмысление стратегии продукта компании и изменение места его производства.

Заместитель владельца продукта

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

Использование заместителя владельца продукта – это попытка искусственно вылечить системную проблему. Вместо косметического ремонта организациям следует заняться причинами: например, освободить владельца продукта от других обязанностей, объединить его в одном помещении со scrum-мастером и командой или найти нового владельца продукта.

Комитет владельцев продукта

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

Вопросы для самоконтроля

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

Следующие вопросы помогут успешно применить роль владельца продукта.

• Кто представляет клиентов и пользователей в вашей компании?

• Кто определяет и описывает потребности клиентов и функциональность продукта?

• Кто руководит выработкой концепции продукта и действиями по претворению ее в жизнь? Какую роль играют командная работа и совместное принятие решений?

• Что потребуется для внедрения роли владельца продукта в той форме, которая описана в данной главе?

2. Планирование концепции продукта

В начале 1990-х телефонные конференции были настоящим испытанием. Участникам нередко приходилось отворачиваться от стола и кричать в микрофон. Когда люди говорили одновременно, их голосов не было слышно, так что разговор напоминал какой-то гул. Компания Polycom занималась телепрезентациями и решениями по передаче видеокартинки, голоса и контента. Там осознали, что клиентам необходимы телефонные конференции, которые были бы больше похожи на личное общение, без искажений, эха и других помех. Поэтому Polycom запланировала концепцию продукта со следующими свойствами (Lynn and Reilly, 2002; 63):

• Превосходное качество аудио, позволяющее говорить нескольким людям одновременно без ущерба для понимания.

• Простота в использовании, без загадочных кнопок и проводов.

• Привлекательный внешний вид, подходящий для использования в конференц-зале руководства.

В итоге появился продукт под названием SoundStation, который был запущен в 1992 году. Концепция стала важным фактором его успеха. В этой главе рассказывается о методах планирования концепции продукта. Начнем с содержания и свойств эффективной концепции.

Видение продукта

– Скажите, пожалуйста, куда мне отсюда идти?

– Это во многом зависит от того, куда ты хочешь прийти, – ответил Кот.

– Да мне почти все равно, – начала Алиса.

– Тогда все равно, куда идти, – сказал Кот.

Льюис Кэрролл, «Алиса в Стране чудес»[13]

Способность представить себе то, как должен выглядеть новый продукт или его новая версия, необходима для того, чтобы куда-то прийти. Представления о продукте выливаются в видение – набросок будущего продукта[14]. Видение служит объединяющей целью, которая придает энергию и направляет работу людей. В этой цели смысл существования продукта. Как и в примере с Polycom, видение описывает продукт в самом общем виде, указывает суть – информацию, которая считается критичной для разработки и запуска успешного продукта. Демонстрация обновлений продукта клиентам и пользователям на обзорных совещаниях во время спринта и частые и быстрые релизы ПО служат для подтверждения и уточнения концепции. Эффективное видение должно содержать ответы на следующие вопросы:

• Кто будет покупать этот продукт? Кто его целевой клиент? Кто будет использовать продукт? Кто его целевые пользователи?

• Каким потребностям будет отвечать продукт? Какую ценность он создает?

• Какие свойства продукта жизненно необходимы для удовлетворения избранных потребностей, а следовательно, и для успеха продукта? Как приблизительно продукт будет выглядеть и работать? В каких аспектах он станет особенно хорош?

• Как он будет выглядеть на фоне других продуктов, выпущенных конкурентами или самой компанией? Каковы уникальные коммерческие аргументы продукта? Какой станет его цена?

• Как компания будет получать прибыль от продажи продукта? Каковы источники выручки за него и как выглядит бизнес-модель?

• Осуществимо ли производство продукта? Сможет ли компания его разработать и продавать?

Если вы планируете использовать новый продукт как трамплин для изменения бизнес-модели, то эта информация должна быть отражена в концепции продукта.

Возьмем в качестве примера iPod и iTunes компании Apple. Apple проложила дорогу к доминированию на цифровом музыкальном рынке, создав хороший продукт, iPod, и упаковав его в отличную бизнес-модель. Тесная интеграция iPod и iTunes, музыкального онлайн-магазина компании, не только сделала удобной процесс покупки музыки онлайн, но и замкнула покупателей в пространстве своих продуктов. Это позволило Apple изменить правила игры – продавать музыку онлайн по сравнительно низким ценам. Доход компании от музыки невелик, в отличие от огромной прибыли от продажи MP3-плееров.

Видение iPod должно было обязательно предусматривать безболезненную интеграцию с iTunes, а видение iTunes – обращаться к бизнес-модели и дополнительной выручке от продажи iPod.

Желаемые качества видения

Видение должно кратко сообщать о сути будущего продукта и описывать общую цель, которая дает направление для работы, но достаточно неопределенно, чтобы способствовать творчеству.

Общее и объединяющее

Все люди, связанные с разработкой продукта, должны разделять его видение: scrum-команда, руководство, клиенты, пользователи и другие заинтересованные лица. Питер Сенге формулирует это так: «Концепция действительно является общей, когда у нас с вами возникает схожая картина и мы оба хотим, чтобы эта картина возникала у нас обоих, а не у каждого индивидуально» (Senge, 2006; 192). Общее видение порождает единение и заряжает энергией всех, кто вовлечен в процесс разработки. Оно способствует эффективной командной работе и облегчает обучение команды. «Когда люди действительно разделяют одно видение, они связаны друг с другом общими надеждами» (Senge, 2006; 192). Если же у членов команды видение не совпадает, они будут двигаться в разных направлениях, а не к общей цели. Отличный способ добиться общего видения – привлечь к его разработке членов scrum-команды и заинтересованных лиц.

Широкое и мотивирующее

Видение продукта должно в общих чертах описывать мотивирующую цель, которая будет направлять усилия по разработке, но при этом оставит место для творчества, станет вдохновлять людей. Марисса Майер, вице-президент Google по поисковым продуктам и отношениям с пользователями, описывает, как используется продуктовое видение в Google:

Мы подбираем в команду людей, которые действительно очень заинтересованы в предмете. Считаю полезным, что мы по-прежнему отказываемся от детальных спецификаций продукта. Если вы пишете документ объемом 70 страниц, в котором подробно рассказывается, какой продукт вы должны сделать, – вы убиваете творчество. А так, например, инженер приходит и говорит: знаете, вы тут забыли функцию, а я хочу ее добавить. Нельзя изгонять творческое начало из работы. Консенсусный подход, при котором команда сообща вырабатывает концепцию того, что они делают, и оставляет достаточно пространства для творчества каждому члену команды, действительно способен вдохновлять и нередко приводит к наилучшим результатам[15].

Нужно противостоять искушению перегружать продукт деталями или спецификациями. Дополнительная функциональность будет обнаружена и отражена в бэклоге продукта в ходе проекта.

Краткое и приятное

Если говорить о видении продукта, то оно должно быть кратким и сжатым, содержать только информацию, необходимую для его успеха. Например, продукты-блокбастеры, как показало десятилетнее исследование Линна и Рейли, обладали всего шестью атрибутами (Lynn and Reilly, 2002). Таким образом, видение продукта – это не список функций и оно не должно содержать избыточные подробности. Специалист по agile-управлению проектами Джим Хайсмит поясняет: «Как оказалось, описание пятнадцати-двадцати признаков или функций продукта – задача довольно легкая. А вот выбор трех-четырех из них, которые побудили бы человека этот продукт купить, – дело сложное» (Highsmith, 2009; 97). Специалист по разработке продуктов Дональд Райнертсен соглашается: «У большинства успешных продуктов есть четкое и простое ценностное предложение. Покупатели обычно выбирают между конкурирующими продуктами на основе трех-четырех ключевых факторов» (Reinertsen, 1997; 174–175).

Видение продукта обычно считается сжатым, если может пройти лифтовый тест Мура. «Можете вы объяснить, в чем идея вашего продукта, за то время, пока едете в лифте?» (Moore, 2006; 152). Если ответ отрицательный, то видение, вероятно, слишком сложное или запутанное.

Минимально функциональный продукт

Чтобы создать видение продукта, scrum-команда должна заглянуть в будущее и сформулировать то, как, по ее мнению, будет выглядеть и работать будущий продукт. Конечно, для любого человека, не наделенного даром ясновидения, верное предсказание будущего – дело чрезвычайно сложное. В конце концов, единственное, что мы точно знаем о будущем, – это то, что оно неопределенное. Не существует методики исследования рынка, способной выдавать абсолютно достоверные прогнозы. А полностью безопасные инвестиции – это лишь иллюзия. Так, Купер утверждает, что вероятность неудачи для новых продуктов колеблется от 25 до 45 % (Cooper, 2001; 10). В некоторых исследованиях приводятся еще более высокие проценты. Рынки развиваются самым неожиданным образом, реакцию клиентов предсказать трудно, что и иллюстрирует следующая история[16].

Когда в 1999 году компания Expertcity выпустила интерактивную систему технической поддержки, на нее возлагались большие надежды. Исследования рынка показали, что новый продукт будет иметь большой успех. К сожалению, продукт не оправдал ожиданий. Expertcity, однако, отметила, что пользователи стали широко применять одну из функций продукта – возможность поделиться экраном – неожиданным образом. Они начали с ее помощью управлять удаленными компьютерами. Компания тут же внесла изменения в продукт, превратив его в средство удаленного контроля. Модифицированный продукт получил название GoToMyPC. Он стал настолько успешен, что Citrix в 2003 году решила приобрести Expertcity за 225 миллионов долларов. GoToMyPC сейчас является частью пакета Citrix Online. Хотя исходное видение продукта Expertcity и оказалось неверным, способность компании к адаптации помогла ей превратить явный провал в неожиданный успех.

Поскольку наше умение предсказывать будущее ограниченно, ориентируйтесь ради успеха на минимально функциональный продукт, имеющий небольшое количество функций, которые призваны удовлетворить избранные потребности клиентов[17]. Вспомните iPhone, выпущенный в 2007 году. Уникальное восприятие телефона пользователем полностью затмило конкурентов. Так был установлен новый стандарт для смартфонов. Одним из секретов успеха стал узкий набор потребностей клиента, которые были избраны Apple. Компания избежала искушения попытаться разом удовлетворить запросы многих потребителей, постаравшись скопировать все функции, которые предлагались конкурентами. Вместо этого Apple решила по-новому взглянуть на то, как должны выглядеть смартфоны, и сознательно отказалась от некоторых функций. Первый iPhone поступил в продажу без множества функций, которые считались к тому времени стандартом: копирования и вставки, возможности отправлять текстовые сообщения нескольким получателям и набора для разработки ПО. Однако эти ограничения не сказались на общем успехе. Урезание функциональности позволило Apple разработать и выпустить продукт в конкурентоспособное время и дало компании существенное преимущество над соперниками. Основываясь на успехе первой версии iPhone, Apple в 2008 году запустила 3G-модель, расширив возможности телефона как в программном, так и в аппаратном отношении. Она вышла и на новый сегмент рынка, нацелившись на бизнес-клиентов.

Сравните успех iPhone с другим продуктом компании – Apple Newton, вышедшим на рынок в 1993 году после пяти лет разработки. Помните объявления Apple, которые обещали вам полноценный КПК, способный делать самые невероятные вещи – например, распознавать ваш почерк? Когда Newton наконец вышел на рынок, оказалось, что он чересчур громоздкий. Более того: самая важная его функция – распознавание почерка – не работала должным образом. Продукт не оправдал ожиданий, и в 1998 году его выпуск прекратился. Сейчас можно сказать, что планы Apple на Newton были чрезмерно амбициозными. Компания выпустила продукт, который претендовал слишком на многое, и потерпела неудачу.

Создание минимального продукта дает ряд преимуществ. Это отмечают Смит и Райнертсен (Smith and Reinertsen, 1997) и Денн и Клиленд-Хуан (Denne and Cleland-Huang, 2004)[18]. Продукт выходит быстрее, время выхода на рынок сокращается, функциональность добавляется более своевременно. Снижается стоимость разработки продукта и увеличивается скорость возврата инвестиций. Быстрее можно выручить деньги за товар, что ускоряет движение наличности, убыстряются и темпы обучения. Сократив время выхода на рынок, мы имеем возможность чаще воспринимать реакцию рынка и самостоятельно реагировать на нее, а не пытаться ее предугадать. Быстрый выпуск минимально функционального продукта снижает риски. Если продукт оказывается неудачным и его приходится сразу же отзывать с рынка, мы теряем меньше денег. Это позволяет внедрить в стратегию возможность ошибки, таким подходом активно пользуется Google. Марисса Майер из Google объясняет: «Мы понимаем, что многие продукты придется просто выбросить, но помнить будут только значимые продукты, обладающие большим пользовательским потенциалом»[19].

Поскольку будущее неопределенно, концепция должна распространяться только на следующую версию продукта. Даже если долгосрочной мечтой Стива Джобса было доминирование на рынке мобильных телефонов, это определенно не являлось целью первого iPhone. Большие амбиции лучше всего реализовывать пошагово. «Важен только один шаг – следующий» (Gilb, 1988; 97). Как только появляется концепция, она превращается в готовый продукт благодаря использованию пользовательских и клиентских отзывов. Их собирают по результатам демонстрации новых версий продукта на обзорных совещаниях во время спринтов, а также быстрых и частых релизов продукта. Подобный метод работы позволяет scrum-команде сразу же определить, действительно ли они производят нужный продукт. Если же нет, то видение, вероятно, сформировано неверно, так что следует внести коррективы.

Заметьте, что видение продукта может воплощаться более чем в одном релизе. Например, запуску первой версии Google Chrome в декабре 2008 года предшествовало множество непубличных релизов и публичная бета-версия в сентябре 2008 года. Более долгосрочный взгляд на рост продукта можно воплотить в плане развития, о котором говорится ниже.

Простота

Простота облегчает создание удобного в использовании продукта с минимальной функциональностью. Не стоит путать простоту с упрощенностью. Еще Леонардо да Винчи говорил: «Простота – это высшая степень сложности».

Бритва Оккама

Простота как руководящий принцип – это давняя традиция. Еще в XIV веке францисканский монах Уильям Оккам, как считается, заявил, что при выборе между функционально эквивалентными решениями следует отдавать предпочтение более простому (Lidwell, Holden, and Butler, 2003; 142). Эта идея известна как бритва Оккама.

Простота – это не только эстетика продукта. Это концентрация на его сути, когда создается только действительно необходимое и есть возможность быстро и легко изменять и расширять продукт. Простые, но адекватные продукты удобны в использовании – например, Apple или iPod. Основанный на колесе прокрутки и кнопках на нем, iPod прост и минималистичен, но предлагает все необходимые функции. Бек и Эндрес пишут: «Проекты, тяготеющие к простоте, идут на пользу и человечеству, и производительности» (Beck and Andres, 2005; 110).

Чем меньше, тем лучше

Здравый смысл предполагает: для выигрыша в конкурентной борьбе требуется создать лучший и более функциональный продукт. Мы часто полагаем, что чем больше функций у продукта, тем он лучше и привлекательнее для покупателей. Вовсе нет, утверждает 37Signals (37Signals, 2006), создающая удобные в использовании веб-приложения, удостоенные многочисленных призов. Компания при разработке продуктов руководствуется принципом простоты и сосредоточивается на их сути.

Чтобы опередить конкурентов, делайте меньше, чем они… Возьмите свое видение продукта и уменьшите его наполовину… Начните с экономичного умного приложения и дайте ему набрать обороты. На построенном таким образом надежном основании можно делать что угодно.

Джон Маэда, специалист по простоте решений и профессор Массачусетского технологического института, согласен с этими положениями: «Легче всего достичь простоты при помощи обдуманного исключения. Если вы сомневаетесь в функции, исключите ее» (Maeda, 2006; 1). Стиву Джобсу приписывают фразу: «Инновации – это не значит всегда и всему говорить “да”. Это значит говорить “нет” всему, кроме самых важных функций». Agile-манифест разделяет эту точку зрения, называя простоту одним из 12 принципов и определяя ее как «искусство увеличения работы, которую вы не делаете» (Beck et al., 2001). Каждый раз, когда у вас появляется идея новой функции или вы обнаруживаете новое требование, задайте себе вопрос, насколько эта функциональность значима для успеха продукта. Если она не критична – откажитесь от идеи. В результате получается простой и лаконичный продукт, который предлагает только те функции, которые действительно нужны клиенту или пользователю.

Простые пользовательские интерфейсы

Google – компания, которая открыто взяла на вооружение принцип простоты как ключевой при взаимодействии с пользователем. «Google не ставит целью создавать продукты с богатой функциональностью: наши лучшие продукты содержат только те функции, которые нужны людям для достижения своих целей. В идеале даже те продукты, которые требуют большого количества функций и сложного дизайна, должны быть столь же просты, сколь и эффективны… Мы стараемся не просто добавлять новые функции, но и развивать продукты в других направлениях»[20]. Разработка простых пользовательских интерфейсов, по утверждению Лидуэлла, Холдена и Батлера, прекрасно оправдала себя в Google: «В то время как другие интернет-поисковики стремились добавлять на свои сайты рекламные сервисы и применимые для конкретных случаев функции, Google придерживалась своего простого и эффективного дизайна. Результат – самый производительный и удобный в использовании поисковик в сети» (Lidwell, Holden, and Butler, 2003; 143). А Бернар Жирар, автор книги The Google Way (Girard, 2009; 34), считает, что именно благодаря простоте AdWords – рекламная программа Google – стала такой успешной.

Подобно интуитивному Macintosh GUI, благодаря которому продукты Apple выглядят такими дружелюбными и удобными в использовании, дизайн и направленность на пользователя интерфейса AdWords от Google помогли ему победить. Любой рекламодатель сразу же понимает, как разместить объявление…

Потребности покупателя и свойства продукта

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

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

Определив свойства продукта, часто бывает полезно расположить их в порядке приоритетности: свойства, которые удовлетворяют несколько потребностей, важнее и должны иметь более высокий приоритет. Расстановка приоритетов особенно помогает в случае конфликта свойств.

Рассмотрим два свойства – сочетаемость с другим оборудованием и удобство в эксплуатации. Способность взаимодействовать с разнообразными системами и устройствами обычно требует определенного уровня архитектурной сложности. Удобство в эксплуатации, напротив, предполагает использование простой открытой архитектуры. В результате появляется напряжение: владелец продукта, scrum-мастер и команда вынуждены прилагать усилия, чтобы примирить непримиримое и найти наилучшее решение для удовлетворения потребностей покупателя. Алистер Кокберн (Cockburn, 2005; 147) предлагает при расстановке приоритетов для свойств продукта руководствоваться следующими факторами:

• Пожертвовать остальными ради этого.

• Попытаться сохранить.

• Пожертвовать этим ради остального.

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

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

Рождение видения продукта

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

Любимые проекты

В таких компаниях, как Google, разработчикам разрешается тратить до 20 % времени на «любимые проекты». Это проекты, связанные с частными исследованиями, которые приводят к новым идеям, реализуемым в прототипах. Результаты оправдывают вложения Google: большая часть всех продуктов, выпущенных за вторую половину 2005 года, начиналась как «любимый проект» (Mayer, 2006). Разработчики, выдвинувшие исходную идею, продолжают работать над проектом претворения ее в жизнь, как это было в случае с браузером Google Chrome. Бен Гуджер и Дарин Фишер, два инженера, предложивших прототип, сыграли важную роль в проекте разработки Chrome (Levy, 2008)[21]. Кен Швабер (Schwaber, 2007; 80) приводит такие аргументы в пользу этого подхода к развитию новых идей:

Я рекомендую отвести часть времени каждого сотрудника на деятельность, не имеющую отношения к scrum-командам, в которых он состоит на данный момент, но идущую на благо предприятия. Я советую использовать на это примерно 20 % их времени. Пусть они соединяются в группы по интересам и работают вместе. Какое-то время займет работа с коллегами по поддержанию и расширению функциональных знаний, а какое-то – поиск и разработка прототипов новых идей. Так были разработаны желтые клейкие стикеры в 3M и почта Gmail в Google.

Использование scrum

Если для разработки концепции необходимы более серьезные усилия, используйте для этого Scrum. Попросите владельца продукта, scrum-мастера и команду провести мероприятия по выработке продуктового видения, возглавлять которые должен владелец продукта. Сначала в бэклоге продукта будет фигурировать самое общее видение итогового продукта – например, «Доступны прототипы, исследующие варианты дизайна пользовательского интерфейса» или «Проводятся собеседования с клиентами». В процессе работы в бэклоге продукта появляются высокоуровневые свойства, описывающие будущий продукт в соответствии с продуктовым видением. Каждый визионерский спринт будет порождать обновление – шаг навстречу видению продукта, что в итоге вырастет в итоговый продукт. (Если понадобится только один визионерский спринт, то концепция продукта создается по его результатам.) Например, Supermassive Games – британская студия по разработке компьютерных игр – использует визионерские спринты для организации работы на раннем этапе, который часто именуется «предпроизводством». Команда создает наброски и прототипы для дальнейших итераций на пути к общей концепции компьютерной игры. Прототипы могут быть как моделями Lego и набросками на бумаге, так и действующими программами[22].

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

Техники формирования видения

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

Прототипирование и макетирование

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

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

Планирование, выполнение, проверка и воздействие

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

«Если я обнаружил десять тысяч методов, которые не работают, это не ошибка. Я не обескуражен, потому что исключение каждого неверного метода – это шаг вперед».

Персоны и сценарии

Персоны помогают нам выбрать целевых потребителей. Сценарии позволяют понять, как продукт изменяет их жизнь (Cooper, 1999). Персона – это «гипотетический архетип», представляющий целевого клиента или пользователя. Можно считать персону частным случаем носителя пользовательского сценария или пользовательской роли. В их описания включается информация, важная для использования продукта потребителями: например, должностные обязанности, навыки или интересы пользователя.

Сформировав корректно персоны, мы можем исследовать то, как продукт, который мы собираемся разрабатывать, будет влиять на их жизнь. Для этого создаем сценарии, которые описывают, как персона достигает своих целей без продукта и с ним. Формальный способ создания таких сценариев – составление карты потребления: одна ее часть описывает деятельность, необходимую для достижения конкретной цели без нашего продукта, другая – деятельность, которая потребуется в будущем, когда продукт будет доступен (Womack and Jones, 2005). Использование сценариев и карт потребления позволяет установить ценностное предложение продукта: необходимы ли выбранные свойства? Создают ли они преимущества для всех персон? Можно ли определить более важные свойства продукта?

Визуализация и обзор в отраслевом журнале

Два эффективных метода определения ценностных и коммерческих аргументов продукта – это его визуализация и обзор в отраслевом журнале. Визуализация – это макет упаковки, в которой может поставляться продукт. Для создания визуализации scrum-команда придумывает название продукта, его графическое отображение и три важнейших коммерческих аргумента, при помощи которых продукт будет продаваться. Информация размещается на передней части упаковки. На оборотной части можно указать дополнительные подробности (Highsmith, 2009; 96–97). Чтобы написать обзор в отраслевом журнале, члены scrum-команды выясняют, что бы они хотели прочитать о продукте после его запуска (Cohn, 2009; 232). Это упражнение сделать быстро и легко. Его также можно использовать для проверки того, все ли одинаково понимают и разделяют концепцию продукта.

Модель Кано

Модель Кано помогает выбрать нужную функциональность для создания привлекательного продукта (Kano, 1984). Она рассказывает, насколько может быть удовлетворен покупатель при внедрении определенного свойства продукта. В модели разграничиваются три типа функций: основные, производительные и привлекательные. Рассмотрим работу модели Кано на примере мобильного телефона. Основные функции мобильного телефона – это его включение и выключение, совершение и прием звонков, создание, отправка, получение и чтение текстовых сообщений. Эти рудиментарные функции необходимы, чтобы продать продукт, но удовлетворенность покупателя ими быстро исчерпывается. Например, если добавить еще одну кнопку для включения и выключения телефона, это не создаст никакой дополнительной ценности. Невозможность обеспечить основные функции обычно делает продукт бесполезным. Производительные функции, как правило, приводят к прогрессивному повышению удовлетворения. Они следуют принципу «чем больше, тем лучше». Например, чем легче телефон и чем быстрее он включается, тем более удовлетворенными, вероятнее всего, будут клиенты. Они не могут насытиться требованиями производительности. Однако производительных функций недостаточно, чтобы продукт существенно отличался от всего остального на рынке. Привлекательные функции, как свидетельствует название, призваны привлекать и восхищать покупателей. Интересный дизайн продукта и способность индивидуализировать телефон – это примеры привлекательных функций. Они могут удовлетворять скрытые потребности клиентов, о которых те могли и не догадываться. Именно эти функции продукта создают конкурентное преимущество и уникальное коммерческое предложение.

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

Формирование видения и дорожная карта продукта

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

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

Составьте дорожную карту сразу после того, как продукт был успешно представлен на рынке. (Появление пятилетнего плана прежде, чем вышел релиз продукта, имеет мало смысла. Такой план скорее отражает мечту, чем предсказывает реальность.) В составлении должны принимать участие все важные для продукта лица. К ним относятся scrum-команда, ответственный за продуктовый портфель, представители команд разработки других продуктов и заинтересованные лица. Убедитесь, что дорожная карта продукта имеет реалистичные сроки. В зависимости от рынка и стадии жизненного цикла продукта ограничьтесь 6–12 месяцами и не пытайтесь делать прогнозы на следующие два-три года.

Минимальные продукты и варианты продукта

В процессе взросления продукт начинает отвечать все большему числу потребностей покупателей: обслуживает потребителей в разных сегментах и регионах. Поскольку запросы становятся многочисленнее и разнообразнее, усложняется выпуск обновлений продукта с минимальной функциональностью. Требуется все больше функций для поддержки постоянно растущего количества клиентов и пользователей. Чтобы решить проблему, мы применяем варианты продукта. Каждый вариант адресован конкретной группе пользователей и сегменту рынка. Приведем в качестве примера популярную программу Visio для создания диаграмм. Версия 2007 года доступна в двух вариантах: Office Visio Standard 2007 и Office Visio Professional 2007. Первый позиционируется как «базовое средство визуализации», а профессиональная версия является расширением Visio Standard 2007 и призвана «помочь бизнес- и IT-пользователям визуализировать, анализировать и представлять комплексную информацию, сложные системы и процессы». Эти два варианта обслуживают различные сегменты рынка – домашних и коммерческих пользователей с ограниченной потребностью в диаграммах и профессиональных пользователей, нуждающихся в дополнительной диаграммной функциональности.

Хотя варианты продукта могут стать могущественными союзниками, слишком большое их количество ведет к разбуханию продуктового портфеля, высокой стоимости поддержки и перегруженности клиентов. Представьте себе, что было бы, если бы Microsoft предлагала четыре версии Office Visio 2007: Essentials, Standard, Professional и Deluxe. Потребители затруднились бы с выбором, и им было бы непросто принять решение о покупке[23].

Есть и еще один недостаток: варианты продукта опасны тем, что функциональность придется внедрять снова и снова, что приведет к высоким издержкам на разработку и техническую поддержку. Решить эту проблему может создание набора шаблонов, общих для всех вариантов. Эти шаблоны называются платформой. Например, Apple использует общие компоненты для iPhone и iPod touch. Однако, осознав необходимость введения общих компонентов, не следует попадаться в ловушку – надеяться на создание идеальной мегаплатформы. Начинайте с малого. Платформа должна расти естественным путем по мере увеличения необходимости в вариантах продукта. Тщательно сохраняйте ее функциональность. Этот подход, возможно, приведет к рефакторингу архитектуры, но он исключает опасность чрезмерного усложнения платформы.

Распространенные ошибки

Выработка продуктового видения – это необходимый шаг в подготовке его к запуску. Берегитесь следующих распространенных ошибок: отсутствия видения, пророческого видения, аналитического паралича, а также девизов «мы-лучше-знаем-что-нужно-клиентам» и «большое – значит хорошее».

Отсутствие видения

Очевидная, но, увы, распространенная ошибка – начать разработку продукта без какого-либо видения. Это чаще всего бывает, когда клиенты требуют внедрения в продукт отдельных функций, не понимая необходимости связи между ними. Получающийся при этом продукт носит название функциональной сборной солянки (DeMarco et al., 2008; 143–145). Избегайте этого: убедитесь, что вы имеете концепцию, четко указывающую на клиента, его избранные потребности и важнейшие свойства продукта. Эта концепция затем позволит определить, какие функции следует внедрить, и поможет создать полезный и ценный продукт.

Пророческое видение

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

Аналитический паралич

Как уже говорилось, не стоит увлекаться предварительным исследованием рынка, иначе вы можете попасть в ловушку аналитического паралича, когда приходится проводить все новые и новые изыскания, причем без всякого прогресса. Чрезмерное исследование рынка грозит не только потерей времени и денег, но и тем, что вы не предъявите привлекательный продукт вовремя. Понимание рынка и забота о клиентах очень важны, но ориентация только на клиентов, без собственного понимания того, как должен выглядеть и работать продукт, вряд ли приведет к успеху.

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

«Мы-лучше-знаем-что-нужно-клиентам»

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

«Большое – значит хорошее»

Создание продуктов с огромным количеством функций может, как отмечают Престон Смит и Дональд Райнертсен, создать большую шумиху вокруг вашей компании (Smith and Reinertsen, 1998; 67):

Всем нам нравятся истории успеха разработки, достигнутого героическими стараниями. Команда разработчиков берется за, казалось бы, невозможный проект и прилагает сверхчеловеческие усилия… Эти проекты похожи на длинные передачи, приводящие к тачдауну[24] и сводящие с ума болельщиков. Они гораздо интереснее, чем обычная игра, в которой за один раз не проходишь и 10 метров.

Но какими бы увлекательными ни были огромные проекты, есть у них и недостатки: на них уходит масса денег и времени, при этом очень велик риск провала. «Компании часто совершают ошибку – пытаются найти идеальное решение, которое с первого же дня всех устроит. Часто это выливается в создание слишком сложных дорогих продуктов, которые не очень хорошо функционируют» (Anthony et al., 2008; 125). При этом в больших проектах очень сложно развивать продукт на основании отзывов клиентов и пользователей, поскольку многие функции предопределены.

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

Вопросы для самоконтроля

Убедитесь, что вся scrum-команда разделяет видение будущего продукта. Это видение должно быть умеренным и ориентированным на ближайшую версию продукта. Думайте о большом, но начинайте с малого. Проверьте свое видение, приглашая на обзорные совещания во время спринтов потребителей и клиентов и быстро выпуская обновления продукта. Затем развивайте продукт на основе клиентских отзывов.

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

• Преследуют ли ваши продукты общие цели?

• Как вырабатываются цели и кто их формулирует?

• Как выработать концепцию, обладающую описанными в этой главе качествами?

• Как такая концепция обогатит вашу инновационную деятельность?

3. Работа с бэклогом продукта

Немногие элементы Scrum могут похвастаться такой популярностью, как бэклог продукта. И на то есть причины. Бэклог продукта хорош своей простотой: это всего лишь сформированный по приоритетности список пока не выполненных дел, необходимых для создания продукта.

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

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

Глубинные свойства бэклога продукта

Элементы бэклога продукта обладают четырьмя свойствами: имеют достаточную степень детализации, оценены, независимы и приоритизированы – в английском языке получается удобная аббревиатура DEEP (от detailed, estimated, emergent, prioritized) – глубинный[25]. Рассмотрим эти свойства подробнее.

Достаточная степень детализации

Элементы бэклога продукта имеют достаточную степень детализации, это показано на рисунке 3.1. Элементы с более высоким приоритетом описаны подробнее, чем менее важные. «Чем ниже приоритет, тем меньше деталей, вплоть до полного минимума», – пишут Швабер и Бидл (Schwaber and Beedle, 2002; 33). Следуя этому правилу, вы сохраняете бэклог продукта минималистичным, а его элементы – реализуемыми в течение спринта. В результате требования выявляются, декомпозируются и детализируются в течение всего проекта.


Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Рисунок 3.1. Степень приоритетности элемента бэклога продукта определяет уровень его детализации


Оценка

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

Развитие

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

Приоритетность

Все элементы бэклога продукта расположены по приоритетности. Самые важные внедряются в первую очередь. Они находятся в верхней части бэклога продукта, как показано на рисунке 3.1. После завершения работы над элементом он удаляется из бэклога.

Работа над бэклогом продукта

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

• Выявляются и описываются новые элементы, а существующие при необходимости изменяются или удаляются.

• Происходит расстановка приоритетов. Самые важные задачи помещаются в верхнюю часть.

• Высокоприоритетные элементы подготавливаются к ближайшему совещанию по планированию спринта. Они декомпозируются и детализируются.

• Команда определяет масштаб элементов бэклога продукта. Это необходимо ввиду внесения в него новых элементов, изменения существующих и исправления оценок.

Хотя владелец продукта отвечает за хорошее состояние бэклога продукта, работа над ним – это командный процесс. Выявляются и описываются элементы, они выстраиваются по приоритету, декомпозируются и детализируются всей scrum-командой. В Scrum выделяется на эту деятельность до 10 % командного времени (Schwaber, 2007). При необходимости в процесс вовлекаются и заинтересованные лица. Требования больше не спускаются команде сверху, в их формулировании принимают участие все члены команды. Владелец продукта, scrum-мастер и команда общаются не через документацию, а лично.

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

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

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

Ниже подробно рассмотрим четыре этапа работы с бэклогом продукта, начав с выявления и описания его элементов.

Выявление и описание элементов

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

Выявление элементов

Выявление элементов бэклога продукта начинается с его создания. Лучше всего это делается совместными усилиями: члены scrum-команды и при необходимости заинтересованные лица в ходе мозгового штурма выявляют элементы, нужные для создания продукта, используя в качестве точки отсчета его идею, его видение или дорожную карту. При этом не пытайтесь думать обо всех элементах сразу. Каждый раз, когда вы работаете с бэклогом, сосредоточивайтесь на минимальной функциональности, необходимой для выхода продукта на рынок, и придерживайтесь принципа простоты, который обсуждался в главе 2. В ходе проекта появятся новые идеи, и бэклог продукта будет развиваться в соответствии с отзывами клиентов и пользователей. Если в самом начале бэклог продукта станет слишком длинным и сложным, будет трудно сосредоточиться и правильно расставить приоритеты. Используйте идею или видение продукта, чтобы направлять свои усилия. Сконцентрируйтесь на главном и отложите в сторону остальное. Нужно противостоять искушению слишком быстро добавлять новые подробности. Элементы перечня описываются с течением времени в соответствии с их приоритетностью. Низкоприоритетные элементы остаются неделимыми и обобщенными, пока их приоритет не изменится (либо они станут более срочными, либо основные задачи будут уже выполнены). Нефункциональные требования, которые относятся к свойствам всего продукта, служат исключением из этого правила. Как вы узнаете из этой главы, они должны быть подробно описаны с самого начала.

Как только первичный бэклог продукта составлен, появляется масса возможностей для выявления новых элементов. Это и груминг-сессии, когда scrum-команда расставляет приоритеты и декомпозирует элементы бэклога продукта, и обзорные совещания по спринтам, где заинтересованные лица сообщают свои отзывы, и комментарии пользователей и клиентов по выходящим обновлениям продукта.

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

Описание элементов

Scrum не предписывает методов описания элементов бэклога продукта, но я предпочитаю работать с пользовательскими историями (Cohn, 2004). Как можно догадаться по названию, это история о том, как клиент или пользователь работают с продуктом. Она содержит имя, краткую информацию и критерии приемки – условия, которые позволяют понять, реализована история или нет. История может быть обобщенной или подробной. Обобщенные истории называются эпиками. Писать, декомпозировать и детализировать пользовательские истории несложно. Конечно, для описания требований можно применять любой другой метод. А если вы предпочитаете пользовательские истории, то необязательно описывать все элементы бэклога продукта. Например, требования по удобству пользователя рекомендуется отображать в виде прототипов или набросков.

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

Структурирование бэклога продукта

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


Таблица 3.1. Образец бэклога продукта

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

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

Расстановка приоритетов в бэклоге продукта

Никогда не забуду тот день, когда я предложил менеджеру продукта в области здравоохранения расставить приоритеты в отношении лежащих перед ней вариантов использования. Она посмотрела на меня с удивлением и ответила: «Я не могу. Они все очень важные».

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

Расстановка приоритетов направляет работу команды, сосредоточивая ее на самых важных элементах. Она также поддерживает на одном уровне содержание бэклога продукта. Как уже говорилось, элементы конкретизируются в зависимости от их приоритета. Это вносит гибкость в процесс и позволяет откладывать на потом решения по низкоприоритетным элементам, что дает scrum-команде больше времени на оценку вариантов, сбор отзывов от клиентов и получение нового знания. В итоге это приводит к наилучшим решениям и более качественному продукту[26].

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

Ценность

Ценность – это довольно обычный фактор при расстановке приоритетов. Разумеется, в первую очередь мы хотим реализовать самые ценные элементы бэклога продукта. Но что делает элемент бэклога ценным? Ответ прост – его важность для выхода продукта. Если это не так, то элемент не имеет значения и его можно исключить из текущего релиза или версии продукта. Scrum-команда либо лишает такой элемент приоритетности и помещает его в самый низ бэклога, либо отказывается от него. Если элемент важен для какой-то из будущих версий, то он появится вновь.

Прежде чем включить элемент в релиз, нужно понять, не будет ли продукт и без данного элемента приносить те же преимущества. Это помогает создать простой продукт с минимальной функциональностью, как описано в главе 2. Apple, например, выпускала iPhone первого и второго поколения без возможности копирования и вставки, что не повредило успеху гаджета. Если элемент действительно нужен, подумайте, нет ли альтернативы, которая приносит те же выгоды, но требует меньше усилий, времени или денег. Команды, к сожалению, часто сдерживают какие-то неявные ограничения, поэтому они не всегда способны оценить все варианты.

Тщательно нужно проверять не только новые требования. Постоянно пересматривайте и уже существующие. По мере того как scrum-команда осознает потребности клиента, часто возникают более интересные альтернативы и вырабатываются решения. Упрощайте, сокращайте и стремитесь к порядку, как садовник, выпалывающий сорняки и подрезающий кустарник.

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

Знания, неопределенность и риск

«Риск – сущностная характеристика инновационного продукта. Каждое решение, касающееся проекта (принимается оно явно или по умолчанию), связано с рисками», – пишут Смит и Мерритт (Smith and Merritt, 2002; 4). Таким образом, риск – неотъемлемая часть разработки ПО. Ни один продукт без риска просто не выпустить. С риском связана неопределенность, и чем она выше, тем рискованнее проект. Неопределенность же, в свою очередь, связана с недостатком знаний. Чем меньше мы знаем о том, что нужно разрабатывать и как это делать, тем больше неопределенность. Таким образом, знания, неопределенность и риск взаимосвязаны.

Поскольку риск и неопределенность влияют на успех продукта, неопределенные и рискованные элементы должны быть наделены высоким приоритетом. Это ускоряет процесс получения нового знания, устраняет неопределенность и снижает риск. Если, например, scrum-команда не уверена в некоторых аспектах дизайна пользовательского интерфейса, то соответствующие варианты нужно побыстрее изучить и проверить, собрав отзывы клиентов и пользователей. Если команда не знает, какой уровень доступа к данным для третьей стороны применить, нужно ввести требования, запускающие транзакции базы данных, чтобы можно было оценить различные варианты. Риск может содержаться и в инфраструктуре, и в среде – например, не до конца настроенном процессе разработки или в том, что члены scrum-команды не сидят в одном помещении.

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

Возможность выпуска

Быстрые и частые релизы – отличный способ превратить ваше ПО в продукт, любимый покупателями, о чем будет говориться в главе 4.

Кроме того, это хороший способ уменьшить риски. Если scrum-команда сомневается, стоит ли внедрять функцию и как именно это делать, ранние релизы помогут ответить на этот вопрос, как в упоминавшемся случае с Google News.

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

Взаимозависимости

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

Объединение нескольких зависящих друг от друга элементов бэклога продукта в один более крупный и переформулирование для устранения зависимости – вот два основных метода работы с взаимозависимыми пользовательскими историями (Cohn, 2004; 17). Рассмотрим в качестве примера две истории: «Я как пользователь хочу написать текстовое сообщение» и «Я как пользователь хочу написать электронное письмо». Они зависят друг от друга, поскольку обе связаны с обработкой текста. Если сначала внедрить текстовые сообщения, это сократит усилия на работу с электронными письмами, и наоборот. Первый вариант – соединить их в более крупную пользовательскую историю – не очень подходит нам, поскольку история получается слишком сложной. Второй вариант – разбить требования по-иному. Если общая функциональность выделяется в отдельную историю – «Я как пользователь хочу вводить текст», то две исходные истории больше не зависят друг от друга. Таким образом, их оценка больше не связана с порядком работы над ними.

Подготовка к планированию спринта

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

Выбор цели спринта

Цель спринта формулирует его желаемый результат. Он должен подвести scrum-команду на шаг ближе к запуску успешного продукта. Один владелец продукта выбрал для первого спринта следующую цель: «У высоких деревьев глубокие корни». Эта фраза отлично описывала цель спринта – закладку основания для всего последующего проекта. Хорошая цель спринта обширна, но реалистична. Она должна оставлять команде пространство для маневра и не предполагать непременную реализацию всех главных элементов бэклога продукта. Как и в случае с бэклогом, вся команда должна принимать участие в формулировке цели. Это обеспечит ясность задач и мотивацию. Установить цель спринта важно по нескольким причинам.

• Она порождает единение между владельцем продукта, scrum-мастером и командой: все движутся к единой цели.

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

• С ее помощью проще объяснить заинтересованным лицам, над чем работает команда.

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

Когда нужно и ровно столько, сколько нужно

Как только избрана цель спринта, нужно подготовить ровно столько элементов для будущего спринта, сколько нужно и когда нужно[27]. (Крупные проекты, при работе над которыми необходимо заглядывать далеко вперед, описаны ниже в этой же главе.) Работа с бэклогом продукта во время первого спринта строится вокруг элементов для второго спринта, во время второго спринта – вокруг элементов для третьего и т. д. У такого подхода есть ряд преимуществ: сводятся к минимуму траты времени и денег на описание элементов, а также снижается количество элементов, нуждающихся в подробном описании. Избыточное количество информации – это пустая трата сил. Подробно описывая лишь те элементы, которые, вероятнее всего, понадобятся для следующего спринта, мы даем бэклогу продукта возможность развиваться.

Подготовка элементов для совещания по планированию спринта требует декомпозиции более крупных элементов бэклога продукта. Они должны стать достаточно малы для спринта, и их необходимо довести до совершенства, чтобы они были понятными, исполнимыми и контролируемыми. Этот процесс показан на рисунке 3.2. Реализация декомпозированного элемента может занять несколько спринтов. Об этом речь пойдет ниже.


Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Рисунок 3.2. Расширение и улучшение компонентов бэклога продукта


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

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

Декомпозиция элементов

Декомпозиция элементов бэклога продукта – это постепенное их уменьшение до степени готовности для спринта. Такой процесс, известный также как последовательная декомпозиция элементов (Reinertsen, 1997), может занимать более чем один спринт. Возможно, декомпозицию какого-то элемента придется начать за несколько спринтов до его возможного внедрения, особенно если он большой и сложный. Это позволяет собрать необходимые отзывы клиентов, пользователей и других заинтересованных лиц еще до подробного описания элемента. Рассмотрим, как можно провести последовательную декомпозицию пользовательских историй.

Как показано на рисунке 3.3, scrum-команда изначально вписала в бэклог продукта эпик «Создать электронное письмо». Поскольку это слишком большая и неопределенная задача для одного спринта, эпик разделили на несколько недетализированных пользовательских историй. История «Задать получателя» была затем вновь разбита на две более подробные пользовательские истории. Теперь они достаточно малы для спринта. Эпик – это пример сложной истории, то есть пользовательской истории, имеющей не одну цель (Cohn, 2004; 24–25). Для декомпозиции подобной истории вводим отдельную историю для каждой цели. Таким образом, «Создать электронное письмо» разделяется на «Задать тему», «Задать получателя» и «Задать важность».


Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Рисунок 3.3. Декомпозиция пользовательских историй


Затем нужно подвергнуть декомпозиции и другие пользовательские истории, в том числе сложные и имеющие слишком много критериев. Обычно сложная пользовательская история слишком велика для разработки за один спринт из-за внутренней неопределенности или слишком большой функциональности (Cohn, 2004; 25–26). Если она чересчур туманна, мы вводим в бэклог продукта один или несколько элементов, исследующих эту неопределенность и порождающих соответствующие знания, например: «Исследовать JavaServer Faces как технологию пользовательского интерфейса». Если история описывает слишком много функций, то мы разбиваем ее на несколько, чтобы впоследствии пошагово добавлять функциональность. Эта техника известна как разрезание торта (Cohn, 2004; 76). Например, пользовательскую историю «Проверка пользователя» можно разложить на «Проверку имени пользователя» и «Проверку пароля».

Иногда кажется, что с историями все в порядке, но только до определения критериев приемлемости. Если их более десяти или если требования скрываются в самих критериях, то нужно переработать историю и подвергнуть ее декомпозиции. Вот пример: «Я как пользователь хочу удалить текстовое сообщение». Критерии приемлемости таковы: «Я могу выбрать любое текстовое сообщение. Я могу удалить текст сообщения. Я могу сохранить измененное сообщение». Во-первых, второе условие избыточно, а во-вторых, два других вводят новые требования, а не указывают критерии приемлемости. Такую историю нужно разбить на три части – историю об удалении текстовых сообщений, о правке текстовых сообщений и о сохранении измененных сообщений.

Обеспечение четкости, проверяемости и осуществимости

Когда элемент доведен до достаточно малого размера, следует убедиться в его четкости, проверяемости и осуществимости[28]. Требование считается четким, если все члены scrum-команды одинаково понимают его смысл. Совместное описание требований и выражение элементов бэклога продукта в простой и сжатой форме облегчают достижение четкости. Элемент называют проверяемым, если существует эффективный способ определить удовлетворенность реализацией требования в течение спринта. У истории должны быть критерии приемки, которые определяют ее проверяемость. Элемент является осуществимым, если он может быть внедрен за один спринт в соответствии с критериями приемки, принятыми в команде. (О стандартах осуществления говорится в главе 5.) Для обеспечения осуществимости мы оцениваем зависимость от других элементов, в том числе функциональных и нефункциональных требований. Если история ограничена, например, требованием пользовательского интерфейса, то должно быть ясно, каким будет получающееся обновление продукта. В противном случае команда должна перед реализацией пользовательской истории исследовать требование пользовательского интерфейса. Если это требует больших усилий, то исследования должны быть проведены во время отдельного спринта – например, можно создать одноразовый прототип для изучения дизайна пользовательского интерфейса.

Определение масштабов элементов

Оценка элементов бэклога продукта позволяет нам примерно понять их сложность и трудоемкость. Это полезно по двум причинам – облегчает расстановку приоритетов и позволяет отслеживать и прогнозировать ход проекта. В Scrum используются два различных типа оценок: приблизительные – в бэклоге продукта, указывающие на примерный масштаб элемента, – и более точные оценки в спринт-бэклоге, сообщающие размер задач, на которые разбит элемент бэклога, обычно выраженный в рабочих часах. В этом разделе рассказывается об определении масштабов элементов бэклога продукта. Они оцениваются, если выявляются новые или модифицируются старые элементы либо изменяется командное понимание размеров элемента. Поэтому необходимо средство измерения, быстрое и удобное в использовании. Я предпочитаю очки историй[29].

Очки историй

Очки за пользовательскую историю – это приблизительные, относительные единицы измерения сложности и трудоемкости[30]. Элемент, который стоит одно очко за пользовательскую историю, равен половине элемента, стоящего два очка. Элемент, оценивающийся в три очка, требует столько же усилий, как одноочковый и двухочковый, вместе взятые. Относительные измерения пользуются тем фактом, что размер сам по себе относителен, значения большого и малого зависят от точки отсчета. Так, компьютерная мышь невелика по сравнению с ноутбуком, но большая, если ее сравнить со слотом памяти. Распространенный спектр очков за пользовательскую историю приведен в таблице 3.2.


Таблица 3.2. Распространенный спектр очков за пользовательскую историю

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Нелинейная последовательность из таблицы 3.2 ускоряет процесс принятия решений командой. Она предотвращает продолжительные дискуссии об «истинной ценности», которые могут возникнуть при использовании линейных последовательностей.

Команда может продолжить спектр, представленный в таблице 3.2, добавив более крупные значения – 40 и 100, если сопоставление сравнительных оценок остается верным. Однако какой бы спектр значений ни был бы избран, последовательность должна быть удобной для команды и оставаться неизменной. Поскольку очки историй – критерий относительный и произвольный, нельзя сравнивать их у разных команд, если только они не договорились об общем спектре очков с общей семантикой.

Покерное планирование

Очки историй – хороший, но недостаточный инструмент. Нам нужен метод эффективной командной оценки, и он существует – это покерное планирование (Cohn, 2005; 56–59). В покерном планировании каждому члену команды выдается колода карточек, которая содержит определенное количество очков. Если мы используем, например, спектр из таблицы 3.2, то в колоде будет восемь карточек, каждая из которых имеет одно из значений спектра. Оценка начинается сразу после того, как участникам будут розданы все карточки.

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

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

Оценка нефункциональных требований

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

Чтобы добиться точных оценок, требуется три фактора: команда должна понимать, что нужно для внедрения элемента, ее члены – уметь выявлять взаимозависимости этого элемента с другими, а критерии готовности должны быть доступными. Если команда не может оценить элемент, необходимо добавить в бэклог продукта новый элемент, который создаст требуемое знание, например: «Создание прототипа или макета для исследования вариантов дизайна пользовательского интерфейса».

Только члены команды, занимающиеся реализацией инкремента продукта, должны оценивать элементы бэклога. Владелец продукта и scrum-мастер не принимают участия в оценке и не влияют на ее результаты (если они не являются одновременно рядовыми сотрудниками команды или если команда не обращается к ним за советом). Однако владелец продукта должен присутствовать на совещании. Многие элементы бэклога продукта будут выглядеть довольно приблизительно, так что владельцу продукта потребуется их объяснить и конкретизировать.

Экспресс-оценка

Если команда слишком ограничена во времени для покерного планирования, можно использовать следующий метод оценки. Разделите одну стену конференц-зала на несколько частей, каждая из которых будет отражать одно из значений спектра очков за пользовательскую историю. Распечатайте на бумажных карточках элементы бэклога продукта и положите их на стол. Пусть все члены команды возьмут по карточке, примут решение об оценке и прикрепят карточку на ту часть стены, которая соответствует избранному ими значению. При этом элемент должен соответствовать по размеру другим элементам той же группы. Если кто-то видит неподходящую карточку, он сразу перемещает ее в нужную группу. Этот процесс дает возможность очень быстро и с минимальными усилиями оценить многие элементы. Основной недостаток состоит в том, что команда не обсуждает размер элементов. Поэтому качество оценки обычно ниже по сравнению с результатами покерного планирования.

Работа с нефункциональными требованиями

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

Описание нефункциональных требований

Нефункциональные требования могут быть выражены как ограничители (Newkirk and Martin, 2001; 16–18). Например, можно описать требование к производительности, как показано на рисунке 3.4.


Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Рисунок 3.4. Нефункциональное требование, сформулированное как ограничитель


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

Управление нефункциональными требованиями

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


Таблица 3.3. Образец бэклога продукта с нефункциональными требованиями

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

В отличие от своих глобальных родственников, локальные нефункциональные требования относятся только к конкретному функциональному требованию – например, требованию к производительности по получению информации. Если нефункциональное требование выражено как ограничитель, просто добавляем этот ограничитель к истории (Newkirk and Martin, 2001) и (Cohn, 2004). Это можно сделать, аннотировав историю ограничителем.

Бэклог продукта при масштабировании

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

Использование единого бэклога продукта

Для работы над каждым большим scrum-проектом нужен один бэклог продукта, содержащий описание всего функционала, необходимого для создания продукта. Избегайте отдельных журналов для каждой команды или компонента, где требования к продукту трансформируются в требования к подсистеме или компоненту. Это приводит к лишнему объему работы, поскольку содержание должно быть выделено из общего потока требований, который должен прорабатываться, а при реализации надо постоянно следить за синхронизацией. Постарайтесь давать всем командам указания из общего бэклога продукта, отдавая при этом предпочтение функциональным командам, о чем говорилось в главе 1. Дэрин Фишер, один из инженеров проекта браузера Chrome, так описывает действия Google по работе с одним бэклогом продукта в рамках большого проекта: «Когда дело дошло до требований, многие процедуры свелись к совещаниям в формате мозгового штурма, где мы обсуждали функционал. У нас в Google была открытая внутренняя рассылка, там люди могли выразить свое мнение по поводу того, как сделать лучше… Мы старались, чтобы элементы бэклога продукта были конкретными и минималистичными. Затем мы предлагали этот список команде, и ее члены сами выбирали, над чем хотят работать»[31].

Расширьте горизонт груминга

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

Создайте различные видения бэклога продукта

Крупные agile-проекты, в которых участвует несколько функциональных команд, могут выиграть от использования разных представлений о бэклоге продукта (Cohn, 2009; 330–331). Каждое представление соотносится с определенным разделом. Если в течение следующих нескольких спринтов функциональная команда работает, например, по теме «органайзер», то видение бэклога для команды ограничивается соответствующим разделом. Это может предотвратить конфликты между несколькими владельцами продукта и командами, использующими один и тот же бэклог.

Распространенные ошибки

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

Замаскированная спецификация

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

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

Список просьб к Санта-Клаусу

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

Навязывание требований

Иногда владелец продукта пишет элементы бэклога продукта в одиночку и затем на совещании по планированию спринта вручает их команде. Такой подход укрепляет разделение на «мы» и «они»: владелец продукта здесь, а команда – там. Это отказ от знаний, опыта и творческого потенциала команды, который усложняет планирование спринта. Владелец продукта должен привлекать к грумингу бэклога продукта коллег по scrum-команде. Назначьте несколько сессий по грумингу бэклога во время спринта, пригласите остальных членов scrum-команды и напоминайте им о необходимости выделять на это время при каждом спринте. Никогда не забывайте девиз сотрудничества, отраженный в agile-манифесте: «Представители бизнеса и разработчики должны каждый день вместе работать над проектом» (Beck et al., 2001).

Пренебрежение грумингом

Большинство совещаний по планированию спринтов очень интересны. За исключением тех, которые основываются на плохо проработанном бэклоге продукта. Когда он не проработан до совещания, владелец продукта и команда нередко пытаются немедленно это исправить и тратят драгоценное время на его груминг, что не спасает от плохо прописанных требований и низкой заинтересованности. Кроме того, к концу совещания все очень устают. Поэтому если не был проведен груминг, то следующий спринт просто не начнется. Его надо отложить, пока бэклог не будет готов.

Конкурирующие бэклоги продуктов

У одного моего клиента с командой работали сразу пять владельцев продукта. Поскольку каждый из них хотел, чтобы все было сделано как можно быстрее, команде приходилось иметь дело со всеми пятью бэклогами во время каждого спринта. Это давало владельцам продукта определенный уровень комфорта: они знали, что над их требованиями идет работа. Но при этом они были крайне разочарованы, ведь проходит масса времени, прежде чем что-то делается! Казалось бы, в одновременной работе над несколькими продуктами нет ничего плохого: все заняты, над всеми требованиями трудятся… Но мгновенно ничего не происходит. Напротив, у команды нет общей цели спринта, а драгоценное время тратится на переключение между задачами. Если вашей команде приходится работать с несколькими бэклогами, сделайте так, чтобы каждый спринт был выстроен вокруг только одного продукта. Лучше всего попросить команду работать над единственным продуктом в течение нескольких спринтов, чтобы она могла быстро выпустить новую версию. Затем можно переходить к следующему. Этот подход требует расставить приоритеты для продуктов и назначить процедуру для управления продуктовым портфелем. В проблеме моего клиента в итоге оказался виноват CEO компании, который хотел, чтобы все было сделано «еще вчера», и не мог назначить приоритеты, которыми могли бы руководствоваться владельцы продукта.

Вопросы для самоконтроля

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

Следующие вопросы помогут вам применить идеи, описанные в этой главе.

• Как у вас на работе выявляются и описываются требования?

• Обладает ли ваш продукт DEEP-характеристиками? Как ведется работа над грумингом бэклога вашего продукта?

• Насколько сложно коллективно выявлять и описывать требования при каждом спринте?

• Как вы работаете с нефункциональными требованиями? Где и как они фиксируются?

4. Планирование релиза

«Планирование… – это поиск ценности», – пишет Майк Кон (Cohn, 2005; 5), а планирование релиза поддерживает разработку и запуск успешного продукта. Оно облегчает диалог между scrum-командой и заинтересованными лицами и отвечает на вопрос, какая функциональность будет включена в ближайший релиз продукта. Планирование релизов происходит в течение всего проекта, поскольку команда прислушивается к отзывам клиентов и пользователей и реагирует на них. Переход от основанного на документах и отчетах планирования к диалогу и беседам позволяет scrum-команде использовать простые методы планирования, отчего планы становятся проще и прозрачнее. Несмотря на то что планирование релиза – это совместный труд, ответственный за принятие всех необходимых решений – владелец продукта.

В этой главе рассказывается об основных идеях и методах планирования релиза. Более подробно они описаны в книге Agile Estimating and Planning (Cohn, 2005).

Время, затраты и функциональность

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

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

Определить дату запуска легче, если есть видение продукта. Оно позволяет установить возможное окно – временной интервал, когда продукт должен быть запущен для получения желаемых выгод. Фиксация этого окна защищает время как самый важный и труднодоступный ресурс. Если пропустить нужную дату, то возможность будет упущена и запуск продукта окажется бессмысленным. Выбор даты запуска на основании работы, записанной в бэклоге продукта, – не лучшая идея, поскольку это заставляет команду заморозить требования и часто приводит к плохой оценке. На деле реальный срок работы, основанный на требованиях, может составлять 60–160 % от примерного. Так, проект, рассчитанный на 20 недель, может занять от 12 до 32 недель (Cohn, 2005; 4). Это хорошо известное соотношение называется «воронка неопределенности»[32]. Определение возможного окна вместо попыток оценить вероятную дату запуска позволяет избежать этих проблем.

Фиксация даты позволяет создать постоянный ритм для инноваций. Это достигается выбором единого временного ограничения для всех релизов. Звучит невероятно? Но именно так поступили в Salesforce.com – ведущем поставщике услуг по управлению связями с заказчиками по запросу. И преуспели. В 2006 году после нескольких лет быстрого роста Salesforce.com оказалась в неприятной ситуации. Способность компании выпускать новые продукты сократилась до одного в год, резко упала и производительность. Чтобы вернуть упущенное, команда внедрила методологию Scrum. Крис Фрай, вице-президент по разработке платформ Salesforce.com, поясняет:

Решение перейти к agile-методам в Salesforce.com выросло из желания быстрее выпускать более предсказуемые релизы. Мы уже год не выпускали ни одного крупного релиза и хотели перейти к более предсказуемому расписанию выхода продуктов, которые будут приносить ценность покупателям на постоянной основе.

После внедрения Scrum Salesforce.com стала следовать строгому ритму инноваций. «Вся организация перешла от двенадцатимесячного цикла к четырехмесячному, выпуская по три крупных релиза в год в соответствии с расписанием, включая разработку программного продукта, технические операции и внутренние IT-системы», – заявляет Стив Грин, вице-президент по управлению программами и гибкой разработке в Salesforce.com[33]. Результаты оказались поразительными. Salesforce.com стала вырабатывать на 97 % больше функций благодаря кратким устойчивым циклам релизов. В то же время компании удалось сократить время на разработку новой функциональности на 61 %. Оценка и планирование стали точнее и эффективнее. Клиенты Salesforce.com могли твердо рассчитывать на следующий релиз. В то же время вырос и моральный дух разработчиков (Greene and Fry, 2008).

Фиксация даты и работа со стабильными scrum-командами существенно упрощают выработку бюджета, если считать оплату труда основным фактором издержек. Когда проект приходится масштабировать, точное предсказание бюджета оказывается сложным делом, особенно при разработке новых программных продуктов. Если бюджет подвергается опасности или превышен, владельцу продукта придется сделать выбор – представить продукт с меньшей функциональностью или повысить его стоимость, подключив к проекту дополнительных сотрудников (если эти новые члены смогут за оставшееся время повысить производительность). Apple, например, решила увеличить затраты и добавила сотрудников к своему первому проекту iPhone, чтобы успеть к дате релиза. При этом не стоит забывать о законе Брукса: «Увеличение числа участников при подготовке опаздывающей программы только замедляет процесс» (Brooks, 1995; 25).

Как насчет контрактов с фиксированной стоимостью?

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

Стабильность качества

Как мы убедились, функциональность продукта развивается. Его точность тоже может возрастать в ходе проекта: улучшаются внешний вид, ощущения и опыт использования. Но качество продукта в Scrum стабильно. Критерии качества зафиксированы в критериях готовности. Такое определение обычно подразумевает, что результат каждого спринта должен быть (потенциально) готов к постановке инкремента продукта: это будет исполняемая программа, проверенная, задокументированная и готовая к релизу. Обеспечение качества и меры контроля образуют неотъемлемую часть любого спринта. Они не проводятся в конце проекта задним числом.

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

Быстрые и частые релизы

«Наш приоритет – удовлетворить покупателя, часто и постоянно выпуская ценные программы», – утверждается в agile-манифесте, а далее приводится рекомендация: «Почаще выпускайте рабочие программы – с интервалом от пары недель до пары месяцев, но предпочтительны более короткие интервалы» (Beck et al., 2001). Быстрый и частый выпуск инкремента продукта для целевых потребителей вместо разового выхода законченного продукта порождает ценные отзывы[34].

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

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

Команда, разрабатывавшая браузер Chrome, сначала планировала не использовать панель закладок. Но отзывы пользователей показали, что некоторые любят переходить именно по этой панели. Поэтому команда выступила с новым решением: если пользователь изначально подбирал закладки в Internet Explorer или Firefox, Chrome импортирует их. В ином случае у пользователей не будет панели закладок, пока они не добавят ее. Не выпустив первых версий браузера, команда не осознала бы важности панели закладок, так что продукт в итоге получился бы не оптимальным.

Частые релизы образуют строительные кирпичики для инновационных возможностей Google, отмечает Бернар Жирар, автор книги The Google Way: «Быстро выводя на рынок даже не до конца готовые продукты, Google извлекает максимум из своих усилий и сводит на нет потенциальную конкуренцию… Стратегия Google, состоящая в быстрых и частых релизах, – это блестящая и изобретательная маркетинговая стратегия: она устраняет потенциальных конкурентов, повышает стоимость выхода на рынок и удерживает пользователей в сфере влияния Google» (Girard, 2009; 86).

Но, как известно, бесплатный сыр бывает только в мышеловке. Частые релизы имеют свою цену: программы должны быть высокого качества и нужно иметь возможность легко получить и установить продукт. Совершенно нормально, когда в ранних релизах лишь частично внедряются некоторые функции. Приемлемо также предлагать функциональность, обеспечивающую клиенту или пользователю лишь ограниченные преимущества. Однако качество программ, которое обозначено в критериях готовности, должно быть высоким для всех инкрементов продукта. Это позволяет команде быстро улучшать продукт во время будущих спринтов и препятствует возникновению ошибок, которые могут навредить репутации продукта. Такие методы, как разработка через тестирование и автоматизация тестов, рефакторинг и непрерывная интеграция, облегчают создание работающих обновлений продукта. Командам понадобится время, чтобы освоить эти техники, а их применение может потребовать изменения инфраструктуры и среды.

Если получить и установить новые версии продукта будет нелегко, то потребители откажутся от обновлений или проигнорируют их. Хотя достичь этого непросто, «любой большой проект можно разбить на серию более мелких и с более ранними сроками поставки. Не сдавайтесь, даже если для этого потребуются новые технические решения. Вас должны интересовать результаты, а не технологии» (Gilb, 1988; 336).

Квартальные циклы

В Scrum не существует правил, которые предписывали бы конкретную длительность проекта. Однако agile-проекты обычно длятся от трех до шести месяцев. Если для вывода продукта на рынок требуется более трех-четырех месяцев, используйте квартальные циклы, выпуская ежеквартально как минимум одну версию работающей, протестированной и задокументированной программы (Beck and Andres, 2005; 47–48). Google пользовалась этой методикой в течение тех двух лет, которые ушли на разработку первой версии браузера Chrome. Дэрин Фишер так описывает процесс: «Мы ориентировались на квартальные циклы, так что живой документ [бэклог продукта] пересматривался каждый квартал. Например, в этом квартале мы работаем с таким набором функций, в следующем – с другим и т. д. Это было полезным средством продвижения вперед, к тому же продукт мог применяться кем угодно в Google на самых ранних стадиях, так что мы непрерывно получали отзывы»[35]. Еще одна компания, систематически пользующаяся квартальными циклами, – это PatientKeeper, выпускающая продукты для сферы здравоохранения. Новая версия продукта выходит у них каждые три месяца (Sutherland, 2005). Если учесть, что продукты PatientKeeper имеют особые требования по безопасности, нуждаются в одобрении регулятора и применяются в больницах в самых разных условиях, то это огромное достижение, дающее компании значительные конкурентные преимущества. Неудивительно, что PatientKeeper утвердилась в качестве лидера среди производителей мобильных приложений в сфере здравоохранения, опережая гораздо более мощных конкурентов.

Скорость

Скорость – индикатор того, какой объем работы может выполнить команда в течение одного спринта. Она позволяет отследить и предсказать ход проекта. Точнее говоря, скорость – это сумма усилий, затраченных на достижение результата, принятого владельцем продукта в течение одного спринта. Рассмотрим пример. На совещании по планированию спринта команда решает завершить работу над шестью историями общей суммой в 12 очков историй. В конце спринта владелец продукта тщательно проверяет обновление и обнаруживает, что все требования выполнены в соответствии с приемочными критериями, кроме одного: не окончена небольшая часть документирования истории Г. Поскольку Г не закончена, очки за нее не попадают в сумму командной скорости, как указано в таблице 4.1. Сумма очков за принятые элементы бэклога продукта равна 10. Таким образом, скорость команды в этом спринте равна 10.


Таблица 4.1. Определение скорости

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Как показывает этот пример, скорость лучше всего определять по способности команды превращать элементы бэклога продукта в инкремент продукта. «Работающие программы – это основная мера прогресса», – сообщает по этому поводу agile-манифест (Beck et al., 2001). Скорость может колебаться в зависимости от многих факторов – например, динамики командной работы, затруднений и доступности средств. Если несколько членов команды уходят в отпуск, то скорость, вероятнее всего, упадет. В случае новых команд или проектов разработки новых продуктов может потребоваться два-три спринта, прежде чем скорость стабилизируется (Cohn, 2005; 179).

Скорость специфична для каждой команды, ее не стоит сравнивать у разных команд, если только они не договорились об использовании очков за пользовательскую историю с одинаковым значением. Когда команда, разрабатывающая продукт А, имеет скорость 40, а создающая продукт Б – скорость 20, это не значит, что первая команда продуктивнее. Исходные данные могут быть разными, оценки первой команды иногда просто ниже.

Диаграмма сгорания работ для релиза

Диаграмма сгорания работ – это неотъемлемый инструмент отслеживания и прогнозирования хода проекта в Scrum. Она может выглядеть как график или как столбиковая диаграмма. Сначала рассмотрим график.

График сгорания работ для релиза

График сгорания работ позволяет отслеживать и прогнозировать ход проекта (Schwaber and Beedle, 2002; 83–88). Он основан на скорости предыдущих спринтов и способен предсказывать будущее, так что scrum-команда может на основании этих прогнозов видоизменять продукт и проект нужным ей образом[36]. Он базируется на двух факторах: времени и оставшемся объеме работ из бэклога продукта. График лучше всего составлять и обновлять на обзорном совещании по спринту, когда результаты спринта уже известны.

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

На этом графике видны две линии. Сплошная линия – это действительное сгорание. Она соответствует реальному прогрессу и оставшемуся объему работ. Видно, что начало проекта получилось довольно медленным. Это могло быть вызвано задержками, материализацией рисков, проблемами при построении команды или технологическими сложностями. В третьем спринте количество оставшихся усилий даже увеличилось. Это может быть связано с переоценкой командой элементов бэклога продукта или выявлением новых требований, необходимых для реализации видения. Четвертому спринту соответствует пологий спуск: проект быстро прогрессирует. Если сейчас рассмотреть предыдущие спринты, то можно отметить тенденцию сгорания, которой и соответствует прерывистая линия на рисунке 4.1. Тенденция сгорания предсказывает прогресс в ходе следующих спринтов. Оказывается, что если работа по бэклогу продукта и темпы сгорания задач останутся прежними, то проект не будет закончен за десять спринтов, то есть команда сбилась с пути. Поняв проблемы, scrum-команда может выяснить, в чем причины задержки – медленном прогрессе или чрезмерном количестве работы. Когда команда приходит к определенному выводу, она может принять верное решение. Если дата фиксирована, то можно либо снизить количество функций, либо попросить добавить в состав команды еще одного специалиста.


Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Рисунок 4.1. График хода сгорания работ


График хода сгорания работ можно использовать «на автопилоте», по выражению одного из моих коллег, Штефана Рука. Это простое средство, стимулирующее диалог и облегчающее исследования. Тщательно выберите временное окно и решите, принимать во внимание все спринты или только их часть. Выясните, не проявляют ли какие-то спринты аномалий, которые могут исказить прогноз. Например, это могут быть болезни членов команды, падение сервера в процессе разработки или слишком высокий темп работы. Затем внесите соответствующие изменения в тенденцию.

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

Столбиковая диаграмма сгорания работ

Более сложная версия диаграммы сгорания работ – это столбиковый вариант (Cohn, 2005; 221–224). Столбиковая диаграмма сгорания работ обладает всеми свойствами соответствующего графика, но проводит границу между переоценкой элементов и выполнением работы, с одной стороны, и добавлением и исключением элементов бэклога продукта – с другой. Если команда добивается прогресса или снижает оценки усилий, то верхушка столбика движется вниз. А когда увеличивает оценки – верхушка столбика движется вверх. Если в бэклог добавляются новые элементы, то нижняя часть движется вниз. Когда элементы удаляют из бэклога или их заменяют на требующие меньших усилий, нижняя часть движется вверх. На рисунке 4.2 показан образец столбиковой диаграммы сгорания работ.


Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Рисунок 4.2. Столбиковая диаграмма сгорания работ


Диаграмма на рисунке 4.2 – это те же самые данные, что и в примере графика на рисунке 4.1. Разница в том, что теперь мы лучше понимаем, что случилось во время третьего и четвертого спринтов. Верхушка столбиков пошла вниз, значит, команда добилась прогресса в ходе обоих спринтов. То, что нижняя часть столбика пошла вниз на третьем спринте, свидетельствует о появлении в бэклоге продукта новых элементов. В ходе четвертого спринта нижняя часть двинулась вверх, показывая, что элементы были устранены. Самый первый столбик демонстрирует количество работы до первого спринта.

На рисунке 4.2 видны две пунктирные линии, обозначающие тенденции, – верхняя и нижняя. Верхняя представляет тенденцию сгорания работ и наносится точно так же, как и в случае с графиком. Нижняя отражает текущую нулевую линию.

План релиза

«Планы – ничто, планирование – все», – заметил как-то Дуайт Эйзенхауэр[37]. Эта идея особенно подходит для плана релиза. Хотя в Scrum от команд в обязательном порядке не требуется план релиза, планировать его все-таки необходимо. Многим командам Scrum достаточно использовать диаграмму сгорания работ и группировать элементы бэклога продукта по категориям, чтобы понимать, какие функции и в каком релизе внедрять[38]. Однако большие scrum-проекты и те, которые требуют координации с другими проектами, партнерами или поставщиками, все же должны разрабатывать формальный план релиза.

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

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


Таблица 4.2. Образец плана релиза

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

В примере, представленном в таблице 4.2, проект находится на стадии четвертого спринта, а выход версии 1.0 должен состояться еще через четыре спринта.

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

Прогнозирование скорости

Чтобы спрогнозировать скорость работы команды, мы предпринимаем следующие шаги: если разрабатывается новый продукт, команда никогда не работала вместе или ее состав существенно изменился, нам нужно понаблюдать скорость работы команды по крайней мере по итогам первого спринта, а лучше – после двух или трех. Как уже упоминалось, чтобы скорость стабилизировалась, может потребоваться несколько спринтов. После этого мы можем использовать полученные данные по скорости работы команды для прогнозирования в будущих спринтах. В плане релиза из таблицы 4.2 для четвертого спринта ожидается скорость работы команды от 20 до 28 очков со средним значением 24 очка.

Кроме того, чтобы спрогнозировать будущую скорость работы команды, можно использовать и таблицу 4.3 (Cohn, 2005; 180). Так и поступила scrum-команда в плане релиза из таблицы 4.2.


Таблица 4.3. Множители скорости на основе завершенных спринтов[39]

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Используя среднюю скорость трех первых спринтов из таблицы 4.2, мы умножаем 24 на соответствующие наименьший и наибольший множитель из таблицы 4.3. Получается диапазон значений скорости работы команды от 21 до 28 очков.

После того как команда проделала пять и более спринтов, можно составить точный прогноз (Cohn, 2009; 297–300). Допустим, мы завершили восьмой спринт из таблицы 4.2 и хотим предсказать скорость команды в следующем релизе. Скорости завершенных спринтов имеют следующие значения: 20, 25, 28, 26, 16, 20, 26, 26. Теперь исключаем из рассмотрения данные по тем спринтам, в которых произошли аномалии – например, половина команды заболела или сервер на несколько дней стал недоступен. Затем сортируем список оставшихся значений в порядке возрастания. Получается следующее: 16, 20, 20, 25, 26, 26, 26, 28. Теперь, пользуясь таблицей 4.4, мы с 90 %-ной уверенностью можем определить будущую скорость работы команды.


Таблица 4.4. Использование n-ного наименьшего и n-ного наибольшего наблюдения в отсортированном списке значений скорости для нахождения 90 %-ного интервала достоверности[40]

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Поскольку мы прошли восемь спринтов, берем второе наблюдение скорости с начала и с конца последовательности. Это дает диапазон значений скорости от 20 до 26 со средней скоростью 23. Можно быть на 90 % уверенными, что реальное значение скорости работы команды будет внутри этого диапазона.

Составление плана релиза

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

Вернемся к плану релиза из таблицы 4.2. Из него следует, что реальная скорость работы команды по итогам первых трех спринтов составила 20, 25 и 28. Средняя скорость спринта, таким образом, равняется 24 очкам. Scrum-команда спрогнозировала скорость в диапазоне от 21 до 28 очков для четвертого, седьмого и восьмого спринтов, воспользовавшись множителями из таблицы 4.3.

План релиза также прогнозирует падение скорости для пятого и шестого спринтов, поскольку в это время несколько членов команды берут отпуск, после чего возвращаются на работу.

Если работа в бэклоге продукта не будет завершена в допустимые сроки (например, в случае фиксированной даты запуска), можно либо сократить функциональность, либо увеличить бюджет, добавив людей в команду (например, одного специалиста).

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

Планирование релизов в больших проектах

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

Общие ориентиры для оценок

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

Перспективное планирование

Чтобы помочь каждой команде в процессе оптимизации хода всего проекта, нужно приложить дополнительные усилия. Прежде всего следует заглянуть на два-три спринта вперед. Это даст возможность понять, над какими элементами бэклога продукта, вероятнее всего, будет проводиться работа (Cohn, 2005; 206. Pichler, 2008; 146). Это требует более ранней декомпозиции и оценки элементов бэклога продукта. Теперь в его верхней части будет больше детализированных элементов.

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

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

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

Конвейерная работа

Конвейер – это последний шанс. К данной методике стоит обращаться, только если все остальные возможности исчерпаны. Конвейерная работа разделяет то, что должно быть единым целым. Она распределяет работу над одним элементом бэклога продукта по нескольким спринтам (Larman, 2004; 251–253). Вот как это работает: допустим, у нас есть две команды – А и Б. Команда А должна поставить компонент для команды Б, а команда Б будет с ним работать. В процессе перспективного планирования мы обнаруживаем, что обе части процесса нельзя выполнить в ходе одного спринта. Сложно также сократить объем работы посредством последующей декомпозиции требований. Последний шанс – перейти на конвейерный метод. Мы просим команду А внедрить нужный компонент в ходе ближайшего спринта, а команду Б – использовать его в ходе следующего.

Звучит замечательно, но сразу возникает проблема: что будет сделано, когда команда А завершит работу? И как убедиться в том, что компонент будет работать нужным образом, когда команда Б начнет его использовать? Поскольку за частично сделанную работу не начисляется очков, то деятельность команды А не будет отражена в диаграмме сгорания работ, что затруднит отслеживание прогресса. Более того, может потребоваться резерв времени, чтобы убедиться в том, что команда А действительно сможет поставить нужный компонент (Cohn, 2005; 208). Буфер нужен в том случае, если команда A столкнется с необходимостью приложить больше усилий к работе над проектом, чем ожидалось. Потребности в конвейерной работе можно снизить, если задействовать функциональные, а не компонентные команды.

Распространенные ошибки

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

Отсутствие диаграммы сгорания работ или плана релиза

Мне встречались организации, которые, привыкнув к предварительному составлению детального плана проекта, бросались в другую крайность и вообще отказывались от планирования релиза. Жить от спринта к спринту опасно, а попасться в эту ловушку довольно легко. Из-за этого трудно оценить прогресс проекта и внести нужные изменения в продукт и проект. Необходимо всегда иметь диаграмму сгорания работ или план релиза. Они должны быть размещены в рабочем помещении и на вики-портале проекта и быть легко доступными для всех участников.

Владелец продукта в кресле пассажира

Владелец продукта должен принимать активное участие в деятельности по планированию релиза, не перекладывая ее полностью на команду или scrum-мастера. Как человек, который прежде всего отвечает за успех продукта, он должен руководить им с самого начала.

Взрывной релиз

Если выбрать главный совет этой главы, то вот он: делайте все возможное для быстрых и частых релизов ПО. Избегайте взрывного релиза, то есть поставки продукта только после внедрения всей возможной функциональности. В этом случае очень трудно, если вообще возможно, вовремя отреагировать на отзывы клиентов и пользователей, так что вероятность создания продукта, который полюбят клиенты, стремится к нулю. Есть и еще один недостаток. Взрывной релиз означает, что команда впервые сдает программу при выходе ее на рынок. Это часто влечет за собой дополнительный стресс членов команды и может привести к опозданию и срыву даты запуска.

Работа в ущерб качеству

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

Вопросы для самоконтроля

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

Выпустите обновления, а затем снова улучшайте проект.

• Каковы будут последствия, если зафиксировать время, качество или гибкость функциональности?

• Каковы выгоды от частых и быстрых релизов? И как на них перейти? Что нужно сделать, чтобы организовать выпуск проекта квартальными циклами? Какова скорость работы вашей команды?

• Что вы используете: диаграмму сгорания работ или план? Кто составляет и обновляет их?

5. Совместная работа на совещаниях по спринту

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

Мои картины создаются поэтапно, по одному квадратику за раз, что напоминает работу писателя… Среди преимуществ поэтапной работы могу назвать то, что у меня нет необходимости ежедневно изобретать колесо. Сколько я сегодня сделал, столько и сделал, нравится вам это или нет. Мне не нужно ждать вдохновения. Для меня не существует удачных и неудачных дней. Каждый день – это продолжение той работы, которую я делал накануне.

К счастью, Scrum дает возможность работать поэтапно, шаг за шагом претворяя в жизнь продукт, так что результат каждого нового спринта базируется на результатах предшествующих спринтов. Состав спринта вырабатывается и корректируется на нескольких обязательных встречах команды. Встреча для планирования спринта происходит вначале, демонстрация результатов спринта и ретроспективное совещание замыкают цикл. Совместные встречи – ценная возможность для взаимодействия и общения, обмена информацией и сотрудничества. Джерри Лэйборн, владелец продукта Ript – программы визуального планирования, – согласен с этим (Judy, 2007):

За тот год, когда мы создавали [Ript], я пропустил только одно совещание из тех, что проводились раз в две недели. Я посещал их, потому что они были действительно интересными и я многому на них учился.

Эта глава особенно важна для владельцев продукта. В ней говорится об их участии в scrum-митингах и предлагается несколько советов по эффективной работе с командой.

Планирование спринта

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

Роль владельца продукта во время планирования спринта состоит в том, чтобы помочь команде осознать, что должно быть сделано. Команда же прикидывает, каков объем работы и как ее можно сделать. Вы не должны указывать команде, сколько работы нужно выполнить за спринт, или определять состав задачи от имени команды, не посоветовавшись с ней. Это прерогатива команды. И она должна брать на себя только такие обязательства, которые действительно может выполнить. Ограничение объема работы на спринт определяется скоростью работы команды и ее размерами, что в итоге создает оптимальный темп разработки: «Заказчики, разработчики и пользователи должны уметь до бесконечности выдерживать постоянный темп разработки» (Beck et al., 2001). Бесполезно пытаться добиваться слишком амбициозной цели в течение одного спринта, только чтобы полностью истощить свои силы к следующему. Scrum отдает предпочтение равномерному, устойчивому потоку задач из бэклога продукта в спринты. Надежность важнее ложных амбиций, это необходимое условие для составления реалистичных прогнозов. А излишнее давление убивает творчество.

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

Критерии готовности

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

Перед первым спринтом владелец продукта должен встретиться со scrum-мастером и командой и выработать критерии готовности. В некоторых проектах в критерии готовности включаются конкретные цели – например, тестирование единиц ПО. После выработки критериев они должны быть записаны и доступны в течение всего проекта.

Ежедневный scrum-митинг

Такой вид scrum-собрания позволяет команде управлять своей работой изо дня в день и выявлять препятствия и проблемы. Владелец продукта должен постоянно посещать их. Это отличная возможность понять, как идет работа, и выяснить, не нужна ли команде помощь (например, нужно быть готовым отвечать на вопросы, анализировать результаты работы или помогать устранять препятствия). Можно также сообщить информацию и рассказать команде, над чем вы работаете сейчас и что планируете делать дальше. Часто работа владельца продукта предоставляет важную информацию о действиях на уровне релиза и на периферии проекта.

Во время ежедневных scrum-митингов желательно не вмешиваться в самоорганизацию команды, формулировать и назначать задания, комментировать прогресс отдельных сотрудников. Если вас беспокоит ход работы, делитесь своим мнением конструктивно – например, задавая вопросы[41]. Чтобы прояснить ситуацию с достижением цели спринта, можно сказать: «Я заметил: диаграмма сгорания задач для спринта показывает, что осталось еще много работы до завершения спринта. Вас это беспокоит?» Задавая вопросы, вы привлекаете внимание команды, но оставляете выбор действий за ней.

Препятствия

Нерешенные проблемы размножаются как грибы после дождя. Вот почему Scrum уделяет особое внимание борьбе с препятствиями – выявлению и устранению проблем, которые мешают работе и причиняют вред проекту. Члены команды рассказывают о препятствиях и проблемах на ежедневном scrum-митинге, и scrum-мастер отвечает за то, чтобы они были устранены как можно быстрее. Даже если работа над проблемами кажется замедлением хода проекта, она препятствует возникновению более серьезных трудностей и долгих отсрочек. «Проблемы – это сокровища, – пишет эксперт по бережливому управлению Паскаль Деннис. – Они дают возможность учиться и совершенствоваться» (Dennis, 2006; 19).

Спринт-бэклог и диаграмма сгорания работ для спринта

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

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

Обзор итогов спринта

Обзор итогов спринта способствует созданию успешного продукта. Он дает scrum-команде возможность взаимодействовать с заинтересованными лицами, рассмотреть ход разработки продукта на данное время и принять решение относительно дальнейших действий. Это лучше, чем просто верить, что все идет по плану. Среди заинтересованных лиц могут быть представители маркетинга, продаж и сервиса, а также клиенты и пользователи. Например, один клиент Primavera Systems – поставщика программных решений для управления проектами, программами и портфелями – посещал обзоры итогов спринта компании, считал их чрезвычайно полезными, ценил прозрачность и возможность повлиять на разработку продукта. Отметим, что подготовка к обзору должна быть сведена к минимуму. Обзор – это рабочая процедура, а не шоу. Командам стоит воздержаться от формальных презентаций и не использовать слайды. Цель обзора – не произвести впечатление или вызвать ажиотаж, а обеспечить прозрачность, проанализировать продукт и выработать меры по его улучшению.

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

Владелец продукта, давая отзыв на работу команды, должен передавать ей четкие и конструктивные послания. Необходимо проявлять уважение к усилиям команды и ее доброй воле. Если вам нравятся достигнутые результаты, похвалите команду. Если нет – так и скажите. Движение к цели спринта – это дело всей команды. Поэтому нужно обращаться ко всей команде, не выделяя никого конкретно. Проявляйте уважение к коллегам – членам scrum-команды, следите за своими намерениями и действиями и всегда думайте о том, как помочь команде двигаться вперед[42].

После определения степени прогресса заинтересованные лица должны выступить с отзывами на обновление продукта. Нравится ли им то, что они видят? Какие изменения нужно внести, чтобы продукт стал более успешным? Продолжает ли действовать концепция? Что с функциональностью: не слишком ли ее мало или много? Не внедрена ли какая-то функция некорректно? Может быть, стоит изменить внешний вид продукта и то, как он воспринимается? Если это нужно, то почему? На этом этапе нередко обнаруживаются новые требования или выясняется неактуальность старых. Заметим, что отзывы заинтересованных лиц позволяют владельцу продукта и команде увидеть обновление их глазами, что устраняет опасность шаблонного мышления. Чтобы получить полезные отзывы, поработайте с ожиданиями заинтересованных лиц. Объясните, что обновление продукта на раннем этапе может напоминать конечный продукт лишь отчасти, а новые идеи и требования должны поддерживать концепцию. Поэтому заинтересованным лицам, возможно, придется подождать еще в течение одного-двух спринтов, прежде чем можно будет внедрить новые идеи, в зависимости от приоритетов и успешности работы с бэклогом продукта.

Своевременные обзоры

Владельцу продукта необязательно ждать обзора итогов спринта, чтобы дать отзыв о результатах работы. Полезно проводить своевременные обзоры сразу после появления результатов спринта. Это дает команде возможность что-то исправить уже в ходе спринта. Своевременные обзоры особенно важны, если элементы бэклога продукта, внедряемые в ходе спринта, достаточно мелкие, чтобы команда могла закончить работу над ними за несколько дней.

Ретроспективный анализ спринта

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

Владелец продукта должен постоянно участвовать в ретроспективном анализе спринта. Присутствуя на совещаниях, нужно регулярно предлагать пути улучшения и укреплять отношения с остальными участниками scrum-команды. Приведем пример одного ретроспективного анализа спринта. Обзор итогов выявил расхождения в ожиданиях у команды и владельца продукта, в результате чего он отверг большую часть работы. Члены команды были расстроены, считая, что сделали все хорошо, а владелец продукта испытал разочарование в команде. Решено было разрядить атмосферу при помощи ретроспективного анализа – докопаться до основных причин случившегося. После конструктивного обсуждения ситуации scrum-команда сумела выработать два важнейших пути совершенствования: владелец продукта решил проводить с командой больше времени, а члены команды – помогать ему в работе с бэклогом. Если бы владелец продукта не присутствовал на ретроспективном анализе, команде пришлось бы нелегко с принятием верных решений.

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

Совещания по спринтам в крупных проектах

Хотя крупные проекты следуют тому же расписанию совещаний, что и другие проекты Scrum, сами совещания видоизменяются. В этом разделе мы расскажем, как это происходит.

Совместное планирование спринта

Чтобы провести совещание по планированию спринта среди нескольких команд, требуется дополнительная подготовка. Это и расширение горизонта работы с бэклогом, и внедрение перспективного планирования, описанные в главах 3 и 4. Большим проектам часто идет на пользу, если команды или их представители собираются вместе в начале совещания по планированию спринта, чтобы обсудить общую цель, к которой и будут двигаться все команды. Как только команды провели индивидуальные действия по планированию спринта, нужно снова собраться и определить, какие общие планы проекта должны быть реализованы в ходе спринта.

Scrum-совещание по scrum

Scrum-совещание по Scrum позволяет нескольким командам ежедневно координировать свои действия в ходе спринта. Представители команд после этого приходят на ежедневные scrum-митинги своих команд, чтобы обсудить положение дел, запланированную работу и взаимодействие между командами (Schwaber, 2007; 72). Это совещание – тактическое и не может служить компенсацией за недостаточную подготовку к спринту – например, отсутствие стратегического планирования.

Демонстрация результатов спринта

Организация эффективной встречи для одной-двух команд и клиентов, руководства и других заинтересованных лиц для демонстрации результатов спринта – непростая задача. Если же команд пять, десять или больше, то обеспечить общее понимание прогресса и выработать пути продвижения вперед еще сложнее. В компании Primavera нашли отличный способ организовать свои демонстрации, в которых нередко принимало участие сразу 15 команд. Боб Шатц, бывший вице-президент Primavera по разработке, поясняет: «Наши демо больше всего напоминали выставки в школе. Каждая команда собирала стенд, на котором демонстрировала то, над чем работает. Конечные пользователи, заинтересованные лица и еще несколько человек из нашей компании объединялись в небольшие группы. Каждая такая группа начинала со своего стенда. На анализ отводилось пятнадцать минут, после чего обозреватели переходили к следующим стендам. Все это проходило в атмосфере, полной энергии, вдохновения и радости» (Schatz, 2009)[43]. Совместная встреча заинтересованных лиц в одном помещении – отличный способ дать им всем возможность для взаимодействия и обмена мнениями. Если в офисе компании это невозможно, заказывайте конференц-зал хотя бы для каждой второй демонстрации результатов спринта.

Совместная ретроспектива спринта

Изменения и улучшения, которые каждая scrum-команда вырабатывает на своих ретроспективах, безусловно, помогают большим проектам. Но этого недостаточно. Для улучшения результатов команды должны определить общие пути совершенствования и поделиться друг с другом найденными идеями. Это позволяет делать совместная ретроспектива спринта. Эффективный метод ее проведения – привлечение представителей команд, что способствует перекрестному обмену идеями. Но при этом творческий импульс и знания всех участников команд не используются. Альтернатива – совместная ретроспектива всеми участниками команд. Это затратное дело: может занять полдня или больше, но так полнее используется накопленный опыт команд, а все их члены могут взаимодействовать друг с другом, укрепляя межкомандные взаимоотношения. Отличный способ организации ретроспективного анализа спринта – Open Space Technology (Owen, 1997), когда участники проекта самоорганизуются вокруг проблемных областей и определяют пути улучшения. Отметим, что оба варианта хорошо сочетаются. Например, организация может регулярно проводить ретроспективы с представителями команд и после каждого третьего спринта назначать общую ретроспективу, на которой будут присутствовать все члены команд.

Распространенные ошибки

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

Владелец продукта – «Чайка»

Такой владелец продукта появляется на планировании спринта, исчезает и затем возникает только на демонстрации. «Чайка» не взаимодействует с командой вовремя. Даже общение с ним по телефону или электронной почте часто затруднено. Иногда scrum-мастер или один из членов команды заполняют эту нишу, исполняя обязанности владельца продукта: это помогает команде двигаться вперед, но не позволяет устранить глубинные причины проблемы. Владелец продукта играет ключевую роль в его успехе. Поэтому обязанности владельца продукта должны стоять для вас на первом месте. Нужно проводить достаточно времени на рабочем месте с командой и быть готовым отвечать на вопросы, анализировать работу или устранять препятствия.

Незаинтересованный владелец продукта

Рабочее помещение было переполнено. Владелец продукта, scrum-мастер, команда, пользователи и несколько менеджеров среднего звена смотрели на монитор компьютера. Тестировщик, сидящий перед ним, изо всех сил старался объяснить функциональность, которую представлял. Владельцу продукта было не по себе, и он очень медленно отворачивался от монитора. Периодически он согласно кивал. Через десять минут демонстрация закончилась. Scrum-мастер посмотрел на владельца продукта и спросил: «Вам нравится то, что вы увидели?» Владелец продукта еще раз кивнул и сказал: «Хорошая работа». После этого он встал и вышел из комнаты. Другие члены scrum-команды молча смотрели друг на друга. «Пора начинать ретроспективу», – сказал scrum-мастер.

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

Нежизнеспособный темп

«Перерыва между спринтами не будет. Новый спринт начнется на следующий рабочий день», – говорю я. Одна из присутствующих поднимает руку и спрашивает: «Но как команда сможет восстановиться?» «Она и не должна», – отвечаю я. Я смотрю на поникших коллег, кто-то качает головой. Я продолжаю: «Нужно убедиться, что команда способна выполнить нужный объем работы – ровно столько элементов бэклога продукта, сколько она способна действительно воплотить в продуктовом инкременте, не перерабатывая и не чувствуя истощения».

Разработка продукта похожа на марафон. Если вы хотите финишировать, нужно подобрать оптимальный темп. Многие владельцы продукта совершают ошибку, оказывая на команду давление, чтобы она работала активнее. Так достигается краткосрочный выигрыш в скорости, но сам темп нежизнеспособен. Более того, он вообще контрпродуктивен. Спринты превращаются чуть ли не в гонку на выживание – люди быстро перегорают, заболевают или уходят. Владелец продукта должен уважать силы своей команды независимо от того, как выглядит диаграмма сгорания задач. Если дело движется медленно, соберите совещание, чтобы найти подходящее решение. Но не требуйте от сотрудников, чтобы они работали больше.

Стремление создать иллюзию

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

Включение в отчет диаграммы сгорания задач спринта

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

Вопросы для самоконтроля

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

Следующие вопросы помогут вам оценить свое поведение.

• Каким образом вы будете на планировании спринта поддерживать команду без ущерба для ее самоорганизации?

• Какой вклад вы можете внести в ежедневные scrum-митинги?

• Как вы будете сотрудничать с командой, предоставляя первые отзывы по результатам работы?

• Как сделать демонстрации результатов спринта еще эффективнее и интереснее?

• Посещаете ли вы ретроспективы спринта? Если нет, то как начать это делать? В чем преимущества этого?

6. Превращение во владельца продукта

Когда я познакомился с Полом, в первый раз выполнявшим функции владельца продукта, он спросил меня: «Что мне нужно делать и сколько времени это займет?» Пол объяснил, что хочет еще раз проверить свои повседневные обязанности. Особенно его беспокоило время, которое необходимо тратить на эту работу, и поддержка руководства. И Пол такой не один. Многие неопытные владельцы продукта не вполне представляют себе круг своих обязанностей и не знают, как лучше перейти к новой роли. В первый раз стать владельцем продукта – нелегкое дело. Часто это требует изменений как личностных, так и организационных. Такие перемены могут быть сложными, даже болезненными. Эта глава адресована читателям, которые собираются стать владельцами продукта, и менеджерам, руководящим переходом к Scrum. Более подробнее о методах перехода к Scrum читайте в (Schwaber, 2007) и (Cohn, 2009).

Как стать отличным владельцем продукта

Чтобы стать отличным владельцем продукта, требуются время и силы. Этот раздел поможет читателям перейти к этой роли и освоиться в ней.

Познайте себя

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

Как уже упоминалось в главе 1, роль владельца продукта многогранна. Практически невозможно найти начинающих владельцев продукта, которые обладают всеми необходимыми навыками. Поэтому вполне вероятно, что вы найдете пробелы в собственных знаниях и навыках. Джон, например, обладает большим опытом взаимодействия с клиентами и создания стратегических планов развития продукта, но не очень успешно пишет пользовательские истории и план релиза. Джейн, наоборот, отлично составляет пользовательские истории и знакома с планированием релиза, однако ей не хватает умения выстроить концепцию развития продукта. Обоим нужно активно проявить свои сильные стороны и улучшить навыки. Лисса Адкинс, автор книги Coaching Agile Teams, дает начинающим владельцам продукта следующие советы (таблица 6.1):[44]


Таблица 6.1. Что нужно и чего не нужно делать владельцу продукта

Управление продуктом в Scrum. Agile-методы для вашего бизнеса

Развитие и рост

Понимание вашего основного потенциала для развития поможет принять самые эффективные меры. Будущим владельцам продукта полезно посещать курсы Scrum для владельцев продукта, чтобы быстро получить необходимые знания. Но дело не только в теории. Будущему владельцу продукта нужно осознать основные принципы гибкого управления и начать жить в соответствии с ценностями Scrum.

Будьте преданны продукту и команде, сосредоточивайтесь на задачах владельца продукта, проявляйте открытость и поощряйте прозрачность, уважайте людей, с которым работаете, и имейте мужество вести себя правильно (Schwaber and Beedle, 2002, 147–154). Будьте командным игроком и доверяйте своим коллегам по scrum-команде.

Дайте себе время раскрыться в новой роли. Не надейтесь, что сразу же будете выдавать идеальный результат. Ошибки – это часть процесса обучения. Будьте терпеливы, но не допускайте самоуспокоенности. Начав работать владельцем продукта, вы яснее увидите свои слабые и сильные стороны.

Во время ретроспективы узнайте у scrum-мастера и команды мнение о вашей работе и внесите соответствующие изменения.

Найдите наставника

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

Еще одна хорошо зарекомендовавшая себя форма наставничества – ученичество. Вот пример одного из моих клиентов. Сара, руководитель бизнес-отдела, взяла на себя роль владельца продукта для первого релиза продукта. Но вскоре поняла: у нее недостаточно времени, чтобы продолжать выполнять эти функции. Тогда Сара решила пригласить в качестве помощника одного из своих подчиненных, Тома. Это дало ему время освоиться. После успешного первого релиза Саре удалось постепенно передать роль владельца продукта Тому.

Убедитесь в поддержке на нужном уровне

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

Вы еще не готовы

Проработав несколько месяцев в новой роли и устранив первые барьеры, вы будете чувствовать себя комфортнее. Дойти до этого этапа – уже большое достижение. Но нельзя останавливаться. Продолжайте развиваться, постоянно подвергая анализу свою работу. Прислушивайтесь к отзывам коллег по scrum-команде, работайте над оставшимися пробелами, связанными с вашими знаниями и навыками. Отличный способ совершенствования – стать участником сообщества владельцев продукта, где можно общаться с коллегами, обмениваться идеями и опытом, делиться мнениями и выявлять лучшие методы работы – например, регулярно участвуя в мастер-классах для владельцев продукта[45].

Как развивать владельцев продукта

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

Осознайте важность роли

Высшее руководство должно осознать полномочия и ответственность, сопряженные с ролью владельца продукта, и как эта роль влияет на организацию. Это не только жизненно важно для успешного функционирования гибкого управления продуктом, но и является ключевым фактором успеха в переходе на Scrum в целом. Согласен с этим и Кен Швабер (Schwaber, 2007; 85).

До недавнего времени я рассматривал эти отношения [между управлением продуктом и разработкой] как всего лишь одну из многих перемен при переходе на Scrum. Сейчас я считаю, что это самое важное изменение – краеугольный камень перехода. Если эта перемена прошла успешно, то Scrum у вас приживется и его выгоды станут очевидны. Если же изменения не будут внедрены успешно, то успех всего перехода на Scrum окажется под сомнением.

Выбирайте правильного владельца продукта

Владельцев продукта надо выбирать тщательно. Вы как руководитель должны принимать во внимание не только желаемые характеристики кандидата на должность (описанные в главе 1), но и другие факторы, в том числе продукт, его размер и отрасль. Идеальный владелец для одного продукта может плохо подходить для другого. К тому же у каждой компании должен быть собственный подход к выбору кандидатов. Например, в Salesforce.com менеджеры продуктов работают и владельцами продукта, при этом они относятся к одному и тому же подразделению. В mobile.de функции владельца продукта исполняются членами бизнес-подразделений. И каждое подразделение следит за своим набором продуктов или функций продукта[46]. Как и в целом в Scrum, все зависит от результата. Когда организация воплотит несколько scrum-проектов, обычно начинает вырабатываться общее представление о том, кто должен выполнять роль владельца продукта.

Наделяйте владельцев продукта полномочиями и поддерживайте их

Начинающим владельцам продукта, чтобы освоиться в новой роли, нужны время, доверие и поддержка. Есть вероятность того, что новый владелец продукта будет делать ошибки, начиная игнорированием заинтересованных лиц и заканчивая прерыванием спринта. Нередко ошибки – это неотъемлемая часть процесса обучения. Вы как представитель высшего руководства можете помочь ему, приняв меры по его обучению и наставничеству. «Раннее погружение владельцев продукта в agile-принципы и их обучение, создание бэклога продукта и пользовательских историй, оценка и планирование – вот ключи к успеху любой agile-команды. Кроме того, помимо начальной фазы обучения, для укоренения нового процесса в культуре компании необходимо постоянное наставничество владельца продукта в течение всего периода его работы», – делятся Фрай и Грин, описывая свой опыт работы в Salesforce.com. Также они советуют компаниям «обращаться за профессиональной помощью. Внешние наставники уже обладают необходимым опытом и способны раньше вас распознать препятствия. Они помогут учиться на примере других организаций, где подобный переход уже завершился» (Fry and Greene, 2007; 139).

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

Поддерживайте институт владельцев продукта в компании

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

Иногда, чтобы окончательно укоренить роль владельца продукта в корпоративной культуре, необходимы организационные изменения. Вот пример CSG Systems – компании по управлению взаимодействием с покупателями, предлагающей программные решения. Маурисио Замора, исполнительный директор CSG, так объясняет подход компании (Leffingwell, 2009):

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

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

Вопросы для самоконтроля

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

Следующие вопросы помогут перейти к роли владельца продукта.

• Какие аспекты этой роли кажутся вам трудными?

• Как вы можете получить необходимые знания для быстрого старта?

• Кто может помочь вам как владельцу продукта развиваться и расти профессионально?

• Есть ли в вашей компании другие владельцы продукта, с которыми можно обсудить возникающие проблемы?

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

• Как роль владельца продукта может повлиять на компанию?

• Что имеет наибольшее значение для успешных владельцев продукта?

• Как вы можете помочь владельцам продукта в их работе?

• Как может организация эффективно поддерживать существование роли владельца продукта?

Библиография

37Signals. 2006. Getting Real: The Smarter, Faster, Easier Way to Build a Successful Web Application. https://gettingreal.37signals.com/.

Anthony, Scott, Johnson, Mark, Sinfield, Joseph and Altman, Elizabeth. 2008. The Innovator’s Guide to Growth: Putting Disruptive Innovations to Work. Harvard Business School Press. Издание на русском языке: Руководство инноватора: Как выйти на новых потребителей за счет упрощения и удешевления продукта / М. Джонсон, С. Олтман, Дж. Синфилд, С. Энтони. М.: Альпина Паблишер, 2011.

Beck, Kent. 2000. Extreme Programming Explained: Embrace Change. Addison-Wesley.

Beck, Kent, and Cynthia Andres. 2005. Extreme Programming Explained: Embrace Change, 2nd edition. Addison-Wesley.

Beck, Kent, and Martin Fowler. 2000. Planning Extreme Programming. Addison-Wesley.

Beck, Kent, et al. 2001. The Manifesto for Agile Software Development, http://agilemanifesto.org/, http://agilemani-festo.org/principles.html.

Brooks, Frederick P. 1995. The Mythical Man-Month: Essays on Software Engineering, 2nd edition. Addison-Wesley. Издание на русском языке: Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы. СПб.: Символ-Плюс, 2010.

Bryson, John M. 2004. “What to Do When Stakeholders Matter: Stakeholder Identification and Analysis Techniques.” Public Management Review 6, no. 1, 21–53.

Carroll, Lewis. 1998. Alice’s Adventures in Wonderland and Through the Looking-Glass. Penguin Classics. Издание на русском языке: Кэрролл Л. Алиса в Стране чудес и Зазеркалье. М.: Эксмо, 2016.

Catmull, Ed. 2008. “How Pixar Fosters Collective Creativity.” Harvard Business Review, September, 64–72.

Christensen, Clayton M. 1997. The Innovator’s Dilemma: When Technologies Cause Great Firms to Fail. Harvard Business School Press. Издание на русском языке: Кристенсен К. Дилемма инноватора: Как из-за новых технологий погибают сильные компании. М.: Альпина Паблишер, 2016.

Cockburn, Alistair. 2005. Crystal Clear: A Human-Powered Methodology for Small Teams. Addison-Wesley.

Cohn, Mike. 2004. User Stories Applied: For Agile Software Development. Addison-Wesley.

–. 2005. Agile Estimating and Planning. Prentice Hall.

–. 2008. “Writing the Product Backlog Just Enough and Just in Time.” Scrum Alliance Weekly Column, February 12. www.scrumalliance.org/community/articles/2008/february/writing-the-product-backlog-just-enough-and-just-i.

– 2009. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley. Издание на русском языке: Кон М. Scrum. Гибкая разработка ПО. М.: Вильямс, 2015.

Conway, Melvin E. 1968. «How Do Committees Invent?” Datamation, April, 28–31.

Cooper, Alan. 1999. The Inmates Are Running the Asylum: Why High-Tech Products Drive Us Crazy and How to Restore Sanity. Sams Publishing.

Cooper, Robert G. 2001. Winning at New Products: Accelerating the Process from Idea to Launch, 3rd edition. Perseus.

Cunningham, Ward. 1992. “The WyCash Portfolio Management System.” OOPSLA 1992 Experience Report. http://c2.com/doc/oopsla92.html.

DeMarco, Tom, Peter Hruschka, Tim Lister, Suzanne Robertson, James Robertson, and Steve McMenamin. 2008. Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior. Dorset House. Издание на русском языке: Балдеющие от адреналина и зомбированные шаблонами. Паттерны поведения проектных команд / Т. Демарко, Т. Листер, С. Макменамин и др. СПб.: Символ Плюс, 2010.

Denne, Mark, and Jane Cleland-Huang. 2004. Software by Numbers: Low-Risk, High-Return Development. Sun Microsystems Press.

Dennis, Pascal. 2006. Getting the Right Things Done: A Leader’s Guide to Planning and Execution. Lean Enterprise Institute.

Finkelstein, Sydney, Andrew Campbell, and Jo Whitehead. 2009. Think Again: Why Good Leaders Make Bad Decisions and How to Keep It from Happening to You. Harvard Business School Press.

Fry, Chris, and Steve Greene. 2007. “Large Scale Agile Transformation in an On-Demand World.” Paper presented at Agile 2007, August 13–17, IEEE, 136–42.

Gilb, Tom. 1988. Principles of Software Engineering Management. Addison-Wesley.

Girard, Bernard. 2009. The Google Way: How One Company Is Revolutionizing Management as We Know It. No Starch Press.

Greene, Steve, and Chris Fry. 2008. “Year of Living Dangerously: How Salesforce.com Delivered Extraordinary Results through a ’Big-Bang’ Enterprise Agile Revolution.” Presentation at the Scrum Gathering, Chicago, April.

Highsmith, Jim. 2009. Agile Project Management: Creating Innovative Products, 2nd edition. Addison-Wesley.

Judy, Ken H. 2007. “CEO and Team: Collective Product Ownership at Oxygen Media.” Presentation at the Scrum Gathering, London, November.

Kaner, Sam, Lenny Lind, Catherine Toldi, Sarah Fisk, and Duane Berger. 1996. Facilitator’s Guide to Participatory Decision-Making. New Society Publishers. Издание на русском языке: Руководство фасилитатора. Как привести группу к принятию совместного решения / С. Кейнер, Л. Линд, К. Толди и др. М.: Издательство Дмитрия Лазарева, 2016.

Kano, Noriaki. 1984. “Attractive Quality and Must-Be Quality.” Journal of the Japanese Society for Quality Control, April, 39–48.

Larman, Craig. 2004. Agile and Iterative Development: A Manager’s Guide. Addison-Wesley.

Larman, Craig, and Bas Vodde. 2009. Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum. Addison-Wesley.

Leffingwell, Dean. 2009. “The Product Owner in the Agile Enterprise.” Agile Journal, April 6.

Levitt, Theodore. 1960. “Marketing Myopia.” Harvard Business Review 38, no. 4, 45–56.

Levy, Steven. 2008. “Inside Chrome: The Secret Project to Crush IE and Remake the Web.” Wired, no. 16 (October), www.wired.com/2008/09/mf-chrome/.

Lidwell, William, Kritina Holden, and Jill Butler. 2003. Universal Principles of Design. Rockport Publishers.

Lynn, Gary S., and Richard R. Reilly. 2002. Blockbusters: The Five Keys to Developing Great New Products. HarperCollins.

Maeda, John. 2006. The Laws of Simplicity. MIT Press. Издание на русском языке: Маэда Дж. Законы простоты. Дизайн. Технологии. Бизнес. Жизнь. М.: Альпина Паблишер, 2008.

Mayer, Marissa. 2006. “Nine Lessons Learned about Creativity at Google.” Presentation at Stanford University, May.

Moore, Geoffrey A. 2006. Crossing the Chasm. Marketing and Selling Disruptive Products to Mainstream Customers, revised edition. Collins Business Essentials. Издание на русском языке: Мур Дж. Преодоление пропасти. Как вывести технологический продукт на массовый рынок. М.: Манн, Иванов и Фербер, 2012.

Newkirk, James, and Robert C. Martin. 2001. Extreme Programming in Practice. Addison-Wesley.

Oberkirch, Brian. 2008. “Working in Close.” 43 Folders, November. www.43folders.com/2008/01/11/working-close.

Owen, Harrison. 1997. Open Space Technology: A User’s Guide, 2nd edition. Berrett-Koehler Publishers.

Pichler, Roman. 2008. Scrum – Agiles Projektmanagement erfolgreich einsetzen. dpunkt.verlag.

Poppendieck, Mary and Tom. 2003. Lean Software Development: An Agile Toolkit for Software Development Managers. Addison-Wesley. Издание на русском языке: Поппендик М. и Т. Бережливое производство программного обеспечения. От идеи до прибыли. М.: Вильямс, 2010.

Reinertsen, Donald G. 1997. Managing the Design Factory: A Product Developer’s Toolkit. Free Press.

Schmidkonz, Christian. 2008. “Product Owner at SAP – A New Job Title Developed.” Presentation at ObjektForum, Stuttgart, September.

Schatz, Bob. 2009. “The Sprint Review: Mastering the Art of Feedback.” www.scrumalliance.org/articles/124-the-sprint-review-mastering-the-art-of-feedback.

Schwaber, Ken. 2004. Agile Project Management with Scrum. Microsoft Press.

–. 2007. The Enterprise and Scrum. Microsoft Press.

–. 2009. “Scrum Guide.” Scrum Alliance, May.

Schwaber, Ken, and Mike Beedle. 2002. Agile Software Development with SCRUM. Prentice Hall.

Senge, Peter M. 2006. The Fifth Discipline: The Art and Practice of the Learning Organization, revised and updated edition. Random House.

Simons, Matthew. 2004. “Distributed Agile Development and the Death of Distance.” Cutter Consortium Executive Report, Sourcing and Vendor Relationships 5, no. 4.

Smith, Preston G., and Guy M. Merritt. 2002. Proactive Risk Management: Controlling Uncertainty in Product Development. Productivity Press.

Smith, Preston G., and Donald G. Reinertsen. 1998. Developing Products in Half the Time: New Rules, New Tools. John Wiley and Sons.

Sutherland, Jeff. 2005. “Future of Scrum: Parallel Pipelining of Sprints in Complex Projects.” Proceedings of the Agile Development Conference, 90–102.

Wake, Bill. 2003. “INVEST in Good Stories, and SMART Tasks.” xp123.com/articles/invest-in-good-stories-and-smart-tasks/. August.

Womack, James P., and Daniel T. Jones. 2005. Lean Solutions: How Companies and Customers Can Create Value and Wealth Together. Simon and Schuster. Издание на русском языке: Вумек Дж., Джонс Д. Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании. М.: Альпина Паблишер, 2016.

Благодарности

Эта книга появилась на свет благодаря помощи многих людей. Хотел бы от всего сердца поблагодарить всех, кто рецензировал ее, делился своими историями и давал советы:

Лиссу Адкинс, Гейра Амше, Маркуса Андрезака, Габриэля Бенефилда, Роберта Богетти, Томке Буля, Каустаба Деббармана, Пита Димера, Криса Фрая, Стива Грина, Роланда Хэнбери, Кевлина Хенни, Бена Хогана, Клинтона Кита, Андреаса Клингера, Ханса-Петера Корна, Йохена Кребса, Крэга Лармана, Билла Ли, Лоуэлла Линдстрема, Кэтрин Луис, Родриго Луна, Артема Марченко, Джейсона Мартинеса, Ралфа Мярку, Филиппа Мисслера, Бента Мюллерупа, Джеффа Паттона, Тобиаса Пихлера, Бретта Квинера, Сезарио Рамоса, Дэна Росторна, Саймона Робертса, Стефана Рука, Рене Розендаля, Джоанну Ротман, Кеннета Рубина, Мартина Руснака, Ханса-Петера Самиоса, Боба Шатца, Андреаса Шлипа, Кена Швабера, Кристу Шваннингер, Карла Скотланда, Мартина Шоу, Лизу Шуп, Джеймса Сиддла, Мишель Слайгер, Престона Смита, Дитера Стефановича, Джеффа Сазерленда, Мадса Трельс-Хансена, Баса Водде, Джеффа Уоттса, Харви Уитона, Рийдигера Вольфа, Элизабет Вудворд и Лу И.

Особенно благодарю Майка Кона. Его терпение, помощь и отзывчивость бесценны. Большое спасибо, Майк! Благодарю также Джеффа Сазерленда и Бретта Квинера за замечательные предисловия. И спасибо Кену Шваберу за то, что научил меня Scrum.

Я бесконечно признателен своей семье. Моя жена, Мелисса Пихлер, дала мне возможность не беспокоиться ни о чем постороннем и полностью посвятить себя написанию книги. Она терпеливо выслушивала мои идеи, редактировала текст и помогала с дизайном обложки. Спасибо, любимая! Я благодарен также сыну Лео и дочке Ясмин, которые самоотверженно старались ходить на цыпочках, пока папа пишет. Особая признательность пятилетнему Лео за его честность. Прочитав несколько предложений, он сказал: «Папа, это немного странно».

Также я хотел бы поблагодарить Ребекку Трегер за прекрасную редакторскую работу и команду издательства Pearson – Криса Гузиковски, Райну Хробак, Шери Кейн, Анну Попик и Барбару Вуд – за помощь и трудолюбие.

Об авторе

Роман Пихлер – один из ведущих экспертов по Scrum и agile-управлению продуктом. Он опытный наставник и помог многим компаниям в применении эффективных методов управления продуктом. Роман часто выступает на международных конференциях. Он сертифицированный тренер по Scrum и возглавлял Scrum Alliance в процессе выработки курса обучения владельцев продукта.

Сноски

1

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

2

Гик – человек, чрезвычайно интересующийся чем-либо, фанат. Первоначально так называли людей, увлеченных высокими технологиями (обычно компьютерами и гаджетами). Прим. ред.

3

От Chief Executive Officer (англ.) – высшая исполнительная должность в компании. В принятой в России иерархии аналог генерального директора. Прим. ред.

4

Визионер (от англ. vision – видение) – человек, обладающий стратегическим мышлением. Прим. ред.

5

Личное сообщение Филиппа Мисслера, CTO компании mobile.de, 18 июня 2009 года.

6

Из письма Джеффа Сазерленда на рассылку scrum-тренеров Yahoo! от 2 октября 2008 года и из личного сообщения Джеффа Сазерленда от 16 декабря 2008 года.

7

Личное сообщение Филиппа Мисслера, CTO компании mobile.de, 22 июня 2009 года.

8

Например, у профессиональных регбистов есть несколько тренеров: по атакам, защите, схваткам, ударам, тренеры форвардов, а также главный тренер.

9

О техническом долге и оптимальном темпе работы подробно говорится в главах 4 и 5.

10

Эта идея излагается в законе Конвея (Conway, 1968). Он гласит, что структура организации, разрабатывающей продукт, часто влияет на архитектуру самого продукта. Например, если в проекте участвуют три команды, то архитектура нередко будет состоять из трех основных подсистем.

11

Владелец продукта верхнего уровня не всегда именуется главным владельцем продукта. Швабер использует термин владелец общего продукта (Schwaber, 2007); Ларман и Водде называют главного владельца продукта просто владельцем продукта (Larman & Vodde, 2009).

12

Кен Швабер (Schwaber, 2007; 71) предлагает каждому владельцу продукта стать частью интегрированной scrum-команды, в которую входят также scrum-мастер и команда. Каждая интегрированная scrum-команда поддерживает команды более низкого уровня. Так, на рисунке 1.3 интегрированная scrum-команда «Игры» поддерживает scrum-команды «Тетрис» и «Шахматы».

13

Перевод Б. Заходера. Прим. перев.

14

Хотя концепция продукта не входит в структуру Scrum, она упоминается у Швабера и Бидла (Schwaber and Beedle, 2002; 34). Кен Швабер пишет: «Концепция описывает причины, по которым запускается проект, и его желаемый результат» (Schwaber, 2004; 68).

15

“Inside Google’s New-Product Process”, BusinessWeek.com, June 30, 2006.

16

На точность предсказания реакции рынка влияет его динамика и степень инновационности продукта. Для стабильных рынков и продуктов, переживающих постоянные или пошаговые инновации, реакция рынка может быть просчитана довольно хорошо. Для других рынков и продуктов это сложно или даже невозможно – например, в случае прорывных инноваций. Кристенсен (Christensen, 1997; 143) отмечает: «Нельзя анализировать рынки, которые еще не существуют».

17

Термин «минимально функциональный продукт» отсылает нас к работе Марка Денна и Джейн Клиленд-Хуан. В их книге Software by Numbers (2004) предложен термин «минимальная коммерчески ценная функциональность», который обозначает наименьшую функциональность, способную все же создать ценность для покупателя. Идея быстрого формирования небольшого набора функций и пошагового улучшения продукта восходит к методу эволюционной разработки Тома Гилба (Gilb, 1988).

18

Смит и Райнертсен (Smith and Reinertsen, 1997) называют метод разбиения инновации на более мелкие и быстрые этапы пошаговой инновацией.

19

“So Much Fanfare, So Few Hits”, BusinessWeek.com, July 10, 2006. Подобный же подход отражен в знаменитом изречении Арта Фрая из 3М: «Чтобы найти принца, придется перецеловать много лягушек». Заметьте, что прекрасный принц заплатит за всех этих лягушек. (Имеется в виду сказка братьев Гримм «Принц-лягушка». Прим. ред.)

20

“Ten principles that contribute to a Google user experience”. www.google.com/corporate/ux.html.

21

Проект браузера Google возглавлял менеджер продукта Брайан Раковски (Levy, 2008).

22

Личные сообщения Харви Уитона, CEO Supermassive Games, 21 октября и 2 ноября 2009 года.

23

Кстати, Microsoft в конце 1990-х годов предлагала три варианта Visio – Standard, Pro и Tech. Затем компания решила упростить свой портфель.

24

Тачдаун – один из способов набрать очки в американском и канадском футболе. Прим. ред.

25

Аббревиатуру DEEP придумал Майк Кон.

26

Откладывание решений до того момента, когда их все же придется принять, также называется самым поздним ответственным решением (Poppendieck, 2003)

27

Термины «сколько нужно» и «когда нужно» впервые использованы в работе Кона (Cohn, 2008) для описания работы над бэклогом продукта.

28

Билл Уэйк предложил так называемые INVEST-критерии, имея в виду, что истории должны быть независимыми (independent), согласуемыми (negotiable), ценными (valuable), удобными для оценки (estimatable), небольшими (small) и контролируемыми (testable) (Wake, 2003). Взаимозависимости и ценности обсуждаются в разделе расстановки приоритетов, об оценке говорится в этой главе. Под согласуемостью понимается возможность изменения пользовательской истории. Как сказал Рон Джеффрис, история – это обещание диалога, а не жесткое требование.

29

Более подробное и полное описание методов оценки см. в: Cohn, 2005.

30

Время оценивается отдельно по соотношению усилий и скорости работы, о чем пойдет речь в главе 4.

31

Интервью Коллин Фрай с Дэрином Фишером на сайте SearchSoftwareQuality.com, 1 октября 2008 года.

32

Термин «воронка неопределенности» впервые предложен Барри Бемом.

33

Личное сообщение Стива Грина, 16 апреля 2009 года.

34

Быстрые и частые релизы – не новая идея, они восходят к идее эволюционной разработки Тома Гилба (Gilb, 1988). Экстремальное программирование также придерживается идеи частых релизов, именуя их короткими релизами (Beck, 2000) и поэтапным развертыванием (Beck and Andres, 2005).

35

Интервью Коллин Фрай с Дэрином Фишером на сайте SearchSoftwareQuality.com, 1 октября 2008 года.

36

Бек и Фаулер (Beck and Fowler, 2000) называют это свойство вчерашней погодой. Отметим, что приблизительный прогноз вполне приемлем, если ход работ проверяется каждые несколько недель в процессе обзорных совещаний на спринтах, что дает возможность обновить график и изменить прогноз.

37

Дуайт Эйзенхауэр (1890–1969) – 34-й президент США. Прим. ред.

38

Эти категории также называют журналами релиза (Schwaber and Beedle, 2002; 71–72).

39

Из книги Майка Кона Agile Estimating and Planning. Печатается с разрешения.

40

Из книги Майка Кона Succeeding with Agile: Software Development Using Scrum. Печатается с разрешения.

41

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

42

Уважение в Scrum настолько важно, что входит в число пяти базовых ценностей (Schwaber and Beedle, 2002; 147–154). Остальные четыре – это преданность делу, сфокусированность, открытость и смелость.

43

Отметим, что владельцы продукта помогали представлять обозревателям результаты работы команды.

44

Личное сообщение Лиссы Адкинс, 29 июня 2009 года.

45

Кон (Cohn, 2009; 70–79) подробно рассказывает о сообществах по совершенствованию как о варианте освоения Scrum.

46

Личные сообщения Бретта Квинера, старшего вице-президента по продуктам в Salesforce.com (9 июня 2009 года), и Филипа Мисслера, технического директора mobile.de (18 июня 2009 года).


Купить книгу "Управление продуктом в Scrum. Agile-методы для вашего бизнеса" Пихлер Роман

home | my bookshelf | | Управление продуктом в Scrum. Agile-методы для вашего бизнеса |     цвет текста   цвет фона   размер шрифта   сохранить книгу

Текст книги загружен, загружаются изображения



Оцените эту книгу