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

Шаг 1. Сопоставьте проблему или потребность с видением

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

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

Шаг 2. Оцените критичность проблемы или потребности

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

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

На диаграмме ниже показано, как я обрабатываю новый запрос об устранении проблемы или удовлетворении потребности.

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

Шаг 3. Оцените стоимость и время усилий по поиску решения (применимо только к некритическим проблемам и потребностям)

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

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

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

Шаг 4. Примите решение на основе разработанной стратегии и тактики.

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

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

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

Пример стратегии (результаты)

Не разрабатывайте новые функции для функциональности X, не оставляйте их в живых и не выводите из эксплуатации к 4 кварталу 2021 года.

Разработайте новый функционал Y и запустите его ко второму кварталу 2021 года.

Пример тактики

Поддержите клиентов и объясните им, как использовать функциональность X. Приложите небольшие усилия профильного эксперта / бизнес-аналитика к этой деятельности.

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

Сделайте приоритетными усилия по устранению проблемы, если она

  • не имеет обходного пути;
  • стоит менее 3-х очков истории;
  • приносит пользу покупателю.

Если у незначительной проблемы есть обходной путь, попросите клиента воспользоваться им. Если исправление этой проблемы стоит более 3-х баллов, постарайтесь этого не делать.

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

Затратить не менее 80% общих ресурсов на внедрение и запуск функционала Y.

На исправление ошибок функциональности X тратить не более 10% от общих ресурсов.

Пример проблемы

Некоторое время назад клиент сообщил о проблеме с некоторыми особенностями функциональности X. Бизнес-аналитик проанализировал проблему и предложил клиенту использовать обходной путь, чтобы избежать проблемы. Заказчик остался доволен.

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

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

Пример решения

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

Согласно тактике, развитие функциональности Y имеет приоритет над устранением мелких проблем с функциональностью X.

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

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

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

Резюме

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

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