“나는 그들이 무언가를 한다는 것을 알고 있지만, 그 무언가가 정확히 무엇인지 잘 모르겠어요.”
동료 중 한 명이 다른 팀이나 부서를 언급하면서 그런 말을 (또는 솔직히 말해서, 했)도록 얼마나 많은 말을 들어봤나요? 우리는 일상 업무에서 회사의 자신만의 구석에 갇히기 쉽고, 이는 때때로 우리 집 건너편의 동료들이 비즈니스가 작동하도록 돕기 위해 도대체 무엇을 하는지 이해하지 못하게 만들기도 합니다. 그리고 그럴만한 이유가 있습니다: 자신이 전문성을 가진 영역과 책임에 집중하는 것은 모든 사람이 자신의 기능에서 성장하는 데 도움을 줍니다. 하지만 그런 시각이 너무 좁아져서 팀들이 그들의 일이 회사의 나머지 부분에 미치는 영향을 볼 수 없는 경우, 어떻게 될까요?
회사 지식 는 크로스 기능적으로 존재하기를 원합니다.
팀들이 그들의 기능을 단절된 상태에서 바라보면, 그들은 종종 팀의 지식도 단절된 상태로 봅니다. 마케팅 팀에게는, 이는 구매자 페르소나 또는 기능 포지셔닝 설명을 의미할 수 있습니다. 엔지니어링 팀에게는, 이는 기술 문서 또는 환경 설정 지침을 의미할 수 있습니다. 지원 팀에게는, 이는 자주 묻는 질문에 대한 답변이나 기능 결함에 대한 문제 해결 가이드를 의미할 수 있습니다. 이 자원은 개별 팀들이 의존하는 여러 도구들, 예를 들어 Google Drive, GitHub, Intercom 등에서 존재할 수 있으며, 문서화에 집중하는 팀의 리더 또는 전문가가 소유하거나 공동 소유할 수 있습니다.
표면적으로는 서로 다른 팀들이 그들의 워크플로우에 가장 잘 맞는 다양한 문서 도구가 필요하다는 것이 이해되지만, 더 깊이 파고들면 단절된 상태에서 운영하는 것과 관련된 실제 비즈니스 리스크를 밝혀냅니다.
단절된 지식이 운영에 미치는 영향
대부분의 문서화는 크로스 기능 협력과 어떤 형식으로든 관련이 있습니다. 지원 에이전트가 기능에 대한 헬프 센터 기사를 업데이트하는 예제를 살펴봅시다. 에이전트는 우선 팀에서 수집한 자주 묻는 질문으로 시작할 수 있으며, 그 다음에는 엔지니어링 팀과 협력하여 답변을 얻어야 합니다. 그 답변 중 일부는 GitHub에 문서화되어 있지만, 대부분은 한 주제 전문가의 기억 속에 존재합니다.
지원 에이전트가 그 답변을 얻은 후, 기능의 장점에 대해 올바른 용어를 사용하고 있는지 확인하기 위해 제품 마케팅 팀과 확인해야 할 수도 있습니다. 그 제품 마케팅 팀은 구글 드라이브에서 지난해 기능 출시와 관련된 메시지를 포함하는 원 시트를 보낼 수 있으며, 이는 구식일 수 있습니다. 마지막으로, 지원 에이전트는 영업 팀과 확인하여 추가할 질문이 있는지 확인하고, 질문이 있을 경우 다시 엔지니어링 팀과 확인해야 합니다.
지원 에이전트가 새로운 헬프 센터 기사를 완성했을 때, 그들은 회사 전반의 동료들과 대화를 나누어야 했으며, 그들은 각자의 지식 채널로 들어가 지원 정보를 찾아야 했습니다. 그리고 모든 것이 순조롭게 진행된다고 가정했을 때입니다. 해당 기능의 주제 전문가인 엔지니어가 그 주에 휴가 중이라면 무슨 일이 발생할까요? 혹은 영업팀이 추가할 질문이 있다는 것을 깨닫지만, 해당 질문들이 여러 Slack 채널에 산재해 있다면요? 도로에 있는 모든 장애물과 함께, 일정이 늘어나고, 지식 누수 및 잘못된 의사소통의 기회가 점점 더 많아집니다.
이제 모든 팀이 중요하고 최신 제품 지식을 문서화하고 접근할 수 있는 장소를 공유하는 대안 시나리오를 고려해 보겠습니다. 지원 에이전트가 질문으로 처음 엔지니어링 팀에 연락할 때, 엔지니어링 팀은 그 SME가 그 주에 휴가라는 것을 걱정할 필요가 없습니다. 그들은 이전에 공유 지식 기반을 통해 팀 전체와 전문성을 공유했을 것입니다.
제품 마케팅 팀이 1년 전에 쓰여진 정보가 구식일 가능성을 걱정하면서 실제로 접근할 것은 매 분기마다 정확성을 검증한 최신 메시지 및 포지셔닝 정보입니다. 그리고 영업팀이 그들이 이전에 답변을 찾기 위해 질문한 질문을 Slack 채널을 통해 찾는 것을 번거롭게 하지 않고, 그들은 모든 질문을 문서화하여 공유 플랫폼에서 쉽게 전달할 수 있습니다.
이 전체 프로세스의 더 좋은 점은 지원 에이전트가 다른 사람의 워크플로우를 방해하지 않고도 스스로 많은 정보를 찾을 수 있다는 것입니다.
이 모든 정보가 팀 특정의 단절된 도구에 보관되면 자가 서비스 지식 검색은 단순히 불가능합니다.
동료 간의 실시간 협력의 역할은 결코 제거되지 않을 것입니다. 결국, 그런 상호작용이 우리에게 서로와의 관계 및 공감을 형성하도록 도와줍니다. 하지만 제품 전달 및 지원 주기 동안 여러 단계에서 모든 팀 전반에 걸쳐 지식이 민주화될 때, 보다 효율적으로 완료될 수 있는 작업들이 존재합니다. 지식 탐색자와 주제 전문가 모두 그들의 워크플로우를 방해받지 않고 계속할 수 있으며, 더 의미 있고 창의적인 작업을 위한 실시간 협력의 대역폭을 절약할 수 있습니다.
“나는 그들이 무언가를 한다는 것을 알고 있지만, 그 무언가가 정확히 무엇인지 잘 모르겠어요.”
동료 중 한 명이 다른 팀이나 부서를 언급하면서 그런 말을 (또는 솔직히 말해서, 했)도록 얼마나 많은 말을 들어봤나요? 우리는 일상 업무에서 회사의 자신만의 구석에 갇히기 쉽고, 이는 때때로 우리 집 건너편의 동료들이 비즈니스가 작동하도록 돕기 위해 도대체 무엇을 하는지 이해하지 못하게 만들기도 합니다. 그리고 그럴만한 이유가 있습니다: 자신이 전문성을 가진 영역과 책임에 집중하는 것은 모든 사람이 자신의 기능에서 성장하는 데 도움을 줍니다. 하지만 그런 시각이 너무 좁아져서 팀들이 그들의 일이 회사의 나머지 부분에 미치는 영향을 볼 수 없는 경우, 어떻게 될까요?
회사 지식 는 크로스 기능적으로 존재하기를 원합니다.
팀들이 그들의 기능을 단절된 상태에서 바라보면, 그들은 종종 팀의 지식도 단절된 상태로 봅니다. 마케팅 팀에게는, 이는 구매자 페르소나 또는 기능 포지셔닝 설명을 의미할 수 있습니다. 엔지니어링 팀에게는, 이는 기술 문서 또는 환경 설정 지침을 의미할 수 있습니다. 지원 팀에게는, 이는 자주 묻는 질문에 대한 답변이나 기능 결함에 대한 문제 해결 가이드를 의미할 수 있습니다. 이 자원은 개별 팀들이 의존하는 여러 도구들, 예를 들어 Google Drive, GitHub, Intercom 등에서 존재할 수 있으며, 문서화에 집중하는 팀의 리더 또는 전문가가 소유하거나 공동 소유할 수 있습니다.
표면적으로는 서로 다른 팀들이 그들의 워크플로우에 가장 잘 맞는 다양한 문서 도구가 필요하다는 것이 이해되지만, 더 깊이 파고들면 단절된 상태에서 운영하는 것과 관련된 실제 비즈니스 리스크를 밝혀냅니다.
단절된 지식이 운영에 미치는 영향
대부분의 문서화는 크로스 기능 협력과 어떤 형식으로든 관련이 있습니다. 지원 에이전트가 기능에 대한 헬프 센터 기사를 업데이트하는 예제를 살펴봅시다. 에이전트는 우선 팀에서 수집한 자주 묻는 질문으로 시작할 수 있으며, 그 다음에는 엔지니어링 팀과 협력하여 답변을 얻어야 합니다. 그 답변 중 일부는 GitHub에 문서화되어 있지만, 대부분은 한 주제 전문가의 기억 속에 존재합니다.
지원 에이전트가 그 답변을 얻은 후, 기능의 장점에 대해 올바른 용어를 사용하고 있는지 확인하기 위해 제품 마케팅 팀과 확인해야 할 수도 있습니다. 그 제품 마케팅 팀은 구글 드라이브에서 지난해 기능 출시와 관련된 메시지를 포함하는 원 시트를 보낼 수 있으며, 이는 구식일 수 있습니다. 마지막으로, 지원 에이전트는 영업 팀과 확인하여 추가할 질문이 있는지 확인하고, 질문이 있을 경우 다시 엔지니어링 팀과 확인해야 합니다.
지원 에이전트가 새로운 헬프 센터 기사를 완성했을 때, 그들은 회사 전반의 동료들과 대화를 나누어야 했으며, 그들은 각자의 지식 채널로 들어가 지원 정보를 찾아야 했습니다. 그리고 모든 것이 순조롭게 진행된다고 가정했을 때입니다. 해당 기능의 주제 전문가인 엔지니어가 그 주에 휴가 중이라면 무슨 일이 발생할까요? 혹은 영업팀이 추가할 질문이 있다는 것을 깨닫지만, 해당 질문들이 여러 Slack 채널에 산재해 있다면요? 도로에 있는 모든 장애물과 함께, 일정이 늘어나고, 지식 누수 및 잘못된 의사소통의 기회가 점점 더 많아집니다.
이제 모든 팀이 중요하고 최신 제품 지식을 문서화하고 접근할 수 있는 장소를 공유하는 대안 시나리오를 고려해 보겠습니다. 지원 에이전트가 질문으로 처음 엔지니어링 팀에 연락할 때, 엔지니어링 팀은 그 SME가 그 주에 휴가라는 것을 걱정할 필요가 없습니다. 그들은 이전에 공유 지식 기반을 통해 팀 전체와 전문성을 공유했을 것입니다.
제품 마케팅 팀이 1년 전에 쓰여진 정보가 구식일 가능성을 걱정하면서 실제로 접근할 것은 매 분기마다 정확성을 검증한 최신 메시지 및 포지셔닝 정보입니다. 그리고 영업팀이 그들이 이전에 답변을 찾기 위해 질문한 질문을 Slack 채널을 통해 찾는 것을 번거롭게 하지 않고, 그들은 모든 질문을 문서화하여 공유 플랫폼에서 쉽게 전달할 수 있습니다.
이 전체 프로세스의 더 좋은 점은 지원 에이전트가 다른 사람의 워크플로우를 방해하지 않고도 스스로 많은 정보를 찾을 수 있다는 것입니다.
이 모든 정보가 팀 특정의 단절된 도구에 보관되면 자가 서비스 지식 검색은 단순히 불가능합니다.
동료 간의 실시간 협력의 역할은 결코 제거되지 않을 것입니다. 결국, 그런 상호작용이 우리에게 서로와의 관계 및 공감을 형성하도록 도와줍니다. 하지만 제품 전달 및 지원 주기 동안 여러 단계에서 모든 팀 전반에 걸쳐 지식이 민주화될 때, 보다 효율적으로 완료될 수 있는 작업들이 존재합니다. 지식 탐색자와 주제 전문가 모두 그들의 워크플로우를 방해받지 않고 계속할 수 있으며, 더 의미 있고 창의적인 작업을 위한 실시간 협력의 대역폭을 절약할 수 있습니다.
Experience the power of the Guru platform firsthand – take our interactive product tour
.webp)
