Nous avons une organisation qui compte environ 50 projets logiciels différents en cours (environ 90 développeurs). Quelques grands, quelques petites. Certains sont des solutions de retour avant et arrière et certains s'appuient sur des solutions et des technologies existantes.
Certains de ces projets sont une nouvelle initiative et certaines sont des améliorations progressives sur les logiciels existants que nous avons construits.
Notre haute direction cherche une manière élégante pour visualiser tous les projets en cours, notamment:
La raison en est que nous voulons probablement déplacer des ressources pour garantir le meilleur retour sur investissement mais que tous les développeurs ne sont pas fongibles en fonction de leurs compétences.
Dans ma tête, il en résulte un type de chaleur ou de tableau de bord, mais je voulais voir s'il y a une solution ou des outils recommandés qui attaquent cette zone.
À l'heure actuelle, nous avons simplement des feuilles de calcul énumérant chaque projet et ressources et d'une manière ou d'une autre, cela ne donne pas vraiment une bonne visualisation de ce qui se passe réellement.
Toute suggestion?
4 Réponses :
g'day,
avoir une lecture de l'excellent livre d'excellent Johanna Rothman " Gérez votre Portefeuille de projet "qui aborde cette question très en fournissant une approche d'évaluation de plusieurs projets afin de déterminer une priorité.
EDIT: J'ai oublié de dire que j'applique la technique moi-même sur plusieurs flux de travail ATM.
htth
Agilefant est un outil open-source qui "rassemble les perspectives de la planification de produits à long terme et de publication et gestion du portefeuille de projet »et est activement développé. J'essaierais la version 2.0-Alpha (accessible via la Téléchargements page) pour Amélioration des outils de visualisation, mais vous pouvez également essayer la démo en direct pour obtenir l'idée de ce que Agilefant peut faire.
Une technique de consultant classique ... Je commencerais en les traçant sur un graphique 2x2. Faites l'axe vertical Le ROI, avec une hauteur au sommet, rendez l'axe horizontal deux partitions d'amélioration incrémentielle de l'initiative gauche et nouvelle à droite - et je parie qu'il y a des projets qui sont un peu des deux, alors peut-être que vous avez peut-être un continuum. Tracer chaque projet sur ces axes comme cercle et que la zone du cercle représente le nombre de jours d'homme.
Les choses en haut à droite sont de haut à droite, de nouvelles initiatives, des éléments en bas à gauche sont des améliorations de maintenance de rendement faible / incrémentielles. Si vous faites un tableau pour le déploiement actuel des ressources et un autre pour le déploiement de ressources planifiées, vous obtiendrez une forte idée de la façon dont vous passez votre main-d'œuvre.
Il y a beaucoup de variations à ce sujet et vous pouvez choisir ce que vous voulez parcourir où vous devez montrer votre histoire. Il est simple et puissant comme une aide visuelle et vous pouvez obtenir 90 cercles sur votre carte sans perdre les bois pour les arbres.
ht et bonne chance.
Vrai, les diagrammes de bulles rendent les propriétés des projets dans le portefeuille visible. L'alignement sur la stratégie de développement de produits (s'il existe) devrait également être évalué.
Si je comprends bien cette question, la solution dépend fortement de l'objectif final qui n'est pas clair dans la plupart des cas similaires.
Avant de faire des "diagrammes comme des" diagrammes comme kanban "pour que cette affaire ait notamment déclaré l'objectif déclaré (je suggère que cela ne signifie que, pas un objectif) de rééquilibrer la force de travail que je recommanderais de penser à des points suivants: < / p>
Je recommanderais donc (à la place ou en plus du suivi de l'efficacité du projet) pour suivre l'efficacité des développeurs / la satisfaction / l'efficacité de la satisfaction / de l'équipe / la satisfaction et essayez de résoudre les efforts de ré-balance non seulement à cause du retour sur investissement, mais également de gagner des personnes (du moins à moins que les projets ne soient rentables de ne pas mettre des estimations de retour sur investissement sur tout). Ne faites pas ruiner le projet (pas aussi mais oui) simplement parce que quelqu'un a besoin d'un développeur dans un autre projet brillant.
OK, ce n'est que mon opinion générale, mais cela m'a grandement aidé au cours de l'année dernière. J'espère que cela aidera quelqu'un aussi.