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

Question

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

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

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

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

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

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

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

есть предложения?

Answer 1

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

Answer 2

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

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

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

HTH и удачи.

Answer 3

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

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

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

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

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

Answer 4

G'day,

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

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

НТН