Il est quand même nécessaire qu'un chef de projet s'intéresse aux problèmes des gens qu'il encadre. Il faut parfois comprendre un minimum les problèmes, c'est tout a fait possible d'obtenir des informations d'un programmeur pour sentir la gravité d'un problème et trouver qui peut le résoudre.
J'ai rencontré des chefs de projets qui faisaient tout une affaire d'un simple oubli lors d'une répétition parce qu'ils n'arrivaient pas à maîtriser la facilité de correction définitive alors qu'un petit problème ne pouvant en fait pas être corrigé ne les inquiétait pas.
Je me rappelle une migration de système d'info. J'avais présenté le scénario à la personne habituellement chargée des maintenances en tête à tête. Il m'avait fait part de plein de choses intéressantes et m'avait alerter sur des problèmes potentiels. J'étais arrivé tard sur le projet et bizarrement personne avant moi ne l'avait consulté.
Parfois, l’intérêt du dialogue, c'est juste de forcer l'interlocuteur à présenter clairement ses idées. Plus les choses sont complexes, plus je me méfie. Si l'on a la chance d'avoir des utilisateurs "sympa", on peut les faire réfléchir à leur demande et parfois la simplifier. Ca peut être simplement une colonne dans un état qui demande beaucoup de traitement ; en expliquant à l'utilisateur la difficulté, il peut s'avéré que la colonne n'est finalement pas indispensable. A contrario on peut proposé d'autres choses que l'utilisateur n'avait pas osé demander.
Il me semble qu'une des qualités nécessaire est de faire la synthèse entre les utilisateurs et les développeurs et de faire partager les difficultés des uns et des autres. Un développeur sera plus efficace s'il se sent écouté et si on essaye de lui facilité la vie. De même un utilisateur sera plus conciliant s'il sent que l'on s'intéresse à son boulot.
[^] # Re: Ce n'est pas ce qu'il dit.
Posté par mazarini . En réponse au journal Grabuge à la FSF : GnuTLS quitte le projet GNU et sed perd son mainteneur. Évalué à 6.
Il est quand même nécessaire qu'un chef de projet s'intéresse aux problèmes des gens qu'il encadre. Il faut parfois comprendre un minimum les problèmes, c'est tout a fait possible d'obtenir des informations d'un programmeur pour sentir la gravité d'un problème et trouver qui peut le résoudre.
J'ai rencontré des chefs de projets qui faisaient tout une affaire d'un simple oubli lors d'une répétition parce qu'ils n'arrivaient pas à maîtriser la facilité de correction définitive alors qu'un petit problème ne pouvant en fait pas être corrigé ne les inquiétait pas.
Je me rappelle une migration de système d'info. J'avais présenté le scénario à la personne habituellement chargée des maintenances en tête à tête. Il m'avait fait part de plein de choses intéressantes et m'avait alerter sur des problèmes potentiels. J'étais arrivé tard sur le projet et bizarrement personne avant moi ne l'avait consulté.
Parfois, l’intérêt du dialogue, c'est juste de forcer l'interlocuteur à présenter clairement ses idées. Plus les choses sont complexes, plus je me méfie. Si l'on a la chance d'avoir des utilisateurs "sympa", on peut les faire réfléchir à leur demande et parfois la simplifier. Ca peut être simplement une colonne dans un état qui demande beaucoup de traitement ; en expliquant à l'utilisateur la difficulté, il peut s'avéré que la colonne n'est finalement pas indispensable. A contrario on peut proposé d'autres choses que l'utilisateur n'avait pas osé demander.
Il me semble qu'une des qualités nécessaire est de faire la synthèse entre les utilisateurs et les développeurs et de faire partager les difficultés des uns et des autres. Un développeur sera plus efficace s'il se sent écouté et si on essaye de lui facilité la vie. De même un utilisateur sera plus conciliant s'il sent que l'on s'intéresse à son boulot.