“أعرف أنهم يقومون بأشياء، لكنني لست متأكداً تمامًا مما هو هذا الشيء.”
كم مرة سمعت (أو لنكن صادقين، قلت) تلك الكلمات من أحد زملائك في إشارة إلى فريق أو قسم آخر؟ من السهل علينا أن نضيع في زوايانا الخاصة من شركتنا في عملنا اليومي، مما يؤدي أحيانًا إلى نقص في الفهم لما يقوم به زملاؤنا في الجانب الآخر من الشركة لمساعدة أعمالنا على العمل. ولسبب وجيه: التركيز على مجالات خبرتك ومسؤولياتك يساعد الجميع على النمو في وظائفهم الخاصة. ولكن ماذا يحدث عندما تصبح تلك الرؤية ضيقة لدرجة أن الفرق تكافح لرؤية الطرق التي تؤثر بها أعمالهم على بقيتنا في الشركة؟
معرفة الشركة تريد أن تكون عبر الوظائف
عندما ترى الفرق وظائفها في فراغ، فإنهم غالبًا ما يرون معرفة فريقهم في فراغ أيضًا. بالنسبة لفرق التسويق، قد يعني هذا شخصية المشتري أو أوصاف وضع الميزات. أما بالنسبة لفرق الهندسة، فقد يعني هذا التوثيق الفني أو تعليمات إعداد البيئة. أما بالنسبة لفرق الدعم، فقد يعني ذلك الردود على الأسئلة المتكررة أو أدلة استكشاف الأخطاء وإصلاحها للأخطاء في الميزات. قد تعيش هذه الموارد في أي عدد من الأدوات التي يعتمد عليها الأفراد، مثل Google Drive وGitHub وIntercom، ويمكن أن تكون مملوكة بشكل جماعي أو بواسطة قائد/متخصص في الفريق يركز على التوثيق.
على السطح، يبدو من المنطقي أن تحتاج الفرق المختلفة إلى أدوات توثيق مختلفة لتناسب أساليب العمل الخاصة بها، ولكن عند الغوص أعمق، نكشف المخاطر التجارية الحقيقية المرتبطة بعمل السلاسل المنعزلة.
كيف تؤثر المعرفة المنعزلة على العمليات
تشمل معظم الوثائق التعاون عبر الوظائف بطريقة ما. دعونا نتحدث من خلال مثال لوكيل دعم يقوم بتحديث مادة مساعدة عن ميزة. قد يبدأ الوكيل بالأسئلة المتكررة التي جمعتها فريقهم، ثم يحتاج للتعاون مع فريق الهندسة للحصول على الإجابات. بعض تلك الإجابات موثقة في GitHub، لكن معظمها موجود في رأس خبير في الموضوع.
عند حصول وكيل الدعم على تلك الإجابات، قد يحتاج أيضًا إلى مراجعة فريق التسويق المنتج للتأكد من أنهم يستخدمون المصطلحات الصحيحة لفوائد الميزة. قد يرسل فريق التسويق المنتج بعد ذلك ورقة واحدة من Google Drive الخاصة بهم، تحتوي على بعض الرسائل من إطلاق العام الماضي للميزة والتي قد تكون قديمة. وأخيرًا، يتواصل وكيل الدعم مع فريق المبيعات لمعرفة ما إذا كان لديهم أي أسئلة إضافية يمكن إضافتها، وإذا كانوا كذلك، فيجب عليهم التحقق مرة أخرى من فريق الهندسة.
بحلول الوقت الذي أنشأ فيه وكيل الدعم مقالة مساعدة جديدة، كان قد أجري محادثات مع زملاء عبر الشركة، الذين كان عليهم جميعًا الدخول إلى قنواتهم المعرفية المنفصلة للعثور على المعلومات الداعمة. وهذا يفترض أن كل شيء يسير بسلاسة على طول الطريق. ماذا قد يحدث إذا كان المهندس الذي هو خبير الموضوع في الميزة في إجازة خلال ذلك الأسبوع؟ أو إذا أدرك فريق المبيعات أنه لديهم أسئلة إضافية ليضيفوها، لكنها متناثرة في قنوات Slack المختلفة؟ مع كل عقبة في الطريق، يتم تمديد الجدول الزمني، وتظهر المزيد والمزيد من الفرص لتسرب المعرفة وسوء التواصل.
الآن، دعونا نفكر في سيناريو بديل - سيناريو حيث تشارك جميع الفرق مكانًا لتوثيق والوصول إلى المعرفة المهمة والحديثة عن المنتج. عندما يتواصل وكيل الدعم مع فريق الهندسة أولاً مع الأسئلة، لا يحتاج فريق الهندسة للقلق إذا كان الخبير في الموضوع في إجازة خلال ذلك الأسبوع - كانوا قد شاركوا سابقًا خبراتهم مع باقي الفريق من خلال قاعدة المعرفة المشتركة.
بدلاً من أن يرسل فريق التسويق المنتج معلومات قد تكون قديمة كتبت منذ عام، فإنهم يصلون إلى رسائلهم ومعلوماتهم عن التموقع المحدثة التي يتحققون منها من الدقة كل ربع عام. وعوضًا عن قيام فريق المبيعات بالتجوّل في قنوات Slack للعثور على أسئلة كانوا قد طلبوا إجابات عنها مسبقًا، فإن لديهم جميعها موثقة في منصة مشتركة يسهل إرسالها بعدها.
ما هو الأفضل في هذه العملية هو أن وكيل الدعم يمكنه حتى العثور على الكثير من هذه المعلومات بنفسه، دون إخراج الآخرين من سير عملهم، ببساطة عن طريق البحث.
عندما يتم الاحتفاظ بكل هذه المعلومات في أدوات معينة ومتناثرة بين الفرق، فإن استرجاع المعرفة ذاتية الخدمة ليس ممكنًا ببساطة.
لن يتم إلغاء دور التعاون في الوقت الحقيقي بين الزملاء؛ فبعد كل شيء، فإن تلك التفاعلات هي ما يساعدنا على تشكيل الروابط والتعاطف مع بعضنا البعض. ولكن في مراحل عديدة عبر دورة تسليم المنتج وتمكينه، توجد مهام يمكن إتمامها بكفاءة أكبر عندما يتم ديمقراطية المعرفة عبر جميع الفرق. يمكن لكل من الباحث عن المعرفة والخبير في الموضوع الاستمرار في سير عملهم دون انقطاع، ويمكنهما توفير عرض التعاون في الوقت الحقيقي لأعمال أكثر معنى وإبداعًا.
“أعرف أنهم يقومون بأشياء، لكنني لست متأكداً تمامًا مما هو هذا الشيء.”
كم مرة سمعت (أو لنكن صادقين، قلت) تلك الكلمات من أحد زملائك في إشارة إلى فريق أو قسم آخر؟ من السهل علينا أن نضيع في زوايانا الخاصة من شركتنا في عملنا اليومي، مما يؤدي أحيانًا إلى نقص في الفهم لما يقوم به زملاؤنا في الجانب الآخر من الشركة لمساعدة أعمالنا على العمل. ولسبب وجيه: التركيز على مجالات خبرتك ومسؤولياتك يساعد الجميع على النمو في وظائفهم الخاصة. ولكن ماذا يحدث عندما تصبح تلك الرؤية ضيقة لدرجة أن الفرق تكافح لرؤية الطرق التي تؤثر بها أعمالهم على بقيتنا في الشركة؟
معرفة الشركة تريد أن تكون عبر الوظائف
عندما ترى الفرق وظائفها في فراغ، فإنهم غالبًا ما يرون معرفة فريقهم في فراغ أيضًا. بالنسبة لفرق التسويق، قد يعني هذا شخصية المشتري أو أوصاف وضع الميزات. أما بالنسبة لفرق الهندسة، فقد يعني هذا التوثيق الفني أو تعليمات إعداد البيئة. أما بالنسبة لفرق الدعم، فقد يعني ذلك الردود على الأسئلة المتكررة أو أدلة استكشاف الأخطاء وإصلاحها للأخطاء في الميزات. قد تعيش هذه الموارد في أي عدد من الأدوات التي يعتمد عليها الأفراد، مثل Google Drive وGitHub وIntercom، ويمكن أن تكون مملوكة بشكل جماعي أو بواسطة قائد/متخصص في الفريق يركز على التوثيق.
على السطح، يبدو من المنطقي أن تحتاج الفرق المختلفة إلى أدوات توثيق مختلفة لتناسب أساليب العمل الخاصة بها، ولكن عند الغوص أعمق، نكشف المخاطر التجارية الحقيقية المرتبطة بعمل السلاسل المنعزلة.
كيف تؤثر المعرفة المنعزلة على العمليات
تشمل معظم الوثائق التعاون عبر الوظائف بطريقة ما. دعونا نتحدث من خلال مثال لوكيل دعم يقوم بتحديث مادة مساعدة عن ميزة. قد يبدأ الوكيل بالأسئلة المتكررة التي جمعتها فريقهم، ثم يحتاج للتعاون مع فريق الهندسة للحصول على الإجابات. بعض تلك الإجابات موثقة في GitHub، لكن معظمها موجود في رأس خبير في الموضوع.
عند حصول وكيل الدعم على تلك الإجابات، قد يحتاج أيضًا إلى مراجعة فريق التسويق المنتج للتأكد من أنهم يستخدمون المصطلحات الصحيحة لفوائد الميزة. قد يرسل فريق التسويق المنتج بعد ذلك ورقة واحدة من Google Drive الخاصة بهم، تحتوي على بعض الرسائل من إطلاق العام الماضي للميزة والتي قد تكون قديمة. وأخيرًا، يتواصل وكيل الدعم مع فريق المبيعات لمعرفة ما إذا كان لديهم أي أسئلة إضافية يمكن إضافتها، وإذا كانوا كذلك، فيجب عليهم التحقق مرة أخرى من فريق الهندسة.
بحلول الوقت الذي أنشأ فيه وكيل الدعم مقالة مساعدة جديدة، كان قد أجري محادثات مع زملاء عبر الشركة، الذين كان عليهم جميعًا الدخول إلى قنواتهم المعرفية المنفصلة للعثور على المعلومات الداعمة. وهذا يفترض أن كل شيء يسير بسلاسة على طول الطريق. ماذا قد يحدث إذا كان المهندس الذي هو خبير الموضوع في الميزة في إجازة خلال ذلك الأسبوع؟ أو إذا أدرك فريق المبيعات أنه لديهم أسئلة إضافية ليضيفوها، لكنها متناثرة في قنوات Slack المختلفة؟ مع كل عقبة في الطريق، يتم تمديد الجدول الزمني، وتظهر المزيد والمزيد من الفرص لتسرب المعرفة وسوء التواصل.
الآن، دعونا نفكر في سيناريو بديل - سيناريو حيث تشارك جميع الفرق مكانًا لتوثيق والوصول إلى المعرفة المهمة والحديثة عن المنتج. عندما يتواصل وكيل الدعم مع فريق الهندسة أولاً مع الأسئلة، لا يحتاج فريق الهندسة للقلق إذا كان الخبير في الموضوع في إجازة خلال ذلك الأسبوع - كانوا قد شاركوا سابقًا خبراتهم مع باقي الفريق من خلال قاعدة المعرفة المشتركة.
بدلاً من أن يرسل فريق التسويق المنتج معلومات قد تكون قديمة كتبت منذ عام، فإنهم يصلون إلى رسائلهم ومعلوماتهم عن التموقع المحدثة التي يتحققون منها من الدقة كل ربع عام. وعوضًا عن قيام فريق المبيعات بالتجوّل في قنوات Slack للعثور على أسئلة كانوا قد طلبوا إجابات عنها مسبقًا، فإن لديهم جميعها موثقة في منصة مشتركة يسهل إرسالها بعدها.
ما هو الأفضل في هذه العملية هو أن وكيل الدعم يمكنه حتى العثور على الكثير من هذه المعلومات بنفسه، دون إخراج الآخرين من سير عملهم، ببساطة عن طريق البحث.
عندما يتم الاحتفاظ بكل هذه المعلومات في أدوات معينة ومتناثرة بين الفرق، فإن استرجاع المعرفة ذاتية الخدمة ليس ممكنًا ببساطة.
لن يتم إلغاء دور التعاون في الوقت الحقيقي بين الزملاء؛ فبعد كل شيء، فإن تلك التفاعلات هي ما يساعدنا على تشكيل الروابط والتعاطف مع بعضنا البعض. ولكن في مراحل عديدة عبر دورة تسليم المنتج وتمكينه، توجد مهام يمكن إتمامها بكفاءة أكبر عندما يتم ديمقراطية المعرفة عبر جميع الفرق. يمكن لكل من الباحث عن المعرفة والخبير في الموضوع الاستمرار في سير عملهم دون انقطاع، ويمكنهما توفير عرض التعاون في الوقت الحقيقي لأعمال أكثر معنى وإبداعًا.
تجربة قوة منصة Guru بشكل مباشر - قم بجولة تفاعلية في المنتج
.webp)
