Discussion :

[ddoumeche]

Le chef de projet n'est normalement pas apte à mesurer directement la qualité du code, mais le respect des délais donnés par le développeur: c'est à dire que c'est ce dernier qui doit évaluer la tâche, tant techniquement qu'en terme de temps de développement.
La qualité du code est mesurée par le responsable hiérarchique du développeur, l'architecte, voir ses pairs.

La qualité du code est mesurée par le nombre de bugs créés, ou plutôt par le temps de maintenance des nouvelles fonctionnalités. Sachant qu'il est rare que de nouvelles fonctionnalités n'introduisent pas d'incidents, le développeur doit vendre du temps de tests, fait par lui ou des collègues spécialisés.

[Bousk]

[...]délais donnés par le développeur: c'est à dire que c'est ce dernier qui doit évaluer la tâche, tant techniquement qu'en terme de temps de développement.

Belle théorie et doux rêve.
La plupart du temps c'est un groupe de cravateux, parfois même le chef de projet n'y est pas convié, qui se regroupent pour décider des délais, et des features, mettant d'autant plus de pression sur l'équipe de dév.
Quand ce sera réellement comme ça, on en reparlera, mais ce n'est pas le cas.

On est en France, ici c'est le nombre d'heures qui compte. Tu peux passer la moitié de ta journée sur Youtube, si tu finis plus tard que tout le monde et rends "à temps" (ou pas trop en retard/pas trop non fonctionnel/pas trop de morceaux manquant) ce qu'on t'a demandé, tu seras bien vu, même très bien vu parce que "ha Machin il est bien, il travaille beaucoup, finit tard".
Si par contre tu décides de partir à l'heure, quand bien même ça fait 2h que tu ne fais plus rien parce que toutes tes tâches sont réalisées, tu auras droit à réflexion dans de nombreuses boîtes. Alors vouloir partir plus tôt quand tu as fini ta journée, faut pas rêver.

[ddoumeche]

Cela dépend des entreprises, ce qui je décrivais était un idéal, pas forcément le commun de tout le monde.
Nous procédions comme cela dans une PME vendant du service et c'est ce qui marchait le mieux. Mais l'équipe de développement était énorme à l'époque, et ses besoins étaient bien pris en compte, avec un changement d'orientation stratégique vers la qualité logicielle. Il faut dire qu'on revenait de loin, avec des couts de maintenance astronomique et du logiciel de très faible qualité.

Mais bien sur, l'équipe de cravateux existera toujours et c'est elle qui dicte les objectifs et les délais. La question pour les cadres intermédiaire est de gérer les priorités et les délais.

[Excellion]

On croirait un discours de ma boite...

Pour savoir si un employé est un employé "model", il faut regarder s'il part tard.
Peu importe ce qu'il fait d'ailleurs.
Pourvu qu'il parte tard.

Du coup, on assiste à une épidémie de réunionites aigües,
de gens qui passent leur temps à aller d'un bâtiment à l'autre,
et bien sur, à une véritable fringale de photocopies,
sans compter le surf.

Deux personnes n'auront jamais la même appréhension d'une situation.
Certaines se contentent du minimum, d'autres sont des perfectionnistes, et enfin,
certaines, nombreuses chez nous, sont en constante difficulté dès qu'on met un pas en dehors des
sentiers battus.

Donc, non, le nombre d'heures ne reflète rien de plus que le nombre d'heures.
Il faut d'autres éléments pour juger du travail d'une personne...

[Obsidian]

À tout cela, il faut encore rajouter un paramètre : la fatigue intellectuelle. Quel développeur n'a jamais passé deux ou trois heures en fin de journée sur un problème insoluble pour le résoudre en un quart d'heure le lendemain matin à tête reposée ?