Nihon (begitu orang Jepang menyebut negaranya) masih tetap misterius dan tidak biasa di mata orang asing. Di luar perbatasannya, banyak stereotip nasional tersebar luas, di antaranya, misalnya, kualitas dan efisiensi tenaga kerja Jepang yang terkenal. Kita juga tahu bahwa orang Jepang sangat bertanggung jawab dan terkadang mati karena terlalu banyak bekerja. Dengan latar belakang ini (serta perbandingan tanpa akhir antara "milik kami dengan Anda"), orang mungkin mendapat kesan bahwa Jepang adalah tempat tinggal produktivitas dan seseorang, dan orang-orang ini tahu banyak tentang proses pembangunan. Begitu? Mari kita lihat contoh proyek kita, di mana pelanggannya adalah perusahaan tradisional Jepang yang besar.
pengantar
Tim kami menghadapi tugas yang sulit untuk mengadaptasi solusi PoS yang ada untuk pasar Jepang dan menjadikannya lintas platform, sambil meminimalkan penyimpangan dari solusi yang ada. Kita dapat mengatakan bahwa di satu sisi kita mendapat carte blanche untuk mengubah produk, tetapi pada saat yang sama kita sangat dibatasi oleh basis kode yang ada. Kami dipercayakan untuk mengubah fungsi inti, dan pengembangan dilakukan sesuai model air terjun. Pengerjaan proyek memakan waktu 3 tahun, selama itu kami menangani gigabyte baris kode, melakukan lusinan perjalanan bisnis dari Tokyo ke Kazan dan sebaliknya, dan berhasil bekerja dengan tiga ratus peserta baik dari pelanggan maupun kontraktor terkait dari Jepang, Rusia dan Filipina.
Tentu saja, untuk menilai sepenuhnya seluk beluk bekerja dengan Jepang, satu proyek tidak cukup - bagaimanapun, banyak tergantung pada spesifikasinya dan jenis perusahaan. Tetapi, dengan mempertimbangkan kesan saya dan pengalaman yang terkumpul - baik saya sendiri maupun sesama pelajar Jepang, hari ini saya akan mencoba memberi tahu Anda poin demi poin tentang fitur-fitur yang kami temui ketika bekerja dengan kolega Jepang kami, dan pelajaran apa yang kami pelajari dan apa yang telah dipelajari.
Bekerja di Excel
Hal yang paling menyebabkan rasa sakit. Microsoft Excel di perusahaan Jepang digunakan untuk semuanya: dokumentasi dengan detail yang sangat berbeda (bahkan jika hanya ada diagram UML), kumpulan tangkapan layar dengan bug, dan tentu saja, bidang laporan tanpa akhir, dari sel yang matriks megapikselnya dapat ditambahkan . Bagi manajer kami, Excel tidak tahan dengan penderitaan seperti itu dan menolak untuk bekerja. Ngomong-ngomong, terkadang obsesi ini berbentuk aneh . Jika untuk laporan format ini lebih atau kurang familiar, maka untuk dokumentasi pengembangan itu eksotis, secara halus.
Reli terlalu lama
Pada dasarnya, kolega Jepang kami sangat bertanggung jawab: mereka memahami semua konsekuensi dari keputusan mereka, dan oleh karena itu tidak dapat membuat keputusan ini untuk waktu yang lama. Mereka juga menyukai aksi unjuk rasa. Dan jika bagi orang Barat rapat umum adalah cara untuk menyelesaikan masalah dan melaporkan kembali, bagi orang Jepang itu juga merupakan kesempatan untuk menyetujui keputusan mereka dengan rekan kerja, mengurangi beban tanggung jawab mereka sendiri.
Dan bahkan jika itu berakhir tanpa hasil, durasinya biasanya berbanding lurus dengan volume tiket yang ada di papan kami. Dan karena pengujian dilakukan di pihak Jepang, ada cukup banyak tiket. Bayangkan betapa kami para programmer sangat suka menjelaskan secara detail, dan mengalikannya dengan faktor Jepang. Anda akan menerima berjam-jam masalah teknis terperinci yang didampingi oleh seorang juru bahasa. Dan menambahkan ini terjemahan dari bahasa Jepang ke bahasa Inggris, dan kadang-kadang komentar dalam bahasa Jepang dan Rusia, ketika pihak lawan menunggu giliran mereka, kami mendapatkan catatan 8 jam .
Ketika saya menjadi pemimpin tim, ini tidak cocok untuk saya - dan saya mencoba mengurangi persentase terjemahan yang sering menyesatkan fokus ke komunikasi dalam bahasa Inggris, dan juga berusaha untuk tidak menyerah pada godaan untuk merinci. Secara umum, ini membantu memangkas waktu rapat rata-rata sekitar setengahnya - serta jumlah bug dan jumlah pekerjaan.
Hambatan bahasa
Jepang adalah negara yang mandiri, dan tingkat emigrasinya relatif rendah. Oleh karena itu, bahasa Inggris yang kami harapkan tidak terlalu populer di sana: lawan bicara dengan level A2 adalah jumlah maksimum yang dapat kami andalkan. Ingat, jika Anda memulai proyek dengan bahasa Jepang, maka Anda tidak dapat melakukannya tanpa penerjemah ! Sejak awal proyek, kami memiliki seseorang yang tanpanya tidak mungkin berinteraksi dengan orang Jepang - seorang koordinator proyek berbahasa Jepang, yang bertanggung jawab untuk melakukan negosiasi dan korespondensi utama. Selain dia, beberapa penerjemah berpartisipasi dalam penerjemahan dokumen, surat, tiket, dan negosiasi.
Kesulitan yang terkait dengan kendala bahasa tetap ada hingga akhir proyek - tetapi dalam situasi seperti itu, banyak kepercayaan diri dan ketekunan di pihak kami membantu. Kami memahami bahwa meskipun bahasa berbeda, kami memiliki satu tujuan.
Melaporkan kapanpun, dimanapun
Proyek kami dilaksanakan pada model pengembangan air terjun, dan banyaknya pelaporan dan pembaruan jadwal yang konstan sebagian disebabkan oleh hal ini. Ini tidak berarti bahwa banyaknya reportase adalah fitur murni Jepang. Tetapi jika kita membandingkan proyek serupa di Rusia dan CIS dengan Jepang, maka cita rasa Timur Jauh terwujud dalam segala kemuliaannya. Sebagai pemimpin tim, saya harus sepenuhnya menangani semua jenis dokumen pelaporan baik sebagai pembaca maupun penulis - dengan pengecualian, mungkin, keuangan: dalam hal kualitas dengan analisis penyebab bug, dalam hal kemajuan, teknis luar biasa, dan, tentu saja, tradisional untuk jadwal air terjun. Masing-masing laporan ini adalah file Excel berbobot yang dilapisi dengan tabel-tabel dalam tradisi terbaik kata sandi panti jompo .
Dalam perjalanan komunikasi berkelanjutan di reli musim dingin yang panjang, pemahaman mulai menyebar pertama ke manajemen dan kemudian ke tim. Kami mulai memahami perbedaan utama dari jenis pelaporan ini dalam proyek serupa di Rusia - mereka tidak dibuat untuk pertunjukan, tetapi berisi indikator yang relevan tentang status proyek dan merupakan objek perhatian dan analisis (dan sering kali koreksi) bahasa Jepang kami. rekan kerja.
Jadwal Gaya Jepang
Namun demikian, keduanya memiliki makna dan bahkan tujuan yang baik: misalnya, laporan kualitas menunjukkan area masalah, saat menyusunnya, Anda dapat sampai ke dasar masalah, dan laporan kemajuan membantu melacak jumlah pekerjaan yang diselesaikan hingga saat ini. Omong-omong, kolom kedua dari waktu ke waktu memperoleh semakin banyak kolom baru, dan manajer membutuhkan waktu hingga tiga jam 2 kali seminggu untuk mengisinya, dan terkadang lebih sering. Dengan jadwal, ternyata menjadi lebih sulit: awalnya saya mencoba secara terprogram mengambil tiket dari pelacak tugas bersama dengan perkiraan dan memasukkannya ke dalam jadwal di MS Project, tetapi ternyata sangat berubah-ubah, dan jadwal terus-menerus terbang dan berubah. Putus asa, saya segera melemparkan pembangunan jadwal - di Excel, tentu saja.
Perbedaan waktu
Kami bekerja menurut waktu Moskow, dan perbedaannya dengan Jepang adalah pukul 6. Ketika saya dalam perjalanan bisnis, perbedaan waktu seperti itu sedikit membuat depresi: Anda terbiasa dengan kenyataan bahwa selama hari kerja, seseorang dari kerabat Anda dan bahkan menulis kepada Anda di messenger, lalu ketika saya mulai bekerja, itu masih Jam 3 pagi di Rusia ... Tetapi ketidaknyamanan terbesar adalah selama komunikasi dengan pelanggan.
Bekerja dengan kolega Barat, Anda tampaknya selalu bermain di depan kurva: Anda mulai bekerja sebelum mereka dan Anda dapat dengan tenang menyesuaikan diri dengan suasana kerja, membersihkan surat kemarin, dan bersiap untuk aksi unjuk rasa. Tapi tidak - bayangkan diri Anda berada di tempat orang Jepang. Anda menemukan bug kritis yang perlu segera diperbaiki, saat pengembang masih tidur. Sekalipun Anda memahami bahwa mereka akan mencoba dan terus memperbaiki bug setelah akhir hari kerja Anda, tetapi perasaan keterlambatan abadi akan meningkat sebanding dengan urgensi bug. Untungnya, koordinator kami bekerja di Vladivostok, yang 1 jam lebih cepat dari Jepang. Ini sangat membantu, karena dia dengan gagah berani mengambil pukulan utama kemarahan pada dirinya sendiri dan sedikit meredam perasaan orang Jepang.
Namun demikian, mengingat kecenderungan orang Jepang untuk bekerja berlebihan, bagi kami, sebagai pengembang, periode pengujian penerimaan biasanya menjadi sumber stres yang terus-menerus sepanjang hari kerja: Anda datang bekerja dengan rasa bersalah karena bug dan "terlambat" dan pergi, juga, sebagian bersalah karena Anda tidak berhasil memperbaikinya "hari ini". Namun, seiring waktu, kami terbiasa dengan mode ini, dan pada saat yang sama, untuk komunikasi dan pelokalan bug yang lebih efektif, tim penguji Jepang kami dan pengembang kami memindahkan jadwal kerja mereka lebih dekat satu sama lain.
Fokus pada kualitas
Metodologi yang telah kami kerjakan melibatkan fase pengujian berlapis-lapis. Pertama, pengujian di tingkat pengembangan, dan kemudian beberapa fase lagi di sisi pelanggan. Perfeksionisme adalah hal bermata dua: kondisi seperti itu sering memakan waktu yang ditentukan dalam fase menurut hukum Parkinson pertama, tetapi pada saat yang sama, ketelitian dan ketelitian mereka ditujukan pada hal kecil yang menyatukan kita - kualitas produk akhir.
Jika banyak proses dan rutinitas yang berlebihan tampak tidak berarti bagi kami, maka peduli tentang kualitas kode dan, sebagai hasilnya, produk adalah bahasa yang kami temukan dalam bahasa yang sama. Pada waktu yang berbeda, seluruh kode dijalankan terhadap dua penganalisis statis. Klien mengalokasikan waktu untuk memperbaiki masalah yang ditemukan, yang bukan merupakan praktik umum dalam proyek agile / western. Selain itu, kami membahas semua kode baru dan yang diubah dengan tes. Itu tidak selalu berhasil sepenuhnya, oleh karena itu, untuk menghemat waktu dan efisiensi, penekanan utama pada fase aktif perbaikan bug proyek adalah pada uji integrasi. Ngomong-ngomong, salah satu kiriman kami adalah uji coba dan laporan cakupan kode - perhatian terhadap kualitas bergema di hati kami, dan kami paling sering menemukan kompromi di area ini.
Selain itu, sebagai peningkatan kualitas kode, kami menawarkan kepada orang Jepang praktik melakukan hingga 4 ulasan dari orang yang berbeda, termasuk pimpinan tim, tergantung pada kerumitan tiket. Hasilnya, ini mendorong saya untuk menjelajahi kemungkinan peninjauan kode otomatis di GitLab. Saya tidak dapat menerapkan semua ini pada proyek, tetapi saya menulis template kecil untuk proyek-proyek mendatang. Selain memperkuat tinjauan, kami telah mencapai keberhasilan dalam meningkatkan pengujian otomatis (unit, integrasi, asap).
Metrik kinerja (KS)
Metrik diperkenalkan pada proyek, termasuk jumlah baris (KS) dari kode tertulis. Ini telah menjadi subyek kontroversi dan diskusi yang intens selama pengembangan. Metrik ini digunakan untuk melacak kemajuan, memperkirakan kepadatan bug, dan berfungsi sebagai dasar untuk perkiraan jumlah pengujian, halaman dokumentasi, dan waktu peninjauan.
Jumlah baris kode juga digunakan untuk menghitung produktivitas programmer.
Banyak masalah dengan metode ini segera muncul di benak: kode UI jauh lebih banyak, tetapi mengandung lebih sedikit kerumitan, dan 10 baris kode lainnya dapat diperoleh dengan mengorbankan aktivitas otak yang terus-menerus selama beberapa hari. Kami mencoba untuk mulai mengevaluasi pekerjaan dalam jumlah kasus penggunaan, tetapi tidak ada analis yang berdedikasi, dan kompetensi pengembang tidak cukup. Menjelang pertengahan proyek, ketua tim sebelumnya menyarankan penggunaan jumlah metode sebagai metrik volume. Hasilnya, kami mulai menghitung KS dan jumlah metode.
Seiring berjalannya waktu, kebingungan menjadi semakin besar: Saya memutuskan untuk menggunakan data historis tentang waktu aktual yang dihabiskan dan volume aktual yang diproduksi untuk menemukan koefisien yang akan menerjemahkan jam kerja menjadi perkiraan volume. Karena, selain menulis, kami disertai dengan sejumlah besar tugas proses, fase pengujian, ulasan, dan dokumentasi, kalkulator semacam itu sangat berguna bagi kami.
Estimasi dan tenggat waktu
Di Jepang, ada praktik mendorong pengembang untuk menurunkan perkiraan dan, karenanya, tenggat waktu, dan kemudian mendorong perasaan bersalah (" Anda sendiri yang mengatakannya ") sehingga "pelakunya" akan bekerja ulang, mencoba memenuhi tenggat waktu . Dalam situasi kami, terkadang ini mirip dengan tawar-menawar untuk tenggat waktu. Kami memastikan bahwa 2-3 pengembang tambahan tidak akan mempercepat pekerjaan pada masalah tersebut - tetapi di sisi lain, kabel tersebut berdiri tegak. Dengan berbagai tingkat keberhasilan, kami dengan gagah berani mempertahankan tenggat waktu, dan menjelang tenggat waktu yang sangat kritis kami membuat kompromi, yang biasanya terdiri dari perbaikan dan, lebih jarang, menarik sumber daya tambahan. Namun, kami sering gagal memenuhi tenggat waktu ini.
Seiring waktu, diputuskan untuk mengotomatiskan fenomena ini juga. Saya mengambil tiket sebagai dasar, menambahkan ulasan yang diperlukan, kemungkinan bug dan ... Saya mencoba menarik ini di MS Project. Sayangnya, dari waktu ke waktu dia menunjukkan urutan tugas yang berbeda dan dengan cara yang tidak diketahui menetapkan batasan. Tidak banyak waktu, jadi saya memutuskan untuk segera membuat pembuatan bagan Gantt di Excel - karena ternyata lebih mudah diprediksi dan patuh. Dengan demikian, kami dapat dengan mudah mengubah perkiraan - bersamaan dengan itu, tanggal penyelesaian juga berubah. Menjadi lebih mudah untuk menyusun kembali jadwal, pelanggan menyukainya. Meskipun ini tidak menyelesaikan masalah kegagalan tenggat waktu, kami dapat memperingatkan pelanggan sebelumnya tentang pergeseran waktu.
Tradisi
Ketika saya melakukan perjalanan bisnis ke Jepang dengan tujuh orang, kami diperintahkan untuk mematuhi kode berpakaian tradisional untuk kantor Jepang: setelan bisnis, kemeja tipis, dan dasi. Tentunya bagi programmer yang terbiasa memakai hoodies dalam kehidupan sehari-hari, hal ini menjadi tantangan yang nyata. Namun demikian, waktu memainkan perannya, dan rasa memiliki (bisa disebut insting kawanan ) muncul, yang menambah energi dan bahkan membuatnya menjadi "milik kita". Gambar itu menghibur: di Stasiun Shinagawa di Tokyo, ada sejumlah besar kantor perusahaan tradisional Jepang yang besar, di mana setiap pagi ribuan kerah putih berbondong-bondong dari seluruh ibu kota dan pinggiran kota. Tontonannya luar biasa!
Sumber foto
Biasanya hari kerja kami dimulai pukul 9, meski beberapa rekan Jepang datang kemudian. Untuk makan siang, kami antre dengan pekerja kantoran yang sama di toko ramen favorit kami tidak jauh dari tempat kerja. Saya tidak bisa menyiasati topik antrian di Jepang - ini hanya relaksasi total, karena tidak ada yang akan naik ke depan antrian tanpa kebutuhan vital. Dan di metro ada tempat khusus untuk antrian, dan tidak ada yang pernah melanggar aturan untuk membangun antrian, dan ini bagus.
Pada malam hari, pekerjaan di kantor kami semakin cepat. Di kantor kami, hari kerja berakhir pada pukul 18:00, tetapi hampir tidak ada orang Jepang yang akan pergi. Tapi di saat yang sama, mereka juga suka menghilangkan stres dengan sake dan banyak lagi.setelah bekerja - dan mereka melakukannya cukup sering. Dan meskipun kami memiliki beberapa kontradiksi di tempat kerja, di luar jam kerja dalam suasana informal, kolega kami ternyata adalah lawan bicara yang tulus.
Di perusahaan tradisional Jepang, orang Jepang mempertahankan rantai komando yang ketat dalam hubungan mereka dengan atasan mereka. Menurut saya, inilah salah satu perbedaan utama saat ini antara pengembang Jepang dan Rusia. Ketika masalah muncul, orang Jepang hampir tidak pernah menyalahkan pelaku langsung, tetapi lebih cenderung menyalahkan manajemen, dan di kedua sisi. Semakin tinggi pangkatnya, semakin besar tanggung jawabnya dan semakin tinggi biaya kegagalannya. Semuanya sesuai dengan aturan: semakin banyak kekuatan, semakin banyak tanggung jawab .
Klien adalah tuhan
Jepang dibedakan oleh sikap khususnya terhadap klien. Dan pelanggan Jepang kami mungkin mengharapkan sikap yang sama dari kami.
Memang ada pepatah dalam bahasa Jepang: "O-kyaku-sama-wa kamisama des" (Klien adalah dewa) - dan itu benar-benar tepat sasaran. Jika kita melihat hubungan antara pelanggan dan kontraktor di Rusia, maka perbedaannya dengan Jepang akan sangat terlihat. Sepanjang hidup saya di Rusia, komunikasi yang sopan dengan para pemain tidak menjanjikan sesuatu yang baik bagi pelanggan - sebaliknya, semakin banyak skandal dan kekasaran dengan mereka yang memberi Anda layanan (kurir, pelayan, tukang reparasi, dll.), Semakin banyak hasil terbaik dijamin. Di Jepang, menurut pengamatan saya, Anda bisa tenang. Ya, layanannya mahal, tapi dijamin memuaskan pelanggan. Ini masalah selera, tapi saya suka cara ini - tetap sopan dan tidak khawatir tentang kualitas.
Kesimpulan
Terlepas dari ketidaksepakatan dan kesulitan, kami mengatasi pekerjaan dengan pelanggan Jepang dan tim teknisnya. Beberapa fitur ternyata sulit dan tidak menyenangkan bagi kami, sementara fitur lainnya pantas dihormati dan membuat kami lebih dekat. Kami harus berdamai dengan sesuatu atau bahkan menunggu waktu dan kerja tim untuk melakukan hal mereka, di suatu tempat ternyata menemukan kompromi, dan di suatu tempat - solusi.
Apakah adil untuk mengatakan bahwa sebagian besar stereotip tentang orang Jepang di tempat kerja benar? Semuanya tidak sesederhana itu.
Subordinasi antara atasan dan bawahan memang lebih terasa kental di Jepang, namun belakangan ini kaum muda semakin banyak yang membobol sistem. Daur ulang adalah hal biasa, tetapi ada lebih banyak hari libur di Jepang daripada di Rusia. Ada orang-orang yang sangat bertanggung jawab yang cenderung untuk memenuhi tenggat waktu dengan segala cara, selalu dan di mana saja - dan ini tidak bergantung pada negara atau mentalitas sama sekali. Semakin lama kami bekerja dengan kolega kami dari Jepang, semakin sedikit perbedaan yang terlihat dan semakin banyak kesamaan yang ditemukan. Sejarah dan budaya yang unik tidak dapat tidak mencerminkan karakter dan tradisi nasional, namun demikian, ada lebih banyak kesamaan. Dan saya berterima kasih atas pengalaman ini!