1 / Comprendre les fondamentaux du métier
Pour me mettre dans la peau d’un développeur, j’ai expérimenté la création d’une appli en no-code. J’ai expérimenté (à mon échelle) les émotions que l’on peut ressentir quand ça ne marche pas, et qu’on ne trouve pas l’origine du bogue.
L’inventaire approchait à grand pas, et on risquait de faire pleins d’erreurs en modifiants tous le même fichier Excel au même moment. Et puis, un Excel est difficilement tenable dans le temps, les risques d’erreurs sont nombreux et ce n’est pas toujours simple de le tenir à jour.
J’ai utilisé un outil pour créer une application sans prérequis : « Powerapps » et j’ai expérimenté à mes dépens les erreurs classiques qu’on peut faire en développement :
- les ravages d’une faute de frappe,
- la malédiction des formats de dates,
- et pire, la tourmente résultant d’une mauvaise organisation de ses données avec des noms pas clairs. Et quand ce n’est pas clair, personne n’y comprend plus rien : ni le (vrai) développeur qui vient aider à débugger, ni notre « moi » futur qui aura beaucoup de peine à se replonger dans ce bazar.
Conclusion : je ne serais jamais experte en dév (quoique, on ne sait jamais avec floki…) mais je comprends la nécessité de déterminer un scénario simple et de formuler une demande claire.
Pour communiquer, ça simplifie la vie de comprendre le quotidien et les préoccupations des autres membres de l’équipe. C’est pour ça qu’on essaye tous d’être très polyvalent, d’une part parce que c’est enrichissant, et d’autre part parce que ça nous permet de faciliter les échanges.