Un pot-pourri d’articles intéressants sur la carrière d’analyste d’affaires. Si vous avez des questions, c’est mon boulot, alors vous pouvez me les poser! 
- Les débuts
- L’analyste d’affaires VS l’analyste de systèmes: une analyse comparative intéressante.
- Cinq signes indiquant que vous êtes faits pour l’analyse d’affaire.
- L’analyste d’affaires n’est pas qu’un pont entre le client et l’équipe technique; il construit ce pont essentiel à la réussite d’un projet.
- La progression
Bonne lecture!
Comme mes collègues le savent déjà, je crois fermement que les deux rôles, essentiels sur tout projet de par leur complémentarité, doivent demeurer des rôles distincts. Rien n’empêche une personne de faire les deux sur des projets différents, mais sur un même projet, les priorités de chaque rôle rendent difficile l’atteinte des objectifs visés par l’analyste et le chargé de projet.
J’étais donc bien heureux de tomber sur cet article du Business Analyst Times qui résume bien le fond de ma pensée! Voici quelques citations, mais je vous invite à le lire en entier.
The project objectives help the organization meet its business goals and objectives. The PM focuses on the former; the BA on the latter.
The PM typically focuses on the project-creating baselines and managing project constraints, communications about the project, resolving issues about the project, getting the resources working on activities and tasks. The BA typically focuses on the end product.
Project managers want to deliver the end product on time and within budget. Business analysts want to ensure that customers can actually use the end product once it has been implemented
When we wear multiple hats, which voice do we listen to?
Comme tout bon analyste doit bien comprendre le contexte dans lequel il travaille, en introduire un sur un projet est un défi en soi, encore plus si ce projet est déjà en cours. Pour avoir eu à le faire à 3 reprises sur un projet majeur que je viens de compléter, je peux vous dire qu’il s’agit d’un travail de longue haleine, qui est néanmoins bénéfique. L’un d’entre eux a d’ailleurs bien illustré la transition avec le principe du 30-30-30 (comme l’engrais ):
- 30 jours pour apprendre
- 30 jours pour comprendre
- 30 jours pour assimiler
Ce qui n’est pas très loin de la réalité!
Pour assurer une belle intégration, j’aime bien les grands principes identifiés par Laura Brandau sur son blog (très intéressant en passant), qui permettent de bien structurer toute la connaissance à transférer d’une personne à l’autre. Ça ressemble pas mal aux points que j’avais abordé dans le passé sur mon projet, mais l’avantage, c’est que c’est structuré :
- Connaissances – domaines d’affaires et applicatifs
- Parties prenantes – affaires et TI
- Partage d’information sur les problématiques courantes
- Rôle et responsabilités de l’analyste sur le projet (devoirs & attentes)
