저는 특히 초기 단계에서 이것이, 그리고 프로젝트 상위의 사람들에 대한 신중한 기대치 관리가 매우 중요하다고 생각합니다.
모든 사람에게 문을 활짝 열고 디스코urses(Discourse)를 과하게 홍보하면 프로젝트를 쉽게 망칠 수 있습니다. 관련성 없거나 주의 분산을 일으키는 콘텐츠, 전문가들을 화나게 만드는 형식이 엉망인 질문들이 쏟아지고, 이제 그 초기 사용자 수에 묶여버린 관리팀(그 수는 분명히 줄어들 것입니다)이 생깁니다. 그 상태에서 복구하는 것은 예방하는 것보다 훨씬 어렵습니다.
우리가 이 문제를 해결한 방법 중 하나는 사람들이 특정 주제에 대한 내용을 읽기 전에 새 주제를 만들지 못하도록 하는 것이었습니다:
- 좋은 질문을 작성하는 방법 (스택 오버플로우 방식)
- 공유하면 안 되는 것 (고객의 기밀성 요구 사항에 따라)
- 공유해도 되는 것과 불법적인 내용을 합법적으로 수정하는 방법
이것은 세 가지 결과를 가져왔습니다:
- 플랫폼 관리가 쉬워졌습니다 - 주제를 만들기 전에 무엇이 괜찮고 무엇이 아닌지를 매우 명확하게 설명했기 때문입니다.
- 전문가들을 저열한 콘텐츠의 물결로부터 보호했습니다.
- 많은 사람들을 화나게 했습니다.
특히 3번에 대해 말하자면, 초기 제한 조치에 부딪힌 직원의 약 20~30%는 10분간의 독서가 자신들에게는 하찮은 일이라고 느끼고, 이미 완벽한 질문을 작성하는 방법을 알고 있다고 생각했습니다. 일부 경우에서는 이것이 사실이었지만, 대부분은 제 생각에 우리가 구축하고자 하는 문화에 맞지 않는 사람들을 막아내는 역할을 했습니다. 즉:
- 읽기는 쓰기보다 중요합니다.
- 겸손한 태도로 플랫폼에 오세요.
- 다른 직원들이 잘 형식화된 질문을 통해
- a) 당신을 돕기 위해 자발적으로 내어주는 시간을 덜 쓰게 하고
- b) 2~3년 후에도 그 주제에서 배울 수 있도록 하세요.
이 또한 매우 좋은 지적입니다. 우리는 주제 수, 주제 조회수, 답변 수 등을 기반으로 ROI 공식을 작성하는 것이 매우 유용하다는 것을 발견했습니다. 결국 이는 전문가가 여러 회의와 이메일 체인에서 여러 번 질문받지 않고 디스코urses(Discourse)에서 한 번만 질문받음으로써 얼마나 많은 시간이 절약되었는지를 나타내는 결과로 이어졌습니다.