더 잘 소통하고 협업하기 위한 협업 도구 Best Practice

Confluence나 Jira 를 자료를 올리고 공유하는 용도로만 쓴다면 비싸고 효율적인 게시판을 산 것과 다름 없습니다.

1. Space 와 Page 는 기본 전사  공개

사일로 현상을 방지하고 전사에 협업 문화를 뿌리기 위해 가장 중요한 것은 특정인이 정보를 독점하거나 숨기기 않도록 하는 것입니다.

저는 그래서 confluence의 모든 스페이스와  페이지를 사내에 공개하는 필요하다고 생각합니다.

전에 어떤 분이 인사나 재무같이 누구에게나 공개되면 안 되는 자료도 공개하냐고 물어 보신 적 있는데 공개하기 힘든 자료는 Confluence 에 안 올리는게 좋다고 생각합니다.

2. 팀원과 다른 팀 업무에 관심갖기

내가 하는 업무를 물론 잘해야겠지만 스페이스와 페이지를 전사 공개했다면 팀원과 다른 팀이 어떤 업무를 하는지도 관심을 갖는게 필요합니다.

그리고 이렇게 다른 팀 업무에 관심을 갖는건 사일로 현상을 방지하고 동료를 도와주고 동료에게 도움을 받는 등 건강한 협업 문화 정착에도 큰 도움이 됩니다.

3. 댓글과 좋아요로 동료 컨텐츠에 관심과 고마움 표하기

다른 팀 업무에 관심을 가질때 동료가 작성한 내용이 도움이 되거나 마음에 들면 좋아요를 클릭하고 문의 사항등은 댓글로 관심을 표시해 주는게 좋습니다.

이런 활동은 협업과 공유를 더 뿌리 내리게 하지만 다음과 같은 부가적인 장점이 있습니다.

feed 를 통해 좋은 콘텐츠 발견 가능

좋아요와 댓글이 많은 콘텐츠는 피드 채널에서 cloud 에서는 "인기있는 콘텐츠" , server 에서는 "잘 알려진" 콘텐츠 탭에 표시가 됩니다.

그래서 또 다른 직원이 좋은 컨텐츠를 발견할 수 있고 도움이 될 소지가 높아집니다.

추천 업데이트 메일

저는 컨플루언스의 관리자 설정중에 "추천 업데이트 메일" 을 활성화하는 것을 권장합니다.

조직이 커지고 컨텐츠가 많아지면 사실 다른 팀 업무에 관심 갖기가 어려운 점이 있는데 "추천 업데이트 메일" 을 활성화할 경우 위와 같이 좋아요와 댓글이 많은 컨텐츠를 선별해서 메일로 보내줍니다.

그래서 바빠서 다른 팀에게 관심 가질 시간이 부족해도 메일을 통해 전달된 정보로 사내 컨플루언스에서 어떤 일이 있는지 알수 있습니다.

4. “단일 진실 공급원” 정책 유지

단일 진실 공급원(SSOT; Single Source of Truth)는 사내의 업무 내역과 지식, 노하우를 중복되지 않게 하기 위한 정책으로 업무시에 컨플루언스나 Jira 같은 협업 도구가 단일정보출처가 되도록 노력해야 합니다.

그래서 사내에서는 이메일 사용을 자제하고 confluence page 로 작성하고 공유하고 어쩔수 없이 excel 이나 power point 로 작성해야 하는 자료들은 컨플루언스 page 에 첨부하는 등 단일정보출처를 유지하도록 해야 합니다.

5. 용도가 중복되는 협업 솔루션 통합

4번과 겹치는 얘기지만 slack 같은 메신저와 confluence 를 같이 사용하는 것은 두 도구가 지향하는 바가 다르고 실시간 메신저와 문서 기반 협업 서로 다른 업무이기 때문에 혼란을 주지는 않습니다.

물론 page 로 작성하고 공유한 후에 꼼꼼하게 리뷰해야 할 업무를 메신저로 보내서 깊은 고민을 못 하고 실시간 답변을 해서 깊이가 떨어지는 등의 문제는 있을 수 있습니다.

하지만 용도가 겹치는 협업 도구(google docs, confluence) 를 같이 쓰면 사용자들은 어떤 언제 닥스를 쓰고 언제 컨플루언스를 쓸지 헷갈리며 필요한 정보를 찾을때도 닥스와 컨플루언스 양쪽에서 찾아야 하는 문제가 발생합니다.

제 생각에는 닥스처럼 컨플루언스와 용도가 중복되는 경우는 통합해서 하나만 사용하는게 좋다고 생각합니다.

만약 기존에 닥스에 쌓인 문서가 많은등의 이유로 통합이 어렵다면 용도를 정해서 사용하는 게 좋습니다.

예로 닥스에는 단발성이고 지속적으로 유지될 필요없는 정보만 올린다거나 예로 회식참가자 명단 취합이나 명절 선물 취합같이 여러 가지 정보를 취합해야 하지만 지속적으로 추적하고 현행화할 필요가 없는 정보만 사용하는게 좋습니다.

6. 정책이나 프로세스 문서화시 맥락과 배경 기록하기

정책이나 업무 프로세스 절차등 다른 팀에게도 영향을 주는 프로세스를 정리하고 문서화할 경우 꼭 서두에 이 문서를 만들게 된 배경이 무엇이고 어떤 맥락에서 만들게 되었고 제약사항은 무엇인지를 같이 기록해 주는 게 필요합니다.

정책이나 프로세스는 늘 만능이 아니고 팀이나 회사의 규모에 커짐에 따라서 예전에는 좋은 프로세스였는데 지금은 적합하지 않은 프로세스일 수 있습니다.

문서에 맥락과 배경이 없으면 상황이 바뀌었을때 뭔가 지금 현실에는 안 맞는거 같지만 왜 이렇게 됐는지를 몰라서 계속 따르게 되는 경우가 있고 이런 프로세스가 발목을 잡을수 있기때문입니다.

예로 제가 아는 어느 회사는 직원이 3명도 안 되는때부터 confluence 를 사용해 왔는데 당시에도 협업과 공유가 필요하지만 굳이 스페이스와 페이지를 나누면 컨플루언스에 익숙하지도 않은데 일만 커진다고 생각해서 단일 페이지에 모든 내용을 기록하고 공유하던 곳이 있습니다.

여기에는 관리하는 시스템 목록, 회의록, 누가 언제 연차인지등 온갖 내용을 기록했는데 직원들이 바뀌고 성장하면서 왜 이런 결정을 내렸는지를 잊어버리고 단일 페이지에 기록이 정책이 되버려서 단일 페이지를 계속 사용하고 있으며 변경 이력이 수 백번이 되는 사례가 있습니다.

극단적인 사례이겠지만 정책이나 프로세스를 만드실 경우 꼭 만들때 환경, 맥락, 제약사항을 같이 기록해 두어야 환경이 바뀌면 대응이 용이해 집니다.

또 바뀐 상황에 맞게 변경할 경우 페이지에 커멘트를 달거나 변경사항 기록 기능을 이용해서 변경 이유도 같이 적어두는게 좋습니다.

7. 정비 및 현행화를 위한 별도의 시간 마련(aka 기술 부채 정리의 날)

Open

꾸준히 달리려면 가끔 정비도 해주어야 합니다.

어떤 회사는 "기술 부채 정리의 날" 같은 이름으로 새로운 기능보다는 기존 기능이나 기술 부채 정리에 집중하는 시간을 정기적으로 갖는 경우도 있습니다.

마찬가지로 컨플루언스로 협업을 잘 하려면 주기적으로 별도의 시간을 두고 오래되거나 유용하지 않은 컨텐츠를 보관하거나 별도의 아카이빙 전용 스페이스를 만들고 옮겨서 검색에서 제외하거나 환경이 바뀌어서 변경해야 할 지식을 현행화하는 등 정원 가꿀때 잡초를 뽑듯 정리하는 시간이 필요합니다.