Discussion :

[DonQuiche]

C'est amusant, je bosse depuis 17 ans maintenant dans le monde de l'informatique et je n'ai pas identifié les mêmes types de Chef de Projet pour l'instant.

Il n'y a pas plusieurs types de chefs de projet. Il y a une seule fonction, dont la définition est la même partout. Et puis de l'autre côté il y a la réalité où chaque organisation a ses propres contraintes, et où l'on n'utilise pas 50 personnes quand il en faut cinq.

Est-ce qu'un dév est un sysadmin ? Non, bien sûr. Et pourtant, combien d'entre nous ont déjà déployé des projets ? Est-ce qu'un dév est un chargé de clientèle ? Non, bien sûr, et pourtant combien d'entre nous ont déjà eu à devenir le principal interlocuteur du client pendant un temps ?

Par contre, en te lisant, j'en viens à une autre question: C'est quoi un chef d'équipe ?
C'est quoi la charge de travail et la responsabilité que tu vois dans un CE qui n'est pas celle du CP ?
Pour un petit projet, c'est le CP qui le fait, mais pour un projet moyen, le CE fait quoi?

Il fait ce qui est nécessaire pour avoir l'équipe la plus efficace possible et faire en sorte qu'elle soit utilisée au mieux.

* Ressources humaines (en accompagnement avec la direction des RH) : recrutement, évaluation, support, renvoi, etc. Offrir une formation à untel, apparier un junior, proposer un défi plus stimulant à tel excellent dév qui s'ennuie et pourrait partir, etc.
* Animation : faire en sorte qu'une réunion dure dix minutes et pas soixante, maintenir des dynamiques positives dans l'équipe.
* Planification : il subdivise les tâches et les distribue à chacun.

[Saverok]

* Ressources humaines (en accompagnement avec la direction des RH) : recrutement, évaluation, support, renvoi, etc. Offrir une formation à untel, apparier un junior, proposer un défi plus stimulant à tel excellent dév qui s'ennuie et pourrait partir, etc.

Un CP n'a pas de fonction RH.
Par contre, il fait des recommandations au service RH ainsi que des retours d'expérience suite à la réalisation d'un projet.

Le service RH, au moment des entretiens annuels, vient voir le CP pour demander ce qu'il pense d'untel car il a bossé sur un de ses projets au cours de la dernière période.
Mais en aucun cas, il ne décide de quoique ce soit sur ce plan là.
Tout au mieux, il influence, mais ça s'arrête là.

Un CP manage un projet et une équipe.
Son influence se limite au cadre du projet et sur la durée de celui-ci.
Le suivi RH est sur plus long terme.

Par contre, je te suis bien sur ton dernier exemple : offre un défi stimulant à un dev qui s'ennui"
Ce sur cas là, c'est du pur management de projet dans le sens "animation de l'équipe".
le CP repère les différents profils et potentiels des membres de son équipe et les utilise au mieux pour son projet.
Parfois, cela coïncide avec des objectifs RH mais ce n'est pas le but premier sur le moment.

[DonQuiche]

Par contre, il fait des recommandations au service RH ainsi que des retours d'expérience suite à la réalisation d'un projet. (...)
Un CP manage un projet et une équipe.
Son influence se limite au cadre du projet et sur la durée de celui-ci.
Le suivi RH est sur plus long terme.

Dans certains cas ça peut tout à fait être la rôle du chef de projet que de monter une équipe. Et dans ce cas il sera l'initiateur des recrutements et celui qui aura le dernier mot à leur sujet. Par exemple un projet de long terme nécessitant des recrutements ad hoc.

Évidemment ce ne sera pas le cas si le projet doit durer trois mois ou qu'il le prend en cours de route. Dans ce cas il devra faire avec ce que l'entreprise lui propose.

[Laurent 1973]

Il n'y a pas plusieurs types de chefs de projet. Il y a une seule fonction, dont la définition est la même partout. Et puis de l'autre côté il y a la réalité où chaque organisation a ses propres contraintes, et où l'on n'utilise pas 50 personnes quand il en faut cinq.

Comme en faite on s'adapte toujours au contexte du projet, je reviens bien a ce que je disais avant
Aucun CP ne fait réellement la fonction officiel et il y a autant de CP différents que de projet.

Donc, CP, c'est un peu le manager fourre-tout qui fait ce qui faut faire comme il veux bien le faire pour que le projet avance autant que faire ce peux.

[landry161]

Chez nous il y a un proverbe qui dit un enfant au dos ne sait pas que la route est longue.

[bac_a_sable]

Il y a CP et CP; malheureusement bien souvent il y a aussi un CP chez le client; du coup la demande fait:
Moi->mon CP->CP client->Technicien client->CP client->mon CP->moi

Dans ce schéma, la réponse qui revient n'a bien souvent plus rien à voir avec la demande initiale et elle a mis deux jours à arriver.
Et on est reparti pour deux jours pour redemander la même information... et le délai n'a pas bougé

[hubertcharles]

Il y a différents niveaux de compétences tant pour les CP et les analystes que pour les programmeurs.
Si après quelques mois ou quelques années de maintenance un programmeur peut se débrouiller seul, c'est rarement vrai pour un nouveau projet, surtout si on travaille dans une SSII et qu'en changeant de client on change de domaine d'activité.
Le passage de programmeur à analyste ne va pas de soi, et j'en parle d'expérience.
Trop d'analystes ou prétendus tels n'approfondissent pas leur étude et le programmeur doit se débrouiller comme il peut.
Un analyste digne de ce nom doit être capable de poser les bonnes questions aux utilisateurs et faire un bon dossier sans tomber dans le travers de faire une analyse "technique" avant la lettre. Le document peut alors être programmer en Inde ou ailleurs sans problème. Personnellement j'ai eu le cas et ce fut même le meilleur projet de ma carrière parce que conscient de la difficulté, la hiérarchie nous a donné le temps nécessaire à un travail soigné.

[landry161]

Sommes nous plus crédible quand on annonce un délais de X semaines et qu'au final on livre en X+n semaines parce que comme à chaque fois on ne peut pas prévoir l’imprévisible.
Perso je suis pas capable d'annoncer un délai réaliste avant d'avoir les mains dans le code depuis un petit moment tout simplement parce que avant je n'ai pas une connaissance suffisante du projet, de sa courbe d'évolution, etc ...
C'est encore plus vrai quand on reprend de l'existant et qu'on va de surprise en surprise au fur et à mesure qu'on s'enfonce dans le code.

Très juste.

[phanpile]

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 ...

[Laurent 1973]

...
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.
...
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 a
algorithmique soit en lien avec un ensemble de technologies.
...
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 comme les mooc, etc. 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.
...

Ta remarque est interessante par contre, je ne vous pas comment pouvoir évaluer dans l'absolut un développeur.

On pourrait, en effet, comme pour le TOEIC, imaginer un test de 4h, un super QCM, sur des questions d’algorithmie.
Mais, est-ce que notre travail se limite à l’algorithmie?
Non: nous avons aussi des compétences en analyse de problématique métier, contrainte matériel dû à un contexte particulier et puis notre expérience et connaissance d'une technologie est importante aussi.

On pourrait imaginer alors un mega test sur une techno.
Cela existe déjà je crois sur des certifications Java, .Net, ....
Mais est-ce finalement ce qui fait des bons développeurs?
Cela ne valide pas non plus leurs capacités à comprendre un problème donnée.

Autre point, qui rendrait difficile l’évaluation qualitative d'un développeur: nos projets ne se ressemble pas.
Prenons par exemple 2 projets, réalisé dans la même techno, mais pas avec une qualité initial de développement opposée:
- la première avec des tests d'anti-régression (unitaire et fonctionnel), des stress tests, des normes de codages, des documentations d'architecture, des tutoriels de maintenance, de procédure de mise en production ....
- l'autre rien de tout cela: un gros tas de spaghettis.
Les créateurs de ces solutions sont tous parties et nous confions la nouvelle maintenance à un développeur connaissant la technologie.
Il y a de grande chance, qu'il sera beaucoup plus véloce pour corriger ou améliorer le premier projet que le second.
Est pour le cas que dans le 1er c'est un très bon développeur et dans le second un développeur médiocre?

On voit bien que l'évaluation d'un développeur ne peux pas être absolut, c'est forcement relatif à un contexte technologique et contenue de contrainte du moment.
Le parallélisme pourrait peut être se faire aussi chez les médecins.
Est-ce qu'un médecin est bon au nombre de médicament qui prescrit? au nombre d’arrêt maladie? a la queue dans sa salle d'attente?
Ça va dépendre de son parcours professionnels, de sa clientèle forcement particulière d'une région à l'autre, ....

Pourquoi vouloir classer les développeurs?
Est-ce que l'on ne veux pas 'numériser' quelque chose qui justement n'est pas aussi quantifiable que cela: les ressources humaines ?
Si c'est possible, alors j'invite nos amis RH a vite se reconvertir: on n'aura bientôt plus besoin d'eux.
On les remplace par un QCM et un logiciel de traitement, bienvenu à Gattaca, l'avenir des développeurs est tout tracé.

[Saverok]

Autre point, qui rendrait difficile l’évaluation qualitative d'un développeur: nos projets ne se ressemble pas.

[...]

On voit bien que l'évaluation d'un développeur ne peux pas être absolut, c'est forcement relatif à un contexte technologique et contenue de contrainte du moment.

Justement, dans le cadre d'un exam, tout le monde est au même niveau car évalué dans le même contexte.
De même, les capacités de compréhension d'un problème s'évaluent parfaitement tout comme les connaissances purement techniques.
Ce sont juste des tests différents.

Le parallélisme pourrait peut être se faire aussi chez les médecins.
Est-ce qu'un médecin est bon au nombre de médicament qui prescrit? au nombre d’arrêt maladie? a la queue dans sa salle d'attente?
Ça va dépendre de son parcours professionnels, de sa clientèle forcement particulière d'une région à l'autre, ....

Je pense que tu mets de la complexité là où il n'y en a pas.
Un médecin est évalué à sa capacité à faire un diagnostique juste en utilisant les moyens appropriés ( pas d'examens inutiles par exemple).
Et du coup, à prescrire un traitement adaptés à chaque patient et à savoir le réévaluer au cours de route.
Pour finir, si besoin, orienter son patient vers un vers un spécialiste adapté à sa pathologie.

Le parallélisme avec un analyste programmeur est par ailleurs assez bon.
Un bon AD n'est pas un AD qui développe vite mais un AD qui effectue une bonne analyse de situation, qui comprend une problématique dans son ensemble et est en mesure de proposer une solution adaptée (en fonction du contexte métier, logiciel et matériel) et qui sait faire appels aux compétences de collègues plus aux faits dans une compétence donnée.
L'excuse du "je ne sais pas évaluer mon RAF car le soft est développé avec les pieds" ne tient pas la route.
On ne cherche pas à déterminer le temps de dev standard d'une même fonctionnalité quelque soit le projet. Ça n'a pas de sens. Comme tu le dis, chaque projet est différent.
Ca ne change rien à la capacité d'analyse.
Un AD doit savoir évaluer son RAF quelque soit le projet en s'adaptant à celui-ci.
Ainsi, un AD peut parfaitement donner un chiffrage différent pour une même fonctionnalité sur 2 projets différents car justement, le projet (et son contexte) est différent.
Le tout est de savoir le justifier et cette justification vient de l'analyse.

[Laurent 1973]

Justement, dans le cadre d'un exam, tout le monde est au même niveau car évalué dans le même contexte.
De même, les capacités de compréhension d'un problème s'évaluent parfaitement tout comme les connaissances purement techniques.
Ce sont juste des tests différents.

Je ne met pas en question la nature d'un examen de ce type.
Mais plutôt la corrélation que l'on peut faire entre:
- bonne note à l'examen = bon développeur
- mauvaise note à l'examen = mauvais développeur

Par ce qu'un examen est justement théorique et ce que l'on voudrait savoir c'est si un développeur est bon en pratique.
C'est la même question que l'on peux se posé sur la pertinence d'un tests technique au cours d'un processus de recrutement.

[phanpile]

Tout d'abord je ne suis pas tellement d'accord sur le fait qu'une bonne note à un examen de test de compétences ne serait pas en rapport avec la capacité réelle sur le terrain. Si c'est le cas c'est l'examen qu'il faut revoir.

On ne va pas ici développer une théorie de ce qu'est une évaluation de compétences. Mais en résumé, si l'on souhaite mettre une note à quelque chose ou à quelqu'un au sein d'un groupe de choses ou de personnes comparables (les frigos, les services bancaires, les dentistes, les développeurs, les directeurs financiers, ...), on définit un contexte, des tests et une méthode d'évaluation ; on explique clairement tout ça et ensuite on applique.

Ce n'est pas nouveau. Les examens scolaires, les évaluations annuelles dans les sociétés, les tests de matériels ou même de services dans les magazines de consommateurs, tout est basé sur la même logique. Et effectivement, certaines entreprises l'ont mis en place en interne avec des tests techniques lors du recrutement. Ce qui prouve que ce n'est ni nouveau ni extravagant.

L'idée serait juste de le sortir de l'entreprise A ou B pour en faire quelque chose de plus universel. Du coup cela pourrait aider à la promotion des développeurs.

Plus facile à dire qu'à faire, bien sûr. Pas la peine de me lister tout ce qui pose problème là dedans ...

Toutefois, pour illustrer cela en reprenant l'exemple du TOEIC :
- Tout le monde a le même examen dans quasiment les mêmes conditions
- On s'abstrait des problématiques techniques (au téléphone, dans la rue, par écrit ...)
- On s'abstrait des problématiques métier (ce n'est pas de l'anglais technique par exemple)
- On s'abstrait des problématiques culturelles (ce n'est pas du Shakespeare, ni de l'argo New Yorkais)
- etc.
Et à la fin on a quand même quelque chose qui fait sens. Avec mes 780, je parle bien moins couramment que quelqu'un qui a 950. On peut le tourner dans tous les sens (oui, mais c'était la nuit, il y avait du bruit au téléphone, bla bla bla), à la fin cela reflète la réalité.

Le TOEIC est un exemple intéressant car il se trouve que les grandes entreprises ont souvent accepté de payer pour ce test au cours des dernières années au lieu de se baser (ou en complément de) sur des estimations ou impressions de RH, de supérieurs ou de collègues (plus ou moins doués en anglais eux-mêmes) et il est de ce fait devenu un standard.

De plus, un maçon ou un carreleur peuvent vous montrer les photos de leurs réalisations ou même vous faire visiter. Un fabricant de matériel peut se baser sur de multiples tests, avis et évaluations. Mais sauf évaluation personnelle et ciblée le talent ou les faiblesses d'un traducteur d'anglais ou d'un développeur sont invisibles.

Ceci hormis bien sûr quelques réalisations extraordinaires personnelles (d'accord Steve Wozniak et Mark Zuckerberg sont doués en programmation, pas besoin de test)

A suivre ...

[Laurent 1973]

Petite question sur l’évaluation (un peu taquine)

Comment évaluerais tu alors, dans ta logique, un artiste?
L'art est par définition assez relatif, or on a besoin d'artiste aussi dans les entreprises.

Déjà, pour rester dans nos domaines informatique, comme définir qu'un infographiste est bon?
Pourtant, la réussite de bon nombre de produit informatique (d'autant plus vrai dans les jeux) dépendant d'un bon graphiste.
"angry birds" aurait pu fait un gros flop si le graphiste n'avait pas été à la hauteur, parce que si on réfléchi bien, le jeu est un simple casse brique

Comment identifier la créativité? l'innovation.?
Est ce qu'un développeur n'est qu'un technicien de l'informatique?

[DonQuiche]

Tout d'abord je ne suis pas tellement d'accord sur le fait qu'une bonne note à un examen de test de compétences ne serait pas en rapport avec la capacité réelle sur le terrain. Si c'est le cas c'est l'examen qu'il faut revoir.

Pour commencer tu pars du principe qu'il est possible de mettre au point un bon indicateur pour n'importe quoi. Ce qui est faux.

Ensuite partant du principe que toute quantification de ce genre est affectée d'une marge d'erreur tu dois vérifier si celle-ci est compatible avec l'usage qui en est fait et sinon reconsidérer le protocole qui requiert cette quantification.

Enfin tu peux éventuellement avoir recours au cerveau humain, c'est à dire à une machine capable d'analyser des milliers de paramètres flous pour en tirer une évaluation. Dans de nombreuses situations réelles cela reste pour l'instant une approche plus fiable que n'importe quel algorithme.

[el_slapper]

+1 avec Laurent 1973, évaluer une compétence de suivi de process est faisable par un process. L'Anglais, après tout, n'est qu'un process de communication, que l'on connait, ou que l'on ne connait pas. On peut faire le score max au TOEIC, ça ne fait pas de nous des Shakespeare.(et pareil pour les autres langues, hein, je ne tape pas sur l'anglais).

Quand mon chef vient me voir en me disant "on a un problème, on a oublié de faire un programme, on avait compté 10 jours, tu en as 2", aucune compétence technique mesurable ne peut me permettre de m'en sortir. Par contre, en étant créatif, je peut trouver des chemins de traverse et faire une solution complète, modularisée, lisible et maintenable en 2 jours. Mais ça nécessite que je trouve tout de suite une solution pour faire autrement que ce qui est fait d'habitude - et qui avait été le prélude au chiffrage initial.

Aucun test ne peut mesurer ça.

On peut parfaitement mesurer mon degré de connaissance de la syntaxe COBOL(que nous utilisions sur ce sujet), mesurer ma capacité à comprendre les règles d'un langage que je ne connais pas encore(ce que ma boite actuelle m'a fait faire, vu qu'ils utilisent un langage exotique, ça se tient), ou encore mesurer ma résistance au stress. Mais pas ma capacité à trouver un moyen de résoudre un problème que l'auteur du test n'a jamais rencontré. Ça, c'est de l'art, et c'est forcément subjectif. Et c'est le quotidien d'un paquet de développeurs. J'ai du faire preuve de qualités artistiques(dans le sens "capacité de création novatrice") dans à peu près la moitié de mes missions en SSII, et chez mon éditeur de logiciel actuel. Je ne pense pas être un hasard, ou une exception. C'est la norme. Mes collègues, autour de moi, régulièrement, font face à des problèmes jamais défrichés, et ceux qui sont bons trouvent des solutions novatrices et efficaces. Et tant qu'on ne les a pas vu faire, on ne sais pas si ils sont bons. Et comme c'est de l'art, en plus, c'est un peu aléatoire - la créativité n'est pas quelque chose de systématique.

[Saverok]

On peut parfaitement mesurer mon degré de connaissance de la syntaxe COBOL(que nous utilisions sur ce sujet), mesurer ma capacité à comprendre les règles d'un langage que je ne connais pas encore(ce que ma boite actuelle m'a fait faire, vu qu'ils utilisent un langage exotique, ça se tient), ou encore mesurer ma résistance au stress. Mais pas ma capacité à trouver un moyen de résoudre un problème que l'auteur du test n'a jamais rencontré. Ça, c'est de l'art, et c'est forcément subjectif. Et c'est le quotidien d'un paquet de développeurs. J'ai du faire preuve de qualités artistiques(dans le sens "capacité de création novatrice") dans à peu près la moitié de mes missions en SSII, et chez mon éditeur de logiciel actuel. Je ne pense pas être un hasard, ou une exception. C'est la norme. Mes collègues, autour de moi, régulièrement, font face à des problèmes jamais défrichés, et ceux qui sont bons trouvent des solutions novatrices et efficaces. Et tant qu'on ne les a pas vu faire, on ne sais pas si ils sont bons. Et comme c'est de l'art, en plus, c'est un peu aléatoire - la créativité n'est pas quelque chose de systématique.

La capacité à résoudre un problème n'est pas de l'art, c'est de la logique.
La logique, ça se mesure également.
De même que la qualité du résultat obtenu (temps de réalisation + qualité du code + perf + robustesse + taux de couverture des besoins métier etc, etc, etc)

L'art est subjectif et ne se mesure pas.

Le job de développeur est un job technique mais s'il fait appel à énormément d'abstraction, cela reste technique.
Cela n'a rien de péjoratif tant il est de haute complexité.
On peut donc parler de haute technicité (mais technique tout de même ).

[el_slapper]

La capacité à résoudre un problème n'est pas de l'art, c'est de la logique.
La logique, ça se mesure également.
De même que la qualité du résultat obtenu (temps de réalisation + qualité du code + perf + robustesse + taux de couverture des besoins métier etc, etc, etc)

L'art est subjectif et ne se mesure pas.

Le job de développeur est un job technique mais s'il fait appel à énormément d'abstraction, cela reste technique.
Cela n'a rien de péjoratif tant il est de haute complexité.
On peut donc parler de haute technicité (mais technique tout de même ).

Pas d'accord. On a beaucoup de technique, certes, mais ça ne suffit pas. Je connais la technique pour mapper un fichier, bon, j'en ai 18 à mapper, j'en fait 18! En fait non, j'en reviens à mon exemple, j'ai créé ex-nihilo une structure complète, non répertoriée, qui encapsulait les 18 mappings en question. Ce n'est pas (enfin, pas seulement), de la technique. C'est de la création.

La capacité à résoudre un problème connu, ça se mesure. Construire un tunnel sous la manche, ça a été fait, on sait que c'est faisable, on sait comment les précédents on fait, donc si il faut le refaire, on pourra dire "c'est de la technique". Poser un composant de 40 tonnes sur Mars(nécessaire pour y poser des humains), on ne sait pas faire, et trouver un moyen de le faire, ça sera de la création.

Ma petite moulinette n'est évidemment que poussière en comparaison. Mais chaque jour, des milliers de collègues sont confrontés à des problèmes pour lesquels il n'existe pas de solution répertoriée, et il faut en créer une. Ou alors la solution répertoriée n'est pas satisfaisante, et il faut en trouver une autre. Ce n'est pas juste de la technique. ce sont rarement de grandes inventions(je n'en ai aucune à mon actif), mais ce sont des inventions quand même, et un collègue qui connait bien la technique, mais n'a aucune imagination, ne saura pas s'en sortir.

[Saverok]

Pas d'accord. On a beaucoup de technique, certes, mais ça ne suffit pas. Je connais la technique pour mapper un fichier, bon, j'en ai 18 à mapper, j'en fait 18! En fait non, j'en reviens à mon exemple, j'ai créé ex-nihilo une structure complète, non répertoriée, qui encapsulait les 18 mappings en question. Ce n'est pas (enfin, pas seulement), de la technique. C'est de la création.

C'est de la conception et de la modélisation.
C'est un acte de création technique, c'est la valeur ajoutée d'un ingénieur, au sens historique du terme (https://fr.wikipedia.org/wiki/Ing%C3%A9nieur).

Un ingénieur n'est pas un artiste.
L'inverse peut parfois être vrai (cf les architecte du bâtiment ou les designers).

Il ne faut pas confondre ingénierie et l'artistique.

[GeoffreyOnRails]

Pas d'accord. On a beaucoup de technique, certes, mais ça ne suffit pas. Je connais la technique pour mapper un fichier, bon, j'en ai 18 à mapper, j'en fait 18! En fait non, j'en reviens à mon exemple, j'ai créé ex-nihilo une structure complète, non répertoriée, qui encapsulait les 18 mappings en question. Ce n'est pas (enfin, pas seulement), de la technique. C'est de la création.

La capacité à résoudre un problème connu, ça se mesure. Construire un tunnel sous la manche, ça a été fait, on sait que c'est faisable, on sait comment les précédents on fait, donc si il faut le refaire, on pourra dire "c'est de la technique". Poser un composant de 40 tonnes sur Mars(nécessaire pour y poser des humains), on ne sait pas faire, et trouver un moyen de le faire, ça sera de la création.

Ma petite moulinette n'est évidemment que poussière en comparaison. Mais chaque jour, des milliers de collègues sont confrontés à des problèmes pour lesquels il n'existe pas de solution répertoriée, et il faut en créer une. Ou alors la solution répertoriée n'est pas satisfaisante, et il faut en trouver une autre. Ce n'est pas juste de la technique. ce sont rarement de grandes inventions(je n'en ai aucune à mon actif), mais ce sont des inventions quand même, et un collègue qui connait bien la technique, mais n'a aucune imagination, ne saura pas s'en sortir.

Ton exemple me fait énormément penser à un problème de mathématiques.
Dans ton cas, pour faire l'analogie, tu aurais trouvé une jolie petite astuce créative dont tu es très fier pour rendre ta démonstration plus efficace (sans doute à raison, j'ai pas très bien compris ton exemple ).
Mais tout comme le niveau en maths ou la capacité à trouver des démonstrations aux problèmes, la capacité à trouver des réponses aux problèmes IT (voire des réponses efficaces), ça se mesure très bien (en tout cas ça se mesure).

Pour répondre à el_slapper, la création, ça n'est pas quelque chose de purement aléatoire. Quand tu as vu un certain nombre de problèmes connexes et que tu en connais les meilleures solutions (best practices), quand tu sais comment bien poser tes problèmes de manière claire, tu vas pouvoir beaucoup plus facilement créer / réexploiter une bonne solution pour ton sujet. Et ça s'apprend, ça se travaille.
Certes, tu peux avoir une super idée révolutionnaire en te levant un matin après une bonne nuit, mais selon moi ce n'est pas ce qu'on cherche à mesurer ici, ni ce dont on a besoin au quotidien.