Evaluons donc les programmeurs ...
Moi même ex développeur, analyste, CDP, etc, je m’apprêtais à poster une réponse aux développeurs sur la nécessité d'une structure car je n'avais lu que les premiers commentaires de développeurs disons ... libertaires ...
Il me semble que réponse leur a été donnée sur ce point car il est nécessaire de centraliser la connaissance, le planning, l'organisation et les décisions, de prévoir et de capitaliser (voir en particulier les réponses de Saverok et _skip). Ceci ne peut être fait que par un CP (ou une équipe dédiée selon la taille du projet).
Pour répondre à Laurent_1973 au sujet de la connaissance du métier du client, les développeurs n'ont pas forcément à être laissés dans l'ignorance, mais dès que l'on a une équipe de plus de 3 personnes, si tout le monde doit être au courant de tout, plus personne n'a le temps de travailler.
Concernant le rôle centralisateur de connaissance du CP : il est effectivement dilué dans le cas des méthodes agiles, mais pas supprimé pour autant : quelqu'un doit faire l'inventaire, le suivi et garder vivant l'ensemble des décisions prises.
Enfin, pour tous les développeurs incompris et brimés, ils pourraient peut être tenter de raisonner par l'absurde :
Supposons 10 développeurs dans une pièce travaillant sur un projet pour un client sans structure au dessus : que se passerait il lorsque le client appellerait pour connaitre sa date de livraison, pour demander une modification non pas dans un écran ou une règle de gestion précise mais dans l'organisation d'un processus transverses ? Que se passerait il lorsque le client demanderait : combien cela me couterait-il de passer mon produit de SQL Server à Oracle ? (ou l'inverse), etc. etc.
Dans tous ces cas et bien d'autres, le développeur est bien heureux de pouvoir "renvoyer au dessus", et éventuellement montrer du doigt ensuite quel chef d'équipe, architecte, scrum master, cp, commercial, patron ... a fait une mauvaise réponse ou une mauvaise évaluation ...
Je ferais toutefois deux remarques complémentaires :
Concernant la qualité : ce qui est dit au départ n'est pas faux : on ne peut pas faire bien et vite et si on fait mal au départ, ce sera plus cher ensuite. Ceci est vrai mais se heurte à une réalité que l'industrie informatique, ses RH et les développeurs eux-même ont du mal à gérer : cela dépend de la capacité du développeur à produire du code de qualité (il existe aussi des développeurs qui font lentement et mal - si, si, je vous assure, j'en ai rencontré) et ouvre donc à ma réflexion sur le statut du développeur.
Concernant le statut du développeur, il y d'abord un aspect culturel : au moins en France (il me semble que c'est moins vrai par exemple aux Etats-Unis), rien ne ressemble plus à un programmeur qu'un autre programmeur. Et un programmeur de 45 ans est souvent vu comme un informaticien qui n'a pas réussi à devenir CP.
Toutefois, les services RH (qui eux non plus ne sont pas forcément des fainéants incompétents), s'ingénient dans toutes les grandes boîtes à inventer des notations et classements pour les collaborateurs afin de mieux les employer et/ou les faire progresser (parfois de les punir). Les notions retenues dans ce cadre sont en général les capacités d'organisation pour soi ou les autres, le suivi des consignes, le sérieux, la motivation, la capacité de négociation, de management, etc.
Lorsque l'on cible plus précisément l'activité de développement, on peut au mieux parler :
- d'expertises (Formations, parfois certifications ...)
- d'expériences (Pratiques et durées)
Et des notions suivantes, qui remontent rarement en l'état du CP au RH :
- la tenue des délais (qui n'a pas forcément de sens suivant la complexité cachée ou la qualité produite)
- le taux de retour d'anomalies (dans certains cas)
- l'estimation des CP (il est bon, il va vite, ou l'inverse)
Mais pas grand chose - toujours à ma connaissance - permettant de mesurer réellement la qualité de programmation d'un développeur par rapport à un autre, soit dans une même société, soit même world-wide et il est certain que l'expérience ne fait pas tout.
Toutes les inventions des 20 dernières années que ce soit pour la réalisation (L4G, frameworks divers), ou en évaluation (analyse de code style CAST, méthodes ISO, CMMI, outils de tests ...) s'inquiètent de la qualité d'un développement logiciel global (même si par la bande, on peut parfois relier la qualité de réalisation d'un module à son programmeur).
Il me semble que si l'on voulait promouvoir la qualité logicielle au niveau le plus bas (forcément nécessaire), il faudrait pouvoir évaluer sérieusement la capacité d'un programmeur à un instant t à produire du code de qualité - soit au niveau algorithmique soit en lien avec un ensemble de technologies.
Il me semble que les encadrants seraient ainsi aidés dans leur boulot d'affectation de tâches, et que les programmeurs eux-même y gagneraient eu leur permettant de se positionner par rapport à leurs collègues (je suis très bon ici, je dois me former ou faire des efforts là, je ne souhaite pas intervenir dans ce domaine ...). Une telle évaluation leur permettrait aussi de pouvoir se positionner dans une grille de rémunération et de capacité d'intervention qui se fait beaucoup "au jugé" à l'heure actuelle, que ce soit dans l'entreprise, le service ou sur le marché free-lance.
Les autres métiers sont notés sur des ressentis mais aussi sur des grandeurs mesurables (pour un commercial par exemple : nombre de prospects, de signatures, CA généré, etc). Pourquoi ne pourrait on pas faire de même avec un programmeur ? La tenue des délais et le taux de retour d'anomalies ne sont à mon avis clairement pas suffisants, il faut aller voir "ce qu'il y a dans la boite".
Ceci se heurte à une problématique pratique d'évaluation : la qualité d'écriture d'un composant logiciel est parmi les plus difficile à évaluer (encore plus qu'un composant électronique ou qu'une pièce manufacturée, de qualité mesurable, pouvant parfois même être perçue à l'oeil nu), et ce en particulier parcequ'en dépit des myriades de frameworks ou méthodes disponibles, chaque module de code est une pièce unique. Je n'ai pas trouvé mieux que la relecture de code pour ça, mais c'est irréalisable de façon industrielle et unifiée.
Peut être, parallèlement à la formation pourrait-on organiser dans chaque domaine des sessions d'évaluations annuelles par exemple. Les éditeurs de solutions de formation en ligne pourraient peut être proposer des outils adaptés aux entreprises ou aux programmeurs eux-mêmes. J'ai rapidement vu des outils, mais - toujous à ma connaissance, car je ne passe pas mon temps là dessus - encore rien auquel un programmeur puisse se référer auprès d'un client ou d'un employeur comme un niveau TOEIC d'anglais par exemple.
Enfin, je parie sur le fait qu'un programmeur capable de produire du code de qualité lors d'un examen, en produira aussi en développement. Mais comme cela va en général de pair avec un moindre effort et une satisfaction personnelle supérieure, je pense que c'est raisonnable.
Sur ce, bon développement à tous ...