Управление продуктовыми требованиями в реальной жизни

В большом и серьезном мире ИТ уже давно ни для кого не секрет, что требования — это важнейшая и обязательная составляющая любого проекта. Это могут быть объемные пачки доков с описаниями use cases, это могут быть карточки с user stories. Главное что без них никак. И естественно, начиная очередной проект, хочется сделать его быстрее, выше, сильнее и в том числе улучшить аспект, связанный с ведением требований. Начинаешь гуглить и…

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

Суть большинства «бумажных» подходов в том, что они описывают достаточно идеальные кейсы:

• Имеется один заказчик, знает чего хочет, умеет и жаждет работать по RUP;
• Имеется заказчик, который не знает чего хочет, мы продали ему Agile, теперь он итеративно приходит к пониманию того, что хочет;
• Стартап, сидим и «фигачим».

Но вот незадача – остается достаточное количество проектов, которые совершенно не похожи на подобные типовые и как вести в них требования можно лишь гадать, потому что…

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

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

А меж тем, продуктов с такими реалиями достаточно на рынке, многие из них на слуху. Но много ли постмортемов, статей, докладов мы слышали/видели/читали? Получается какая-то глобальная подписка о неразглашении.

Так что же делать? Как быть? Сжигать трактаты  великих и по тем и по другим методологиям и изобретать свои велосипеды? Или стоит таки вспомнить, что Agile по своей сути – это далеко не только Scrum, XP и Kanban – это философия ведения проектов и если ей заручиться…

В докладе будет проведен обзор и анализ опыта управления требования при продуктовой Agile разработке. При этом работа команды “внутри” организована по Agile и выполняется несколькими Agile мини-командами, а для заказчиков это выглядит так, как они это хотят видеть. Для одних  это — Agile и они активно участвуют в разработке и выделяют Product Owner-а, для других — традиционный RUP подобный подход и полноценный внешний Product Owner для команды заменен  внутренним прокси Product Owner-а.

 В докладе будут также рассмотрены следующие вопросы:

• Так ли необходимы высокоуровневые бизнес требования в продукте?
• Как свести несколько разных подходов ведения требований, навязываемых различными заказчиками продукта (Agile, RUP, и т.п.), в один, который подходит для работы продуктовой Agile команды?
• Как оформлять требования, если наш продукт сильно зависит от готовых компонент третьих компаний (требования к которым недоступны)?
• Управление запросами пользователей в ситуации, когда часть из них заказчики с равными приоритетами
• Как проводить приемку функционала, если разные заказчики делают это по-разному?
• Управление скоупом продукта под влиянием реального положения дел на рынке и поведением конкурентов
• Подход к документированию требований — шаблоны документов, степень детализации
• Обзор программных средств и рабочих подходов

Уровень аудитории: практикующие, эксперты

Направления: Product Management, Experience Report, Agile Process

Докладчик

Антон Зотин
Luxoft (Москва)