접근 및 참여 전략

고객은 팀과 얼마나 가까워야 할까요?

지난주에 이 주제에 대해 시간을 들여 생각해보았습니다. 특히 Meta에서 우리 팀이 더 적극적으로 참여하기 위해 진행해 온 논의들이 그 배경이 되었습니다.

고객과 제품 팀 사이의 건강한 경계 설정

제품 팀이 커뮤니티 내에서 고객과 상호작용하는 방식은 조직마다 크게 달라질 수 있으므로, 여기서는 Meta에서의 경험을 중심으로 말씀드리겠습니다.

우리의 상황은 고객과 함께 실시간으로 우리 제품을 사용하는(도그푸딩) 점이 매우 독특합니다. 프로젝트 초기 몇 년간은 조직 내 모든 구성원이 제품 개발에 직접 관여했기 때문에 커뮤니티에 참여하는 것은 직무의 필수적인 부분이었습니다. 시간이 지나면서 이런 상황은 줄어들었고, 이제는 지원(고객 서비스) 범위를 넘어 직원들의 참여를 적극적으로 독려해야 하는 단계에 이르렀습니다.

팀원 중 일부는 Meta에 시간을 할애하지 않는다고 고백합니다. 어떻게 참여해야 할지 모르기 때문입니다. 자신에게 답할 자격이 있다고 느끼는 질문이 없고, 흥미롭거나 관련성 있는 논의를 주도하는 데 필요한 수준의 깊은 지식을 갖추지 못했다고 느낍니다. Meta에서 팀의 참여를 방해하는 몇 가지 도전 과제들을 식별했는데, 다른 조직들도 유사한 경험을 하고 있을 것이라고 확신합니다.

커뮤니티 참여를 가로막는 장벽

  • 질문에 대한 부정확하거나, 구식이거나, 일관되지 않은 답변. (정답을 모르거나 틀린 답변을 할까 봐 두려워 많은 구성원이 참여를 꺼립니다.)
  • 목소리가 큰 구성원들이 우리 팀에 불균형한 영향을 미칠 수 있으며, 이는 다른 구성원들에게 해가 될 수 있습니다. (외교적으로 상호작용하는 데 많은 에너지를 소모하는 구성원들이 있고, 모든 사람이 그 인내심을 가지고 있지는 않습니다.)
  • 충분한 소통 없이 로드맵을 변경하거나, 피드백을 요청한 뒤 이를 무시하는 것처럼 보일 경우 신뢰가 훼손됩니다. (일부 사람들은 자신이 충족할 수 없는 기대치를 설정하지 않기 위해 비공개로 작업하는 것이 더 안전하다고 느낍니다.)
  • 관련이 없는 주제에 개인적으로 태그(@)당하는 것에서 오는 알림 피로. (사람들이 조급해할 때, 가시적인 존재감을 개인적 지원을 요청하는 초대처럼 여기는 구성원들이 있습니다.)
  • 구성원들이 자신의 목소리가 들리지 않는다고 느낄 때의 좌절감 관리. (누구의 잘못도 없는 경우에도 대립적인 성격 때문에 참여가 부담스러울 수 있습니다.)

여러분의 조직에서는 고객과 제품의 직접적인 상호작용이 잘 작동했던 부분이 어디였으며, 어디에서 어려움을 겪게 되었나요?

12개의 좋아요

흥미롭네요. 소프트웨어를 설계하고 구축하는 사람들이 이러한 유형의 질문과 토론을 다루는 데 가장 적합한 사람들이라고 자연스럽게 생각할 것 같습니다. 이런 자신감 부족의 원인을 더 깊이 파고들어 보셨나요?

7개의 좋아요

팀의 모든 구성원이 엔지니어나 디자이너인 것은 아니죠 :slight_smile:

5개의 좋아요

제품 매니저, 고객 지원, 엔터프라이즈 지원, 마케팅, 영업 등에도 비슷한 전제가 있을 것 같습니다. 필요한 지식이 없으면 이런 업무를 잘 수행하기가 꽤 어려울 테니까요. :person_shrugging:

4개의 좋아요

우리 모두 때때로 이런 느낌을 받는 것 같습니다. 하지만 포럼 기반 커뮤니티가 소셜 미디어보다 유리한 점 중 하나가 바로 이 부분이라고 생각합니다. 대화의 느린 속도나 토론 주제의 장기적인 지속성은 다른 사용자들에 대한 '느낌’을 파악할 수 있는 기회를 주며, 점차 참여에 대해 더 편안함을 느끼게 해줍니다.

'답변 자격’은 어떤 질문이 올라오느냐에 따라 달라집니다. 때로는 Discourse에 대해 아주 미약한 지식만 있어도 도움이 될 수 있습니다. 왜냐하면 질문자가 전혀 감을 잡지 못하고 있을 수도 있기 때문입니다. 반면, 매우 기술적인 주제에 대해 매우 구체적인 질문을 하는 경우도 있습니다. 그런 경우 저는 보통 질문이 충분한 정보를 포함하고 있는지 확인하여, 해당 분야에 자격을 갖춘 멤버가 스레드에 도착했을 때 도움을 줄 수 있는 자료가 갖춰져 있는지 살펴봅니다. (버전 번호 같은 것들요)

다시 말하지만, 이는 부분적으로 인간의 본성이라고 생각합니다. 그리고 흥미로운 대화는 종종 예상치 못한 곳에서 비롯된다는 점이 아이러니합니다.

5개의 좋아요

제가 주제에 대해 직접적으로 답변드릴 수 있을지 모르겠지만, Discourse와 관련하여 몇 가지 관찰 사항을 공유해 보겠습니다:

저는 소프트웨어 자체를 개발하거나 다른 직무를 맡고 있는 팀원이 "아, [Discourse의 특정 기능이나 관련 사항]에 대해 몰랐네요"라고 말하는 것을 가끔 목격합니다.

처음에는 놀랐지만, 오래가지는 않았습니다.

Discourse를 사랑하고, 이를 홍보하며, 때로는 Discourse 관리자이기도 한 저 같은 열성적인 팬들은 (또는 과거에는) 매우 좋은 일반적인 Discourse 지식을 갖추고 있으며 소프트웨어에 대한 많은 질문에 답할 수 있습니다. 어떤 경우에는 팀원보다 더 많거나, 더 정확하게 답변할 수도 있습니다. 저는 이것이 CDCK의 일종의 성공 또는 성과라고 생각합니다. :hugs:

저는 Discourse 개발자조차도 Discourse의 기능에 대해 무엇이든 알아야 한다고 기대하지 않습니다. 알아야 할 것이 너무 많고, 대부분은 그들이 급여를 받는 업무와 무관할 수 있으며, Discourse에 대한 많은 질문은 그들의 전문 분야 밖일 수 있습니다. 그렇다고 해서 그들이 덜 가치 있는 것은 아닙니다. 그들은 자신의 분야에서 전문가입니다.

물론, 그들은 때때로 자신이 안다고 생각하고 질문에 답하다가 결국 틀릴 수 있습니다. 이는 팀원이든 아니든 누구나 겪을 수 있는 일입니다. 저도 많은 번에 그런 일이 있었고, 당시 일반 사용자였든 아니든 간에 가끔은 조금 부끄럽게 느꼈습니다.
전문가도 때때로 틀릴 수 있으며, 그것은 괜찮은 일입니다.

제가 CDCK에 있을 때, 고객의 CSS 문제를 쉽게 빠르게 해결할 수 있을 것이라고 확신하며 뛰어들었던 적이 한 번 있습니다 (심지어 제 업무도 아니었습니다). 하지만 완전히 틀렸습니다. 문제는 제가 예상했던 것보다 훨씬 복잡했고, 결국 전문가들이 해결하도록 맡겼습니다. :laughing: 네, 그때는 부끄러웠지만, 솔직히 큰 문제는 아니었고 금방 잊었습니다.

글쎄요. 제가 인용한 것에 대해 실제로 다루기보다는, 이 시점에서는 일종의 일화(에피소드)를 공유하고 있는 것 같습니다.

이것은 양방향입니다. Meta에서 팀원 중 일부와의 마찰 있는 상호작용은 처음부터 지금까지 간헐적으로 저를 항상 조금은(큰 문제는 아니지만) 불편하게 만든 몇 가지 사항 중 하나였습니다.

저는 그것이 단순히 사람들의 성격, 기분, 기질, 문화에 달려 있다고 생각합니다. 대부분의 경우, 때로는 거칠게 느껴지는 상호작용을 하는 사람들을 비난할 수도, 원망할 수도 없습니다.
그것을 대체로 잔잔한 바다 위의 파도 꼭대기로 봅니다. 인간 본성의 표현입니다.
팀/커뮤니티 상호작용의 목표는 "완전히 마찰이 없는 것"이 될 수도, 되어야 할 수도 없으며, 오히려 "대부분 마찰이 없는 것"이어야 합니다. 저는 Meta가 항상 개선의 여지가 있긴 하지만, 현재 그런 상태라고 생각합니다.

하지만 글쎄요, 네, 주제의 유일한 질문에 답할 수 없으니, 조금 주제에서 벗어난 점 죄송합니다 :face_with_tongue:

9개의 좋아요

네, 이 점을 항상 마음에 새기는 것이 중요하다고 생각합니다! 실수를 하거나 부끄러운 상황이 될 수 있지만, 아무도 시도하지 않는 것보다는 훨씬 낫습니다. 폭발할 만한 일을 하고 있는 것도 아니고, 실수가 돌이킬 수 없는 피해를 줄 경우는 많지 않으니까요.

조금만 인내심을 가지면 해결책을 찾아가면서 무언가를 배울 수 있을 것입니다… 제 경험상, Discourse를 사용하면서 여기에서 이에 대해 논의하는 사람들의 99%는 이 점을 이해하고 있습니다.

5개의 좋아요

점점 더 오프토픽으로 흘러가고 있는 것 같지만, 네가 한 말이 저명한 트랙매니아 스트리머가 아이들, 실패, 그리고 배움(체스든 일반적인 것든)에 대해 한 말을 떠올리게 한다:

[아이들은] 두려움이 전혀 없기도 해. 아이들은 보통 지나치게 생각하지 않고, […] 틀리는 것에 대해 두려워하지 않아. 그게 배우는 가장 좋은 방법이야, 안 되는 것이 뭔지를 보는 거지. 하지만 어른이 새로운 기술을 배우기 시작하면 어딘가 틀리는 것에 대해 두려워하게 돼. 아이들은 어른들보다 훨씬 더 시도하고 실패하는 것에 열려 있어. 마치 선생님이 누군가 생각이 있냐고 물었을 때, 확신에 찬 표정으로 틀린 답을 큰 소리로 외치는 것처럼 말이야. 그리고 이런 종류의 정신 상태가 네가 무언가를 배우는 방식을 형성해.[1]

기억해두면 좋을 것 같아 :slight_smile:

(오프토픽 끝)


  1. https://youtu.be/Hr2nBfa-yaM?t=1970 ↩︎

4개의 좋아요

제임스, 안녕하세요. :slight_smile:

네, 조사했습니다! 참여에 따른 숨겨진 비용에 대한 이해와 참여를 위한 프레임워크가 결합된 결과라고 생각합니다.

직원 참여의 내부 비용

의미 있는 참여는 단순히 질문에 답하는 데 드는 시간과 노력보다 더 많은 것을 요구합니다. 사람들은 정보에 대한 접근성, 모더레이션 지원, 후속 조치 프레임워크, 에스컬레이션 경로, 그리고 무엇을 논의할 수 있는지/어떤 사례를 공유할 수 있는지/어떤 고객을 언급할 수 있는지에 대한 명확한 지침이 필요합니다.

커뮤니티 팀은 일반적으로 이러한 보이지 않는 업무를 흡수합니다. 왜냐하면 어떤 주제별 전문가(SME)를 불러야 하는지 알고, 멤버들과 관계를 맺고 있으며, 대화를 생산적으로 유지하는 기술을 갖추고 있고, 아무것도 빠지지 않도록 확인하는 시간을 확보하고 있기 때문입니다. 이를 통해 신뢰 수준이 유지되고 커뮤니티가 모든 참여자에게 가치를 제공합니다.

우리 팀은 그 신뢰의 가치와 그것을 구축하는 데 얼마나 오랜 시간이 걸리는지 이해하고 있기 때문에, 그것을 훼손할 수 있는 일을 할까 봐 두려워하는 것이 참여 자체를 꺼리게 만드는 요인 중 하나가 됩니다.

내부 팀을 압도하지 않으면서 신뢰 구축하기

신뢰는 끊임없는 가용성보다 예측 가능한 행동에서 더 많이 나옵니다. 프로세스에 대한 확신이 있다면 고객/멤버는 팀에 대한 지속적인 접근이 필요하지 않습니다. 그들은 다음 사항들을 알아야 합니다:

  • 피드백을 남기는 곳
  • 피드백에 대한 처리 방식
  • 누가 피드백을 읽는지
  • 어떤 토론에 답변이 이루어지는지
  • 의사결정이 어떻게 이루어지는지
  • 언제 보고가 이루어지는지

신뢰할 수 있는 일정한 피드백 루프가 필요합니다. 경계가 있는 신뢰할 수 있는 시스템이, 가용성은 높지만 신뢰할 수 없는 시스템보다 나을 수 있습니다. 허공에 외치는 것과 같은 느낌을 받으면 아무도 피드백을 남기는데 시간을 투자하지 않을 것입니다. 멤버의 필요를 이해하기 위해 충분한 직접적인 접촉이 필요하지만, 동시에 모든 사람이 상호작용에서 어떤 가치를 얻는지 알 수 있도록 충분한 구조가 필요합니다.

이 부분은 저에게 흥미롭습니다—@mae를 불러서 기술적 제품 질문에 답하는 것에 대해 어떻게 생각하는지 물어보겠습니다. 꽤 눈여겨볼 만한 부분이 될 것 같습니다.

앤드루, 동의합니다. 누구나 답할 수 있는 소수의 질문은 항상 존재하지만, 그런 경우에도 발견성(Discoverability)이 문제가 될 수 있습니다. 다른 팀들이 이 문제를 어떻게 처리하는지 듣고 싶습니다.

오프토픽이라고 생각하지 않습니다. 그 안에서 우리가 가져갈 수 있는 꽤 가치 있는 것이 있다고 생각합니다. 우리는 실패를 두려워하는 이유를 더 잘 이해해야 합니다.

5개의 좋아요

답이 확실하지 않을 때 저는 이렇게 합니다…

첫째, 질문이 답변 없이 얼마나 오랫동안 방치되어 있는지 봅니다.

만약 1~2시간밖에 지나지 않았거나 주말이라면, 잠시 기다려보며 저보다 더 현명한 누군가가 답변할지 지켜봅니다.

매우 구체적인 질문이고 24시간이 지났는데도 아무 반응(매미 소리만) :cricket: 이 있다면, 저는 그 사람에게 조금은 불쌍한 마음이 듭니다. 질문의 주제에 대해 잘 모르더라도 도움을 주려고 노력합니다. 이런 상황에서는 때때로 빠르게 검색해서 그들을 향할 수 있는 문서가 있는지 확인합니다. 본인이 직접 할 수도 있지만, 아무리 절박해도 많은 사람들이 RTFM(문서 먼저 읽어라)을 하지 않습니다. 아니면 버그라면 재현을 시도해봅니다.

답을 안다고 생각하지만 확실하지 않다면, '제 생각에는…'이라고 말합니다.

답을 안다고 생각하지만 100% 확신이 없다면, '거의 확실합니다…'라고 말합니다.

전혀 감이 잡히지 않는다면, '이건 그냥 추측입니다…'라고 말합니다.

오래 방치된 주제에 대해, 어떤 형태로든 누군가가 답변하는 것이 아무 반응보다 낫습니다. 적어도 사용자는 무시당하고 있지 않다는 것을 알 수 있기 때문입니다. 그리고 종종 답변이 주제를 끌어올려 다른 사람들이 참여하기도 합니다.

저는 이것이 중요하다고 생각합니다. (매우 잘 표현하셨습니다) 자동 응답처럼 느껴지지만 후속 조치가 없는 초고속 응답 팀은 무용지물입니다.

하지만 이것이 다른 주제에서 사람들이 말하는 커뮤니티 참여도 하락과도 관련이 있다고 생각합니다. 지원 포럼이 응답하지 않거나 몇 시간씩 걸린다면, 즉시 답변을 얻기 위해 AI에게 질문하려는 유혹은 더 커집니다.

참고로, 저는 Meta가 이 균형을 잘 맞추고 있다고 생각합니다.

제가 커뮤니티 포럼이 임계 질량(critical mass)에 도달한다고 믿는 지점이 바로 이것입니다!

커뮤니티 포럼을 운영하려는 사람으로서, 언젠가 이 수준에 도달하길 바랍니다.

특히 지원 포럼이 충분히 지식을 갖춘 베테랑 사용자들의 참여를 얻게 되어, 사용자가 질문을 하면 재미로만 질문을 답변하는 수많은 사람들이 모이는 상황이 오면, 우리는 제대로 가고 있는 것입니다. 청중이 충분한 시간대에 걸쳐 분포되어 있어 누군가는 항상 깨어 있고 응답한다면, 이제 우리는 '월드 와이드 웹’의 힘을 제대로 활용하고 있는 것입니다.
그리고 커뮤니티가 줄 수 있지만 AI가 줄 수 없는 것이 있습니다… 바로 '커뮤니티’입니다.

8개의 좋아요

흥미로운 글이었는데, 제가 궁금해했던 핵심 사항은 다루지 않은 것 같습니다. 저는 특히 다음 부분에 더 관심이 있었습니다:

이것은 직관에 반하는 것처럼 보입니다. 더 많은 것을 알고, 다양한 사이트와 사용 사례 전반에 걸쳐 더 잘 알 수 있는 위치에 있는 사람은 누구일까요? 물론 아무도 모든 것을 알 수는 없지만, 평균적인 관찰자(lurker)보다 훨씬 더 많이 알고 있을 것이라고 확신합니다.

제품과 거리가 먼 부서(예: 재무, 법무)가 있을 수 있으므로, 이 피드백이 오직 그 부서들로부터 온 것이라면 더 이해할 만합니다. 하지만 그렇게 쉽게 설명될 수 있었다면, 이전에 그렇게 말씀하셨을 거라고 생각합니다.

이것은 함정처럼 느껴집니다… :slight_smile: 저는 마케팅과 영업이 기술적인 질문과는 약간 다른 전문성을 가진다고 생각했지만, 아마도 제가 너무 깊이 생각하는 것일 수도 있습니다. 미리 판단하지는 않겠습니다. :slight_smile:

다만, 시간과 자원을 어디에 가장 잘 사용해야 하는지에 대해서는 동의합니다. 하지만 그것은, 기여하고 싶지만 그렇게 할 수 없다고 느끼는 것과 별개의 문제입니다.

2개의 좋아요

농구 코치에게 테니스를 배우라고 하시겠습니까? 둘 다 스포츠이지만, 실제로 그 게임을 하는 사람을 원하실 겁니다. 여기에서도 같은 이치입니다. 제가 자격이 없는 답변을 어정쩡하게 내보내는 것보다, 여러분을 올바른 전문가에게 연결해 드리는 편이 낫습니다.

포지셔닝, 메시징, 그리고 우리가 Discourse의 이야기를 어떻게 전달하는지에 대해서는 종일 이야기할 수 있지만, 깊은 기술적 부분은 실제로 그것을 만드는 사람들의 영역입니다.

그럼에도 불구하고, 마케팅과 영업이 Meta에서 더 큰 역할을 해야 한다고 생각합니다. 그리고 덜 기술적인 콘텐츠의 원동력이 될 수도 있죠. 이것은 제게 3분기/4분기 우선순위입니다.

Meta에서 보고 싶으신 덜 기술적인 콘텐츠 아이디어가 있으시다면, 망설이지 말고 연락을 주시거나 주제에서 저를 태그해 주세요. :slightly_smiling_face:

7개의 좋아요

네, 정말 공감합니다. 완벽한 접근 방식이라고 생각해요.

매우 흥미로운 생각입니다—틀림없이 맞을 거예요. 하지만 사람들이 여기(또는 다른 포럼에서) 기본적으로 봇에게 질문할까요, 아니면 완전히 외부로 나갈까요? 측정해 보면 흥미로울 것 같습니다.

제 답변이 좀 복잡했는데요, 제가 하려는 말은 구체적으로 이거였습니다:

그리고 명확히 하자면, 네, 조직의 비즈니스 측면에서 참여에 대한 그 특정 장벽을 느끼고 있습니다. 실제로 기술적 질문을 언급하지 않았는데, 그 부분이 혼동되었네요. :slight_smile:

맞습니다. 누군가 디스코urses에 대한 기본적인 질문을 가져온다면, 저는 꽤 자신 있게 답변할 수 있다고 생각합니다. 하지만 매우 고급 설정이나, 깊숙이 숨겨진 버그로 드러나는 설치 실패 같은 경우에는 제 지식의 범위를 훨씬 벗어납니다.

몇 달 전에는 제가 게시물을 훨씬 적게 올렸던 시기가 있었습니다. 제가 자리를 비웠기 때문이 아니라(저는 항상 그곳에 있었고, 매일 메타를 읽었습니다), 질문들이 훨씬 더 기술적으로 변했고, 시간대 차이 때문에 질문을 훨씬 나중에 확인했기 때문이었습니다. 매우 구체적인 버그 보고나, 제 인스턴스에 적용하기에는 너무 구체적인 질문들이었죠.

그때 저는 결국, 제가 아는 것이 실제 제품을 개발하는 개발자나 Moin, Lilly 같은 사람들과 비교하면 빙산의 일각에 불과하다는 것을 깨달았습니다.

제 주장이 무엇인지는 아시죠? 디스코urses를 정기적으로 사용하더라도, 디스코urses의 구성 가능성은 정보가 거의 무한하다고 보장합니다. 디스코urses는 너무 커스터마이징이 가능합니다(나쁜 일은 아니지만) 때문에, 스톡 포럼과 거의 비슷하지 않을 정도로 심하게 조정될 수 있습니다. 따라서 스태프가 소프트웨어에 대해 모든 것을 알지 못해도 괜찮습니다: 그들은 서로 다른 부분에 특화되어 있으며, 각 부분이 그 부분의 '전문가’로 상담받을 수 있습니다.

4개의 좋아요

아, 확실히 가능성이 낮다는 걸 알았지만, 그 ‘눈을 뜨게 하는’ 설명 덕분에 플라룸(Flarum) 마이그레이션 스크립트나 클라우드플레어(Cloudflare) 터널 설정에 대한 그 난해한 지식을 꺼내 주실 거라고 희망하기 시작했거든요. :slight_smile:

다만, 게시글 후반부에 말씀하신 것처럼, 전문적인 디스코르스 지식을 적용할 수 있는 덜 기술적인 영역이 분명히 있으니, 적어도 원래의 ‘자신감 부족’ 피드백의 일부는 아닌 것 같습니다. :partying_face:

회사는 커뮤니티에 참여할 것으로 기대하는 부서와 사람들에 대해 현실적이 되어야 한다고 생각합니다. 일괄적인 정책이나 '다 똑같다’는 식의 기대는 작은 조직에서도 적합하지 않을 가능성이 큽니다. 포용 전략을 평가할 때 '이 부서/사람이 참여하면 어떤 이점이 있는가’라는 질문이 핵심이라고 생각합니다.

저도 이 대화가 진행되는 가운데 그런 언급이 나온 것이 어색하다고 생각했습니다. :slight_smile: AI의 일시적인 오류 같은 건가요?

7개의 좋아요

무슨 이야기를 하는 건지 궁금해서 대화 전체를 다시 읽어보며 어디서 언급되었는지 확인했어요. 제가 아는 한 여기에는 AI가 관여되어 있지 않으니까요. 그런데 이 부분을 보고 나서야…

혼동했네요! 왜 '기술적인’이라는 단어를 넣었는지 전혀 모르겠어요. 다시 읽어보니 제가 말씀하신 내용을 오해한 것 같습니다. 여기서는 아무도 마케팅 관련 질문을 하지 않는데, 제가 모든 사람이 제품 지식을 가지고 있다고 제안하신 줄 알았어요. 죄송합니다.

6개의 좋아요

저는 ‘제품 지식(product knowledge)’과 ‘기술적 제품 지식(technical product knowledge)’이 양파의 다른 층(layer)이라고 생각합니다. 마케팅과 영업 부서에서는 당연히 ‘제품 지식’을 갖추고 있다고 가정하는데, 아무것도 모른다고 할 수 있는 제품을 마케팅하고 판매하는 것은 상당히 제한적일 것 같아서요. :slight_smile: 하지만 동시에, 회사가 ‘그 혜택이 무엇인가’를 저울질하여 해당 부서들이 커뮤니티 공간에 적합하지 않다고 판단하거나(또는 그들의 시간/자원이 다른 곳에 더 잘 쓰일 수 있다고 결정하는 것)도 완전히 합리적이라고 생각합니다. 위 게시물에서 Mae는 여기에 잠재력이 있다고 생각하는 것 같고, 기업 구조에서 커뮤니티는 종종 마케팅의 범주에 포함되므로 기존에 그런 연결고리가 있는 것도 있지만, 반드시 정답이 있는 것은 아니며 각 회사가 스스로 이러한 결정을 내려야 한다고 생각합니다.

‘어떤 부서인가’와 함께 고려해야 할 또 다른 실용적인 사항은 얼마나 많은 직원이 참여할 것으로 예상하는지, 얼마나 적극적으로 참여할지, 그리고 커뮤니티가 그들을 건강한 방식으로 수용할 수 있을 만큼 충분한 규모인지입니다. 모든 커뮤니티 문화는 다르고, 모든 커뮤니티-회사 조합도 약간 다른 풍미를 가지므로 이는 크게 맥락에 의존할 것입니다. 하지만 커뮤니티에 20명/30명/50명의 활동적인 팀 멤버를 투입했을 때 어떤 효과가 있을지 생각해 볼 가치가 있다고 생각합니다. 공간을 지배하는 것이 의도라면 모르겠지만, 그렇지 않다면 이러한 잠재적 결과에 대해 주의를 기울이는 것이 영향을 완화하는 데 도움이 될 수 있습니다. 예를 들어, 그들의 참여가 가장 잘 발휘될 것으로 생각하는 공간/카테고리를 지정하거나, 언제는 몸을 사리고 커뮤니티에게 먼저 기회를 줄지에 대한 가이드라인을 설정하는 것 등이 있습니다.

이 팀 멤버들이 커뮤니티에 온보딩되도록 돕는 샌드박스 역할을 하는 비공개 카테고리를 설정하는 것도 그들의 전환을 부드럽게 만드는 데 도움이 될 수 있습니다. 공개 영역에 뛰어들기 전에 미디어에 익숙해질 수 있도록 눈에 띄지 않는 작은 장소라고 할까요. 인용하는 법, 투표 생성, 기존 포럼 에티켓 이해 등 간단한 것들을 통해 자신감을 쌓고, 모두 초보자처럼 몰려들지 않도록 하는 것입니다. :slight_smile:

또한, 참여를 의무화할 것인가에 대한 질문도 있습니다. 개인적으로는 가능한 한 이를 피해야 한다고 생각합니다. 강제로 참여하게 느끼는 사람들은 종종 잘못된 분위기를 풍길 수 있고, 어색하거나 딱딱하거나 독단적인 상호작용은 장기적으로 더 많은 해를 끼칠 수 있습니다. 참여의 이점을 설득하는 것이 훨씬 더 바람직한 동기부여 수단이라고 생각합니다. (다만, 이 역시 커뮤니티와 회사 문화에 크게 의존합니다 :slight_smile:)

3개의 좋아요

이런 주제에서는 다른 곳에서처럼 모든 응답에서 배우며 여러분 모두의 글을 읽는 것을 정말 즐깁니다.

저는 완전히 다른 문화권에서 태어나 자랐습니다. 이제야 우리가 모두 같은 감정과 두려움을 공유하고 있다는 것을 볼 수 있습니다. 제 삶이 저를 '예술가’의 영역으로 인도한 후, 여기서 언급하신 핵심 문제가 변화에 뿌리를 두고 있다는 것을 깨닫기 시작했습니다.

변화는 영원하며, 우리 스스로가 생명체로서 존재하는 모든 것입니다. 메타(Meta)도 우리 모두와 같이 변하고 있습니다. 처음에는 어려웠습니다(매우 기술적이고, 매우 중립적이었으니까요) 하지만 지금은 모든 사람에게 더 유쾌하고 쉬워졌습니다. 개발 영역뿐만 아니라 인간적인 지원, 상호작용, 창의성에서도 마찬가지입니다.

제 개인적인 의견입니다 :slight_smile:

4개의 좋아요