Nihon (comme les Japonais appellent leur pays) reste encore mystérieux et inhabituel aux yeux des étrangers. En dehors de ses frontières, de nombreux stéréotypes nationaux sont répandus, parmi lesquels, par exemple, la fameuse qualité japonaise et l'efficacité du travail. On sait aussi que les Japonais sont très responsables et meurent parfois de surmenage. Dans ce contexte (ainsi que des comparaisons interminables entre «le nôtre et le vôtre»), on pourrait avoir l'impression que le Japon est la demeure de la productivité et de quelqu'un, et ces gars-là en savent beaucoup sur les processus de développement. Est-ce vrai? Prenons l'exemple de notre projet, où le client était une grande entreprise japonaise traditionnelle.
introduction
Notre équipe a dû faire face à la tâche difficile d'adapter la solution PoS existante au marché japonais et de la rendre multiplateforme, tout en minimisant les écarts par rapport à la solution existante. Nous pouvons dire que d'une part, nous avons eu carte blanche pour changer le produit, mais en même temps, nous étions sérieusement limités par la base de code existante. On nous a confié le changement des fonctions de base, et le développement a été réalisé selon un modèle en cascade. Le travail sur le projet a duré 3 ans, au cours desquels nous avons traité des gigaoctets de lignes de code, effectué des dizaines de voyages d'affaires de Tokyo à Kazan et retour, et réussi à travailler avec trois cents participants du client et des sous-traitants du Japon, Russie et Philippines.
Bien sûr, pour juger pleinement des spécificités du travail avec les Japonais, un projet ne suffit pas - après tout, beaucoup dépend de ses spécificités et du type d'entreprise. Mais, en tenant compte de mes impressions et de mon expérience accumulée - à la fois les miennes et mes collègues chercheurs japonais, je vais aujourd'hui essayer de vous parler point par point des caractéristiques mêmes que nous avons rencontrées en travaillant avec nos collègues japonais, et des leçons que nous avons apprises et ce que j'ai appris.
Travailler dans Excel
La chose même qui a causé la douleur. Microsoft Excel dans les entreprises japonaises sert à tout: documentation de détails très différents (même s'il n'y a que des diagrammes UML), une collection de captures d'écran avec des bugs, et bien sûr, des champs de rapport sans fin, à partir des cellules desquelles des matrices mégapixels pourraient être ajoutées . Pour nos gestionnaires, Excel ne pouvait tout simplement pas supporter une telle souffrance et a refusé de travailler. À propos, cette obsession prend parfois des formes bizarres . Si pour les rapports ce format est encore plus ou moins familier, alors pour la documentation de développement, il est exotique, pour le moins dire.
Rallyes trop longs
Au fond, nos collègues japonais sont très responsables: ils comprennent toutes les conséquences de leurs décisions, et ne peuvent donc pas prendre ces décisions pendant longtemps. Ils aiment aussi les rallyes. Et si pour un Occidental un rallye est un moyen de résoudre des problèmes et de rendre compte, c'est aussi pour les Japonais l'occasion de se mettre d'accord sur leur décision avec des collègues, réduisant ainsi leur propre fardeau de responsabilité.
Et même si cela ne se terminait en rien, sa durée était généralement directement proportionnelle au volume de billets qui se trouvaient sur notre plateau. Et comme les tests étaient du côté japonais, il y avait suffisamment de billets. Imaginez à quel point nous, les programmeurs, aimons entrer dans les détails, et multipliez cela par le facteur japonais. Vous recevrez des heures de problèmes techniques détaillés accompagnés d'un interprète. Et en ajoutant à cela la traduction du japonais vers l'anglais, et parfois des commentaires en japonais et en russe, lorsque l'adversaire attend son tour, on obtient un record de 8 heures .
Lorsque je suis devenu chef d'équipe, cela ne me convenait pas - et j'ai essayé de réduire le pourcentage de traductions qui trompaient souvent l'attention sur la communication en anglais, et j'ai également essayé de ne pas succomber à la tentation d'entrer dans les détails. En général, cela a permis de réduire d'environ la moitié le temps moyen de réunion, ainsi que le nombre de bogues et la quantité de travail.
La barrière de la langue
Le Japon est un pays autosuffisant et le niveau d'émigration y est relativement faible. Par conséquent, la langue très anglaise que nous espérions n'est pas très populaire là-bas: un interlocuteur de niveau A2 est le maximum sur lequel nous pouvions compter. N'oubliez pas que si vous démarrez un projet en japonais, vous ne pouvez pas vous passer d'un traducteur ! Dès le début du projet, nous avons eu une personne sans qui notre interaction avec les Japonais aurait été tout simplement impossible - un coordinateur de projet de langue japonaise, qui était responsable de la conduite des négociations et de la correspondance clé. En plus de lui, plusieurs traducteurs ont participé à la traduction de documents, lettres et billets et aux négociations.
Les difficultés liées à la barrière de la langue sont restées jusqu'à la fin du projet - mais dans de telles situations, beaucoup de confiance et de persévérance de notre part ont aidé. Nous avons compris que malgré les différentes langues, nous n'avions qu'un seul objectif.
Rapports à tout moment, n'importe où
Notre projet a été réalisé sur un modèle de développement en cascade, et l'abondance des rapports et la mise à jour constante des horaires en est en partie due. Cela ne veut pas dire que l'abondance des rapports est une caractéristique purement japonaise. Mais si nous comparons un projet similaire en Russie et dans la CEI avec le Japon, alors la saveur extrême-orientale se manifeste dans toute sa splendeur. En tant que chef d'équipe, j'ai eu à traiter pleinement tous les types de documents de reporting à la fois en tant que lecteur et en tant qu'auteur - à l'exception peut-être des financiers: en termes de qualité avec une analyse des causes des bugs, en termes de progrès, technique extraordinaire et, bien sûr, traditionnel pour les horaires en cascade. Chacun de ces rapports était un fichier Excel volumineux bordé de tableaux dans les meilleures traditions de scanwords des maisons de retraite .
Au cours de la communication continue lors des longs rallyes hivernaux, la compréhension a commencé à s'étendre d'abord à la direction, puis à l'équipe. Nous avons compris les principales différences par rapport à ce type de reportage dans un projet russe similaire - ils n'étaient pas faits pour le spectacle, mais contenaient des indicateurs pertinents de l'état du projet et ont fait l'objet d'une attention et d'une analyse (et souvent de corrections) de notre japonais. collègues.
Horaire de style japonais
Néanmoins, ils avaient à la fois un sens et même un bon objectif: par exemple, un rapport de qualité montre les domaines problématiques, lors de sa compilation, vous pouvez aller au fond du problème, et un rapport d'avancement a permis de suivre la quantité de travail accompli à ce jour. À propos, le second au fil du temps a acquis de plus en plus de nouvelles colonnes, et cela pouvait prendre jusqu'à trois heures 2 fois par semaine au gestionnaire pour le remplir, et parfois plus souvent. Avec les horaires, cela s'est avéré encore plus difficile: au départ, j'ai essayé de prendre par programme des tickets du tracker de tâches avec des estimations et de les mettre sur le calendrier dans MS Project, mais cela s'est avéré très capricieux, et les horaires volaient constamment et modifié. Désespéré, je me suis rapidement lancé dans la construction des horaires - sous Excel, bien sûr.
Différence de temps
Nous travaillons selon l'heure de Moscou et la différence avec le Japon est de 6 heures. Quand j'étais en voyage d'affaires, un tel décalage horaire était un peu déprimant: vous êtes habitué au fait que pendant la journée de travail, quelqu'un de vos proches et même vous écrivent dans des messagers, puis quand j'ai commencé à travailler, c'était encore 3 heures du matin en Russie ... Mais le plus gros inconvénient était lors de la communication avec le client.
En travaillant avec des collègues occidentaux, vous semblez toujours jouer en avance sur la courbe: vous commencez à travailler avant eux et vous pouvez calmement vous mettre dans une ambiance de travail, nettoyer le courrier d'hier et préparer les rallyes. Mais non - imaginez-vous à la place des Japonais. Vous trouvez un bogue critique qui doit être corrigé de toute urgence, alors que les développeurs dorment encore. Même si vous comprenez qu'ils essaieront de continuer à corriger le bogue après la fin de votre journée de travail, mais le sentiment de retard éternel augmentera proportionnellement à l'urgence du bogue. Heureusement, notre coordinateur travaille à Vladivostok, qui a 1 heure d'avance sur le Japon. Cela a beaucoup aidé, car il a héroïquement pris le principal coup d'indignation sur lui-même et atténué un peu les sentiments des Japonais.
Néanmoins, rappelant la propension même des Japonais au surmenage, pour nous, en tant que développeurs, les périodes de test d'acceptation étaient généralement une source de stress constant pendant toute la journée de travail: vous venez travailler coupable de bugs et "être en retard" et partir, aussi, en partie coupable de ne pas avoir réussi à le réparer "aujourd'hui". Cependant, au fil du temps, nous nous sommes habitués à ce mode, et en même temps, pour une communication et une localisation plus efficaces des bugs, nos équipes de testeurs japonais et nos développeurs ont rapproché leurs horaires de travail.
Focus sur la qualité
La méthodologie avec laquelle nous avons travaillé implique des phases de test à plusieurs niveaux. Tout d'abord, des tests au niveau du développement, puis quelques phases supplémentaires du côté du client. Le perfectionnisme est une chose à double tranchant: de telles conditions mangent souvent tout le temps fixé dans la phase selon la première loi de Parkinson, mais en même temps, leur minutie et leur scrupule visaient le peu qui nous unissait - la qualité de la produit final.
Si de nombreux processus et routines redondantes nous semblaient dénués de sens, alors nous soucier de la qualité du code et, par conséquent, du produit, est ce dans lequel nous avons trouvé un langage commun. À des moments différents, le code entier a été exécuté sur deux analyseurs statiques. Le client a alloué du temps pour résoudre les problèmes rencontrés, ce qui n'est pas une pratique courante dans les projets agiles / occidentaux. De plus, nous avons couvert tous les codes nouveaux et modifiés avec des tests. Cela n'a pas toujours fonctionné complètement, par conséquent, afin de gagner du temps et de l'efficacité, l'accent principal dans la phase active de la correction de bogue du projet était sur les tests d'intégration. Soit dit en passant, l'un de nos livrables était le rapport de test et de couverture du code - un tel souci de qualité résonnait dans nos cœurs, et nous avons le plus souvent trouvé des compromis dans ce domaine.
De plus, pour améliorer la qualité du code, nous avons proposé aux Japonais la pratique de mener jusqu'à 4 revues par des personnes différentes, y compris le chef d'équipe, en fonction de la complexité du ticket. En conséquence, cela m'a incité à explorer les possibilités de pré-révision automatique du code dans GitLab. Je ne pouvais pas appliquer tout cela sur le projet, mais j'ai écrit un petit modèle pour les projets futurs. En plus de renforcer la revue, nous avons réussi à améliorer les tests automatisés (unité, intégration, fumée).
Mesures de performance (KS)
Des métriques ont été introduites sur le projet, y compris le nombre de lignes (KS) du code écrit. Cela a fait l'objet d'intenses controverses et discussions tout au long du développement. Cette métrique a été utilisée pour suivre la progression, estimer la densité des bogues et servir de base pour le nombre prévu de tests, de pages de documentation et de temps de révision.
Le nombre de lignes de code a également été utilisé pour calculer la productivité du programmeur.
Beaucoup de problèmes avec cette méthode viennent immédiatement à l'esprit: le code de l'interface utilisateur est beaucoup plus volumineux, mais contient moins de complexité, et les 10 autres lignes de code peuvent être obtenues au prix d'une activité cérébrale persistante pendant plusieurs jours. Nous avons essayé de commencer à évaluer le travail dans le nombre de cas d'utilisation, mais il n'y avait pas d'analystes dédiés, et les compétences des développeurs n'étaient pas suffisantes. Vers le milieu du projet, un ancien chef d'équipe a suggéré d'utiliser le nombre de méthodes comme mesure du volume. En conséquence, nous avons commencé à compter à la fois KS et le nombre de méthodes.
Au fil du temps, la confusion est devenue encore plus grande: j'ai décidé d'utiliser des données historiques sur le temps réel passé et le volume réel produit pour trouver des coefficients qui traduiraient les heures de travail en estimations de volume. Puisque, en plus de l'écriture, nous étions accompagnés d'un grand nombre de tâches de processus, de phases de test, de revues et de documentation, un tel calculateur nous a été très utile.
Estimations et délais
Au Japon, il existe une pratique consistant à pousser le développeur à baisser les estimations et, en conséquence, les délais, puis à pousser le sentiment de culpabilité (« vous l'avez dit vous-même ») afin que le «coupable» retravaille, en essayant de respecter les délais . Dans notre situation, cela ressemblait parfois à une négociation des délais. Nous nous sommes assurés que 2 ou 3 développeurs supplémentaires n'accéléreraient pas le travail sur le problème - mais de l'autre côté, les fils ont tenu bon. Avec plus ou moins de succès, nous avons héroïquement défendu les délais et, à la veille de délais particulièrement critiques, nous avons fait un compromis, qui consistait généralement en des révisions et, moins souvent, en attirant des ressources supplémentaires. Cependant, nous avons souvent réussi à ne pas respecter ces délais.
Au fil du temps, il a également été décidé d'automatiser ce phénomène. J'ai pris des billets comme base, ajouté les critiques nécessaires, les bugs possibles et ... j'ai essayé de tirer cela dans MS Project. Malheureusement, de temps en temps, il montrait un ordre différent des tâches et fixait de manière inconnue des contraintes. Il n'y avait pas beaucoup de temps, j'ai donc décidé de faire rapidement la construction de diagrammes de Gantt dans Excel - car il s'est avéré plus prévisible et obéissant. Ainsi, nous pourrions facilement modifier les estimations - avec elles, les dates d'achèvement ont également changé. Il est devenu beaucoup plus facile de reconstruire les horaires, le client les a aimés. Bien que cela n'ait pas résolu le problème du non-respect des délais, nous avons pu avertir le client à l'avance du décalage horaire.
Traditions
Lorsque je suis parti en voyage d'affaires au Japon avec sept personnes, on nous a ordonné d'observer le code vestimentaire traditionnel des bureaux japonais: un costume, une chemise légère et une cravate. Bien sûr, pour les programmeurs habitués à porter des sweats à capuche dans la vie de tous les jours, c'était un vrai défi. Néanmoins, le temps a joué son rôle, et un sentiment d'appartenance (vous pouvez l'appeler instinct de troupeau ) est apparu, ce qui a ajouté de l'énergie et l'a même en quelque sorte «nôtre». La photo était amusante: à la gare de Shinagawa à Tokyo, il y a un grand nombre de bureaux de grandes entreprises traditionnelles japonaises, où chaque matin des milliers de cols blancs affluent de toute la capitale et de la banlieue. Le spectacle est fantastique!
Source de la photo
Habituellement, notre journée de travail commençait à 9 heures, bien que certains collègues japonais soient venus plus tard. Pour le déjeuner, nous avons fait la queue avec les mêmes employés de bureau dans notre magasin de ramen préféré non loin du lieu de travail. Je ne peux pas contourner le sujet des files d'attente au Japon - c'est juste une relaxation complète, car personne ne pourra jamais prendre une longueur d'avance sur la file d'attente sans nécessité vitale. Et dans le métro, il y a des endroits spéciaux pour les files d'attente, et personne n'enfreint jamais les règles de création de files d'attente, et c'est génial.
Le soir, le travail dans notre bureau ne faisait que s'accélérer. Dans notre bureau, la journée de travail se terminait à 18 heures, mais presque aucun des Japonais n'allait partir. Mais en même temps, ils aiment aussi soulager le stress avec du saké et plus encore.après le travail - et ils le font assez souvent. Et même si nous avions des contradictions au travail, en dehors des heures de travail dans un cadre informel, nos collègues se sont révélés être des interlocuteurs sincères.
Dans les entreprises japonaises traditionnelles, les Japonais maintiennent une chaîne de commandement stricte dans leurs relations avec leurs supérieurs. Il me semble que c'est l'une des principales différences actuelles entre les développeurs du Japon et de la Russie. Lorsque des problèmes surviennent, les Japonais ne blâment presque jamais les artistes directs, mais sont plus enclins à blâmer la direction, et des deux côtés. Plus le rang est élevé, plus la responsabilité est grande et plus le coût de l'échec est élevé. Tout est selon les règles: plus il y a de force, plus il y a de responsabilité .
Le client est Dieu
Le Japon se distingue par son attitude particulière envers le client. Et notre client japonais attendait probablement la même attitude de notre part.
Il y a en effet un dicton en japonais: "O-kyaku-sama-wa kamisama des" (Le client est un dieu) - et ça fait vraiment l'affaire. Si nous examinons la relation entre le client et l'entrepreneur en Russie, le contraste avec le Japon sera très perceptible. Tout au long de ma vie en Russie, une communication polie avec les artistes n'a rien promis de bon au client - au contraire, plus il y a de scandale et d'impolitesse avec ceux qui vous fournissent des services (courriers, serveurs, réparateurs, etc.), plus le le meilleur résultat est garanti. Au Japon, d'après mes observations, vous pouvez être calme. Oui, le service est cher, mais il est garanti de satisfaire le client. C'est une question de goût, mais j'aime cette façon de rester poli et de ne pas se soucier de la qualité.
Conclusion
Malgré les désaccords et les difficultés, nous avons fait face au travail avec le client japonais et son équipe technique. Certaines fonctionnalités se sont révélées difficiles et désagréables pour nous, tandis que d'autres méritaient le respect et nous rapprochaient. Nous avons dû accepter quelque chose ou même attendre le temps et le travail d'équipe pour faire leur travail, quelque part il s'est avéré trouver un compromis, et quelque part - une solution de contournement.
Est-il juste de dire que la plupart des stéréotypes sur les Japonais au travail sont corrects? Tout n'est pas si simple.
La subordination entre supérieurs et subordonnés est en effet ressentie plus fortement au Japon, mais récemment, les jeunes brisent de plus en plus le système. Le recyclage est courant, mais il y a plus de vacances au Japon qu'en Russie. Il y a des gens hyper-responsables qui sont enclins à respecter le délai à tout prix, toujours et partout - et cela ne dépend pas du tout du pays ou de la mentalité. Plus nous travaillions longtemps avec nos collègues du Japon, moins les différences étaient perceptibles et plus les similitudes étaient constatées. L'histoire et la culture uniques ne peuvent que refléter le caractère et les traditions nationales, mais néanmoins, il y avait beaucoup plus en commun. Et je suis reconnaissant pour cette expérience!