좋은 질문입니다. 위의 글에서는 첫 출시를 염두에 두고 있었지만, 현실에서는 그렇게 단순하지 않습니다. 엔터프라이즈 기업에서는 이전 커뮤니티가 어떤 형태로든 항상 존재합니다.
제가 무슨 뜻인지 구체적인 예를 들어보겠습니다. 우리의 Discourse 이전의 커뮤니티는 여러 플랫폼에 흩어져 있었습니다:
- Yammer(Viva Engage)
- Sharepoint
- Microsoft Teams
이로 인해 기대치 관리가 훨씬 더 어려워졌습니다.
Viva Engage에서 넘어온 사용자들은 "내가 하고 싶은 것을 아무거나 올릴 수 있다"는 기대를 하고 있었습니다. 이를 운영하던 팀은 검수를 하지 않았고, 접근하는 모든 매니저의 요구를 단순히 받아들이기만 했습니다. 그 결과, 매니저의 KPI를 충족시키기 위한 목적만으로 존재하는 커뮤니티들이 생겨났습니다. 새로운 커뮤니티가 생기고 3개월 동안 활성화되었다가, 그 후 죽음을 맞는 식이었습니다. Needless to say(말할 것도 없이), 이러한 사고 방식을 극복하고 왜 정확히 그 접근 방식이 몇 달 후 실패하는지, 그리고 왜 우리의 구조적이고 장기적인 접근 방식이 처음에는 더 느리겠지만 6~12개월 후에 더 나은 결과를 제공할 수 있는지를 설득하기 위해 상당한 코칭과 커뮤니케이션 노력이 필요했습니다.
Sharepoint는 "내가 원하는 파일을 아무거나 업로드할 수 있다"는 기대를 형성했습니다. 엔터프라이즈 수준에서는 파일을 공개적으로 공유할 때 매우 신중해야 합니다. 각 고객과 서비스 제공업체는 회사와 각각 계약이 있으며, 그들이 우리에게 공유하는 각 파일은 서로 다른 기밀성 요구 사항을 가집니다. Sharepoint는 사용자가 해당 파일에 누가 접근할 수 있는지 정확히 설정할 수 있게 해주지만, Discourse는 그렇지 않습니다(그리고 그럴 이유가 있습니다. 그것은 파일 공유 플랫폼이 아니므로). 저는 이 문제를 사용자들에게 Sharepoint에 파일을 업로드한 후 해당 파일의 링크를 공유하도록 장려하여 해결했습니다. 공유된 파일에 접근할 수 없는 사람이 있다면 해당 주제(topic)에서 권한을 요청할 수 있었습니다. 귀찮은 일이었지만, 소송보다 비용이 덜 들었습니다.
MSTeams는 "여기에 나만의 채널/커뮤니티 구획을 가질 수 있다"는 기대를 만들었습니다. 아니요, Discourse의 핵심은 바로 그 반대였습니다. 이 프로젝트의 목표는 지식의 비효율적인 단절(silos)이 아닌 지식 공유를 만드는 것이었습니다. 팀 채널은 기밀이 있거나 프로젝트에 특화된 지식에는 좋은 솔루션이었지만, 더 일반적인 맥락으로 추상화할 수 있는 모든 것은 Discourse에서 공유하도록 장려했습니다.