Revenons dans le passé (Premier jour de travail). José et Olivier ne sont pas encore associés et travaillent chacun pour leurs patrons. Pour sa première expérience, Olivier se voit chargé de la maintenance d’une ancienne application. Lors de l’arrivée d’un nouveau collaborateur, la logique veut que l’équipe en place donne les informations nécessaires pour que le nouvel entrant s’intègre au projet.
Olivier doit remplacer Éric qui part à la fin du mois. Olivier devrait donc principalement travailler avec Éric puisqu’il reprend son travail. Mais l’urgence fait que ce dernier ne peut lui consacrer que très peu de temps. Idem pour le reste de l’équipe. Après une courte présentation fonctionnelle du produit, Marie et Sylviane renvoie Olivier vers la documentation. S’agissant d’un outil de gestion des ressources humaines (GRH), Olivier se dit qu’il pourra comprendre facilement le domaine grâce aux cours de sa formation.
La présentation de Marie et Sylviane était brève. Si elles maîtrisent parfaitement le sujet et le présente bien, Olivier se rend compte en lisant leur documentation qu’il s’avère plus complexe que ce qu’il pensait. Les termes employés sont différents de ceux qu’il connaît par ses cours de RH. Il s’y fera. La documentation fait plusieurs centaines de pages, et la moitié est consacrée à des ‘paramétrages’ et un quart est constitué de schémas qui n’ont rien à voir avec le formalisme étudié à l’école. Le tout expliqué en 1 heure par ses deux collègues AMOA. Et elle lui ont donné une ‘documentation utilisateur’.
La partie métier censée être acquise par notre jeune recrue, place à la partie technique. Ce sera Jean-Claude qui fera la formation, en une demi journée, pause café incluse. La maintenance applicative, surtout si l’application est ancienne, peut présenter plusieurs subtilités :
- le logiciel peut être écrit dans un langage peu répandu,
- sur un framework technique spécifique,
- par des développeurs ‘originaux’.
C’est le cas pour la mission d’Olivier. Et pour parfaire ce tableau Jean-Claude prévoit une formation accélérée. Ici les concepts techniques sont balayées rapidement. “Tu connais SQL ? Pour le requêtage ici c’est pareil. Tu connais le Java et le C ? Le langage ne devrait pas te poser de problèmes, alors !”. Et il enchaîne les verbes spécifiques du langage dans lequel est écrit l’application. Ni plus, ni moins. Pour le schéma de la base de données, c’est un détail qu’Olivier verra lors de ses premiers programmes.
Pour la documentation, John renvoie Olivier à d’obscurs documents, écrits par un développeur à l’origine de l’application, il y a presque 10 ans, qui sont plus des catalogues de variables. Les schémas UML ne devaient pas exister à l’époque, ni aucune autre forme de concepts autres que les lettres de l’alphabet. Les documents sont verbeux, trop verbeux. Et les pages s’enchaînent sans que l’on ne puisse comprendre le but du programme décrit.
Olivier sait que s’il veut intervenir sur cette application, il va devoir la décrire pour lui même. Officiellement, il peut poser des questions aux autres membres de l’équipe. En pratique, ils n’ont jamais le temps de répondre à ses questions. Ils ont plus de temps pour les pauses et les discussions personnelles. Mais ne caricaturons pas.
Lorsqu’on a vu le cycle en V, on a vu que chaque étape de ce cycle est en principe décrite par un document. Même pour la méthode Scrum, la documentation est présente, en principe. En pratique, il s’agit du premier élément sacrifié lorsque le projet commence à prendre du retard. Et il est rare qu’un projet se finisse dans les temps.
Sans plan de formation correctement établi avec des présentations et des documentations précises et complètes, la montée en compétence sur un domaine peut être difficile. Si rien n’est prévu, il faut compter sur les autres membres de l’équipe. Là on rentre dans le domaine des relations humaines et rien n’est sûr. Il reste bien souvent notre intelligence et notre capacité d’adaptation.
Olivier est intelligent et se dit que ce qu’il n’a pas trouvé auprès de ses nouveaux collègues, il le comprendra en étudiant l’application elle même. Un structure cohérente et des commentaires dans les programmes permet de pallier à une absence documentaires … ou pas 😉