Nihon (como os japoneses chamam seu país) ainda permanece misterioso e incomum aos olhos dos estrangeiros. Fora de suas fronteiras, muitos estereótipos nacionais são generalizados, entre os quais, por exemplo, a famosa qualidade e eficiência da mão de obra japonesas. Também sabemos que os japoneses são muito responsáveis e às vezes morrem de excesso de trabalho. Contra esse pano de fundo (assim como as comparações infinitas do "nosso com o seu"), pode-se ficar com a impressão de que o Japão é a morada da produtividade e de alguém, e esses caras sabem muito sobre processos de desenvolvimento. É assim? Vejamos o exemplo do nosso projeto, onde o cliente era uma grande empresa tradicional japonesa.
Introdução
Nossa equipe enfrentou a difícil tarefa de adaptar a solução de PoS existente para o mercado japonês e torná-la multiplataforma, enquanto minimizava os desvios da solução existente. Podemos dizer que, por um lado, tínhamos carta branca para mudar o produto, mas, ao mesmo tempo, estávamos seriamente limitados pela base de código existente. Fomos encarregados de alterar as funções centrais e o desenvolvimento foi realizado de acordo com um modelo em cascata. O trabalho no projeto durou 3 anos, durante os quais lidamos com gigabytes de linhas de código, fizemos dezenas de viagens de negócios de Tóquio a Kazan e de volta, e conseguimos trabalhar com trezentos participantes do cliente e contratados relacionados do Japão, Rússia e Filipinas.
Claro, para julgar completamente as especificidades de trabalhar com os japoneses, um projeto não é suficiente - afinal, muito depende de suas especificidades e do tipo de empresa. Mas, levando em consideração minhas impressões e experiência acumulada - tanto minhas quanto de meus colegas acadêmicos japoneses, hoje tentarei contar a vocês ponto por ponto sobre as próprias características que encontramos ao trabalhar com nossos colegas japoneses, e quais lições aprendemos e o que aprendi.
Trabalhando em Excel
A mesma coisa que causou a dor. O Microsoft Excel nas empresas japonesas é usado para tudo: documentação de detalhes muito diferentes (mesmo que haja apenas diagramas UML), uma coleção de capturas de tela com bugs e, claro, campos de relatório infinitos, a partir das células das quais matrizes megapixel podem ser adicionadas . Para nossos gerentes, o Excel simplesmente não suportou tanto sofrimento e se recusou a trabalhar. Aliás, às vezes essa obsessão assume formas bizarras . Se para relatórios esse formato é ainda mais ou menos familiar, para documentação de desenvolvimento é exótico, para dizer o mínimo.
Ralis muito longos
Basicamente, nossos colegas japoneses são muito responsáveis: eles entendem todas as consequências de suas decisões e, portanto, não podem tomar essas decisões por muito tempo. Eles também adoram ralis. E se para um ocidental um comício é uma forma de resolver problemas e apresentar um relatório, para os japoneses também é uma oportunidade de chegar a um acordo sobre sua decisão com os colegas, reduzindo seu próprio fardo de responsabilidade.
E mesmo que terminasse em nada, sua duração costumava ser diretamente proporcional ao volume de ingressos que havia em nosso conselho. E como o teste era do lado japonês, havia ingressos suficientes. Imagine o quanto nós, programadores, adoramos entrar em detalhes e multiplicar isso pelo fator japonês. Você receberá horas de detalhes técnicos acompanhados por um intérprete. E acrescentando a isso a tradução do japonês para o inglês, e às vezes comentários em japonês e russo, quando o adversário está esperando sua vez, temos um recorde de 8 horas .
Quando me tornei líder de equipe, isso não me convinha - e tentei reduzir a porcentagem de traduções que muitas vezes enganam o foco na comunicação em inglês, e também tentei não sucumbir à tentação de entrar em detalhes. Em geral, isso ajudou a reduzir o tempo médio das reuniões pela metade - assim como o número de bugs e a quantidade de trabalho.
A barreira linguística
O Japão é um país autossuficiente e o nível de emigração é relativamente baixo. Portanto, a língua inglesa que esperávamos não é muito popular por lá: um interlocutor com nível A2 é o máximo com que poderíamos contar. Lembre- se , se você está iniciando um projeto em japonês, não pode ficar sem um tradutor ! Desde o início do projeto, tínhamos uma pessoa sem a qual nossa interação com os japoneses teria sido simplesmente impossível - um coordenador do projeto que falava japonês, que era responsável por conduzir as negociações e a correspondência essencial. Além dele, diversos tradutores participaram da tradução de documentos, cartas e passagens e das negociações.
As dificuldades associadas à barreira do idioma permaneceram até o final do projeto - mas nessas situações, muita confiança e perseverança de nossa parte ajudaram. Percebemos que apesar dos diferentes idiomas, tínhamos um único objetivo.
Relatórios a qualquer hora, em qualquer lugar
Nosso projeto foi realizado em um modelo de desenvolvimento em cascata, e a abundância de relatórios e atualização constante de cronogramas se deveu em parte a isso. Isso não quer dizer que a abundância de reportagens seja um recurso puramente japonês. Mas se compararmos um projeto semelhante na Rússia e na CEI com o Japão, o sabor do Extremo Oriente se manifestará em toda a sua glória. Como líder de equipe, tive que lidar integralmente com todos os tipos de documentos de relatório, tanto como leitor quanto como autor - com exceção, talvez, dos financeiros: em termos de qualidade com uma análise das causas dos bugs, em termos de progresso, técnica extraordinária e, é claro, tradicional para cronogramas em cascata. Cada um desses relatórios era um arquivo Excel pesado forrado com tabelas nas melhores tradições de scanwords de lares de idosos .
No decorrer da comunicação contínua nos longos ralis de inverno, o entendimento começou a se espalhar primeiro para a gerência e depois para a equipe. Chegamos a compreender as principais diferenças desse tipo de relatório em um projeto russo semelhante - eles não foram feitos para serem exibidos, mas continham indicadores relevantes do status do projeto e foram objeto de atenção e análise (e muitas vezes de correções) de nossos japoneses colegas.
Programação Estilo Japonês
No entanto, eles tinham significado e até mesmo um bom propósito: por exemplo, um relatório de qualidade mostra áreas problemáticas, ao compilá-lo, você pode chegar ao fundo do problema, e um relatório de progresso ajudou a rastrear a quantidade de trabalho concluído até o momento. A propósito, o segundo com o tempo adquiriu cada vez mais colunas novas, e o gerente podia levar até três horas 2 vezes por semana para preenchê-lo, e às vezes com mais frequência. Com os cronogramas, ficou ainda mais difícil: inicialmente tentei pegar os tickets programaticamente do rastreador de tarefas junto com as estimativas e colocá-los na programação no MS Project, mas acabou sendo muito caprichoso, e os cronogramas voavam constantemente e mudado. Desesperado, rapidamente lancei a construção de cronogramas - no Excel, é claro.
Diferença de tempo
Trabalhamos de acordo com o horário de Moscou, e a diferença com o Japão é às 6 horas. Quando eu estava em viagem de negócios, essa diferença de fuso horário era um pouco deprimente: você está acostumada com o fato de que durante a jornada de trabalho, alguém de seus parentes e até te escrevia em mensageiros, aí quando comecei a trabalhar ainda era 3 da manhã na Rússia ... Mas o maior inconveniente foi durante a comunicação com o cliente.
Trabalhando com colegas ocidentais, você parece estar jogando à frente da curva o tempo todo: você começa a trabalhar antes deles e pode se sintonizar calmamente com o clima de trabalho, limpar a correspondência de ontem e se preparar para os ralis. Mas não - imagine-se no lugar dos japoneses. Você encontra um bug crítico que precisa ser corrigido com urgência, enquanto os desenvolvedores ainda estão dormindo. Mesmo que você entenda que eles vão tentar e continuar a consertar o bug após o fim do seu dia de trabalho, mas a sensação de eterno atraso aumentará na proporção da urgência do bug. Felizmente, nosso coordenador trabalha em Vladivostok, que está 1 hora à frente do Japão. Isso ajudou muito, já que ele heroicamente recebeu o golpe principal da indignação e amorteceu um pouco os sentimentos dos japoneses.
No entanto, lembrando a própria propensão dos japoneses ao excesso de trabalho, para nós, como desenvolvedores, os períodos de teste de aceitação costumavam ser uma fonte de estresse constante durante todo o dia de trabalho: você chega ao trabalho culpado por bugs e "chegar atrasado" e sai, também, parcialmente culpado por não conseguir consertá-lo "hoje". No entanto, com o tempo, nos acostumamos com esse modo e, ao mesmo tempo, para uma comunicação e localização mais eficaz de bugs, nossas equipes de testadores japoneses e nossos desenvolvedores mudaram seus cronogramas de trabalho mais próximos uns dos outros.
Foco na qualidade
A metodologia com a qual trabalhamos envolve fases de teste em várias camadas. Primeiro, teste no nível de desenvolvimento e, em seguida, mais algumas fases do lado do cliente. O perfeccionismo é uma coisa de dois gumes: tais condições muitas vezes corroem todo o tempo definido na fase de acordo com a primeira lei de Parkinson, mas, ao mesmo tempo, sua meticulosidade e escrupulosidade estavam voltadas para o pouco que nos unia - a qualidade do produto final.
Se muitos processos e rotinas redundantes pareciam sem sentido para nós, então nos preocupamos com a qualidade do código e, como resultado, com o produto, encontramos uma linguagem comum. Em momentos diferentes, todo o código foi executado em dois analisadores estáticos. O cliente alocou tempo para consertar os problemas encontrados, o que não é uma prática comum em projetos ágeis / ocidentais. Além disso, cobrimos todos os códigos novos e alterados com testes. Nem sempre funcionou completamente, portanto, para economizar tempo e eficiência, a principal ênfase na fase ativa da correção de bugs do projeto foi nos testes de integração. A propósito, um de nossos resultados foi a execução de teste e o relatório de cobertura de código - essa preocupação com a qualidade ressoou em nossos corações e, na maioria das vezes, encontramos compromissos nessa área.
Além disso, como uma melhoria na qualidade do código, oferecemos aos japoneses a prática de conduzir até 4 revisões de pessoas diferentes, incluindo o líder da equipe, dependendo da complexidade do tíquete. Como resultado, isso me levou a explorar as possibilidades de pré-revisão automática de código no GitLab. Não pude aplicar tudo isso no projeto, mas escrevi um pequeno modelo para projetos futuros. Além de fortalecer a revisão, obtivemos sucesso na melhoria dos testes automatizados (unidade, integração, fumaça).
Métricas de desempenho (KS)
As métricas foram introduzidas no projeto, incluindo o número de linhas (KS) do código escrito. Este tem sido o assunto de intensa controvérsia e discussão ao longo do desenvolvimento. Essa métrica foi usada para rastrear o progresso, estimar a densidade do bug e servir como base para o número esperado de testes, páginas de documentação e tempos de revisão.
O número de linhas de código também foi usado para calcular a produtividade do programador.
Muitos problemas com esse método vêm imediatamente à mente: o código da IU é muito mais volumoso, mas contém menos complexidade, e as outras 10 linhas de código podem ser obtidas ao custo de atividade cerebral persistente por vários dias. Tentamos começar avaliando o trabalho em número de casos de uso, mas não havia analistas dedicados e as competências dos desenvolvedores não eram suficientes. No meio do projeto, um líder de equipe anterior sugeriu o uso de vários métodos como métrica de volume. Como resultado, começamos a contar KS e o número de métodos.
Com o passar do tempo, a confusão ficou ainda maior: decidi usar dados históricos sobre o tempo real gasto e o volume real produzido para encontrar coeficientes que traduziriam as horas de trabalho em estimativas de volume. Visto que, além de escrever, éramos acompanhados por um grande número de tarefas de processo, fases de teste, revisões e documentação, essa calculadora foi muito útil para nós.
Estimativas e prazos
No Japão, existe a prática de forçar o desenvolvedor a reduzir as estimativas e, consequentemente, os prazos, e depois forçar o sentimento de culpa (" você mesmo disse ") para que o "culpado" retrabalhasse, tentando cumprir os prazos . Em nossa situação, às vezes parecia uma negociação de prazos. Certificamo-nos de que 2-3 desenvolvedores adicionais não acelerariam o trabalho no problema - mas, por outro lado, os fios permaneceram firmes. Com vários graus de sucesso, defendemos heroicamente os prazos e, às vésperas de prazos especialmente críticos, fizemos um compromisso, que geralmente consistia em revisões e, com menos frequência, na atração de recursos adicionais. No entanto, muitas vezes não cumprimos esses prazos.
Com o tempo, decidiu-se automatizar esse fenômeno também. Peguei tickets como base, adicionei os comentários necessários, possíveis bugs e ... tentei puxar isso no MS Project. Infelizmente, de vez em quando ele mostrava uma ordem diferente de tarefas e de forma desconhecida definia restrições. Não me deu muito tempo, então decidi fazer rapidamente a construção dos gráficos de Gantt no Excel - já que acabou sendo mais previsível e obediente. Assim, poderíamos facilmente alterar as estimativas - junto com elas, as datas de conclusão também mudaram. Ficou muito mais fácil reconstruir os horários, o cliente gostou deles. Embora isso não resolvesse o problema de prazos não cumpridos, poderíamos avisar o cliente com antecedência sobre a mudança de horário.
Tradições
Quando fiz uma viagem de negócios ao Japão com sete pessoas, fomos obrigados a observar o código de vestimenta tradicional dos escritórios japoneses: terno, camisa leve e gravata. Claro, para os programadores que estão acostumados a usar moletons na vida cotidiana, esse foi um verdadeiro desafio. No entanto, o tempo cumpriu o seu papel e surgiu um sentimento de pertença (pode-se chamar de instinto de rebanho ), que agregou energia e até o tornou de alguma forma “nosso”. A imagem foi divertida: na estação Shinagawa, em Tóquio, há um grande número de escritórios de grandes empresas tradicionais japonesas, onde todas as manhãs milhares de colarinhos brancos lotavam a capital e os subúrbios. O espetáculo é fantástico!
Fonte da foto
Normalmente, nosso dia de trabalho começava às 9 horas, embora alguns colegas japoneses aparecessem mais tarde. Para o almoço, nos alinhamos com os mesmos funcionários de escritório em nossa loja de ramen favorita, não muito longe do local de trabalho. Não consigo contornar o tópico de filas no Japão - é apenas relaxamento completo, porque ninguém nunca vai ficar na frente da fila sem uma necessidade vital. E no metrô há lugares especiais para filas e ninguém quebra as regras de fazer filas, e isso é ótimo.
À noite, o trabalho em nosso escritório estava acelerando. Em nosso escritório, a jornada de trabalho terminava às 18h, mas quase nenhum japonês ia embora. Mas, ao mesmo tempo, eles também adoram aliviar o estresse com saquê e muito mais.depois do trabalho - e eles fazem isso com bastante frequência. E mesmo que tivéssemos algumas contradições no trabalho, fora do horário de trabalho em um ambiente informal, nossos colegas acabaram sendo interlocutores sinceros.
Nas empresas japonesas tradicionais, os japoneses mantêm uma estrita cadeia de comando no relacionamento com seus superiores. Parece-me que esta é uma das principais diferenças atuais entre os desenvolvedores do Japão e da Rússia. Quando surgem problemas, os japoneses quase nunca culpam os executores diretos, mas tendem a culpar a gerência e os dois lados. Quanto mais alta a classificação, maior a responsabilidade e maior o custo do fracasso. Tudo está de acordo com as regras: quanto mais força, mais responsabilidade .
Cliente é deus
O Japão se distingue por sua atitude especial para com o cliente. E nosso cliente japonês provavelmente esperava a mesma atitude de nós.
De fato, há um ditado em japonês: "O-kyaku-sama-wa kamisama des" (O cliente é um deus) - e realmente acerta o alvo. Se olharmos para o relacionamento entre o cliente e o empreiteiro na Rússia, o contraste com o Japão será muito perceptível. Ao longo da minha vida na Rússia, a comunicação educada com os performers não prometia nada de bom para o cliente - pelo contrário, quanto mais escândalo e grosseria com aqueles que lhe prestam serviço (mensageiros, garçons, reparadores, etc.), mais o melhor resultado é garantido. No Japão, de acordo com minhas observações, você pode ficar calmo. Sim, o serviço é caro, mas com garantia de satisfação do cliente. É uma questão de gosto, mas gosto deste jeito - de ser educado e não me preocupar com a qualidade.
Conclusão
Apesar das divergências e dificuldades, lidamos com o trabalho com o cliente japonês e sua equipe técnica. Algumas características se mostraram difíceis e desagradáveis para nós, enquanto outras mereciam respeito e nos aproximaram. Tínhamos que chegar a um acordo com alguma coisa ou até mesmo esperar o tempo e o trabalho em equipe para fazer o que queriam, em algum lugar descobrimos um meio-termo e em algum lugar - uma solução alternativa.
É justo dizer que a maioria dos estereótipos sobre os japoneses no trabalho está correta? Nem tudo é tão simples.
A subordinação entre superiores e subordinados é de fato sentida com mais força no Japão, mas recentemente os jovens estão quebrando cada vez mais o sistema. A reciclagem é comum, mas há mais feriados no Japão do que na Rússia. Existem pessoas hiper-responsáveis que estão dispostas a cumprir o prazo a todo custo, sempre e em qualquer lugar - e isso não depende do país ou da mentalidade em nada. Quanto mais trabalhávamos com nossos colegas do Japão, menos as diferenças eram perceptíveis e mais semelhanças eram encontradas. A história e a cultura únicas não podem deixar de refletir sobre o caráter e as tradições nacionais, mas, no entanto, havia muito mais em comum. E agradeço essa experiência!