Узнайте, что рекомендуют Agile, Lean и Theory of Diminishing Returns в отношении управления ожиданиями

Возможно, вы росли с мыслью о том, что не хотите просто соответствовать ожиданиям, а желаете их превзойти. Но действительно ли это правильно?

Рискуя повторить очевидное, можно сказать, что превзойти ожидания — значит выйти за рамки обещаний или текущих ожиданий. Как это может быть не правильным?

"Главное — определить реальные ожидания клиентов, а затем не просто соответствовать им, но и превосходить их — желательно необычным и полезным способом." — Ричард Брэнсон

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

Превышение ожиданий — это неправильное решение, если ценность, полученная от его выполнения, меньше, чем то, что вы могли бы предоставить другим способом. Это противоречит основному Agile-принципу, концепции Lean Startup (Бережливого стартапа) и Theory of Diminishing Returns (Теории убывающей отдачи) — все это очень важно при разработке продукта.

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

Вы обязательно должны искать новые пути, чтобы превзойти ожидания клиентов, однако уже сейчас существует способ, позволяющий добиться максимальной эффективности. Давайте рассмотрим, как Agile, Lean и Theory of Diminishing Returns рекомендуют управлять ожиданиями.

Agile-принцип 

Простота — искусство максимального увеличения объема невыполненной работы — имеет важное значение.

"Искусство максимизировать объем несделанной работы" — один из двенадцати принципов Манифеста Agile (Agile Manifesto). Из моего опыта хочу сказать, что это самый трудный для понимания принцип. Как максимизация объема невыполненной работы может принести наибольшую пользу?

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

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

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

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

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

Концепция бережливого производства

Минимально жизнеспособный продукт (MVP)

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

Слово "минимум" может сбить вас с толку, потому что вы, как и я, усвоили, что минимум - это недостаточно хорошо. Вы всю жизнь слышали, что нужно идти выше и дальше и превосходить ожидания. MVP — это сложная для понимания концепция. Где провести грань между тем, что достаточно, а что недостаточно?

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

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

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

Теория убывающей отдачи

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

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

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

В заключение

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

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

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

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

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

Чтобы узнать больше об этой и других концепциях управления, поддерживающих agile-разработку, прочтите книгу  Pursuing Timeless Agility: the Path to Lasting Agile Transformation. (В погоне за бесконечной гибкостью: путь к устойчивому Agile-преобразованию).

Материал подготовлен в рамках специализации «Системный аналитик». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем специализации — приглашаем на день открытых дверей онлайн. Регистрация здесь.