Choisir un outil de gestion de projet Saas en 2013

Après avoir travaillé pendant plusieurs années avec Redmine puis Jira/Confluence d’Atlassian, j’ai récemment fait à nouveau le tour des outils de de gestion de projet en mode Saas.

L’outil de nos rêves permet la gestion de projets « internes » comme de projets « clients ». A la réflexion, la principale différence entre ces deux types de projet se situe dans la phase d’analyse du projet. Un projet interne est  essentiellement technique : analyse et conception sont réalisées par un groupe très réduit de personnes internes à la société, il est souvent développé en vol de cycle mais la durée de vie du logiciel développé est souvent très longue : une base de connaissance est donc indispensable. Un projet client, par contre, fait l’objet d’un devis, puis d’une analyse partagée entre l’équipe cliente et le chef de projet fonctionnel (l’AMOA) ; les échanges sont nombreux et doivent être tracés, le calendrier projet doit être soigneusement entretenu, les versions s’enchainent pour les documents de spécification, les mockups et les créas : tout doit être tracé afin d’éviter des dérives dans les demandes client par rapport au devis initial.  La phase de  développement pur – agile bien entendu – est souvent moins exposée au client, mais celui-ci doit pouvoir juger de l’avancement du travail.  Le temps de développement des différentes tâches doit être soigneusement géré afin de pouvoir facturer proprement. Lors des tests et après la mise en service du logiciel, le client doit pouvoir créer des tickets d’incident et obtenir des réponses rapides. Les demandes d’évolution seront traitées comme des itérations de la boucle analyse-conception-développement.

On voit donc apparaitre deux besoins assez différents : gérer des échanges fonctionnels d’une part, et gérer des taches techniques d’autre part. Et c’est le chef de projet (ou le Product Owner d’une équipe Scrum) qui va faire le lien entre ces deux pôles.

Mais quelles sont les fonctionnalités utiles pendant ces différentes phases ? Après m’être un peu gratté la tête je suis parvenu à la liste suivante :

Fonctionnalités utiles pendant la phase de conception

  1. IHM en français ; en effet les clients ne maitrisent pas tous l’anglais (les chefs de projet non plus J).
  2. Profil détaillé des membres de l’équipe projet et des clients ; il est très pratique de retrouver facilement le numéro de téléphone ou le skype d’un membre de l’équipe cliente.
  3. Tableau de bord clair de l’activité sur chaque projet ; le point d’entrée sur le projet doit donner un aperçu immédiat de l’état du projet, si possible avec une vision des risques.
  4. Calendrier ; il centralise la roadmap, l’agenda des confcalls, les jalons atteints (tiens je n’ai pas dit milestones).
  5. Listes de to-do ; pour la roadmap comme pour chaque aspect du développement, la to-do list est un principe universellement compris. Chaque élément de la liste est un tâche fonctionnelle (et non technique).
  6. Discussions sur les tâches ; elles doivent permettre d’éradiquer les échanges sauvages par email.
  7. Fichiers et gestion de versions des documents ; les drafts, mockups, designs et livrables restent sous la main, les évolutions sont tracées facilement. Une gestion de répertoires est pratique pour éviter une énorme liste de documents.
  8. Intégration des documents Google Drive ; je préfère en effet travailler sur les drafts de spécification via un document texte Google Drive. Une fois validé, un pdf est généré et devient un livrable du projet.
  9. Synchronisation des contacts et calendriers Google Drive ; pour ceux qui utilisent quotidiennement les outils Google, il est pratique d’éviter les duplications.
  10. Opacité de certains aspects pour les clients ; eh oui, certaines discussions internes ou certains document doivent rester internes. La possibilité de marquer hidden certains aspects  évite là aussi d’avoir recours aux emails.
  11. Notifications par email ; elle doit être quotidienne et gérée par projet.
  12. Archivage de  projets ; il est utile de mettre de côté un projet terminé mais pouvoir accéder à son historique sans avoir à le recharger.
  13. Récupération des données ; c’est un must pour tout service Saas.

Fonctionnalités utiles pendant la phase technique

  1. Gestion de tâches ; tout bonnement une gestion des demandes de développement ou d’évolution de fonctionnalité et de correction de bugs, avec une date de début et d’échéance, un état de résolution et un workflow de validation. Il doit permettre de filtrer les issues par projet et par personne.
  2. Time tracker ; un timer sur chaque tache (ou ticket) permet de gérer les charges de développement. Une catégorisation des taches (ex veille, design, évolution, correction) permet de faire le joint entre estimation (par catégorie) et tâches de granularité très fine. Encore faut-il s’astreindre à donner une catégorie à chaque ticket …
  3. Gestion de sprints (scrum) ; si l’on est lancé dans une démarche itérative de type Scrum, la gestion facile des sprints dans l’IHM du produit est un bonheur.
  4. Edition de diagrammes de Gantt ; entre techniciens, la possibilité de visualiser les projets sous forme de Gantt est pratique. Encore faut-il que les ressources, les délais et les charges apparaissent bien sur le graphique.
  5. Gestion des coûts ; le reporting projet et la facturation sont facilités par la possibilité d’affecter des coûts horaires aux personnes, des coût horaires ou forfaitaires aux tâches.
  6. Accessibilité depuis un mobile ; la gestion des incidents impose aujourd’hui la possibilité d’intervenir en mobilité.

En faisant mon tour d’horizon des produits, je me suis aperçu qu’aucun outil n’aborde parfaitement ces deux besoins distincts et que la meilleure solution est … de sélectionner deux produits Saas complémentaires, voire trois.

Dans un prochain article, je vous donnerai un aperçu des produits testés et détaillerai ceux que j’ai choisis.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

Commentaires protégés par WP-SpamShield pour WordPress