Pourquoi les entreprises japonaises perdent-elles leurs programmeurs ? Si les discussions ne manquent pas sur le sujet, on compte peu récits de gens qui racontent leur propre expérience. Le blogueur et programmeur Ryo Asai (@ryoasai74) en livre un sur son blog “Becoming a Master Programmer” (Devenir un Champion de la Programmation). Asai a postulé récemment pour un emploi chez Amazon Japon et a été retenu.
En tant qu'employé d'une entreprise étrangère (Amazon), le plus stressant pour moi, c'est de communiquer en anglais. Lors du déjeuner de bienvenue, j'étais soudainement au milieu d'étrangers dont je ne connaissais même pas le nom. Puis, il y a les télé-conférences en anglais avec les équipes basées en Chine ou aux États-unis. Je comprends très mal l'anglais, il m'est donc très difficile de suivre tout à fait une conversation en anglais, même si mes collègues et mes managers se montrent tous aimables en faisant la traduction pour moi, ce qui m'apaise beaucoup. Je suis plutôt du genre à m'adapter difficilement à un nouvel environnement, et je ne me suis pas encore totalement fait à mon nouvel emploi, mais j'apprends progressivement comment les choses marchent et m'efforce de m'adapter et de faire partie intégrante de l'équipe.
Même si je n'en suis pas encore au point où je peux affirmer que j'ai compris la culture qui prévaut dans ma nouvelle boîte, je perçois déjà de manière assez nette la différence de culture entre mon ancienne entreprise, dans le secteur de l'intégration des systèmes, et la nouvelle, une multinationale qui utilise l'approche Agile.
Une entreprise Agile
Développer des logiciels à partir de la méthode Agile a également nécessité quelques changements :
La première différence que j'ai notée, c'est que l'équipe de développement est placée tout à côté du département, directement au cœur du métier et des bénéfices de l'entreprise. Ce qui signifie que les développeurs sont en communication étroite avec les personnes chargées du commercial, comme les chefs de produits. Les commerciaux et les programmeurs sont dans la même pièce. Du point de vue de la programmation, cela signifie que, par exemple, les demandes quotidiennes pour effacer un champ donné afin de simplifier le code et rendre l'interface utilisateur plus propre sont rapidement approuvées et intégrées dans les objectifs du mois suivant.
Il est très motivant de savoir que sa petite contribution à la simplification du système se traduira par des revenus accrus pour l'entreprise. Dans l'industrie de l'intégration des systèmes, où la plupart des entreprises utilisent la méthode “Waterfall” pour le développement, ajouter ou supprimer un champ nécessite d'envoyer une demande officielle et d'obtenir l'accord de plusieurs managers, ce qui prend des semaines, voire des mois à finaliser. Du coup, ce qui se passe, c'est qu'un programmeur qui a une bonne idée ne se risquera pas à la proposer et se contentera plutôt de mettre seulement en œuvre ce qui est spécifié dans le cahier des charges, sauf problème majeur.
Les équipes [chez Amazon] sont également assez réduites. Les équipes opérationnelles sont assez proches des programmeurs et peuvent ainsi communiquer de manière étroite et sans trop de paperasse. Cela peut varier d'une équipe à l'autre, mais je me suis rendu compte que des wikis sont utilisés pour suivre la production de codes et que très peu de documents Word ou Excel sont utilisés. L'essentiel de notre temps, on le passe à coder et à faire des tests sur Emac, Vim ou Eclipse. Dans mon ancienne boîte [japonaise], je passais tout au plus 10% de mon temps à la production de codes. Ça me change donc beaucoup. Mais, d'un autre côté, je suis très mauvais en anglais, si bien que même quand les collègues essaient de m'expliquer les choses, je ne les comprends pas toujours. Parfois, j'ai envie d'un cahier de charges simple et clair, mais je présume que ce n'est qu'une question de différence culturelle.
Un environnement de travail dynamique
Le modèle économique d'Amazon est également différent de celui de son ancienne entreprise :
Il faut ajouter à tout ceci que mon nouvel employeur est une entreprise B2C où de nouvelles fonctionnalités sont sans cesse ajoutées au système. Il est donc difficile de reconstruire tout le système, surtout sur une période de plusieurs années. Au contraire, on y est constamment sous pression pour améliorer progressivement les fonctionnalités et éliminer les bugs qui surviennent. On ne procède à la refactorisation du système que si on trouve un peu de temps libre.
En ce sens, il est virtuellement impossible [chez Amazon] de mettre sur pied un système en partant de zéro, comme on le ferait avec un système d'intégration. Il se peut donc que ce ne soit pas l'emploi idéal pour quelqu'un qui souhaite travailler avec les derniers langages de programmation et les derniers frameworks de développement de logiciels. D'un autre côté, les intégrateurs systèmes n'ont pas souvent l'occasion de réparer et d'administrer leurs propres systèmes, de sorte que même si leur travail pourrait être vraiment intéressant en adoptant les dernières technologies de développement, en réalité la plupart son pris dans la routine et continuent de travailler avec les anciens frameworks.
Un billet précédent publié par Asai sur son blog discutait de “l'âge maximum de départ à la retraite” de 35 ans imposé aux programmeurs au Japon, mais Amazon n'a pas une telle limite d'âge :
Une des choses qui me préoccupaient lorsque j'ai commencé à travailler, c'était mon âge. Mais je viens de découvrir que dans une entreprise internationale, la limite d'âge de 35 ans n'existe pas. Ma nouvelle entreprise semble plus intéressée par des gens qui ont une certaine expérience plutôt que par des jeunes diplômés. Du coup, il est assez fréquent de rencontrer des programmeurs qui ont mon âge. Naturellement, l'entreprise recrute sur la base des compétences et non pas en fonction de l'âge, si bien que de nombreux jeunes programmeurs occupent de hautes fonctions (je parle d'hommes, mais il y a bien sûr beaucoup de femmes dans la programmation dans les multinationales).