Technology Management & Leadership

Il est impressionnant de voir à quel point la vision logistique d’un projet peut influencer l’efficacité du développement et la motivation d’une équipe. Malgré qu’on tente souvent de minimiser l’information concernant les besoins d’affaire concrets dans une analyse pré-digérée ( surtout dans une grande entreprise ), l’équipe, ayant les deux mains dans La réalisation d’une solution se trouve souvent devant des dilemmes non pas d’implémentation, mais de logique. Certaines demandes peuvent sembler ne faire aucun sens, ou même être issues de mauvaises décisions. Dans d’autre cas, certaines demandes sont contradictoires, et le développeur a le choix entre affronter les preneurs de décision, ou concocter une solution satisfaisant tout le monde, selon son propre avis. Le développeur faisant face à ces problèmes construit une certaine frustration, mêlée à un sentiment d’impuissance. Deux comportements font surface; une colère minant le moral général de l’équipe, ou un abandon: “Bof, tant que j’ai mon chèque de paye…”.

Lorsqu’on parle de visibilité, je n’ai aucun doute quant au fait qu’une vision peut être un point d’entrée primordial à une compréhension des décisions obscures d’une politique épaisse, autant qu’à une communication plus simple et rapide du responsable de la solution. Elle indique que même si une décision n’est pas optimale d’un point de vue technique, elle a été prise dans une optique précise: répondre à la vision. De plus, lorsque le développeur désarçonné doit faire face au décideur, il peut hiérarchiser l’information reçue en se basant sur celle-ci.

Je sais que toutes les méthodologies commencent par une vision, mais il est important que celle-ci soit tenue à jour, et aie une signification pour ceux et celles qui vont la réaliser autant que pour les décideurs. Elle se doit d’être un rassemblement ainsi qu’une direction commune.

Je n’ai pas encore vu de telle pratique, mais je crois qu’il serait très bon de hiérarchiser la vision, et attribuer à chacun des éléments un pourcentage de complétion, ainsi qu’une priorité, un peu comme on fait avec les fonctionnalités. C’est une vue très rapide sur l’état du projet, qui ne peut que motiver l’équipe ou alarmer les gestionnaires lorsque beaucoup de travail est fait pour peu de mouvement dans le tableau de vision. On verrait clairement la plus-value des efforts quotidiens dans le “monde réel”. En effet, un tel tableau permettrait aux développeurs de se sentir impliqués dans leurs tâches. J’aime beaucoup mieux dire: “J’ai aidé à augmenter les ventes de 25% en un an!” que: “J’ai refait un formulaire qui était en ASP”.