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

Question

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

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

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

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

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

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

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

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

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

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

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

Сюда:

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

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

Answer 5

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

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

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

Answer 6

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

Answer 7

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

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

Answer 8

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

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

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

Answer 9

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