Last update: 02/06/2016 13:53
Pas vraiment les conditions idéales
L'activité informatique de build/programmation/développement dans les
entreprises de services est réalisée dans des conditions de terrain le plus
souvent inadéquates. Cette affirmation est le résultat des descriptions qui
me viennent de collègues, pairs et amis. Mes propres observations renforcent
le constat.
La conséquence de ces condtions inappropriées est un manque cinglant de
productivité: des projets qui s'enlisent, qui sont livrés tardivement,
avec des budgets pharaoniques .
En quoi les conditions de terrain sont-elles inadéquates?
Permettez-moi de ne pas m'embourber dans une théorie assommante et de vous
présenter une liste non-triée des éléments les plus perturbateurs:
- les heures de travail ne correspondent pas aux moments de créativité
maximale des programmeurs. Il conviendrait de mettre au point des horaires
plus personnalisés (la difficulté ici c'est que les moments de créativité
maximale sont très différents d'un individu à l'autre).
- les bureaux/tables de travail sont exigus et ne permettent pas aux
informaticiens de déployer documents, schémas, livres techniques, …
bref l'attirail habituel de l'informaticien (auquel s'ajoutent aujourd'hui
les inévitables tablette, smartphone, etc.).
- la configuration de l'espace ne permet pas l'isolement (alone-time),
ni les coins de réflexion, encore moins les coins détente, ou des salles
d'exercices physiques.
- le travail organisé en bureau (au contraire du mode plateau) ne convient
pas au travail des programmeurs. Le mode plateau est le plus adéquat mais il
devrait exister des salles "alone-time" qui permettent l'isolement et le
silence (conditions d'accès à ce type de salles).
- le matériel (PC, écrans, claviers, …) est dépassé: un
informaticien/développeur a besoin quasiment du dernier cri
.
- le programmeur est contraint à des outils qui ne lui permettent pas
d'atteindre sa productivité maximale (politique de tooling contraignante).
Il vaudrait mieux laisser le soin à chaque programmeur de prendre l'outil
qui lui convient le mieux (surtout dans la mesure où les outils en question
sont aujourd'hui souvent peu onéreux voire gratuits) et donc de le laisser
décider pour lui-même. Le tooling d'entreprise est souvent obsolète et ne
répond plus aux exigences du moment alors que le tooling en question avance
aussi vite que le reste des technologies. En imposant des contraintes, les
entreprises s'encombrent elles-mêmes d'un travail inutile: énumération
du tooling, comités de décisions sur le tooling (décisions qui viennent
tardivement, communication sur le tooling, …) soit tout un travail
qui doit être organisé pour un résultat inapproprié (over-processing
totalement inutile). Par contre, il existe aussi une catégorie de tooling
d'entreprise à laquelle on ne peut pas échapper (exemples parfaits = système
de versioning, de gestion des sources, …)
- le programmeur ne dispose pas d'une bibliothèque technique, ni physique,
ni digitale … car il n'existe tout simplement pas de budget
"documentation".
- politique d'accès à Internet contraignante. Plusieurs cas m'ont été
rapportés où les programmeurs qui cherchaient des informations techniques
ont été bloqués dans leurs recherches parce que les pages où les réponses
leur étaient données intégraient des
iframes où des vidéos
illustraient la nature du problème recherché et sa solution. Ils en sont
réduits dès lors à continuer leurs recherches sur d'autres sites (perte de
temps, over-processing et waiting-time – cfr. LEAN) ou à effectuer ces
mêmes recherches chez eux, le soir venu.
- les entreprises ne sont pas en phase avec le renouvellement du savoir
dans la sphère informatique. Il est cependant de bon ton dans ce métier de
renouveler la quasi totalité de son savoir tous les 5 ans ce qui tenterait à
nous faire dire qu'il faudrait qu'un informaticien passe 1/5 de son temps à
se former, soit 1 jour par semaine.
- les Project Managers et autres Delivery Managers ne sont pas en position
d'aider les programmeurs car ils sont englués dans des tâches de reporting
qui vont jusqu'au poildecutage.
- pas d'encouragement à l'étude; pas de temps de lecture/apprentissage
prévu dans l'occupation des équipes.
- politique de recrutement parfaitement inadaptée où le diplôme compte
plus que la passion et l'envie de savoir et d'apprendre. Le problème, c'est
qu'après 5 ans le diplôme ne vaut (quasi) plus rien. On veut la belle carte
de visite et on s'occupe peu de la tête bien faite.
- le programmeur ne dispose pas des outils matériels de réflexion comme
tableau, flipchart, marqueurs, … sauf à aller dans des salles de
réunion éloignées de son PC avec ce que cela présuppose comme tableaux qui
sont effacés par d'autres locataires, comme l'impossibilité d'avoir le
tableau sous les yeux de manière permanente, etc.
- les murs, s'ils peuvent être occupés pour des tableaux, doivent être
distants d'une longueur minimale des bureaux pour satisfaire aux conditions
de travail. J'ai connu une situation où un simple tableau de plexiglass
apposé sur le mur a nécessité une réimplantation complète de la pièce et des
bureaux alors que l'espace entre le mur et le bureau demeurait inchangé
(forcément, puisque le tableau était apposé au mur). Il est à noter que des
schémas d'infrastructure de papier étaient épinglés au même mur mais que
cela ne posait de problème à personne!
- le programmeur ne dispose pas des droits d'administration de son PC
alors qu'il en est le meilleur spécialiste: pas possible d'installer
FireFox sur son propre PC alors qu'il souhaite pouvoir bénéficier de FireBug
(simple exemple). Il en est réduit à utiliser des outils archaïques comme IE
6 sans que quiconque s'interroge sur sa perte de productivité.
- les bureaux sont encombrés d'objets qui ne sont plus actuels (téléphone
fixe, clavier obsolète, souris filaire, …
- le nombre de prises électriques est limité à 2 ou 3 ce qui ne rend pas
compte des besoins actuels: 1 ou 2 portables, 1 ou 2 smartphones, 1 ou
2 tablettes, l'inévitable lecteur mp3 (peut-être le smartphone), lampe de
bureau (si autorisation d'en posséder une), …
- les politiques de flex desk sont un énorme frein à sa productivité car
elles présupposent le rangement systématique du bureau (on vit dans une
salle stérile mais pas vraiment un bureau où on travaille pour de bon). Les
mêmes politiques ne tiennent aucun compte de l'environnement fixe (tableaux
kanban d'équipes, kanbans personnels, lieu habituel de standup meeting,
…)
- les politiques de clean desk sont un autre frein énorme à la
productivité du développeur (sensiblement la même problématique que le flex
desk). Néanmoins, le clean desk en lui-même n'est pas le problème car il est
très utile à toute une série de métiers (et d'ailleurs je le rapproche de
LEAN – débarrasser, ranger, nettoyer); ce serait plutôt son
application aux programmeurs que je remets en cause.
- les programmeurs sont trop souvent interrompus par un management
intrusif (questions qui cassent le cours de leur réflexion, le téléphone qui
sonne pour obtenir un statut urgent, une demande de participation impromptue
à une réunion de crise pour obtenir l'avis du spécialiste, …). J'ai
connu une situation où les programmeurs étaient dans un bâtiment séparé où
personne n'était admis sans leur consentement, y compris l'actionnaire
majoritaire, patron de l'entreprise: autre philosophie
manifestement!
- travail administratif souvent trop intense (ou perçu comme tel) comme
par exemple obligation de timesheets avec 100 ou 150 lignes de tâches
possibles. Il en résulte que les programmeurs pointent leur temps sur
presque n'importe quoi pourvu que cela soit vraisemblable et personne ne
s'interroge plus sur la pertinence d'un découpage aussi fin (poildecutage,
over-processing).
- politique d'extinction des lumières à des heures précises avec
prolongations possibles de 15 minutes (ce qui coupe évidemment toute
réflexion et ne permet pas de s'y remettre rapidement avant qu'une nouvelle
interruption de lumière ne survienne)
- dans certains cas interdiction de disposer de son propre matériel de
bureau (lampe de bureau, chevalet, …)
- politique de sécurité complètement inadaptée au travail de
l'informaticien qui en arrive à s'envoyer du code par email parce qu'il ne
lui est plus permis de copier physiquement ledit code sur une clef USB ou
sur un disque dur externe. Voici quelques exemples de parfaite
inadéquation: fichiers dangereux, refus de download de JavaScripts,
refus de transmission par mail de fichiers zip, ou de fichiers exécutables
… Punaise, les gars, c'est justement cela leur boulot à vos
informaticiens!
- locaux exigus encombrés d'armoires datant d'un autre âge
- impossibilité de disposer de pans de mur suffisants (particulièrement
dans des environnements agiles). Les murs devraient leur appartenir pour
qu'ils puissent y mettre les schémas dont ils estiment avoir besoin
comme référence immédiate, pour leurs card walls, pour leurs kanbans,
…
- politiques d'achats trop restrictives. J'ai l'exemple d'un Portfolio
Manager ne pouvant pas acheter des marqueurs effaçables sans passer par un
département "achats" d'une lenteur exaspérante et après avoir rempli 2
formulaires qui devaient être contresignés par le chef de département.
Over-processing évident, waiting-time affolant.
- espaces de stockage disque minuscules (cela vaut pour d'autres types de
fonction également comme les Chefs de projet) là encore issus de politiques
périmées mises en place et défendues par des responsables qui ne le sont pas
moins. Le programmeur dispose d'une centaine de megabytes pour stocker des
myriades d'exemples, de notes, … Bien entendu, le programmeur peut
aussi disposer d'un espace réseau mais il n'ira pas y déposer tout ce qu'il
a tendance à garder, thésauriser.
- assignation du travail dans un mode non ou peu planifié imposant au
final un task switching important (changement de
priorités permanent). Le processeur en arrive à ne plus rien faire d'autre
que du task switching ou pas loin. Il ne faut plus se
demander pourquoi les projets sont chers ni pourquoi ils prennent toujours
davantage de temps.
- modes de travail mixtes de type waterfall-agile mis en place par des
gens qui pensent que … mais ayant peu ou pas de connaissance
pratique (cad qui peuvent justifier d'une expérience passée efficace).
Apparition du modèle "Avalanche" ou du "Water-SCRUM-fall".
- politique de composition d'équipe établie par lien hiérarchique au lieu
d'être changeante en fonction du travail à realiser. Il vaudrait mieux
partir sur des équipes variables pour les projets et des équipes fixes pour
les produits/technologies. Quand un projet est lié à une seule technologie,
alors il faut favoriser l'équipe fixe.
- les départements continuent à être gérés selon un mode qui défend
l'équivalence entre le jour et l'homme. Ignorance complète de
l'avertissement de Frederick Brooks (Le Mythe du mois-homme). Il en découle
que les projets en retard (et ils le sont quasiment tous notamment à cause
des facteurs présentés ici) voient leur staffing augmenter ou alors il est
demandé aux informatiiens de travailler soirs et week-ends. On ignore le
fait que la montée à bord de nouvelles personnes gonfle le travail de ceux
qui ne s'en sortent déjà pas.
- difficulté immense de l'IT de défendre des plannings viables vis-à-vis
du Business. On passse dès lors souvent au "Mettons plus de gens" et on
retombe dans la perversité du mythe du mois-homme.
- politique d'infrastructure inadéquate : il n'est pas rare de voir
le département "infrastructure" réclamer un recurring
cost de 20000 €/an par serveur … ce qui est évidemment
hors de proportion lorsqu'on regarde ce que coûte le même serveur dans un
datacenter indépendant. Dans pas mal de cas il suffirait de quelques
serveurs bien calibrés pour satisfaire les programmeurs et même d'en laisser
la gestion directement aux développeurs (vitesse d'intervention).
- peu (ou même pas du tout) d'empowerment (on ne leur
permet pas de s'auto-organiser … même si au demeurant on leur
demande de travailler en mode agile: cela fait tellement bien de dire
qu'on travaille en mode agile mais on ne sait pas ce que cela veut dire au
fond). Managers champions du Bullshit Bingo!
- interventionnisme du management dans l'organisation du travail. Ce
management-là aurait pourtant bien besoin d'être recentré sur ses réelles
missions et responsabilités et de laisser les gens organiser le travail pour
lequel ils sont rémunérés. Faisons confiance à ceux qu'on paye pour qu'ils
s'organisent le mieux possible et, surtout, ne nous en ocupons pas! On
ne veut pas se faire dire que nous sommes la mouche du coche.
- politiques d'outsourcing parfaitement farfelues (on outsource tout et
n'importe quoi … pourvu que la facture de construction/build soit
moins importante … sans aucune autre réflexion sur les coûts de
réappropriation, des incidences de demandes de changement et autres). Il
n'entre pas dans mon intention de dénigrer les avantages de l'outsourcing
mais ce que je combats ici c'est la manière de s'y prendre et surtout ce
qu'on outsource.
- les processus sont trop complexes et donnent l'occasion à de
nombreux wait-time de ralentir la réalisation
des tâches
- on compartimente encore le travail en des activités qui ne correspondent
plus au monde actuel de l'ingénierie logicielle: analyste fonctionnel,
analyste technique, développeur, testeur. Si ces activités existent toujours,
elles ne sont néanmoins plus réalisées par des profils différents. Il faut
donc être en position de s'adjoindre des profils plus pointus, des gens
capables de faire la synthèse de toutes ces activités dans un seul
cerveau.
Voilà quelques ingrédients de la recette pour devenir "obsolète" de manière
assurée (100% sure!) pour ces entreprises de services qui n'ont pas encore
bien saisi qu'elles étaient devenues des entreprises IT (des entreprises de
software). Il en est ainsi notamment des banques et des assurances .
Come on! It's time to get real!
Our website uses cookies to save your
preferences. We kindly ask you to consent to our use of cookies when you
first visit our website. If you do not consent, the sole recourse is to
stop visiting our website. X
