ভালো code একা যথেষ্ট নয়
জাপানের engineering team-এ কাজ শুরুর দিকে ভাবতাম, ভালো engineer হওয়া মানে clean code লেখা, সঠিক architecture বেছে নেওয়া, সমস্যার efficient সমাধান বের করা। এটা পুরোপুরি ভুল না, কিন্তু অসম্পূর্ণ ছিল।
কয়েক মাসের মধ্যেই বুঝেছিলাম, একজন engineer যত ভালো code-ই লিখুন, team-এর বাকিরা যদি সেই কাজের context আর সীমাবদ্ধতা না বোঝেন তাহলে সেটা শেষ পর্যন্ত সমস্যা তৈরি করে। Manufacturing software বা computer vision-এর মতো কাজে, যেখানে একটা ভুল সরাসরি production line-এ গিয়ে লাগে, communication gap মানেই বাস্তব ক্ষতি।
ভাষার বাধা
শুরুতে সবচেয়ে বড় সমস্যা ছিল ভাষা। জাপানি ভাষায় সাবলীল না হওয়ায় প্রতিটা meeting-এ একটু বাড়তি effort দিতে হতো—কথা বোঝা, নিজের বক্তব্য গুছিয়ে বলা, সিদ্ধান্তে দ্রুত অংশ নেওয়া।
এখান থেকে একটা জিনিস শিখেছি: ভাষা perfect না হলেও communication clear হতে পারে। জটিল sentence বানানোর চেষ্টা না করে ছোট, সরাসরি বাক্যে বললে ভুল বোঝাবুঝি কমে যায়। "এই feature-টা এভাবে কাজ করে কারণ..." লম্বা করে বলার বদলে "এটা X করে। কারণ: Y।"—এই ধরনের সংক্ষিপ্ত গঠন non-native speaker হিসেবে আমার জন্য অনেক বেশি কাজে দিয়েছে।
যা trust তৈরি করেছে
তিনটা অভ্যাস আমাকে সবচেয়ে বেশি সাহায্য করেছে। প্রথমত, meeting-এর আগে প্রস্তুতি লিখে রাখা—আলোচনার বিষয়, প্রশ্ন, প্রস্তাবিত সমাধান সংক্ষেপে নোট করে নেওয়া, যাতে ভাষার সীমাবদ্ধতা থাকলেও নিজের বক্তব্য দ্রুত ও স্পষ্টভাবে বলা যায়।
দ্বিতীয়ত, decision-এর কারণ document করা। শুধু "আমরা এই approach নিয়েছি" লিখলে চলে না; কেন সেটা বেছে নেওয়া হয়েছে, কী কী option বিবেচনা করা হয়েছিল—এসব লিখে রাখলে পরে কেউ নতুন যোগ দিলে বা কোনো প্রশ্ন উঠলে অনেক সময় বাঁচে।
তৃতীয়ত, নিয়মিত progress share করা। কাজ পুরো শেষ হওয়ার অপেক্ষা না করে ছোট ছোট ধাপে জানানো—এতে সমস্যা তাড়াতাড়ি ধরা পড়ে, শেষ মুহূর্তে বড় surprise আসে না।
Meeting culture
জাপানি workplace-এর meeting culture-এ একটা জিনিস আমাকে অবাক করেছিল: সিদ্ধান্ত নেওয়ার আগে সবার মতামত শোনার প্রবণতা, যাকে অনেকে "nemawashi" বলেন। শুরুতে এটাকে ধীরগতির মনে হতো। পরে বুঝেছি এই প্রক্রিয়াটাই আসলে পরবর্তী execution-কে দ্রুত ও ঝামেলাহীন করে তোলে, কারণ সিদ্ধান্তের আগেই সম্ভাব্য দ্বিমত বা সমস্যা identify হয়ে যায়।
এখান থেকে যেটা নিয়েছি: তাড়াহুড়ো করে সিদ্ধান্ত চাপিয়ে না দিয়ে, আগে সংশ্লিষ্ট সবার input নেওয়া—এতে সময় একটু বেশি লাগলেও ফল ভালো হয়।
Visual ও লিখিত communication
শুধু মৌখিক আলোচনার ওপর নির্ভর না করে visual example আর written summary ব্যবহার করলে communication অনেক বেশি নির্ভুল হয়। একটা diagram, একটা annotated screenshot, একটা ছোট flowchart—লম্বা ব্যাখ্যার চেয়ে অনেক দ্রুত idea পৌঁছে দেয়।
Computer vision আর robotics-এর কাজে এটা বিশেষভাবে কাজে লেগেছে, যেখানে system-এর behavior visual data-নির্ভর। একটা annotated image দেখিয়ে "এই অংশটা misdetect হচ্ছে" বলা, শুধু মুখে বলার চেয়ে সবাইকে দ্রুত একই বোঝাপড়ায় নিয়ে আসে।
শেষ কথা
Communication কোনো "soft" বা optional extra না—এটা engineering delivery-এর একটা অংশ। কাজ শেষ করাই একজন engineer-এর একমাত্র দায়িত্ব না; সেই কাজ যেন team বুঝতে পারে, যাচাই করতে পারে, দরকার হলে এগিয়ে নিতে পারে—সেটাও তাঁর দায়িত্বের অংশ।
ভাষা perfect না হলেও structured thinking, ধারাবাহিক documentation আর clear visual communication দিয়ে একজন engineer cross-cultural team-এ পুরোপুরি কার্যকর থাকতে পারেন। এই শিক্ষাটা আজও প্রতিদিনের কাজে সঙ্গে থাকে।
