Делайте демо результатов труда: простой способ поднять эффективность проекта

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

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

Какую ценность дают такие встречи команде? Получение быстрой обратной связи от владельца продукта о том, что сделано за спринт (итерацию). А это, в свою очередь, дает возможность команде уточнить требования к продукту, который она создает.

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

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

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

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

Расскажу об этом подробнее.

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

1. Можно приходить не всем участникам команды.

Как правило, на демо приходит вся команда. В случае, когда этого сделать нельзя, нужно учесть:

• Тот, кто придет от команды, должен быть способен показать все, что сделано всеми участниками
• Представитель команды должен ответить на вопросы владельца продукта

2. Владельцу продукта можно показывать прототип (прототипы). Мне очень нравится эта практика. Команда работает непосредственно над продуктом, создавая быстрые прототипы и показывая, как они работают. В этом случае команде не нужно тратить много времени на «причесывание» ТЗ всего продукта.

Мне, например, гораздо проще обсуждать требования к продукту, когда есть его упрощенная модель.

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

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

Что делать, если вы понимаете, что владелец продукта/его коллеги не готовы смотреть что-то незаконченное или полусырое? Я в таких ситуациях предпочитаю проводить демо не по окончании каждого спринта, а по завершении какой-то логической части продукта.

Да, это совсем не в духе Scrum. Но не отменять же из-за того, что владелец продукта не может смотреть на незаконченные вещи, работу с использованием Scrum?!

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

Поэтому очень важно, чтобы кто-то в команде владел навыками презентации.

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

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

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

Что в итоге дает демо

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

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

Таким образом, продукт проекта:

• Наращивает свою функциональность от спринта к спринту
• Имеет шанс к концу проекта полностью «попасть» в ожидания владельца продукта

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

Удачи вам в ваших проектах.

Максим Якубович Эксперт по управлению проектами. Директор компании «АйТи уит» Опыт работы в сфере управления проектами - с 2003 года. Более 20-ти выполненных проектов в роли руководителя проекта и руководителя программы проектов. Опыт преподавания - с 2005 года. Около 2300 студентов, прошедших обучение на его семинарах. Консультант и бизнес-тренер в консалтинговой группе «Здесь и сейчас». Преподаватель модуля «Управление проектами» Русской школы управления. Приглашенный преподаватель курса «Управление проектами» в Британской Высшей школе дизайна. Приглашенный преподаватель компании «Инфопарк-проект» Ведущий блога по управлению проектами.