Discourse 팀이 새로운 사람들의 제안에 대해 여기저기서 열린 자세를 취해준 것에 대해 감사드립니다.
저는 지난 몇 년간 Meta에서 이런 일이 자주 발생하는 것을 목격해 왔습니다. 하지만 이번 사안이 제가 일반적인 관점에 대해 제 생각을 공유하는 계기가 되었습니다. 과거에도 이런 상황을 목격할 때마다 짜증이 났지만, 어떻게 이 문제를 제기해야 할지 잘 몰랐습니다. 그래서 이제 이 문제에 대해 써보려 합니다:
배경
Meta 주변에서 가끔 Discourse의 기능이나 변경 사항에 대한 신참들의 제안에 대해 사람들이 일제히 부정적인 반응을 보이는 경향을 보았습니다. 소프트웨어를 처음 접하는 사람들의 경험 – 10년 이상 Discourse를 사용해 온 우리조차도 도움이 될 통찰력을 담고 있는 – 를 경청하고 이해하는 대신, 커뮤니티의 일부 사람들이 사전에 그 아이디어를 깎아내리는 경우가 있습니다.
이러한 반응은 보통 아이디어가 과거에 Discourse 팀에 의해 거부되었거나, Discourse 팀이 특정 기본 설정을 다른 구성보다 선택했을 때와 같은 상황에서 발생합니다.
그렇더라도, 과거에 논의된 적이 있는 아이디어나 소프트웨어에 대한 불평에 대해 사전에 즉시 무시하려는 경향에 대해 왜 그렇게 해서는 안 되는지에 대한 제 생각을 공유하고 싶습니다.
Discourse 팀이 최종 결정권을 가집니다. 많은 것이 변했습니다. 과거의 일들은 지금에 적용되지 않을 수 있습니다.
우선, 우리 커뮤니티 구성원들은 Discourse의 프로덕트 매니저가 아닙니다. 누군가의 아이디어가 과거에 거부되었다고 말하고 그 이유를 설명하는 것은 Discourse 프로덕트 팀의 현재 결정을 반드시 반영하지 않을 수 있습니다.
때로는 Discourse 팀 자체도 과거에 배제되었던 기능을 작업하기로 결정할 수 있습니다. 오랫동안 채팅(chat)이 그런 기능 중 하나였습니다.
따라서 과거의 결정이 현재의 결정과 항상 같을 것이라는 100%의 보장은 없습니다.
Discourse 팀 내에서도 Discourse의 우선순위가 무엇이어야 하는지에 대해 서로 다른 견해를 가질 수 있습니다.
예를 들어, 저는 @erlend_sh의 블로그를 자주 읽었습니다. 그는 채팅이 Discourse에서 어떻게 되어야 하는지에 대해 팀의 나머지 멤버들과 다른 견해를 가지고 있었다고 논의했습니다 – 굵은 강조는 제 것입니다:
대부분의 오픈소스 프로젝트는 전용 포럼이 없지만, 포럼이 있는 프로젝트들은 거의 항상 그룹 채팅도 가지고 있습니다. 제가 Discourse에서 마지막으로 근무했던 기간은 두 가지 모드를 하나로 통합하려는 시도였으며, Discourse Chat의 도입을 통해 이루어졌습니다.
저는 그 MVP(이후 코어로 졸업했습니다)에 대해 정말 자랑스럽게 생각합니다, 하지만 거기서부터 제가 가고자 했던 방향은 전통적인 포럼으로서의 Discourse 프로젝트의 DNA와 이해할 수 있는 이유로 호환되지 않았습니다: 저는 채팅을 우리 커뮤니티 경험의 선두로 만들자고 제안했습니다. 커뮤니티는 채팅 룸에서 시작된다고 생각했습니다. Discourse는 그렇게 생각하지 않았고, 우리는 우호적으로 이별했습니다.
몇 년이 지난 지금도 제 입장은 변하지 않았습니다. '그룹 채팅’과 '포럼’은 대략 같은 것을 의미해야 합니다. 실제로 우리가 나아가고 있는 방향은 바로 그것입니다. 우리 커뮤니티의 지배자라고 할 수 있는 Discord가 이제 포럼 패러다임에 잘 맞는 다양한 스레드 & 보드 기능을 지원하기 때문입니다.
따라서 시간이 지남에 따라 변할 수 있는 것이므로, Discourse에 포함되지 않아야 하는 것을 우리가 서둘러 결정할 문제는 아닙니다.
Discourse의 초기 시기를 기억하는 우리는 CDCK가 10명 미만이었을 때와, 프로덕트 매니지먼트가 Discourse 공동 창립자들에 의해 크게 주도되었던 때를 기억할 것입니다. 하지만 오늘날 CDCK는 100명의 인원을 보유하고 있으며 CDCK에는 전담 프로덕트 팀이 있습니다!
Discourse 자체는 훨씬 더 큰 사용자 기반을 가지고 있으며, 이 사용자들의 필요와 소프트웨어 사용 방식은 초기 Discourse 도입자들보다 훨씬 성장했습니다. 더 광범위하게 말하면, 소셜 플랫폼의 지형도 변했습니다(모멘텀이 Facebook에서 Discord 등으로 이동했으며, 그 외 많은 변화가 있었고), 사람들의 일반적인 기대치도 변했습니다.
팀이 Discourse 초기 시절보다 훨씬 더 커졌기 때문에, 과거 프로덕트 개발 초기 단계에서 훨씬 낮은 우선순위로 여겨졌던 다른 기능들을 작업할 더 많은 역량을 가지고 있습니다.
따라서 현재 기능 요청을 검토하는 방식은 초기 시절과 꽤 다를 가능성이 높습니다. 프로덕트 팀은 의사결정과 최종적으로 무엇이 언제 작업될지를 결정하기 위한 자체적인 프로세스를 가지고 있을 것입니다.
더 많은 데이터 포인트가 더 좋습니다
둘째, Discourse 팀에게는 더 적은 데이터 포인트보다 더 많은 데이터 포인트를 듣는 것이 보통 도움이 됩니다.
Meta에서 Rule of 3(3의 법칙)으로 느슨하게 대중화된 것이 있었습니다(기능 요청이 고려되기 전에 최소 3명의 사람이 무언가에 대해 불평해야 함). 그럼에도 불구하고, 3명의 다른 사람이 무언가에 대해 문제를 발견하도록 듣기 위해서는 사람들이 자신의 경험을 공유하고 불평할 수 있게 해야 합니다.
그 외에도, 또 다른 대중화된 아이디어는 불평 주도 개발(Complaint Driven Development)이었습니다. 그리고 이것에 대해서도 사람들의 의견을 경청해야 합니다:
제가 본 적으로 작동하는 유일한 것은 사용자들과 함께 현장에 깊이 파고들어, 그들과 소통하고 관계를 구축하는 것입니다.
그 글을 다시 읽은 후, 저는 그 “3의 법칙” 뒤의 원래 전제가 실제로는 다른 사람이 불평하지 않으면 당신의 의견은 중요하지 않다는 것이 아니라는 점을 매우 강력히 주장합니다.
그 핵심은 (특히 자원이 부족한 팀인 경우) 사람들이 가장 많이 불평하는 것들을 찾는 것이 사용자가 가장 골치 아파하는 문제를 찾는 효율적인 방법이라는 것이었습니다 – 그래서 먼저 그것들을 수정할 수 있도록요.
Steve Krug가 Don’t Make Me Think에서 말하듯:
수정할 자원이 있는 것보다 항상 더 많은 문제를 발견하게 될 것이므로, 가장 심각한 문제부터 먼저 수정하는 데 집중하는 것이 매우 중요합니다. 그리고 3명의 사용자는 테스트하고 있는 작업과 관련된 가장 중요한 문제 중 많은 부분을 경험할 가능성이 매우 높습니다.
따라서 다른 많은 사람들이 같은 것에 대해 불평하지 않았다고 해서 그것이 중요하지 않다는 의미는 아닙니다. Discourse 팀이 사용자의 현재 주요/부차적痛点(고민)이 무엇인지 고려할 때, 더 많은 데이터 포인트는 여전히 도움이 됩니다.
구현하지 않더라도 사람들의 피드백을 감사할 수 있습니다
셋째, 모든 제안을 구현할 수 없거나 구현하지 않기로 결정했더라도, 사람들의 피드백에 대해 감사 인사를 드리는 것은 여전히 가능합니다.
게임 설계를 공부하면서 피드백을 주고받는 것이 프로세스의 매우 큰 부분이었던 덕분에, 저는 이런 방식으로 피드백을 처리하는 데 더 숙달되었습니다. 모든 게임 레벨, 설계 문서 또는 기타 모든 것의 반복 과정에서, 우리는 최소 3명의 다른 사람의 작업에 피드백을 주고 최소 3명의 다른 사람으로부터 피드백을 받았습니다. 저는 다른 사람들이 결석하거나 과제를 늦게 제출하는 경우를 보완하기 위해 4~5명의 사람에게 피드백을 주려고 노력했습니다.
종종 사람들의 피드백은 매우 통찰력 있고 유용하지만, 중요한 점이 10개 이상인 반면 현재는 1~3가지만 구현할 시간이 있는 경우가 많습니다.
저는 소규모 스타트업의 일원으로 커뮤니티와 자주 상호작용하며 전문 소프트웨어 엔지니어로 일했을 때도 마찬가지였습니다. 중요한 버그 리포트가 10개 이상 있을 수 있지만, 다음 업데이트에서는 그중 1~3가지만 수정할 시간이 있을 수 있습니다.
어쨌든, 저는 사람들의 관찰에 대해 감사하고, 그들의 생각을 공유해준 것에 대해 감사하고, 버그 재현 단계를 작성해준 시간에 대해 감사하며, 불편을 드린 것에 대해 사과하는 것이 매우 의무감 있게 느껴집니다.
대부분의 경우, 사용자/플레이어는 정말로 번거로울 때만 말을 합니다. 따라서 거의 모든 서면 피드백/기능 요청/버그 리포트는 무언가에 대해 자신의 생각을 공유하는 데 시간을 할애한 누군가로부터 옵니다 – 많은 다른 사람들이 생각했지만 아직 식별하거나 말하지 않은 것들, 아마도 당신이 놓친 것들, 그리고 그 외 많은 것들입니다.
따라서 모든 사람이 말하는 것을 구현할 수 없더라도 – 이는 90%의 경우일 수 있습니다 – 모든 그 피드백에 대해 즉각적으로 달려들어 그것을 무력화해야 한다는 의미는 아닙니다. 피드백은 여전히 중요합니다. 현재 행동할 자원이 없거나, 심지어 행동하지 않기로 결정했더라도요.
어쨌든, 그것이 왜 우리 커뮤니티 구성원으로서 더 새로운 사람들이 그들의 생각을 공유할 수 있게 하고, Discourse에 대한 사람들의 제안을 즉시 무시하려는 경향에서 벗어나야 한다고 생각하는지입니다. 이는 Discourse 팀의 기능에 대한 입장이 시간이 지남에 따라 변할 수 있고, 피드백은 Discourse 팀에 대한 데이터 포인트로서 여전히 유용하기 때문입니다. 지금 바로 구현하지 않더라도요.