Как управлять большим портфелем продуктов?[закрыто]

Question

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

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

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

Поскольку сейчас мы довольно большие компании, у нас сложный продукт и много клиентов, базовых решений (таблица, документ Google, список дел Basecamp) просто недостаточно, чтобы справиться с этим.Нам нужен способ группировать вещи различными способами, расставлять приоритеты на постоянной основе, давать понять, что мы делаем и что будет дальше, - без необходимости тратить все чье-то время на простое управление каким-то инструментом.

Как вам удается это сделать так, чтобы бизнес всегда делал то, что наиболее ценно для существующих клиентов, помогал привлекать новых и сохранял работоспособность внутреннего программного обеспечения?

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

Вы нашли метод или инструмент, который работает?Если да, поделитесь!(А если вы тоже хотите узнать ответ, оцените вопрос, чтобы он оставался видимым :)

Приложение: Конечно, приятно сначала исправить все ошибки, но в реальной системе, которая фактически установлена ​​на машинах клиентов, это не всегда практично.Например, у нас может быть ошибка, которая возникает очень редко и для исправления которой потребуется огромное количество времени и архитектурных изменений — мы можем оставить это на некоторое время.Или у нас может быть ошибка, когда кто-то думает, что что-то сложно использовать, и мы думаем, что для ее исправления следует подождать более масштабного обновления этой области.Итак, существует множество причин, по которым мы не просто исправляем их все сразу, а оставляем открытыми, чтобы не забыть.Кроме того, сложнее всего расставить приоритеты без ошибок;представь, у нас их нет :)

Answer 1

Агрессивное управление большим отставанием почти всегда является расточительным.К тому времени, как вы доберетесь до середины приоритетной стопки, все чаще всего меняется.Я бы порекомендовал использовать что-то вроде того, что Кори Ладас называет фильтром приоритетов:

http://leansoftwareengineering.com/2008/08/19/priority-filter/

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

Редактировать: Аллан спросил, что делать, если задачи разного размера.По сути, большая часть этой работы — это правильное определение ваших задач.Мы применяем этот приоритет только к пользовательским историям.Истории пользователей обычно значительно меньше, чем «создать сайт сообщества».Я бы посчитал этот сайт сообщества эпопеей или даже проектом.Чтобы определить приоритетность, его необходимо будет разбить на значительно более мелкие части.

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

Что касается перемещения вибблов на два пикселя, многие из этих простых вещей можно сделать «бесплатно».Вам просто нужно быть осторожным, чтобы сбалансировать их, и делать их только в том случае, если они действительно почти бесплатны и действительно важны.

Мы относимся к ошибкам аналогично.Ошибки получают одну из трех категорий: «Сейчас», «Скоро» или «Со временем».Мы исправляем ошибки «Сейчас» и «Скоро» так быстро, как только можем, с той лишь разницей, что мы публикуем исправления.В конце концов, ошибки не исправляются, если разработчикам не становится скучно и им нечего делать или они каким-то образом не становятся более приоритетными.

Answer 2

Ключом является агрессивная категоризация и расстановка приоритетов.

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

Answer 3

Простой метод — использовать матрицу приоритетов.

Примеры:

• http://erc.msh.org/quality/pstools/psprior2.cfm

• http://it.toolbox.com/blogs/enterprise-solutions/sample-project-prioritization-matrix-23381

Также полезны квадранты расстановки приоритетов (два измерения:Важность, срочность), которые предлагает Кови: http://www.dkeener.com/keenstuff/priority.html.Сосредоточьтесь на важном и срочном, затем на важном и несрочном.Неважные вещи... ну...если кто-то хочет сделать это в нерабочее время :-).Вариант квадрантов Кови, который я использовал, имеет измерения Важности и Легкости.Легкость — хороший способ расставить приоритеты задач в секторе Кови.

Answer 4

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

Вещи, по которым вы могли бы расставить приоритеты:

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

Answer 5

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

Answer 6

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

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

Answer 7

Поскольку вы уже работаете гибко, вы можете позаимствовать некоторые идеи из XP:

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

Сюда:

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

Для получения дополнительной информации см. Планирование экстремального программирования к Кент Бек и Мартин Фаулер.Они говорят это гораздо лучше, чем я когда-либо мог сделать.

Answer 8

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

Answer 9

Помимо любого инструмента и процесса, должно быть...некоторые люди ;)

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

Между ними можно установить приоритеты как на высоком уровне (функциональные запросы), так и на низком уровне (ошибки и технические проблемы).