Формирование команды проекта
Многие люди старательно собирают в команду лучших людей, которых могут найти, – специалистов с соответствующим опытом, экспертов в своей области – и затем все портят, не предоставляя адекватного понимания бизнеса и лидерства. Не ставьте телегу впереди лошади! Важно достичь правильного уровня участия бизнеса в проекте – включить одного человека, который понимает видение бизнеса. Это не просто практично и прагматично, но и логично с точки здравого смысла.
В Agile этого человека обычно называют «владельцем продукта» (Product Owner), но существуют и варианты названия. Конечно, в этой блистательной книге его стоило бы называть «руководителем продукта», но для начала остановимся на простом определении. Владелец продукта представляет интересы бизнеса и конечного пользователя. Владелец продукта живет, дышит и мечтает о продукте и о том, каким он должен быть. Такие люди знают, чего именно хотят, даже если не знают способа, как этого достичь. Они лидеры, способные быстро принимать решения и отстаивать их.
Agile-команда – разнообразная, многофункциональная группа индивидуумов, способных воплотить видение от имени бизнеса. Проще говоря, у них есть все, чтобы выполнить работу надлежащим образом. Владелец продукта указывает путь только в плане бизнес-видения, но и это большой вклад в работу команды. Команда состоит из людей с гибким мышлением, не боящихся изменений и не считающих, что бюрократия – решение всех проблем. Уверенно принимающие решения, проявляющие инициативу деятельные люди подойдут лучше всего.
В определение видения и всех аспектов, касающихся выпуска продукта, должна быть вовлечена вся команда. Если поступать не так, возникнут сложности.
Создание журнала требований
Когда определены видение и то, какую выгоду проект должен приносить, следующий шаг для команды проекта – записать требования в возможных деталях. В центре каждого проекта – список требований, который в Agile называется журналом требований продукта, или бэклогом (Product Backlog). Он заменяет традиционное, подробное техническое задание и представляет собой список важных для бизнеса идей. Элементы журнала всегда ориентированы на конечного пользователя продукта, даже если речь идет о технической части проекта. Они должны быть понятны любому.
Важно, чтобы с самого начала команда проекта выработала коллективное видение, чтобы быть уверенными, что все понимают цели, содержание проекта и способы их концептуализации. Убедитесь, что все на одной волне с самого начала – это проще, чем потом пытаться исправить готовый на две трети продукт. Многоплановость команды также важна, потому что важно иметь возможность посмотреть на проблему под разными углами. Если необходимо, специалисты будут помогать друг другу.
Как сделать так, чтобы с самого начала все пошло наперекосяк
• Заявлять, что Agile – универсальное средство, даже для не предназначенных для него областей.
• Говорить, что тут все очевидно и любой дурак сможет справиться, так что никакого обучения не нужно.
• Считать, что Agile непогрешим, а неудачи происходят из-за личных недостатков.
• Устанавливать нереалистичные цели и сроки, оправдывая это тем, что в дивном новом мире Agile все возможно.
Определите базовую функциональность
Цель состоит в том, чтобы составить сводный список того, что необходимо для воплощения видения проекта. Есть несколько способов это сделать, и наш любимый подход – подумать о каждом шаге клиента, чтобы спланировать рабочий процесс.
Создайте функциональные группы
Как только определен или составлен рабочий процесс, соберите вместе все идеи насчет того, что необходимо будет сделать на каждом шаге этого пути. Подобная группировка этих элементов обеспечивает описание функциональности шага и может называться функциональными группами. Какие-то детали будут совершенно необходимы, а другие можно отнести к категории приятных дополнений. Их стоит упорядочить с самого начала.
Приоритетность характеристик
Опираясь на видение проекта и здравый смысл, определите приоритет каждого элемента в нисходящем порядке – от самого важной в каждом списке.
Определение первого выпуска
Как только вышесказанное будет сделано, обдумайте каждый важный шаг в движении к заказчику от первого дня до реализации и что является самой ценной частью идеи в рамках этих шагов. Такой выбор может быть сложным и в конце концов зависеть от мнения, но мнение заказчика – или того, кто представляет собой его бизнес, – имеет решающую роль. Конечный результат шагов – тот приемлемый минимум для заказчика, которого проект должен достичь в этом шаге. Это обычно называется минимально жизнеспособным продуктом (minimum viable product, MVP) или минимально жизнеспособным выпуском (minimum viable release, MVR).
Один из больших плюсов – быстрое получение важной обратной связи от конечных пользователей, однако, чтобы составить свое мнение, им необходимо что-то довольно существенное. Невозможно получить значимую обратную связь о техническом процессе, но о новой форме заказа VegBox – вполне. Естественно, это будет частью минимально жизнеспособного продукта.
Стоить помнить, что чем больше всего будет в минимально жизнеспособном продукте, тем больше времени потребуется для получения обратной связи, тогда как если продукт будет слишком мал, будет недостаточно информации для получения обратной связи. Вам придется найти баланс между прибылью и риском – никакого универсального правила тут нет. Постарайтесь найти точку, в которой вы получите полезные отзывы о чем-то, что поможет вам принимать обоснованные решения. Это будет полезно и для анализа рынка.
Также обращайте внимание на термины. Для кого-то слово «выпуск» будет означать доступный для использования продукт, для других – продукт, предназначенный для тестирования закрытой группой. Помните, что всегда существует возможность сначала представить продукт малой группе, а уже потом выпустить продукт соответствующим образом. Главное, не делайте допущений, что все понимают термины одинаково! Нет абсолютно правильных подходов – выберите тот, что лучше подходит вам.
Добавление характеристик
Как только определено, что будет в минимально жизнеспособном продукте (MVP) или минимально жизнеспособном выпуске (MVR), начинается настоящее веселье. Дополнительный функционал или новые характеристики продукта могут добавляться по частям или быть частью большого релиза. Это называется инкрементная поставка, и бизнесмены ее очень любят. Никаких больше долгих лет ожидания одного большого выпуска со всеми «свистульками». Выпуск продукта в Agile-разработке происходит быстро и часто. И, опять же, именно заказчик определяет, что и когда выпускать. Как минимум отдельный выпуск должен содержать одну характеристику, проверенную практикой.
