Как вы управляете крупным портфелем продуктов?

Question

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

• Новых проблемные областей для наших продуктов для решения
• Новой функциональности в поддержке существующих проблемных зон
• Новая функциональность по просьбе наших существующих пользователей
• Юзабилити и «смотреть» повышениями
• Architectural модернизаций к фоновым
• Bug ф ixes

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

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

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

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

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

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

Answer 1

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

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

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

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

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

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

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

Answer 2

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

Answer 3

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

Вещи, которые вы могли бы определить приоритетность по являются:

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

Answer 4

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

Answer 5

Простая методика заключается в использовании матрицы приоритетов.

Примеры:

• 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. Сосредоточьтесь на важном и неотложном, а затем на важном и не срочном. Неважный материал ... ну .. если кто-то хочет сделать это в свое время :-). Вариант квадрантов Covey, который я использовал, имеет размеры важности и простоты. Простота - это хороший способ определить приоритеты задач в квадранте Covey.

Answer 6

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

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

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

Answer 7

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

• возможности отмечать элементы работы как ошибка или увеличение запросов на
• категории поля для региона ответственности, что элемент работы подпадает под (UI, фоновый, и т.д.)
• Version # fi поле, когда исправление или функция планируется сделать
• поле Status (в процессе, завершен, проверено и т.д.)
• Priority поле

Answer 8

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

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

Answer 9

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

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

Таким образом:

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

Для более информация, см. Планирование экстремального программирования от Kent Bech и Martin Fowler. Они говорят это намного лучше, чем я когда-либо мог.