Nihon (wie die Japaner ihr Land nennen) bleibt in den Augen von Ausländern immer noch mysteriös und ungewöhnlich. Außerhalb seiner Grenzen sind viele nationale Stereotypen weit verbreitet, darunter zum Beispiel die berühmte japanische Qualität und Effizienz der Arbeit. Wir wissen auch, dass die Japaner sehr verantwortungsbewusst sind und manchmal an Überarbeitung sterben. Vor diesem Hintergrund (sowie endlosen Vergleichen von "unserem mit Ihrem") könnte man den Eindruck gewinnen, dass Japan der Wohnsitz der Produktivität und jemand ist, und diese Leute wissen viel über Entwicklungsprozesse. Ist es so? Schauen wir uns das Beispiel unseres Projekts an, bei dem der Kunde ein traditionelles großes japanisches Unternehmen war.
Einführung
Unser Team stand vor der schwierigen Aufgabe, die vorhandene PoS-Lösung für den japanischen Markt anzupassen und plattformübergreifend zu gestalten und dabei Abweichungen von der vorhandenen Lösung zu minimieren. Wir können sagen, dass wir einerseits einen Freibrief erhalten haben, um das Produkt zu ändern, aber gleichzeitig waren wir durch die vorhandene Codebasis ernsthaft eingeschränkt. Wir wurden mit der Änderung der Kernfunktionen beauftragt und die Entwicklung nach einem Wasserfallmodell durchgeführt. Die Arbeit an dem Projekt dauerte drei Jahre. Während dieser Zeit haben wir uns mit Gigabyte Codezeilen befasst, Dutzende von Geschäftsreisen von Tokio nach Kasan und zurück unternommen und es geschafft, mit dreihundert Teilnehmern sowohl des Kunden als auch verwandter Auftragnehmer aus Japan zusammenzuarbeiten. Russland und die Philippinen.
Natürlich reicht ein Projekt nicht aus, um die Besonderheiten der Zusammenarbeit mit den Japanern vollständig beurteilen zu können - schließlich hängt vieles von seinen Besonderheiten und der Art des Unternehmens ab. Aber unter Berücksichtigung meiner Eindrücke und gesammelten Erfahrungen - sowohl meiner eigenen als auch meiner japanischen Kollegen - werde ich heute versuchen, Ihnen Punkt für Punkt zu sagen, auf welche Merkmale wir bei der Arbeit mit unseren japanischen Kollegen gestoßen sind und welche Lektionen wir gelernt haben und was gelernt haben.
Arbeiten in Excel
Genau das, was den Schmerz verursacht hat. Microsoft Excel in japanischen Unternehmen wird für alles verwendet: Dokumentation sehr unterschiedlicher Details (auch wenn es nur UML-Diagramme gibt), eine Sammlung von Screenshots mit Fehlern und natürlich endlose Berichtsfelder, aus deren Zellen Megapixel-Matrizen hinzugefügt werden könnten . Für unsere Manager konnte Excel ein solches Leiden einfach nicht ertragen und weigerte sich zu arbeiten. Übrigens nimmt diese Besessenheit manchmal bizarre Formen an . Wenn dieses Format für Berichte noch mehr oder weniger bekannt ist, ist es für die Entwicklungsdokumentation, gelinde gesagt, exotisch.
Zu lange Rallyes
Grundsätzlich sind unsere japanischen Kollegen sehr verantwortungsbewusst: Sie verstehen alle Konsequenzen ihrer Entscheidungen und können diese Entscheidungen daher lange nicht treffen. Sie lieben auch Rallyes. Und wenn für eine westliche Person eine Kundgebung eine Möglichkeit ist, Probleme zu lösen und Bericht zu erstatten, ist dies für die Japaner auch eine Gelegenheit, ihre Entscheidung mit Kollegen zu vereinbaren und so ihre eigene Verantwortung zu verringern.
Und selbst wenn es mit nichts endete, war seine Dauer normalerweise direkt proportional zum Volumen der Tickets, die sich auf unserem Board befanden. Und da die Tests auf japanischer Seite stattfanden, gab es genügend Tickets. Stellen Sie sich vor, wie sehr wir Programmierer gerne auf Details eingehen, und multiplizieren Sie dies mit dem japanischen Faktor. Sie erhalten stundenlang detaillierte technische Fragen in Begleitung eines Dolmetschers. Hinzu kommt die Übersetzung vom Japanischen ins Englische und manchmal Kommentare auf Japanisch und Russisch. Wenn die gegnerische Seite darauf wartet, dass sie an die Reihe kommt, erhalten wir einen Rekord von 8 Stunden .
Als ich Teamleiter wurde, passte das nicht zu mir - und ich versuchte, den Prozentsatz der Übersetzungen zu reduzieren, die oft den Fokus auf die Kommunikation auf Englisch irreführten, und versuchte auch, nicht der Versuchung zu erliegen, auf Details einzugehen. Dies trug im Allgemeinen dazu bei, die durchschnittliche Besprechungszeit um etwa die Hälfte zu verkürzen - ebenso wie die Anzahl der Fehler und den Arbeitsaufwand.
Die Sprachbarriere
Japan ist ein autarkes Land, und die Auswanderung ist dort relativ gering. Daher ist die englische Sprache, auf die wir gehofft haben, dort nicht sehr beliebt: Ein Gesprächspartner mit einem A2-Niveau ist das Maximum, auf das wir zählen können. Denken Sie daran, wenn Sie ein Projekt mit Japanisch starten, können Sie nicht auf einen Übersetzer verzichten ! Von Beginn des Projekts an hatten wir eine Person, ohne die unsere Interaktion mit den Japanern einfach unmöglich gewesen wäre - einen japanischsprachigen Projektkoordinator, der für die Durchführung der Verhandlungen und die Korrespondenz verantwortlich war. Neben ihm waren mehrere Übersetzer an der Übersetzung von Dokumenten, Briefen und Tickets sowie an den Verhandlungen beteiligt.
Die mit der Sprachbarriere verbundenen Schwierigkeiten blieben bis zum Ende des Projekts bestehen - aber in solchen Situationen hat viel Selbstvertrauen und Ausdauer unsererseits geholfen. Wir haben verstanden, dass wir trotz der verschiedenen Sprachen ein einziges Ziel hatten.
Berichte jederzeit und überall
Unser Projekt wurde an einem Wasserfallentwicklungsmodell durchgeführt, und die Fülle an Berichten und die ständige Aktualisierung von Zeitplänen war teilweise darauf zurückzuführen. Dies bedeutet nicht, dass die Fülle der Berichterstattung ein rein japanisches Merkmal ist. Wenn wir jedoch ein ähnliches Projekt in Russland und der GUS mit Japan vergleichen, zeigt sich das fernöstliche Flair in seiner ganzen Pracht. Als Teamleiter musste ich mich sowohl als Leser als auch als Autor mit allen Arten von Berichtsdokumenten befassen - mit Ausnahme vielleicht finanzieller: in Bezug auf die Qualität mit einer Analyse der Ursachen von Fehlern, in Bezug auf Fortschritt, außergewöhnliche technische und natürlich traditionelle Wasserfallpläne. Jeder dieser Berichte war eine gewichtige Excel-Datei mit Tabellen in den besten Traditionen der Pflegeheim-Scanwords .
Im Verlauf der kontinuierlichen Kommunikation bei den langen Winterrallyes verbreitete sich das Verständnis zuerst auf das Management und dann auf das Team. Wir haben die Hauptunterschiede zu dieser Art der Berichterstattung in einem ähnlichen russischen Projekt verstanden - sie wurden nicht zur Schau gestellt, sondern enthielten relevante Indikatoren für den Projektstatus und waren Gegenstand genauer Aufmerksamkeit und Analyse (und häufig Korrekturen) unserer Japaner Kollegen.
Zeitplan im japanischen Stil
Trotzdem hatten sie sowohl eine Bedeutung als auch einen guten Zweck: Beispielsweise zeigt ein Qualitätsbericht Problembereiche an. Wenn Sie ihn kompilieren, können Sie dem Problem auf den Grund gehen, und ein Fortschrittsbericht half dabei, den bisher abgeschlossenen Arbeitsaufwand zu verfolgen. Übrigens hat die zweite im Laufe der Zeit immer mehr neue Spalten erhalten, und der Manager konnte bis zu drei Stunden zweimal pro Woche benötigen, um sie auszufüllen, und manchmal häufiger. Bei den Zeitplänen stellte sich heraus, dass es noch schwieriger war: Anfangs habe ich versucht, programmgesteuert Tickets zusammen mit Schätzungen aus dem Task-Tracker zu entnehmen und sie in MS Project in den Zeitplan aufzunehmen, aber es stellte sich als sehr launisch heraus, und die Zeitpläne flogen ständig und geändert. Verzweifelt warf ich schnell die Erstellung von Zeitplänen ein - natürlich in Excel.
Zeitunterschied
Wir arbeiten nach Moskauer Zeit und der Unterschied zu Japan beträgt 6 Uhr. Als ich auf Geschäftsreise war, war ein solcher Zeitunterschied ein wenig deprimierend: Sie sind daran gewöhnt, dass während des Arbeitstages jemand von Ihren Verwandten und sogar in Boten an Sie schrieb, und als ich anfing zu arbeiten, war es immer noch so 3 Uhr morgens in Russland ... Die größte Unannehmlichkeit bestand jedoch in der Kommunikation mit dem Kunden.
Wenn Sie mit westlichen Kollegen zusammenarbeiten, scheinen Sie die ganze Zeit der Kurve voraus zu sein: Sie beginnen vor ihnen zu arbeiten, und Sie können sich ruhig auf eine Arbeitsstimmung einstellen, die Post von gestern aufräumen und sich auf Kundgebungen vorbereiten. Aber nein - stellen Sie sich an die Stelle der Japaner. Sie finden einen kritischen Fehler, der dringend behoben werden muss, während die Entwickler noch schlafen. Selbst wenn Sie verstehen, dass sie versuchen werden, den Fehler nach dem Ende Ihres Arbeitstages weiter zu beheben, wird das Gefühl der ewigen Verspätung proportional zur Dringlichkeit des Fehlers zunehmen. Glücklicherweise arbeitet unser Koordinator in Wladiwostok, das 1 Stunde vor Japan liegt. Dies half sehr, da er den Hauptschlag der Empörung heldenhaft auf sich nahm und die Gefühle der Japaner ein wenig dämpfte.
Wenn wir uns jedoch an die Neigung der Japaner erinnern, zu überarbeiten, waren die Abnahmetestperioden für uns als Entwickler normalerweise eine Quelle ständigen Stresses für den gesamten Arbeitstag: Sie kommen, um sich für Fehler schuldig zu machen und "zu spät zu kommen" und gehen, Auch teilweise schuldig, weil Sie es nicht schaffen, es "heute" zu reparieren. Im Laufe der Zeit haben wir uns jedoch an diesen Modus gewöhnt und gleichzeitig haben unsere Teams japanischer Tester und unsere Entwickler ihre Arbeitspläne näher zusammengerückt, um eine effektivere Kommunikation und Lokalisierung von Fehlern zu erreichen.
Qualität im Fokus
Die Methodik, mit der wir gearbeitet haben, umfasst mehrschichtige Testphasen. Zuerst Tests auf Entwicklungsebene und dann einige weitere Phasen auf Kundenseite. Perfektionismus ist eine zweischneidige Sache: Solche Bedingungen verschlingen oft die ganze Zeit, die in der Phase nach dem ersten Parkinson-Gesetz festgelegt wurde, aber gleichzeitig richteten sich ihre Sorgfalt und Skrupellosigkeit gegen das Wenige, das uns vereinte - die Qualität der Endprodukt.
Wenn uns viele Prozesse und redundante Routinen bedeutungslos erschienen, dann haben wir uns um die Qualität des Codes und damit um das Produkt gekümmert, in dem wir eine gemeinsame Sprache gefunden haben. Zu unterschiedlichen Zeiten wurde der gesamte Code gegen zwei statische Analysatoren ausgeführt. Der Kunde hat Zeit zur Behebung der festgestellten Probleme zur Verfügung gestellt, was in agilen / westlichen Projekten nicht üblich ist. Darüber hinaus haben wir den gesamten neuen und geänderten Code mit Tests abgedeckt. Es hat nicht immer vollständig geklappt, daher lag der Schwerpunkt in der aktiven Phase des Projekt-Bugfixes auf Integrationstests, um Zeit und Effizienz zu sparen. Übrigens war eines unserer Ergebnisse der Testlauf und der Bericht zur Codeabdeckung - diese Sorge um die Qualität hat in unseren Herzen Resonanz gefunden, und wir haben in diesem Bereich am häufigsten Kompromisse gefunden.
Um die Qualität des Codes zu verbessern, haben wir den Japanern die Möglichkeit geboten, je nach Komplexität des Tickets bis zu 4 Überprüfungen von verschiedenen Personen, einschließlich des Teamleiters, durchzuführen. Dies veranlasste mich daher, die Möglichkeiten der automatischen Code-Vorprüfung in GitLab zu untersuchen. Ich konnte das alles nicht auf das Projekt anwenden, aber ich habe eine kleine Vorlage für zukünftige Projekte geschrieben. Neben der Stärkung der Überprüfung haben wir Erfolge bei der Verbesserung automatisierter Tests (Einheit, Integration, Rauch) erzielt.
Leistungsmetriken (KS)
Im Projekt wurden Metriken eingeführt, einschließlich der Anzahl der Zeilen (KS) des geschriebenen Codes. Dies war während der gesamten Entwicklung Gegenstand intensiver Kontroversen und Diskussionen. Diese Metrik wurde verwendet, um den Fortschritt zu verfolgen, die Fehlerdichte zu schätzen und als Grundlage für die erwartete Anzahl von Tests, Dokumentationsseiten und Überprüfungszeiten zu dienen.
Die Anzahl der Codezeilen wurde auch zur Berechnung der Produktivität des Programmierers verwendet.
Viele Probleme mit dieser Methode fallen sofort ein: Der UI-Code ist viel umfangreicher, enthält jedoch weniger Komplexität, und die anderen 10 Codezeilen können auf Kosten einer anhaltenden Gehirnaktivität für mehrere Tage abgerufen werden. Wir haben versucht, die Arbeit anhand der Anzahl der Anwendungsfälle zu bewerten, aber es gab keine dedizierten Analysten, und die Kompetenzen der Entwickler reichten nicht aus. Gegen Mitte des Projekts schlug ein früherer Teamleiter vor, die Anzahl der Methoden als Maß für das Volumen zu verwenden. Infolgedessen begannen wir, sowohl KS als auch die Anzahl der Methoden zu zählen.
Mit der Zeit wurde die Verwirrung noch größer: Ich entschied mich, historische Daten über die tatsächlich aufgewendete Zeit und das tatsächlich produzierte Volumen zu verwenden, um Koeffizienten zu finden, die Arbeitsstunden in Volumenschätzungen umwandeln würden. Da wir neben dem Schreiben von einer Vielzahl von Prozessaufgaben, Testphasen, Überprüfungen und Dokumentationen begleitet wurden, war ein solcher Taschenrechner für uns sehr nützlich.
Schätzungen und Fristen
In Japan gibt es die Praxis, den Entwickler dazu zu drängen, Schätzungen und dementsprechend die Fristen zu senken und dann das Schuldgefühl („ Sie haben es selbst gesagt “) zu verstärken, damit der „Schuldige“ überarbeitet und versucht, die Fristen einzuhalten . In unserer Situation ähnelte es manchmal Tarifverhandlungen. Wir haben dafür gesorgt, dass 2-3 zusätzliche Entwickler die Arbeit an dem Problem nicht beschleunigen - aber auf der anderen Seite haben sich die Drähte behauptet. Mit unterschiedlichem Erfolg haben wir die Fristen heldenhaft verteidigt und am Vorabend besonders kritischer Fristen einen Kompromiss geschlossen, der in der Regel aus Überholungen und seltener aus der Gewinnung zusätzlicher Ressourcen bestand. Wir haben diese Fristen jedoch oft erfolgreich nicht eingehalten.
Im Laufe der Zeit wurde beschlossen, auch dieses Phänomen zu automatisieren. Ich habe Tickets als Grundlage genommen, die erforderlichen Bewertungen, mögliche Fehler hinzugefügt und ... Ich habe versucht, dies in MS Project abzurufen. Leider zeigte er von Zeit zu Zeit eine andere Reihenfolge von Aufgaben und setzte auf unbekannte Weise Einschränkungen. Da nicht viel Zeit blieb, beschloss ich, Gantt-Diagramme schnell in Excel zu erstellen - da es sich als vorhersehbarer und gehorsamer herausstellte. So konnten wir Schätzungen leicht ändern - zusammen mit ihnen änderten sich auch die Fertigstellungstermine. Es wurde viel einfacher, die Zeitpläne neu zu erstellen, der Kunde mochte sie. Obwohl dies das Problem der Terminüberschreitung nicht löste, konnten wir den Kunden im Voraus vor der Zeitverschiebung warnen.
Traditionen
Als ich mit sieben Personen auf Geschäftsreise nach Japan ging, wurde uns befohlen, die für japanische Büros traditionelle Kleiderordnung einzuhalten: einen Business-Anzug, ein leichtes Hemd und eine Krawatte. Für Programmierer, die es gewohnt sind, im Alltag Hoodies zu tragen, war dies natürlich eine echte Herausforderung. Trotzdem spielte die Zeit ihre Rolle, und es entstand ein Zugehörigkeitsgefühl (man kann es Herdeninstinkt nennen ), das Energie hinzufügte und es sogar irgendwie zu „unserem“ machte. Das Bild war unterhaltsam: In der Shinagawa Station in Tokio gibt es eine große Anzahl von Büros großer traditioneller japanischer Unternehmen, in denen jeden Morgen Tausende von Angestellten aus der ganzen Hauptstadt und den Vororten strömten. Das Spektakel ist fantastisch!
Fotoquelle
Normalerweise begann unser Arbeitstag um 9 Uhr, obwohl einige japanische Kollegen später auftauchten. Zum Mittagessen stellten wir uns mit denselben Büroangestellten in unserem Lieblings-Ramen-Laden unweit des Arbeitsplatzes an. Ich komme in Japan nicht um das Thema Warteschlangen herum - es ist nur völlige Entspannung, denn niemand wird jemals ohne eine wesentliche Notwendigkeit vor die Warteschlange klettern. Und in der U-Bahn gibt es spezielle Plätze für Warteschlangen, und niemand bricht jemals die Regeln für das Erstellen von Warteschlangen, und das ist großartig.
Am Abend beschleunigte sich die Arbeit in unserem Büro. In unserem Büro endete der Arbeitstag um 18:00 Uhr, aber fast keiner der Japaner wollte gehen. Gleichzeitig lieben sie es aber auch, Stress mit Sake und mehr abzubauen.nach der Arbeit - und das oft. Und obwohl wir außerhalb der Arbeitszeit in einem informellen Umfeld einige Widersprüche bei der Arbeit hatten, erwiesen sich unsere Kollegen als aufrichtige Gesprächspartner.
In traditionellen japanischen Unternehmen pflegen die Japaner eine strenge Befehlskette in ihrer Beziehung zu ihren Vorgesetzten. Es scheint mir, dass dies einer der aktuellen Hauptunterschiede zwischen den Entwicklern Japans und Russlands ist. Wenn Probleme auftreten, beschuldigen die Japaner fast nie die direkten Darsteller, sondern eher das Management und beide Seiten. Je höher der Rang, desto größer die Verantwortung und desto höher die Ausfallkosten. Alles ist nach den Regeln: Je mehr Kraft, desto mehr Verantwortung .
Klient ist Gott
Japan zeichnet sich durch seine besondere Haltung gegenüber dem Kunden aus. Und unser japanischer Kunde hat wahrscheinlich die gleiche Einstellung von uns erwartet.
Auf Japanisch gibt es tatsächlich ein Sprichwort: "O-kyaku-sama-wa kamisama des" (Der Klient ist ein Gott) - und es trifft wirklich ins Schwarze. Wenn wir uns die Beziehung zwischen dem Kunden und dem Auftragnehmer in Russland ansehen, wird der Kontrast zu Japan sehr deutlich. Während meines gesamten Lebens in Russland versprach die höfliche Kommunikation mit den Darstellern dem Kunden nichts Gutes - im Gegenteil, je mehr Skandal und Unhöflichkeit mit denen, die Sie bedienen (Kuriere, Kellner, Mechaniker usw.), desto mehr Das beste Ergebnis ist garantiert. In Japan können Sie nach meinen Beobachtungen ruhig sein. Ja, der Service ist teuer, aber er wird garantiert den Kunden zufrieden stellen. Es ist Geschmackssache, aber ich mag diese Art - höflich zu bleiben und sich keine Sorgen um die Qualität zu machen.
Fazit
Trotz der Meinungsverschiedenheiten und Schwierigkeiten haben wir die Arbeit mit dem japanischen Kunden und seinem technischen Team bewältigt. Einige Merkmale erwiesen sich für uns als schwierig und unangenehm, während andere Respekt verdienten und uns näher zusammenbrachten. Wir mussten uns mit etwas abfinden oder sogar auf die Zeit und die Teamarbeit warten, um ihr Ding zu machen. Irgendwo stellte sich heraus, dass es einen Kompromiss gab, und irgendwo - eine Problemumgehung.
Ist es fair zu sagen, dass die meisten Stereotypen über Japaner bei der Arbeit richtig sind? Alles ist nicht so einfach.
Die Unterordnung zwischen Vorgesetzten und Untergebenen ist in Japan zwar stärker zu spüren, aber in letzter Zeit brechen junge Menschen zunehmend das System. Recycling ist üblich, aber in Japan gibt es mehr Feiertage als in Russland. Es gibt überverantwortliche Menschen, die dazu neigen, die Frist um jeden Preis immer und überall einzuhalten - und dies hängt überhaupt nicht vom Land oder der Mentalität ab. Je länger wir mit unseren Kollegen aus Japan zusammengearbeitet haben, desto weniger waren die Unterschiede spürbar und desto mehr Ähnlichkeiten wurden festgestellt. Die einzigartige Geschichte und Kultur kann nur über den nationalen Charakter und die nationalen Traditionen nachdenken, aber es gab noch viel mehr Gemeinsamkeiten. Und ich bin dankbar für diese Erfahrung!