En voyant la rage et l'énergie dépensée, vous vous êtes peut-être dit comme moi : peut-être que c'est important ? Et puis, vous vous êtes repris : Non, ça ne peut-pas être important ! Mais alors, comment lutter contre le brassage de vent ? Car en luttant pour le bon sens, on s'aperçoit que la voie la plus raisonnable n'est pas la plus facile à défendre. Selon moi, l'industrie informatique est en passe d'atteindre la maturité, mais certains comportements radicaux de son adolescence subsistent.
Pour atteindre la sagesse, il convient de considérer les choses avec du recul. Il ne suffit pas d'être rigoureux, il ne suffit pas d'être couvert par les responsable hiérarchique pour bien travailler. L'intelligence n'est pas une vertue strictement positive, dans le sens ou elle constitue un cheminement logique, c'est au contraire la capacité à s'adapter à toutes les situation qui défini le mieux l'intelligence.
L'organisation typique d'une entreprise de développement informatique est la suivante :
- Un bureau des méthodes
- Un chef de projet de réalisation
- Un architecte technique
- Les développeurs
Chacun de ces acteurs sont humains et recherchent à travers leur travail la reconnaissance d'un rôle dans la société. Cet objectif inavoué (et respectable) ne doit pas être oublié pour comprendre des aberrations qu'on rencontre dans la vie des entreprises. Aussi, je voudrais m'attarder à travers l'entreprise sur le sujet tabou des affects et faire de la psychologie appliquée. Les goût qui orientent les vocations de chacun et donc, à tel type de métier correspond un profil psychologique.
Ces acteurs défendent chacun des intérêts propres et déclenchent souvent des conflits d'intérêts, où s'invite le passionel :
Le bureau des méthodes
Le bureau des méthodes a deux objectifs :
- Améliorer la maintenabilité : Donner des normes, poser des exigences de qualité.
- Améliorer la productivité : Fournir des outils et des frameworks, une configuration standard.
Ces deux vocations sont contradictoires. Pour contrer cet antagonisme de surface, suivre la voie du milieu est la meilleure option, mais c'est aussi la plus difficile.
Parce qu'il s'agit d'orienter subtilement les équipes de développement, pour le bureau des méthode, la qualité de la relation avec les équipe de développement est cruciale. Elle passe essentielement par des échanges importants. Une communication ni trop souple, ni trop dure est la solution. Les mails sont utiles, mais rien ne vaut les moyens plus informels pour se comprendre correctement, le téléphone et les réunions. Dans toutes les entreprises que j'ai connues, il n'en est pas une seule ou la relation entre le bureau des méthode et les équipes de réalisation ai été complétement détendue. Ces frictions sont naturelles et inévitable dans une certaine mesure, mais les conflits ouverts ou larvés sont toujours néfastes. Il faut les éviter à tout prix. Il vaut mieux faire des recommandations que des impositions.
Le travers d'un bureau des méthodes est d'alourdir inconsidérément le processus. Le meilleur moyen de ne pas se couper de la réalité du terrain est d'appliquer à soit même ce qui est imposé dans le développement des projets réels, au sein même de l'équipe méthode.
Le chef de projet
Le rôle d'un chef de projet est :
- Optimiser le cout de réalisation
- Augmenter le bénéfice
Encore un fois, dans le cas du chef de projet, il faut naviguer entre deux eaux. Ce n'est pas un rôle facile, car il n'est pas strictement borné en terme d'affectation. Un chef de projet ne doit pas s'enliser dans la technique et perdre son pragmatisme. A l'inverse, sombrer dans la bureaucratie et ne plus comprendre le langage des équipe qu'il dirige constitue un autre travers. Un chef de projet doit mesurer les impacts des modifications demandées et ne pas rester dans un langage utilisant seulement tache, reste à faire, quand etc. Sa vision doit être synthétique. Le distance raisonnable est une affaire d'expérience, ni trop loin, ni trop proche.
L'architecte
Le rôle de l'architecte consiste à :
- Effectuer des choix techniques
- Expliquer et argumenter les solutions
Contrairement au autre rôle, un architecte n'a pas besoin de se préserver d'une schizophrénie. Son rôle est tout à fait positif et requiert essentielement de la pédagogie.
Un architecte technique tend à concevoir ses projets à partir de sa seule expérience. Ce n'est pas mauvais en soit, mais cela conditionne l'hermétisme à d'autres solutions plus pragmatiques. Il faut éviter de sacraliser sa propre expérience. Et puis, c'est une mauvaise communication de commencer à présenter ses solutions par : "Croyez-en mon expérience". La capacité de remise en cause est fondamentale pour éviter les tentacules de la déréliction. Mieux vos décliner patiemment les avantages de votre solution.
Le développeur
Le rôle d'une développeur est de produire un programme conforme à ce qui lui a été demandé.
Le travers d'un développeur est de rechercher la solution immédiate à ses problèmes, sans se préoccuper du long terme. Pour bien faire, il faut penser à ses successeurs. L'inverse peut également se produire, lorsqu'un développeur souhaite utiliser une technologie uniquement pour progresser dans ses connaissances.
Quelque soit votre place dans l'organisation, la meilleure option est de suivre la voie du milieu.
La voie du milieu doit avant tout éviter les écueils typiques :
- Auto référence :
Avec l'avènement d'internet, les experts techniques (le bureau des méthodes) ont tendance à prendre pour argent comptant ce qui est affirmé sur les experts. Ce genre de pratique est tellement généralisé, que les publications d'experts reprennent souvent ce qu'il ont lus d'autres experts : La boucle est bouclée. Cette auto-référence décorelle les vérités d'internet de celle du monde réel.
- Généralisation de l'automatisation :
Dans la recherche de la qualité, l'utilisation des outils fournissant des indicateurs s'est généralisée. De plus en plus fréquement, la qualité d'un code est appréciée suivant des paramètres automatique. Il est bon de rappeler, tout ce qui est automatique se substitue rarement à l'intelligence. La conformité checkstyle n'est en rien la garantie d'un "bon" code. Rien ne vaut un audit de code utilisant de la matière grise.
- Complexité inutile :
L'informatique s'applique toujours à la modernisation. Tout les acteurs ont économiquement des intérêts à promouvoir la nouveauté. Confondre la nouveauté avec l'efficacité est un mensonge défendu à tous les niveaux du secteur informatique. C'est pourtant clairement faux, ne l'oubliez pas. La plupart des projets de modernisation visent à améliorer l'efficacité. C'est seulement en atteignant cet objectif que vous ferez un client heureux.
- Jargonnage :
L'architecture en informatique est un concept flou. Généralement, il s'agit de conception sous toute ces formes : du découpage, des choix techniques, mais ce peut-être aussi des choix d'organisation qui concerne la gestion de projet.
Ce statut incommode manque parfois de respectabilité. Selon moi, le soucis principal des architectes est de se positionner correctement pour avoir une autonomie importante. Il existe deux manières pour ce faire :
- la pédagogie (qui est lente)
- La rétention d'information et le dirigisme envers le développeur
Bien évidement la pédagogie nécessite plus de patience mais elle paie mieux sur le long terme.
Méfiez vous systématiquement de quelqu'un qui utilise trop d'acronymes. Comme dit Pascal, ce qui se conçoit bien s'énonce clairement.
- Exploitation de la peur :
La peur est utilisée pour saigner les clients. Elle sert à vendre des "optimisations" à priori. Alourdissant inutilement l'architecture. Lorsqu'une optimisation est proposée, elle doit correspondre à une volumétrie réelle. Si vous n'êtes pas google, il y a de fortes chances que les meilleures réponses aux problèmes de performance consistent à modifier les processus.
La peur intervient également dans le domaine de la sécurité informatique. Ce n'est pas un hasard si les audits de sécurité sont parmi les plus chers qui soient. Ils font intervenir uniquement des experts. Rappelez-vous simplement ceci, aucune sécurité n'est infaillible. Un chantier de sécurisation sert à placer curseur plus ou moins haut. Si une faille est découverte, cela ne suffit pas à démontrer que le système est mauvais, l'inverse est évidement vrai aussi. la sécurité n'est pas une mesure binaire.
1 commentaire:
Excellent !
Enregistrer un commentaire