ضائع في Slack: لماذا القابل للبحث ليس قابلا للعثور
لدى فريقك قنوات Slack كثيرة جدا ولا يمكنه العثور على شيء. إليك لماذا لن يحل البحث وحده المشكلة، وما الذي سيحلها.
By Ellis Keane · 2026-03-17
كم عدد قنوات Slack التي يمتلكها فريقك الآن؟ ليس الرقم الموجود في الشريط الجانبي، لأنك كتمت معظمها. الرقم الفعلي، بما في ذلك القنوات التي أنشأها أشخاص لمشروع انتهى قبل ستة أشهر، والقنوات ذات الأسماء المتشابهة جدا لدرجة أنك لست متأكدا أبدا أيها الصحيح، وحفنة من القنوات التي تحدث فيها أشياء مهمة فعلا لن تجدها أبدا مرة أخرى لأنك لم تكن تعلم أنها تحدث في ذلك الوقت.
أخمن أنك لا تعرف الرقم. ولا نحن كذلك، بصراحة. وهذا هو بيت القصيد نوعا ما.
النصيحة القياسية للعبء الزائد لقنوات Slack هي إعادة التنظيم، وإنشاء اصطلاحات تسمية، وأرشفة ما لا تحتاجه، وربما إجراء تنظيف ربع سنوي (نوع الطقوس التي تبدو مثمرة لفترة ما بعد الظهر ثم تتفكك ببطء على مدار الأسابيع الستة التالية). وهذه النصيحة جيدة، إلى حد ما، لكنها تعالج العرض بدلا من الآلية. السبب في أن فريقك لديه قنوات Slack كثيرة جدا ولا يمكنه العثور على أي شيء ليس أنك سيئ في التنظيم (حسنا، ربما قليلا)، بل لأن Slack بُني للمحادثات، وليس للمعرفة، والفجوة بين هذين الشيئين هي المكان الذي يموت فيه كل سياقك المهم.
قابل للبحث لا يعني قابلا للعثور
هذا هو الشيء الذي يوقع معظم الفرق في الخطأ. بحث Slack جيد فعلا فيما يفعله. تكتب كلمة، فيجد الرسائل التي تحتوي على تلك الكلمة، بل ويصنفها حسب الصلة ويتيح لك التصفية حسب القناة والشخص والنطاق الزمني. إذا كنت تعرف ما تبحث عنه ومتى حدث تقريبا، فإن بحث Slack سيوصلك إلى هناك.
المشكلة هي أن "قابل للعثور" و"قابل للبحث" يصفان قدرات مختلفة جوهريا، ويقدم Slack واحدة منها فقط.
"قابل للبحث وقابل للعثور يصفان قدرات مختلفة جوهريا، ويقدم Slack واحدة منها فقط." – Ellis Keane
قابل للبحث يعني: لدي كلمة رئيسية محددة، وأريد رؤية كل رسالة تحتوي عليها. قابل للعثور يعني: أتذكر حدوث محادثة، وأعرف تقريبا ما كانت تدور حوله، لكنني لا أتذكر الكلمات الدقيقة التي استخدمها أي شخص، أو أي قناة كانت فيها، أو متى حدثت بالضبط. هذا الثاني هو، في تجربتنا، حوالي 80% من كيفية محاولة الأشخاص فعليا استرداد المعلومات من Slack.
فكر في المرة الأخيرة التي حاولت فيها العثور على شيء في Slack. هل كنت تكتب كلمة رئيسية دقيقة، أم كنت تجرب أشكالا مختلفة، وتمرر عبر القنوات، وتتحقق من الرسائل المباشرة، وتسأل شخصا ما في النهاية "مرحبا، هل تتذكر أين تحدثنا عن...؟" إذا كان الخيار الثاني (وأراهن بمال حقيقي أنه كذلك عادة)، فإن بحث Slack ليس معطلا. إنه يحل مشكلة مختلفة عن المشكلة التي لديك بالفعل.
كيف تتكاثر القنوات ويتجزأ السياق
إليك ما يحدث فعليا في معظم الفرق التي لاحظناها. يبدأ الأمر بشكل بريء: تنشئ قنوات للفرق (#engineering، #design، #product)، وقنوات للمشاريع (#project-atlas، #project-beacon)، وقنوات للوظائف (#standup، #deployments، #incidents)، وربما بعض القنوات الاجتماعية (#random، #watercooler). هذا ربما 15-20 قناة وتعمل بشكل جميل لمدة ثلاثة أشهر تقريبا.
ثم تبدأ الحواف في التلاشي. يبدأ شخص محادثة حول مشكلة نشر في #engineering والتي يجب أن تكون في #incidents. تمتد محادثة مراجعة التصميم عبر #design و#project-atlas وسلسلة رسائل مباشرة. يقوم شخص بإنشاء #project-atlas-design لأنه يريد مساحة مخصصة لملاحظات التصميم في ذلك المشروع، والآن هناك مكانان قد تعيش فيهما قرارات تصميم Atlas، ومن الأفضل التحقق من كليهما إذا أردت الصورة الكاملة.
عدد القنوات ليس المشكلة فعلا، رغم أنه يبدو كذلك (ولا يمكنني إثبات ذلك عبر كل فريق، لكنه كان صحيحا بالنسبة لكل فريق تحدثت إليه حول هذا الموضوع). المشكلة أن كل قناة تصبح جيبا معزولا من السياق دون اتصالات بالجيوب الأخرى. محادثة في #project-atlas تشير إلى مستند Notion يشير إلى تذكرة Linear نوقشت في #engineering، ولا توجد أي من هذه المراجع عبارة عن روابط يمكن للآلة قراءتها. إنها اختصارات بشرية: "كما ناقشنا"، "وفقا للمستند"، "متابعة لتلك السلسلة". يمكن للشخص الذي كان في كل تلك المحادثات تتبع المسار. الشخص الذي لم يكن كذلك (أو الشخص الذي كان، بعد ستة أشهر) ببساطة لا يستطيع.
ما تحله اصطلاحات التسمية فعليا (وما لا تحله)
لا أريد استبعاد اصطلاحات التسمية تماما، لأنها تساعد في شيء واحد محدد: تساعدك في العثور على القناة الصحيحة للبحث فيها. نمط متسق مثل team-engineering، proj-atlas، func-deploys يجعل الشريط الجانبي قابلا للتنقل. هذه قيمة حقيقية، حتى لو نجت الاتفاقية تقريبا حتى يقوم الشخص الثالث الذي لم يقرأ الويكي بإنشاء atlas-design-feedback بدلا من proj-atlas-design.
لكن اصطلاحات التسمية لا تحل مشكلة قابلية العثور، لأن قابلية العثور لا تتعلق بمعرفة القناة التي يجب البحث فيها. تتعلق بالمحادثة التي تحتاجها والمنتشرة عبر ثلاث قنوات ورسالة مباشرة، ولن تخبرك أي اصطلاحات تسمية في العالم بذلك. بنية المعلومات في Slack مسطحة حسب التصميم، وهذا التسطيح هو فعليا أحد نقاط قوتها للمحادثة في الوقت الفعلي (لا تريد تسلسلا هرميا عندما تحتاج إلى تنبيه شخص بسرعة حول عملية نشر)، لكنه كارثة للاسترداد.
مشكلة "القنوات الكثيرة جدا" هي في الواقع مشكلة "سياق محاصر في القنوات". تقليل عدد القنوات يساعد في التنقل لكنه لا يحل التجزئة الأساسية.
لماذا لديك قنوات Slack كثيرة جدا ولا يمكنك العثور على أي شيء
لنفترض أنك تحاول العثور على المحادثة التي قرر فيها فريقك التبديل من REST إلى GraphQL للـ API الداخلي. إليك كيف يبدو ذلك فعليا:
- تبحث عن "GraphQL" في Slack. تحصل على نحو 250 نتيجة عبر اثنتي عشرة قناة. معظمها من #engineering، وبعضها من #random (شخص يشارك مقال مدونة)، والقليل من #project-beacon حيث سأل شخص ما إذا كان التبديل سيؤثر عليه.
- تقوم بالتحسين إلى #engineering. لا تزال هناك عشرات النتائج. القرار نفسه ليس في أي منها لأنه عندما قال كبير المهندسين "لنفعل ذلك"، قال فقط "يبدو جيدا، لنمض في ذلك" ردا على رسالة من يومين سابقين.
- تبحث عن "REST API" على أمل العثور على مناقشة المقارنة. مجموعة مختلفة من النتائج، تداخل جزئي فقط. بعض أهم الرسائل في سلسلة القرار لا تحتوي على "REST" أو "GraphQL" لأنهم كانوا يناقشون تجربة المطور وسلامة النوع بعبارات عامة.
- تستسلم وتسأل في #engineering: "هل يتذكر أحد متى قررنا التبديل إلى GraphQL؟" يرد شخص برابط لتذكرة Linear. ترتبط تذكرة Linear بطلب تعليقات (RFC) في Notion. يشير RFC في Notion إلى سلسلة Slack (لكن الرابط معطل لأن القناة أُرشفت). ولحظة القرار الفعلية كانت في huddle دون أي سجل مكتوب على الإطلاق.
هذه ليست مشكلة بحث. هذه مشكلة رسم بياني معرفي. وهو السبب الحقيقي وراء عدم تمكن الفرق التي لديها قنوات Slack كثيرة جدا من العثور على أي شيء، بغض النظر عن مدى جودة بحث Slack.
ما ينجح فعليا
بعد مشاهدة هذا النمط يتكشف في فريقنا (وسماع قصص مشابهة بشكل ملحوظ من مديري هندسة آخرين)، توصلنا إلى بعض الأشياء التي تساعد حقا:
تقبل أن Slack هو صندوق وارد، وليس أرشيفا. التحول الأكثر فائدة في النموذج العقلي. Slack هو المكان الذي تحدث فيه المحادثات في الوقت الفعلي، وليس المكان الذي تُخزن فيه القرارات. إذا اتُخذ قرار مهم في Slack، فيجب التقاطه في مكان دائم: تذكرة Linear، أو مستند Notion، أو سجل قرار معماري (ADR)، أو حتى رسالة commit. Slack هو المحادثة؛ وتلك الأدوات الأخرى هي السجل.
استخدم سلاسل الرسائل (threads) بانتظام. سلاسل الرسائل هي أفضل ميزة في Slack لقابلية العثور لأنها تحتفظ بمحادثة كاملة في وحدة واحدة قابلة للعنونة. تحتوي السلسلة على رابط دائم. المحادثة المتناثرة عبر المخطط الزمني الرئيسي للقناة لا تحتوي على ذلك. إذا كانت ثقافة فريقك تميل افتراضيا إلى الرد في القناة الرئيسية (والكثيرون يفعلون ذلك لأنها تبدو أكثر فورية)، فإنك تجعل الاسترداد أصعب بشكل كبير.
أنشئ قنوات للقرارات، وليس قنوات للمشاريع. هذا غير بديهي، لكن اسمعني. بدلا من (أو بالإضافة إلى) #project-atlas، جرب #decisions أو #decisions-engineering. قناة واحدة غرضها الوحيد هو تسجيل القرارات بسياق موجز. لن تحتوي على المناقشة الكاملة (يمكن أن تعيش أينما تحدث بشكل طبيعي)، لكنها تمنحك سجلا زمنيا قابلا للبحث لما اتُخذ من قرارات ورابطا لمكان حدوث المناقشة. فكر فيها كسجل commits لتفكير فريقك. آلية الإنفاذ التي تعمل فعليا (في تجربتنا): اجعلها جزءا من قالب طلب السحب الخاص بك. قبل الدمج، اربط منشور القرار ذا الصلة. إنه خفيف الوزن، ويمكن التحقق منه في المراجعة، وينشئ مسارا لا يعتمد على ذاكرة أي شخص أو انضباطه.
اربط النقاط تلقائيا. هذا هو الجزء الذي سأذكر فيه ما نبنيه، لأنه ذو صلة مباشرة. يستوعب Sugarbug رسائل Slack جنبا إلى جنب مع تذاكر Linear وطلبات سحب GitHub ومستندات Notion وتعليقات Figma، ويبني رسم بياني معرفي لكيفية ارتباطها جميعا ببعضها. عندما تكون هذه الاتصالات موجودة، لا تحتاج إلى تذكر القناة التي حدثت فيها المحادثة، لأنه يمكنك البدء من المهمة أو المستند واتباع المسار إلى كل محادثة ذات صلة، بغض النظر عن مكان وجودها. ما زلنا نكتشف أفضل طريقة لإبراز كل هذا (بصراحة، تجربة المستخدم للاسترداد عبر الأدوات أصعب من الاستيعاب)، لكن النهج الأساسي – ربط السياق بدلا من إعادة تنظيمه – هو ما نعتقد أنه يحدث فرقا حقيقيا.
taming notification overload notification fatigue in engineering teams the Slack notification strategy for busy teams توقف عن البحث في خمس قنوات والعودة خالي الوفاض. Sugarbug يربط Slack ببقية أدواتك حتى تظل القرارات قابلة للعثور.
س: ما هو عدد قنوات Slack الذي يعتبر كبيرا جدا؟ ج: لا يوجد رقم سحري، لكن إذا كان فريقك لا يستطيع بانتظام العثور على مكان حدوث محادثة، أو إذا لجأ الأشخاص افتراضيا إلى الرسائل المباشرة لأن القنوات تبدو مربكة، فمن المحتمل أنك تجاوزت الحد. تميل الفرق المكونة من 10 إلى 20 شخصا والتي تضم أكثر من 80 إلى 100 قناة نشطة إلى الاصطدام بهذا الجدار، رغم أن ذلك يعتمد بشكل كبير على مدى انضباط فريقك بشأن الغرض من القناة وأرشفتها.
س: هل يساعد Sugarbug في إدارة العبء الزائد لقنوات Slack؟ ج: لا يدير Sugarbug قنواتك مباشرة، لكنه يحل مشكلة قابلية العثور التي يخلقها العبء الزائد للقنوات. يستوعب رسائل Slack جنبا إلى جنب مع تذاكر Linear وطلبات سحب GitHub ومستندات Notion وتعليقات Figma في رسم بياني معرفي، لذلك عندما تبحث عن قرار أو محادثة، تبحث مرة واحدة وتجدها بغض النظر عن القناة (أو الأداة) التي حدثت فيها.
س: لماذا لا يمكنني العثور على أي شيء في Slack حتى مع البحث؟ ج: يجد بحث Slack الرسائل التي تحتوي على كلماتك الرئيسية الدقيقة، لكن معظم قرارات مكان العمل تستخدم كلمات مختلفة في مراحل مختلفة. قد يقول شخص "خيار Redis" في سلسلة و"BullMQ" في سلسلة أخرى، في إشارة إلى نفس القرار، ولا تشير هذه السلاسل أبدا إلى بعضها. البحث يجد تطابقات نصية. العثور على مسار القرار يتطلب فهم الروابط بين المحادثات، وهي قدرة مختلفة جوهريا.
س: هل يمكن لـ Sugarbug استبدال قنوات Slack بشيء أفضل؟ ج: لا، ولا ينبغي له أن يحاول. Slack ممتاز في المحادثة في الوقت الفعلي، وهذا أمر ذو قيمة حقيقية. المشكلة ليست في Slack نفسه بل في حقيقة أن السياق المهم يُحاصر داخل المحادثات دون أي طريقة لربطه بالمهام والمستندات والكود الذي يتعلق به. Sugarbug يبني هذه الاتصالات تلقائيا حتى لا تضطر إلى تذكر أين نوقشت الأشياء.