Nihon (como los japoneses llaman a su país) sigue siendo misterioso e inusual a los ojos de los extranjeros. Fuera de sus fronteras, están muy extendidos muchos estereotipos nacionales, entre los que, por ejemplo, la famosa calidad y eficiencia del trabajo japonés. También sabemos que los japoneses son muy responsables y, a veces, mueren por exceso de trabajo. En este contexto (además de las interminables comparaciones de "lo nuestro con el tuyo"), uno podría tener la impresión de que Japón es la morada de la productividad y alguien, y estos muchachos saben mucho sobre procesos de desarrollo. ¿Es tan? Veamos el ejemplo de nuestro proyecto, donde el cliente era una gran empresa japonesa tradicional.
Introducción
Nuestro equipo enfrentó la difícil tarea de adaptar la solución PoS existente para el mercado japonés y convertirla en multiplataforma, mientras minimizaba las desviaciones de la solución existente. Podemos decir que por un lado obtuvimos carta blanca para cambiar el producto, pero al mismo tiempo estábamos seriamente limitados por el código base existente. Se nos encomendó cambiar las funciones principales y el desarrollo se llevó a cabo según un modelo en cascada. El trabajo en el proyecto duró 3 años, durante los cuales tratamos con gigabytes de líneas de código, hicimos docenas de viajes de negocios desde Tokio a Kazán y viceversa, y logramos trabajar con trescientos participantes tanto del cliente como de contratistas relacionados de Japón. Rusia y Filipinas.
Por supuesto, para juzgar completamente los detalles de trabajar con los japoneses, un proyecto no es suficiente; después de todo, mucho depende de sus detalles y del tipo de empresa. Pero, teniendo en cuenta mis impresiones y la experiencia acumulada, tanto la mía como la de mis compañeros académicos japoneses, hoy intentaré contarles punto por punto sobre las mismas características que encontramos al trabajar con nuestros colegas japoneses, y qué lecciones aprendimos y aprendimos. lo que he aprendido.
Trabajando en Excel
Lo mismo que causó el dolor. Microsoft Excel en las empresas japonesas se usa para todo: documentación de detalles muy diferentes (aunque solo existan diagramas UML), una colección de capturas de pantalla con errores y, por supuesto, un sinfín de campos de informe, a partir de cuyas celdas se podrían agregar matrices de megapíxeles. . Para nuestros gerentes, Excel simplemente no podía soportar tal sufrimiento y se negó a trabajar. Por cierto, a veces esta obsesión adquiere formas extrañas . Si para los informes este formato es aún más o menos familiar, entonces para la documentación de desarrollo es exótico, por decirlo suavemente.
Mítines demasiado largos
Básicamente, nuestros colegas japoneses son muy responsables: comprenden todas las consecuencias de sus decisiones y, por lo tanto, no pueden tomar estas decisiones durante mucho tiempo. También les encantan los mítines. Y si para un occidental un mitin es una forma de resolver problemas e informar, para los japoneses también es una oportunidad para acordar su decisión con sus colegas, reduciendo su propia carga de responsabilidad.
E incluso si terminaba en nada, su duración solía ser directamente proporcional al volumen de boletos que había en nuestro tablero. Y como las pruebas estaban en el lado japonés, hubo suficientes entradas. Imagínese cuánto nos encanta a los programadores entrar en detalles y multiplicar eso por el factor japonés. Recibirá horas de cuestiones técnicas detalladas acompañadas de un intérprete. Y añadiendo a esto la traducción del japonés al inglés, y en ocasiones comentarios en japonés y ruso, cuando el bando contrario está esperando su turno, obtenemos un récord de 8 horas .
Cuando me convertí en líder de equipo, esto no me convenía, y traté de reducir el porcentaje de traducciones que a menudo desvían el enfoque hacia la comunicación en inglés, y también traté de no sucumbir a la tentación de entrar en detalles. En general, esto ayudó a reducir el tiempo promedio de las reuniones a la mitad, así como la cantidad de errores y la cantidad de trabajo.
La barrera del lenguaje
Japón es un país autosuficiente y el nivel de emigración es relativamente bajo. Por lo tanto, el idioma inglés que esperábamos no es muy popular allí: un interlocutor con un nivel A2 es lo máximo con el que podíamos contar. Recuerde, si está comenzando un proyecto con japonés, ¡no puede prescindir de un traductor ! Desde el comienzo del proyecto, tuvimos una persona sin la cual nuestra interacción con los japoneses habría sido simplemente imposible: un coordinador del proyecto de habla japonesa, que era responsable de llevar a cabo las negociaciones y la correspondencia clave. Además de él, varios traductores participaron en la traducción de documentos, cartas y tickets y en las negociaciones.
Las dificultades asociadas con la barrera del idioma se mantuvieron hasta el final del proyecto, pero en tales situaciones, mucha confianza y perseverancia de nuestra parte ayudaron. Entendimos que a pesar de los diferentes idiomas, teníamos un solo objetivo.
Reporta en cualquier momento y en cualquier lugar
Nuestro proyecto se llevó a cabo en un modelo de desarrollo en cascada, y la abundancia de informes y la actualización constante de los cronogramas se debió en parte a esto. Esto no quiere decir que la abundancia de informes sea una característica puramente japonesa. Pero si comparamos un proyecto similar en Rusia y la CEI con Japón, entonces el sabor del Lejano Oriente se manifiesta en todo su esplendor. Como líder de equipo, tuve que lidiar completamente con todo tipo de documentos de informes, tanto como lector como como autor, con la excepción, quizás, de los financieros: en términos de calidad con un análisis de las causas de los errores, en términos de Progreso, técnico extraordinario y, por supuesto, tradicional para los horarios de cascada. Cada uno de estos informes era un archivo de Excel de gran peso lleno de tablas con las mejores tradiciones de las palabras clave de los hogares de ancianos .
En el curso de la comunicación continua en los largos mítines de invierno, la comprensión comenzó a extenderse primero a la dirección y luego al equipo. Llegamos a comprender las principales diferencias de este tipo de informes en un proyecto ruso similar: no se hicieron para mostrar, sino que contenían indicadores relevantes del estado del proyecto y fueron objeto de una atención y un análisis minuciosos (y, a menudo, de correcciones) de nuestros japoneses. colegas.
Horario de estilo japonés
Sin embargo, tenían un significado e incluso un buen propósito: por ejemplo, un informe de calidad muestra áreas problemáticas, al compilarlo, puede llegar al fondo del problema, y un informe de progreso ayudó a rastrear la cantidad de trabajo completado hasta la fecha. Por cierto, la segunda con el tiempo adquirió más y más columnas nuevas, y el gerente podría tardar hasta tres horas 2 veces a la semana en completarla, y algunas veces con más frecuencia. Con los horarios, resultó aún más difícil: inicialmente traté de tomar tickets programáticamente del rastreador de tareas junto con las estimaciones y ponerlos en el horario en MS Project, pero resultó ser muy caprichoso, y los horarios volaban constantemente y cambió. Desesperado, rápidamente me lancé a la construcción de horarios, en Excel, por supuesto.
Diferencia en el tiempo
Trabajamos según la hora de Moscú, y la diferencia con Japón son las 6 en punto. Cuando estaba en un viaje de negocios, esa diferencia horaria era un poco deprimente: estás acostumbrado a que durante la jornada laboral, alguien de tus familiares e incluso te escriba en mensajeros, luego cuando empecé a trabajar, todavía era 3 am en Rusia ... Pero el mayor inconveniente fue durante la comunicación con el cliente.
Al trabajar con colegas occidentales, parece que se está adelantando a la curva todo el tiempo: comienza a trabajar antes que ellos y puede sintonizar con calma un estado de ánimo de trabajo, limpiar el correo de ayer y prepararse para los mítines. Pero no, imagínate en el lugar de los japoneses. Encuentra un error crítico que necesita ser arreglado con urgencia, mientras los desarrolladores todavía están durmiendo. Incluso si comprende que intentarán y continuarán corrigiendo el error después del final de su jornada laboral, pero la sensación de eterno retraso aumentará en proporción a la urgencia del error. Afortunadamente, nuestro coordinador trabaja en Vladivostok, que está 1 hora por delante de Japón. Esto ayudó mucho, ya que heroicamente recibió el golpe principal de la indignación sobre sí mismo y amortiguó un poco los sentimientos de los japoneses.
Sin embargo, recordando la propensión de los japoneses a trabajar en exceso, para nosotros, como desarrolladores, los períodos de prueba de aceptación solían ser una fuente de estrés constante durante toda la jornada laboral: llegas al trabajo culpable de errores y "llegas tarde" y te vas, también, en parte culpable por no haber logrado arreglarlo "hoy". Sin embargo, con el tiempo, nos acostumbramos a este modo y, al mismo tiempo, para una comunicación y localización de errores más efectivas, nuestros equipos de probadores japoneses y nuestros desarrolladores acercaron sus horarios de trabajo.
Centrarse en la calidad
La metodología con la que hemos trabajado implica fases de prueba de varias capas. Primero, pruebas a nivel de desarrollo y luego algunas fases más del lado del cliente. El perfeccionismo es una cosa de doble filo: tales condiciones a menudo consumen todo el tiempo establecido en la fase según la primera ley de Parkinson, pero al mismo tiempo, su meticulosidad y escrupulosidad estaban dirigidas a lo poco que nos unía: la calidad de la producto final.
Si muchos procesos y rutinas redundantes nos parecían sin sentido, entonces preocuparnos por la calidad del código y, como resultado, el producto es lo que encontramos en un lenguaje común. En diferentes momentos, todo el código se ejecutó en dos analizadores estáticos. El cliente asignó tiempo para solucionar los problemas encontrados, lo que no es una práctica tan común en proyectos ágiles / occidentales. Además, cubrimos todo el código nuevo y modificado con pruebas. No siempre funcionó por completo, por lo tanto, para ahorrar tiempo y eficiencia, el énfasis principal en la fase activa de la corrección de errores del proyecto estuvo en las pruebas de integración. Por cierto, uno de nuestros entregables fue la ejecución de prueba y el informe de cobertura de código; tal preocupación por la calidad resonó en nuestros corazones, y la mayoría de las veces encontramos compromisos en esta área.
Además, como mejora en la calidad del código, ofrecimos a los japoneses la práctica de realizar hasta 4 revisiones de diferentes personas, incluido el líder del equipo, dependiendo de la complejidad del ticket. Como resultado, esto me impulsó a explorar las posibilidades de la revisión previa automática del código en GitLab. No pude aplicar todo esto en el proyecto, pero escribí una pequeña plantilla para proyectos futuros. Además de fortalecer la revisión, hemos logrado el éxito en la mejora de las pruebas automatizadas (unidad, integración, humo).
Métricas de rendimiento (KS)
Se introdujeron métricas en el proyecto, incluido el número de líneas (KS) del código escrito. Este ha sido objeto de intensa controversia y discusión a lo largo del desarrollo. Esta métrica se utilizó para rastrear el progreso, estimar la densidad de errores y servir como base para el número esperado de pruebas, páginas de documentación y tiempos de revisión.
El número de líneas de código también se utilizó para calcular la productividad del programador.
Inmediatamente me vienen a la mente muchos problemas con este método: el código de la interfaz de usuario es mucho más voluminoso, pero contiene menos complejidad, y las otras 10 líneas de código se pueden obtener a costa de una actividad cerebral persistente durante varios días. Intentamos comenzar a evaluar el trabajo en el número de casos de uso, pero no había analistas dedicados y las competencias de los desarrolladores no fueron suficientes. Hacia la mitad del proyecto, un líder de equipo anterior sugirió usar el número de métodos como una métrica para el volumen. Como resultado, comenzamos a contar tanto KS como el número de métodos.
A medida que pasaba el tiempo, la confusión se hizo aún mayor: decidí utilizar datos históricos sobre el tiempo real invertido y el volumen real producido para encontrar coeficientes que traducirían las horas de trabajo en estimaciones de volumen. Dado que, además de escribir, nos acompañaron una gran cantidad de tareas de proceso, fases de prueba, revisiones y documentación, dicha calculadora nos resultó muy útil.
Estimaciones y plazos
En Japón, existe la práctica de presionar al desarrollador para que reduzca las estimaciones y, en consecuencia, los plazos, y luego presionar el sentimiento de culpa (" usted mismo lo dijo ") para que el "culpable" vuelva a trabajar, tratando de cumplir con los plazos. . En nuestra situación, a veces se parecía a la negociación de plazos. Nos aseguramos de que 2 o 3 desarrolladores adicionales no aceleraran el trabajo sobre el problema, pero por otro lado, los cables se mantuvieron firmes. Con diversos grados de éxito, defendimos heroicamente los plazos y, en vísperas de plazos especialmente críticos, hicimos un compromiso, que generalmente consistía en revisiones y, con menos frecuencia, en atraer recursos adicionales. Sin embargo, a menudo no cumplimos con estos plazos.
Con el tiempo, también se decidió automatizar este fenómeno. Tomé boletos como base, agregué las revisiones necesarias, posibles errores y ... intenté sacar esto en MS Project. Desafortunadamente, de vez en cuando mostraba un orden diferente de tareas y, de manera desconocida, establecía limitaciones. No había mucho tiempo, así que decidí hacer rápidamente la construcción de diagramas de Gantt en Excel, ya que resultó ser más predecible y obediente. Por lo tanto, podríamos cambiar fácilmente las estimaciones; junto con ellas, las fechas de finalización también cambiaron. Se hizo mucho más fácil reconstruir los horarios, al cliente le gustaron. Aunque esto no solucionó el problema de incumplimiento de los plazos, pudimos advertir al cliente con anticipación sobre el turno de tiempo.
Tradiciones
Cuando hice un viaje de negocios a Japón con siete personas, se nos ordenó observar el código de vestimenta tradicional de las oficinas japonesas: un traje de negocios, una camisa ligera y una corbata. Por supuesto, para los programadores que están acostumbrados a usar sudaderas con capucha en la vida cotidiana, esto fue un verdadero desafío. Sin embargo, el tiempo jugó su papel y apareció un sentido de pertenencia (se le puede llamar instinto gregario ), que le agregó energía e incluso lo hizo de alguna manera “nuestro”. La imagen fue entretenida: en la estación Shinagawa de Tokio, hay una gran cantidad de oficinas de grandes empresas tradicionales japonesas, donde cada mañana miles de cuello blanco acudían en masa de toda la capital y los suburbios. ¡El espectáculo es fantástico!
Fuente de la foto
Por lo general, nuestra jornada laboral comenzaba a las 9 en punto, aunque algunos colegas japoneses llegaron más tarde. Para el almuerzo, hicimos fila con los mismos trabajadores de oficina en la fila de nuestra tienda de ramen favorita, no muy lejos del lugar de trabajo. No puedo evitar el tema de las colas en Japón, es simplemente una relajación total, porque nadie se adelantará a la cola sin una necesidad vital. Y en el metro hay lugares especiales para las colas, y nadie nunca rompe las reglas para crear colas, y esto es genial.
Por la noche, el trabajo en nuestra oficina se estaba acelerando. En nuestra oficina, la jornada laboral terminaba a las 18:00, pero casi ninguno de los japoneses se iba a ir. Pero al mismo tiempo, también les encanta aliviar el estrés con sake y más.después del trabajo, y lo hacen con bastante frecuencia. Y aunque tuvimos algunas contradicciones en el trabajo, fuera del horario laboral en un ambiente informal, nuestros compañeros resultaron ser interlocutores sinceros.
En las empresas tradicionales japonesas, los japoneses mantienen una estricta cadena de mando en su relación con sus superiores. Me parece que esta es una de las diferencias clave actuales entre los desarrolladores de Japón y Rusia. Cuando surgen problemas, los japoneses casi nunca culpan a los actores directos, pero están más inclinados a culpar a la gerencia ya ambos lados. Cuanto más alto sea el rango, mayor será la responsabilidad y mayor el costo del fracaso. Todo está de acuerdo con las reglas: a más fuerza, más responsabilidad .
El cliente es dios
Japón se distingue por su actitud especial hacia el cliente. Y nuestro cliente japonés probablemente esperaba la misma actitud de nosotros.
De hecho, hay un dicho en japonés: "O-kyaku-sama-wa kamisama des" (El cliente es un dios), y realmente da en el blanco. Si miramos la relación entre el cliente y el contratista en Rusia, entonces el contraste con Japón será muy notable. A lo largo de mi vida en Rusia, la comunicación cortés con los artistas intérpretes o ejecutantes no prometió nada bueno al cliente; por el contrario, cuanto más escándalo y grosería con quienes le brindan el servicio (mensajeros, camareros, reparadores, etc.), más el mejor resultado está garantizado. En Japón, según mis observaciones, puedes estar tranquilo. Sí, el servicio es caro, pero está garantizado que satisfará al cliente. Es cuestión de gustos, pero a mí me gusta así: ser educado y no preocuparme por la calidad.
Conclusión
A pesar de los desacuerdos y dificultades, hicimos frente al trabajo con el cliente japonés y su equipo técnico. Algunas características resultaron ser difíciles y desagradables para nosotros, mientras que otras merecieron respeto y nos acercaron más. Tuvimos que llegar a un acuerdo con algo o incluso esperar el tiempo y el trabajo en equipo para hacer lo suyo, en algún lugar resultó encontrar un compromiso, y en algún lugar, una solución.
¿Es justo decir que la mayoría de los estereotipos sobre los japoneses en el trabajo son correctos? No todo es tan sencillo.
De hecho, la subordinación entre superiores y subordinados se siente con más fuerza en Japón, pero recientemente, los jóvenes están rompiendo cada vez más el sistema. El reciclaje es común, pero hay más días festivos en Japón que en Rusia. Hay personas hiperresponsables que se inclinan a cumplir el plazo a toda costa, siempre y en todas partes, y esto no depende en absoluto del país ni de la mentalidad. Cuanto más trabajamos con nuestros colegas de Japón, menos notables eran las diferencias y más similitudes se encontraban. La historia y la cultura únicas no pueden dejar de reflejar el carácter y las tradiciones nacionales, pero, sin embargo, había mucho más en común. ¡Y estoy agradecido por esta experiencia!