Slack-এ হারিয়ে যাওয়া: কেন Searchable মানে Findable না
তোমার টিমে অনেক বেশি Slack channel আর কিছু খুঁজে পাওয়া যায় না। কেন search একাই ঠিক করবে না, আর আসলে কী করবে।
By Ellis Keane · 2026-03-17
তোমার টিমের এখন ঠিক কতগুলো Slack channel আছে? Sidebar-এর সংখ্যা না, কারণ বেশিরভাগ তুমি mute করে রেখেছো। আসল সংখ্যা, যার মধ্যে আছে ছয় মাস আগে শেষ হওয়া project-এর জন্য বানানো channel, এত একরকম নামের channel যে কোনটা ঠিক সেটা তুমি কখনোই sure না, আর কিছু channel যেখানে সত্যিই গুরুত্বপূর্ণ জিনিস হচ্ছে কিন্তু তুমি কখনো খুঁজে পাবে না কারণ তুমি জানতেই না ওখানে কিছু হচ্ছে।
আমি ধরে নিচ্ছি সংখ্যাটা তুমি জানো না। আমরাও জানি না, সত্যি বলতে। আর সেটাই পুরো point-টা।
Slack channel overload-এর standard পরামর্শ হলো reorganize করো, naming convention বানাও, যেটা দরকার নেই archive করো, হয়তো quarterly cleanup চালাও (এমন একটা ritual যেটা এক বিকেলের জন্য productive মনে হয় আর তারপর পরের ছয় সপ্তাহে আস্তে আস্তে ভেঙে পড়ে)। আর এই পরামর্শ ঠিক আছে, যতদূর যায়, কিন্তু এটা লক্ষণের চিকিৎসা করে, mechanism-এর না। তোমার টিমে অনেক বেশি Slack channel আছে আর কিছু খুঁজে পাওয়া যায় না – এর কারণ তুমি organisation-এ খারাপ (হ্যাঁ, হয়তো একটু), বরং Slack বানানো হয়েছে conversation-এর জন্য, knowledge-র জন্য না, আর এই দুটোর মাঝের ফাঁকেই তোমার সব গুরুত্বপূর্ণ context মরতে যায়।
Searchable মানে Findable না
এই জিনিসটাই বেশিরভাগ টিমকে বিভ্রান্ত করে। Slack-এর search আসলে যা করে তাতে বেশ ভালো। একটা শব্দ টাইপ করো, সেই শব্দ সহ message খুঁজে দেয়, relevance অনুযায়ী rank করে, channel, person আর date range দিয়ে filter করতে দেয়। তুমি কী খুঁজছো আর মোটামুটি কখন হয়েছে জানলে, Slack search তোমাকে সেখানে পৌঁছে দেবে।
সমস্যা হলো "findable" আর "searchable" মৌলিকভাবে ভিন্ন ক্ষমতা বর্ণনা করে, আর Slack শুধু একটা দেয়।
"Searchable আর findable মৌলিকভাবে ভিন্ন ক্ষমতা বর্ণনা করে, আর Slack শুধু একটা দেয়।" – Ellis Keane
Searchable মানে: আমার একটা specific keyword আছে, আর আমি সেটা সহ সব message দেখতে চাই। Findable মানে: আমার মনে আছে একটা conversation হয়েছিল, মোটামুটি বিষয় কী ছিল জানি, কিন্তু কেউ ঠিক কী শব্দ ব্যবহার করেছিল, কোন channel-এ ছিল, বা ঠিক কখন হয়েছিল মনে নেই। দ্বিতীয়টা, আমাদের অভিজ্ঞতায়, মানুষ Slack থেকে তথ্য বের করার প্রায় ৮০% চেষ্টায় যেটা করে।
শেষবার কখন Slack-এ কিছু খুঁজেছিলে সেটা ভাবো। তুমি কি exact keyword টাইপ করেছিলে, নাকি বিভিন্ন variation চেষ্টা করছিলে, channel scroll করছিলে, DM check করছিলে, আর শেষে কাউকে জিজ্ঞেস করছিলে "hey, মনে আছে আমরা কোথায় ... নিয়ে কথা বলেছিলাম?" দ্বিতীয়টা হলে (আর আমি আসল টাকা বাজি ধরবো সাধারণত সেটাই), তাহলে Slack-এর search ভাঙা না। এটা তোমার আসল সমস্যার চেয়ে অন্য একটা সমস্যা solve করছে।
Channel কীভাবে multiply হয় আর context fragment হয়
আমরা যেসব টিম observe করেছি তাদের বেশিরভাগে আসলে কী হয় সেটা বলি। শুরু হয় নির্দোষভাবে: team-এর জন্য channel (#engineering, #design, #product), project-এর জন্য (#project-atlas, #project-beacon), function-এর জন্য (#standup, #deployments, #incidents), আর কিছু social (#random, #watercooler)। হয়তো ১৫-২০টা channel, আর তিন মাস দারুণ কাজ করে।
তারপর edge blur হতে শুরু করে। কেউ #engineering-এ deployment issue নিয়ে conversation শুরু করে যেটা আসলে #incidents-এ হওয়া উচিত। Design review conversation ছড়িয়ে যায় #design, #project-atlas আর একটা DM thread-এ। কেউ #project-atlas-design বানায় কারণ ওই project-এর design feedback-এর জন্য আলাদা জায়গা চায়, আর এখন Atlas design decision দুই জায়গায় থাকতে পারে, আর পুরো picture চাইলে দুটোই check করতে হবে।
Channel সংখ্যা আসলে সমস্যা না, যদিও সমস্যা মনে হয় (আর আমি প্রতিটা টিমের জন্য এটা prove করতে পারি না, কিন্তু আমি যাদের সাথে কথা বলেছি সবার জন্য সত্য)। সমস্যা হলো প্রতিটা channel isolated context-এর pocket হয়ে যায় অন্য pocket-গুলোর সাথে কোনো connection ছাড়া। #project-atlas-এর conversation একটা Notion doc reference করে যেটা একটা Linear issue reference করে যেটা #engineering-এ discuss হয়েছে, আর এই reference-গুলোর কোনোটাই machine-readable link না। সব human shorthand: "as we discussed," "per the doc," "following up on that thread." যে মানুষ সব conversation-এ ছিল সে trail follow করতে পারবে। যে ছিল না (বা যে ছিল, ছয় মাস পরে) simply পারবে না।
Naming convention আসলে কী solve করে (আর কী করে না)
Naming convention পুরোপুরি dismiss করতে চাই না, কারণ একটা specific জিনিসে সাহায্য করে: ঠিক channel খুঁজে পেতে। team-engineering, proj-atlas, func-deploys এরকম consistent pattern sidebar navigate করতে সাহায্য করে। Real value, যদিও convention টিকে থাকে ঠিক যতক্ষণ না তৃতীয় মানুষ যে wiki পড়েনি সে proj-atlas-design-এর বদলে atlas-design-feedback বানায়।
কিন্তু naming convention findability সমস্যা solve করে না, কারণ findability মানে কোন channel-এ search করবে সেটা জানা না। এটা তোমার দরকারি conversation তিনটা channel আর একটা DM জুড়ে ছড়িয়ে থাকা, আর দুনিয়ার কোনো naming convention তোমাকে সেটা বলবে না। Slack-এর information architecture design-এই flat, আর এই flatness আসলে real-time conversation-এর জন্য strength (hierarchy চাও না যখন দ্রুত কাউকে deployment নিয়ে ping করতে হয়), কিন্তু retrieval-এর জন্য disaster।
"অনেক বেশি channel" সমস্যা আসলে "channel-এ আটকে থাকা context" সমস্যা। Channel সংখ্যা কমালে navigation-এ সাহায্য হয় কিন্তু underlying fragmentation solve হয় না।
কেন অনেক বেশি Slack channel আর কিছু খুঁজে পাওয়া যায় না
ধরো তুমি খুঁজছো সেই conversation যেখানে টিম internal API-র জন্য REST থেকে GraphQL-এ switch করার সিদ্ধান্ত নিয়েছিল। দেখো আসলে কেমন হয়:
- Slack-এ "GraphQL" search করো। ডজনখানেক channel জুড়ে প্রায় ২৫০ result আসে। বেশিরভাগ #engineering থেকে, কিছু #random থেকে (কেউ blog post share করেছে), কিছু #project-beacon থেকে যেখানে কেউ জিজ্ঞেস করেছিল switch তাদের affect করবে কিনা।
- #engineering-এ narrow করো। তাও ডজনখানেক result। Decision নিজে কোনোটাতেই নেই কারণ lead engineer যখন বলেছিল "let's do it," তখন শুধু বলেছিল "sounds good, let's go with that" দুই দিন আগের message-এর reply-তে।
- "REST API" search করো comparison discussion খুঁজতে। ভিন্ন result set, partial overlap। Decision thread-এর সবচেয়ে গুরুত্বপূর্ণ কিছু message-এ "REST" বা "GraphQL" কোনোটাই নেই কারণ তারা developer experience আর type safety নিয়ে general term-এ আলোচনা করছিল।
- হাল ছেড়ে #engineering-এ জিজ্ঞেস করো: "কেউ কি মনে করতে পারো কখন আমরা GraphQL-এ switch করার সিদ্ধান্ত নিয়েছিলাম?" কেউ Linear issue-র link দেয়। Linear issue Notion RFC link করে। Notion RFC একটা Slack thread reference করে (কিন্তু link dead কারণ channel archive করা হয়েছে)। আর আসল decision moment ছিল huddle-এ, কোনো written record ছাড়াই।
এটা search সমস্যা না। এটা নলেজ গ্রাফ সমস্যা। আর এই কারণেই অনেক বেশি Slack channel থাকা টিম কিছু খুঁজে পায় না, Slack-এর search যত ভালোই হোক।
আসলে কী কাজ করে
নিজেদের টিমে এই pattern দেখার পর (আর অন্য engineering manager-দের কাছে দারুণভাবে similar গল্প শোনার পর), কয়েকটা জিনিসে আমরা settle করেছি যেগুলো সত্যিই সাহায্য করে:
মেনে নাও Slack inbox, archive না। সবচেয়ে useful mental model shift। Slack হলো যেখানে conversation real time-এ হয়, decision store হয় না। Slack-এ কিছু গুরুত্বপূর্ণ decision হলে সেটা durable কোথাও capture হওয়া দরকার: Linear issue, Notion doc, ADR, এমনকি commit message-ও হতে পারে। Slack হলো conversation; ওই অন্য টুলগুলো হলো record।
Thread ধর্মের মতো ব্যবহার করো। Findability-র জন্য Slack-এর সেরা feature thread, কারণ পুরো conversation একটা addressable unit-এ রাখে। Thread-এর permalink আছে। Channel-এর main timeline জুড়ে ছড়িয়ে থাকা conversation-এর নেই। তোমার team culture যদি main channel-এ reply করায় default হয় (অনেকেরই হয়, কারণ immediate মনে হয়), retrieval dramatically কঠিন হয়ে যায়।
Project channel না, decision channel বানাও। Counterintuitive, কিন্তু শোনো। #project-atlas-এর বদলে (বা পাশাপাশি), #decisions বা #decisions-engineering চেষ্টা করো। একটা channel যার একমাত্র উদ্দেশ্য হলো সংক্ষিপ্ত context সহ decision record করা। পুরো discussion থাকবে না (সেটা যেখানে naturally হয় সেখানেই হোক), কিন্তু একটা searchable, chronological log পাবে কী সিদ্ধান্ত হয়েছে আর discussion-এর link। ভাবো তোমার টিমের thinking-এর commit log। Enforcement mechanism যেটা আসলে কাজ করে (আমাদের অভিজ্ঞতায়): PR template-র অংশ বানাও। Merge-এর আগে relevant decision post link করো। Lightweight, review-তে checkable, আর কারও memory বা discipline-এর ওপর নির্ভর করে না এমন trail তৈরি করে।
Dot connect করো, অটোমেটিকভাবে। এই অংশে বলবো আমরা কী বানাচ্ছি, কারণ directly relevant। Sugarbug Slack message-কে Linear issue, GitHub PR, Notion doc আর Figma comment-এর পাশাপাশি ingest করে, আর একটা নলেজ গ্রাফ বানায় কীভাবে সব relate করে। ওই connection থাকলে কোন channel-এ conversation হয়েছে মনে রাখার দরকার নেই, কারণ task বা document থেকে শুরু করে trail follow করতে পারো প্রতিটা relevant conversation-এ, যেখানেই থাকুক। সব কিছু surface করার best UX নিয়ে আমরা এখনও কাজ করছি (সত্যি বলতে, cross-tool retrieval-এর UX ingestion-এর চেয়ে কঠিন), কিন্তু core approach – context reorganize না করে connect করা – এটাই আমাদের মতে আসলে সুঁই নাড়ায়।
taming notification overload notification fatigue in engineering teams the Slack notification strategy for busy teams পাঁচটা channel search করে হাতে খালি ফেরা বন্ধ করো। Sugarbug Slack-কে তোমার বাকি টুলের সাথে কানেক্ট করে যাতে decision findable থাকে।
প্রশ্ন: কতগুলো Slack channel হলে অনেক বেশি? উত্তর: কোনো magic number নেই, কিন্তু তোমার টিম যদি নিয়মিত খুঁজে না পায় কোন conversation কোথায় হয়েছে, বা channel overwhelming লাগায় মানুষ DM-এ চলে যায়, তাহলে সম্ভবত সীমা পার হয়ে গেছে। ১০-২০ জনের টিমে ৮০-১০০-র বেশি active channel থাকলে এই দেয়ালে ধাক্কা লাগে, যদিও তোমার টিম channel purpose আর archiving-এ কতটা disciplined তার উপর অনেক নির্ভর করে।
প্রশ্ন: Sugarbug কি Slack channel overload ম্যানেজ করতে সাহায্য করে? উত্তর: Sugarbug তোমার channel সরাসরি ম্যানেজ করে না, কিন্তু channel overload যে findability সমস্যা তৈরি করে সেটা solve করে। Slack message-কে Linear issue, GitHub PR, Notion doc আর Figma comment-এর পাশাপাশি একটা নলেজ গ্রাফে ingest করে, তাই decision বা conversation খুঁজলে একবার search করলেই পাওয়া যায়, যেকোনো channel-এ (বা যেকোনো টুলে) হোক না কেন।
প্রশ্ন: Slack-এ search থাকলেও কেন কিছু খুঁজে পাই না? উত্তর: Slack-এর search exact keyword সহ message খোঁজে, কিন্তু কর্মক্ষেত্রের বেশিরভাগ decision বিভিন্ন stage-এ ভিন্ন শব্দ ব্যবহার করে। কেউ হয়তো এক thread-এ "Redis option" বলেছে আর অন্য thread-এ "BullMQ", একই decision reference করে, আর ওই thread দুটো কখনো একে অপরকে reference করে না। Search text match খোঁজে। Decision trail খুঁজে পেতে conversation-গুলোর মধ্যে connection বুঝতে হয়, যেটা মৌলিকভাবে ভিন্ন ক্ষমতা।
প্রশ্ন: Sugarbug কি Slack channel-এর চেয়ে ভালো কিছু দিয়ে রিপ্লেস করতে পারে? উত্তর: না, আর চেষ্টা করা উচিতও না। Slack real-time conversation-এ excellent, আর সেটা সত্যিই মূল্যবান। সমস্যা Slack নিজে না, বরং গুরুত্বপূর্ণ context conversation-এর ভিতরে আটকে যাওয়া, যেটাকে সম্পর্কিত task, document আর code-র সাথে কানেক্ট করার কোনো উপায় নেই। Sugarbug সেই connection-গুলো অটোমেটিকভাবে বানায় যাতে কোথায় কী আলোচনা হয়েছে তোমাকে মনে রাখতে না হয়।