У нас есть набор продуктов, состоящий из четырех продуктов и базовой структуры данных. В прошлом мы управляли работой над каждым продуктом индивидуально, от незавершенной работы до выпуска (как, скажем, «Июльский выпуск продукта XYZ»), и включали всю работу в этот проект под руководством одного менеджера проекта. Вот так мы доставили минимально жизнеспособный продукт.
Теперь, когда минимально жизнеспособные продукты поставляются, мы выводим на рынок решения, которые используют возможности нескольких продуктов. Например, мы выпускаем «Решение для розничного рынка», которое может включать изменения в продуктах XYZ, ABC и 123. Чтобы обеспечить согласованность и совместимость, мы управляем решением как единым проектом, который включает проектирование и разработку решения в целом для всех продуктов. Из-за этого подхода существует расстановка приоритетов, которая происходит на один уровень выше отдельных невыполненных работ по продукту (обычно посредством стратегического планирования). Таким образом, для этого решения для розничного рынка мы назначаем одного менеджера проекта, и этот человек работает с менеджерами по продуктам и владельцами продуктов, чтобы определить элементы незавершенной работы, которые поддерживают это решение... и оттуда,
Мой вопрос заключается в следующем: в модели, в которой вы управляете невыполненными работами по продуктам, которые фиксируют вещи, не входящие в список решений, которые являются небольшими, но все же высокоприоритетными (подумайте о дефектах или инцидентах... или даже очень-очень небольших улучшениях, таких как изменение метки поля) , как вы включаете их в рабочий список управления проектами? Если у меня есть 7 менеджеров проектов, и каждому из них назначен проект, охватывающий несколько продуктов (т. е. решение), какое место в цикле занимают более мелкие элементы? Как сделать так, чтобы они не провалились сквозь трещины?
Огромное спасибо!
Менеджер проекта несет ответственность за ВСЕ пункты, которые необходимо выполнить, независимо от их «размера». Таким образом, на самом деле не существует «минимального порога работы», прежде чем проблема должна быть отслежена. Самый простой ответ — ввести эти небольшие элементы в базу данных отслеживания проблем.
Я предполагаю, что ваш «рабочий список управления проектами» является вашей базой данных для отслеживания проблем. (Это может быть электронная таблица Excel или такой инструмент, как Jira или DevTrack.) Вам было бы проще, если бы у вас была единая база данных задач для всех продуктов, особенно когда вам нужно управлять/просматривать списки дел нескольких менеджеров по продуктам. . Ситуация усложняется, если у каждого менеджера по продукту есть отдельная база данных по проблемам. (Еще сложнее, если один использует Excel, другой использует Jira, а третий использует рукописные карточки для заметок.)
Тем не менее, несколько баз данных проблем или нет, убедитесь, что каждый элемент указан и имеет назначенную жертву, э... ответственное лицо.
Отслеживание всех этих деталей должно дать вашим командам и менеджерам уверенность в том, что вы в курсе всего. Кроме того, это почти всегда вдохновляет других на создание подобных небольших проблем для отслеживания, которые в противном случае никогда не попали бы в список.
Дэнни Шеманн