Управление несколькими программными проектами [закрыто

Question

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

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

Наше высшее руководство ищет гладкий способ визуализации всех проектов, включая:

1. Размер усилий во времени и ресурсах
2. ROI ожидается от работы
3. Укажите постепенное улучшение по сравнению с новой инициативой.

Причина в том, что мы, вероятно, хотим перемещать ресурсы, чтобы обеспечить топ -окупаемость, но не все разработчики могут быть связаны в зависимости от их навыков.

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

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

какие-либо предложения?

Answer 1

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

Прежде чем делать некоторые «канбанские диаграммы» для этого случая, особенно если это объявить цель (я полагаю, что это только означает, а не цель) для повторной балансировки рабочей силы Я рекомендую подумать о следующих пунктах:

• Эффективность каждого разработчика сильно зависит от многих факторов индивидуальных и текущих проектов. Существуют «рефакторические люди» / «поддерживающие люди» / и т. Д., Так что, как они помещаются в другую среду ... это может изменить что угодно.
• Ну, делая усилия по переоборудованию. Что происходит с существующей структурой команды? Хорошие выровненные команды с надлежащей ролью каждого человека очень редки. Стоит ли сломать хорошую команду для некоторой оценки (в небе)?

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

Хорошо, это только мое общее мнение, но оно очень помогло мне в прошлом году. Надеюсь, это тоже кому -то поможет.

Answer 2

Agilefant является инструментом с открытым исходным кодом, который «объединяет перспективы долгосрочного планирования продукта и выпуска и управления портфелем проектов» и активно развивается. Я бы попробовал релиз 2.0-альфа (доступный через Загрузки Страница) для улучшенных инструментов визуализации, но вы также можете попробовать демо вживую, чтобы понять, что может сделать Agilefant.

Answer 3

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

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

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

HTH и удачи.

Answer 4

G'day,

Прочитайте отличную книгу Джоханны Ротман "Управление портфелем проекта«Это решает эту проблему, предоставляя подход для оценки нескольких проектов для определения приоритета.

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

Hth