Это существенное отличие Agile от проектного менеджмента, где продукт показывают в конце всего процесса. И если даже устраиваются промежуточные встречи с Заказчиком, то скорее для того, чтобы сверить, соответствует ли работа, сроки и бюджет ранее установленным в документах параметрам.
Минимально готовый продукт называется так еще и потому, что его уже можно представить рынку, то есть продать. Представим, что мы создаем сайт и хотим, чтобы он был суперсовременным, с личным кабинетом пользователей, видеовставками, обратной связью и тому подобным. Наше техническое задание расписано на несколько страниц. Если мы работаем в Agile, то уже после первого же спринта у нас есть one page – одна страница со всеми выходными данными и торговым предложением потребителям. То есть сайт начинает работать и привлекать клиентов после первого же спринта. И так каждый новый промежуток времени наш сайт дополнятся новыми опциями, продолжая все время работать и расширять клиентскую базу компании. Это, конечно, простой пример.
В Agile вне IT-отрасли сложно выделить минимально готовый продукт. Иногда на это уходят часы и дни командной работы. В Agile в науке мы принимали за такой продукт научную гипотезу. Марина Алекс, интервью с которой будет дальше, разрабатывая Agile для продаж, и вовсе отказалась от этого требования разработчиков методологии. Так как заменила минимально готовый продукт финансовым планом на спринт. И все-таки лучше его поискать.
Минимально жизнеспособный продукт обладает определенными качествами. Он должен быть:
• функциональным;
• надежным;
• готовым к употреблению.
Минимально жизнеспособный продукт в Agile не является прототипом продукта. Потому что прототип мы можем нарисовать в презентации, снять по нему видео, сделать макет, но мы не можем продать его потребителю. В этом отличие этих двух понятий.
Главное назначение минимально готового продукта в Agile:
• убедиться, что идея, над которой работает команда, нужна потенциальным потребителям;
• составить свое представление о целевой аудитории продукта, возможно, внести какие-то изменения в свое первоначальное представление об этом;
• собрать и проанализировать обратную связь, составить протокол необходимых изменений, внести эти изменения в бэклог следующего спринта;
• получить импульс для размышлений о правильности идеи и ее исполнения;
• повысить мотивацию команды, увидевшей реакцию потребителей и Заказчика, даже если она критическая, но все равно доброжелательная, поскольку все заинтересованные лица всегда благодарны за то, что их спросили о продукте по ходу дела, а не в конце, когда уже ничего нельзя изменить;
• начать монетизировать свои разработки;
• сократить сроки и бюджет производства конечного продукта за счет раннего распознавания положительных и отрицательных качеств продукта.
Вернемся к тем понятиям, о которых вскользь упоминалось во вступлении к книге, для выравнивания информационного поля. Теперь – некоторые интерпретации и упорядочение понятий методологии.
Мы не включаем Заказчика в список традиционных ролей в SCRUM, поскольку он действует за рамками процесса. Это может быть руководитель направления, который инициирует проект и принимает решение реализовать этот проект посредством Agile. Иногда роль Заказчика выполняет первое лицо компании. Это зависит от того, какой уровень задачи стоит перед командами, какого размера сам бизнес, какой уровень корпоративной культуры в компании и принятый в коллективе стиль руководства.
Заказчик присутствует на обзоре спринта (релизе), когда команда демонстрирует минимально готовый продукт, созданный за период спринта. Далее на конкретных примерах из бизнеса мы будем говорить о том, чем чревато нарушение этого правила.
Итак, в SCRUM действуют три основные роли.
1. Владелец продукта (Product Owner).
Предпочтительно, чтобы человек, занявший эту роль, прекрасно разбирался в бизнесе, в котором работают команды, и знал запросы потенциальных клиентов. Это важно, так как он составляет бэклог продукта – описывая весь объем работы на проект – и отвечает за результат деятельности команды. Если у участников возникает потребность изменить что-либо в бэклоге продукта, то делается это только через Владельца продукта.
Он дает команде понятные требования для работы, разъясняет сложные моменты, уточняет у Заказчика ответы на вопросы, возникшие у команды, организует взаимодействие с различными подразделениями компании, если это требуется команде. Не являясь руководителем команды ни в коей мере, Владелец продукта участвует в тестировании результата работы перед обзором спринта и демонстрацией продукта перед Заказчиком и потребителями. Основная задача Владельца продукта, несмотря на большую ответственность за производственную часть работы, – постоянно поддерживать у участников видение и понимание цели.
