AI-তে output বাড়লেও message কমে—দলের জ্ঞান হারাচ্ছে কি না মাপুন

AI-সহায়ক output বাড়ার সঙ্গে message কমলে দল জ্ঞান হারাচ্ছে—এ সিদ্ধান্ত সরাসরি নেওয়া যায় না। কম message অপ্রয়োজনীয় সমন্বয় কমার লক্ষণও হতে পারে; ঝুঁকি বোঝার জন্য accepted output-এর পাশে review latency, cross-team reuse, unresolved decision ও communication diversity মাপতে হবে।

সতর্কতার মূল কারণ হলো, নতুন M365 গবেষণায় communication action মোটের ওপর কমেনি; productivity action-এর তুলনায় ধীরে বেড়েছে। তাই message count নয়, কাজ মানুষের পর্যালোচনা পাচ্ছে কি না, সিদ্ধান্তের যুক্তি সংরক্ষিত হচ্ছে কি না এবং শেখা দল পেরিয়ে ছড়াচ্ছে কি না—এই ফলগুলোই knowledge-flow-এর বেশি কার্যকর সংকেত।

M365 trace কী দেখিয়েছে—আর কী দেখায়নি

একাধিক বড় আন্তর্জাতিক প্রতিষ্ঠানের Microsoft 365 digital trace নিয়ে করা পর্যবেক্ষণমূলক arXiv preprint-এ দেখা যায়, adoption-এর পর ২০ সপ্তাহে ১০০ বারের বেশি AI ব্যবহারকারীদের productivity-oriented application action ২১.২% এবং communication action ৭.১% বেড়েছে। email পড়া ও গোছানোর মতো কিছু কাজ কমলেও উভয় শ্রেণির মোট activity বেড়েছে; ফলে গবেষণাটি message-এর সার্বিক পতন বা AI-এর একক causal effect প্রমাণ করে না।

গবেষকদের ব্যাখ্যায় অসম বৃদ্ধিটি individual ও documentation-focused কাজের দিকে ভার সরে যাওয়ার সঙ্গে সম্পর্কিত। এতে দক্ষতা বাড়া বা information overload কমার সম্ভাবনা আছে, আবার interpersonal communication ও diverse information diffusion দুর্বল হওয়ার ঝুঁকিও আছে। কোনো নির্দিষ্ট দলের জ্ঞানপ্রবাহ ক্ষতিগ্রস্ত হয়েছে কি না জানতে তাই স্থানীয় outcome metric দরকার।

Output-কেন্দ্রিক প্রত্যাশার সীমাও এখানে গুরুত্বপূর্ণ। প্রায় ৭৫০ জন জ্যেষ্ঠ corporate financial executive—যাঁদের অধিকাংশ CFO—নিয়ে করা Atlanta Fed-এর working paper output per worker, পণ্য বা সেবার মান, decision speed বা accuracy এবং বেশি মূল্যবান কাজে সময়কে AI ব্যবহারের প্রধান ফলগুলোর মধ্যে রেখেছে। একই জরিপে ২০২৫ সালের executive-reported productivity gain ছিল গড়ে ১.৮%, অথচ revenue ও employment থেকে হিসাব করা implied gain ছিল ০.৬%—দ্রুত বা ভালো কাজের অনুভূতি তাৎক্ষণিক আর্থিক ফলে পুরোটা ধরা নাও পড়তে পারে।

একটি metric নয়, পাঁচ ঘরের scorecard

প্রথম ঘরটি হবে গৃহীত output। AI-এর প্রতিটি draft, edit বা file version না গুনে reviewer বা stakeholder গ্রহণ করেছেন—এমন deliverable, সমাধান হওয়া customer issue, অনুমোদিত analysis বা সম্পন্ন milestone গুনুন। সঙ্গে rework বা পুনরায় খোলার হার রাখুন, যাতে নিম্নমানের draft উৎপাদন বাড়তি ফল হিসেবে গণ্য না হয়।

একটি activity count যে productivity বোঝায় না, তার প্রতিষ্ঠিত উদাহরণ software development। SPACE framework-এর মূল বক্তব্য হলো productivity কোনো একক metric বা dimension দিয়ে মাপা যায় না; এতে satisfaction and well-being, performance, activity, communication and collaboration এবং efficiency and flow একসঙ্গে দেখা হয়। নিচের scorecard সেই নীতিকে সাধারণ knowledge-work-এর জন্য operational রূপ দেয়।

• গৃহীত output: নির্ধারিত সময়ে reviewer বা stakeholder গ্রহণ করেছেন—এমন ফলের সংখ্যা; raw document count নয়। দলের আকার বা demand বদলালে সংখ্যাটি active full-time-equivalent সদস্য বা workload দিয়ে স্বাভাবিক করুন।
• Review latency: কাজ review-ready হওয়ার পর প্রথম অর্থপূর্ণ human review বা অনুমোদন পর্যন্ত মধ্যম সময়। median-এর পাশে ৭৫তম percentile রাখলে দীর্ঘ অপেক্ষার একটি অংশ গড়ের আড়ালে থাকবে না।
• Cross-team reuse: প্রকাশিত reusable artefact-এর কতটি অন্য team বা function নথিভুক্ত reference, import, adaptation বা adoption-এর মাধ্যমে ব্যবহার করেছে। স্বয়ংক্রিয় view বা accidental click reuse নয়।
• Unresolved decision: সম্মত সময়সীমা পেরোলেও owner, outcome বা rationale নথিভুক্ত হয়নি—এমন decision-এর অনুপাত। সবচেয়ে পুরোনো খোলা সিদ্ধান্তটির বয়স আলাদাভাবে রাখুন।
• Communication diversity: গুরুত্বপূর্ণ review ও decision-এ প্রয়োজনীয় কতটি function বা team অর্থপূর্ণ অবদান রেখেছে এবং অবদান অল্প কয়েকজনের মধ্যে কতটা কেন্দ্রীভূত। এটি মোট message-এর বিকল্প নয়, বরং অংশগ্রহণের বিস্তার।

Diversity মানে সবাইকে বেশি message পাঠানোর লক্ষ্য দেওয়া নয়। প্রয়োজনীয় বিশেষজ্ঞ, বাস্তবায়নকারী ও সিদ্ধান্তগ্রহীতার মতামত ঠিক সময়ে পৌঁছাচ্ছে কি না সেটিই প্রশ্ন। ভারতসহ ১০টি বাজারের self-reported survey data নিয়ে তৈরি Microsoft-এর 2026 Work Trend Index বলছে, উন্নত AI ব্যবহারকারীরা অন্যদের তুলনায় দলে AI-এর শেখা ও ভুল ভাগ করা, quality standard আলোচনা করা এবং workflow নথিবদ্ধ করার কথা বেশি জানিয়েছেন; এটি causal proof নয়, তবে message volume-এর চেয়ে শেখা গ্রহণের ক্ষমতা কেন গুরুত্বপূর্ণ তার সহায়ক evidence।

নিজস্ব baseline-এ পরিবর্তন ধরুন

অন্য প্রতিষ্ঠানের universal benchmark বসাবেন না। একই ধরনের workload-এর AI চালুর আগের ছয় থেকে আট সপ্তাহকে প্রাথমিক baseline ধরে বর্তমান চার সপ্তাহের rolling window তুলনা করা ব্যবহারযোগ্য শুরু। headcount, ছুটি, campaign, deadline বা বড় release চিহ্নিত রাখুন, নইলে কাজের স্বাভাবিক ওঠানামা AI-এর প্রভাব বলে মনে হতে পারে।

প্রতিটি flow metric-কে স্থানীয় স্বাভাবিক variation-এর তুলনায় উন্নতি, স্থিতিশীল বা অবনতি হিসেবে চিহ্নিত করুন। উন্নতিকে +১, স্থিতিশীলকে ০ এবং অবনতিকে −১ দিলে চারটি flow metric থেকে −৪ থেকে +৪-এর একটি triage signal পাওয়া যায়। এটি গবেষণায় validated universal score নয়; component লুকিয়ে একটি মোট নম্বর প্রকাশ না করে manager-এর আলোচনায় অগ্রাধিকার ঠিক করার সম্পাদকীয়ভাবে প্রস্তাবিত পদ্ধতি।

• সবুজ: accepted output বাড়ছে, flow signal শূন্য বা তার বেশি এবং কোনো গুরুত্বপূর্ণ decision নির্ধারিত সময় পেরিয়ে খোলা নেই।
• হলুদ: output বাড়লেও পরপর দুই window-তে অন্তত দুটি flow metric খারাপ হচ্ছে। কারণ না জেনে AI deployment-কে সফল বলা যাবে না।
• লাল: output বাড়ার সঙ্গে review latency ও unresolved decision-এর বয়স বাড়ছে, আর reuse বা participation diversity কমছে। এটি workflow bottleneck তদন্তের সংকেত—ব্যক্তির performance rating নয়।

একই message count, ভিন্ন diagnosis

Message কমেছে, কিন্তু review দ্রুত, reuse স্থিতিশীল এবং decision সময়মতো বন্ধ হচ্ছে—এমন হলে দল সম্ভবত অপ্রয়োজনীয় coordination কমিয়েছে। এখানে message বাড়ানোর target নতুন বাধা তৈরি করতে পারে। বিপরীতে output ও message দুটিই বাড়লেও unresolved decision বাড়লে যোগাযোগ হচ্ছে, কিন্তু closure হচ্ছে না; তখন decision log-এ owner, due date, outcome ও সংক্ষিপ্ত rationale রাখা বেশি প্রাসঙ্গিক।

শুধু review latency বাড়লে reviewer capacity, অস্পষ্ট quality bar বা এক ব্যক্তির approval bottleneck দেখুন। reuse ও diversity একসঙ্গে নামলে artefact খুঁজে পাওয়া যাচ্ছে কি না, অন্য function যথাসময়ে review-এ যুক্ত হচ্ছে কি না এবং reusable কাজের owner আছে কি না যাচাই করুন। আর output-এর সঙ্গে rework বাড়লে draft count বাদ দিয়ে metric-কে accepted outcome-এ ফেরান।

সাপ্তাহিক পর্যালোচনায় চারটি প্রশ্ন যথেষ্ট: কোন accepted result বেড়েছে, কোন review আটকে আছে, কোন decision-এর owner নেই এবং গত মাসের কাজ অন্য কোনো দল ব্যবহার করেছে কি না। উত্তর বের করা না গেলে সেটিই measurement gap; workflow-তে review-ready, decision owner ও reusable artefact-এর সংজ্ঞা না থাকা পর্যন্ত telemetry বাড়িয়ে লাভ হবে না।

Team metric-কে নজরদারি বানাবেন না

Scorecardটি team-level operational health-এর জন্য, ব্যক্তির message, activity বা keystroke ranking-এর জন্য নয়। content না পড়ে timestamp, workflow state, cross-team reference ও aggregated participation-এর মতো প্রয়োজনীয় metadata ব্যবহার করুন। কোন data নেওয়া হবে, কত দিন রাখা হবে, কারা দেখবেন এবং কোন সিদ্ধান্তে তা ব্যবহার হবে—কর্মীদের আগে জানান।

Microsoft-এর Viva Insights নির্দেশনা স্পষ্ট করে যে পণ্যটি employee evaluation, tracking, automated decision-making, profiling বা monitoring-এর জন্য নির্মিত নয়। এটি একটি product-specific সীমা; স্থানীয় আইন, কর্মী প্রতিনিধিত্ব ও প্রতিষ্ঠানের নীতির ভিত্তিতে access control, retention এবং minimum group size আরও কঠোর হতে পারে।

Digital trace জ্ঞান স্থানান্তরের পূর্ণ প্রমাণ নয়: কথোপকথনের মান, tacit knowledge বা ভুল সিদ্ধান্তের ভবিষ্যৎ খরচ এতে অনুপস্থিত থাকতে পারে। তাই মাসিক ছোট team pulse-এ সদস্যরা reviewer চেনেন কি না, decision rationale খুঁজে পান কি না এবং অন্য দলের শেখা reuse করতে পারেন কি না জিজ্ঞেস করুন। Accepted output বাড়া এবং knowledge-flow অক্ষুণ্ণ থাকা একসঙ্গে দেখা গেলেই GenAI-কে দলের productivity gain বলা যুক্তিসঙ্গত।