리모트 근무를 효과적으로 실행하기 위해서는 커뮤니케이션 전략, 원격 책임자 고용 등 고민해 보아야 할 일들이 정말 많습니다. 또한 효과적으로 문서 작성을 하고 하나의 공식적인 출처를 통해 모든 사람들이 접근할 수 있게 하는 것도 필수적인데요.

문서화에 대한 핸드북 우선적인 접근 방식은 잘 운영되는 비즈니스에서 은근히 중요합니다. 쉽게 건너뛸 수 있을 것처럼 느껴지거나 심지어 비효율적이라고 생각할 수도 있습니다. 하지만 실제론 프로세스, 문화 및 솔루션을 의도적으로 기록하고 정리함으로써 얻을 수 있는 막대한 이점은 놀랍습니다. 그리고 반대로, 구조화된 문서 작성을 피하는 것이 전반적으로 성장을 저해하는 낮은 수준의 혼돈과 혼란감을 심어주는 가장 좋은 방법일 것입니다.

성공적인 원격근무를 위해 GitLab은 의도적으로 문서 작성을 실행하고 있습니다. 이러한 행동은 핸드북을 먼저 작성 및 운영하고 투명성을 평가하여 모든 사람이 핸드북에 공개적으로 접근할 수 있도록 합니다.

문서화 & 핸드북 우선 (handbook-first)

문서(documentation)라는 용어는 종종 어떠한 행사나 이벤트 후에 무언가를 기록하는 과정을 의미하지만, 이 페이지에서는 보다 의미 있는 접근 방식을 자세히 설명할 것입니다. 문서는 배포되기 전에 먼저 체계적이고 잘 정리된 방식으로 이루어져야 합니다. 예를 들어서, 하나의 프로젝트에 관한 솔루션이 있다고 치면, 이를 먼저 문서화한 후 슬랙 또는 이메일을 통해 발표하는 방식입니다.

Gitlab이 추구하는 목표는 문서 작성을 위해 문서화하는 문화를 만드는 것이 아닙니다. 문서를 배포하기 전에 보편적으로 접근 가능한 핸드북에 새로운 솔루션이 문서화되고, 하나의 공식적으로 인정된 출처(문서 작성이 이루어지는 곳)를 통해 이러한 작업이 반복적으로 이루어지는 환경을 만드는 것입니다. 편집팀이 스타일 가이드를 고수하는 것처럼 각 팀 구성원은 동일한 방식으로 문서에 접근해야 합니다.

핸드북 우선 문서화가 중요한 이유는 무엇일까?

초기 단계의 스타트업에서, 문서화 전략을 피하는 것은 특히 유혹적으로 느껴질 수 있습니다. 이러한 기업은 주로 적은 구성원으로 이루어져 있기 때문에 몇 명의 팀원만 있으면 회의, 슬랙 또는 이메일 스레드를 통해 모든 사람에게 정보를 제공할 수 있기 때문입니다. 장기적으로 보았을 때, 이러한 문서화에 대한 간과는 점점 더 해롭게 작용할 것입니다.

팀이 확장됨에 따라 문서화 필요성은 그렇지 않은 비용과 함께 증가합니다. 즉, 기업이 오래되고 성숙해짐에 따라 문서화 전략을 구현하는 것은 더 어려워지고 더 중요해질 것입니다.

회사의 창립 기간 동안 매출 및 고객 유지와 같은 측정 기준과 함께 문서가 동일한 기준에 놓이는 경우는 거의 없지만, 그럴 가치가 충분히 있습니다. 문서화가 잘 된 회사와 핸드북을 회피하는 회사의 차이는 극명하다는 이야기 입니다.

핸드북을 우선으로 하는 팀원들은 믿을 수 있고 공식적으로 인정된 하나의 출처(문서 작성이 이루어지는 곳)를 통해 막대한 이익을 얻습니다. 이런 종류의 조직은 거의 초자연적인 효율로 운영될 수 있습니다. 구조화된 문서에 공동의 노력을 기울이지 않는 조직은 팀원들이 동일한 비트의 데이터를 영구적으로 요청하고 다시 요청하는 것을 지켜볼 수밖에 없습니다. 또한 이는 중단, 반복적인 회의 및 차선으로의 (최적이 아닌) 지식 이전이라는 고통스러운 행동을 반복하게 될 것입니다.

어떻게 시작할까?

완전 원격근무(All-Remote)로 전환하고자 하는 기존 조직 또는 하이브리드 원격근무 조직의 가장 큰 우려 사항은 회사 핸드북을 만드는 것은 느리고 더디다는 것입니다. 팀들이 원활하게 협업하는 데 필요한 토대를 마련하기 위해 서로 멀리 떨어져 있는 별도의 사무실을 유지하는 회사들도 이런 생각을 합니다.

조직을 위한 최선의 방안이 무엇인지 미리 예상하고, 기업의 발전을 방해하지 않도록 하는 것은 중요합니다. 회사 핸드북을 시작하기에 이상적인 시기는 시작 단계이지만, 그 다음으로 좋은 시기는 오늘입니다.

슬랙 또는 채팅 메시지가 빨리 만료되도록 하기

GitLab에서는 90일의 슬랙 메시지만 유지되고 그 후로는 없어집니다. 이는 슬랙이 end-to-end 프로젝트를 관리하는 유용한 도구로 사용되지 않도록 하기 위한 의도적인 행동입니다. 슬랙, 마이크로소프트 팀즈 및 이와 유사한 도구는 인스턴트 메시징 플랫폼이며, 이는 진정한 비동기 문화를 해칠 수 있습니다.

팀이 단일한 하나의 공식적인 출처에 의존할 수 있도록 보장하는 데 있어서, 훌륭한 리더는 즉각적인 메시지 보존에 관해서는 무자비할 것입니다. 예를 들어서, 팀 구성원이 슬랙같은 인스턴트 메시지 기록을 검색하여 특정 프로젝트에 대한 업데이트를 쉽게 확인할 수 있다고 생각해 보세요. 이렇게 원하는 자료 및 정보에 쉽게 메시지 기록을 통해 접근 할 수 있는 경우, 모두가 접근할 수 있는 곳에 진행 상황을 문서화할 동기는 사라질 것입니다. 이로 인해 막대한 지식 격차가 발생하고 조직 전체의 커뮤니케이션, 조정 및 이해가 더욱 분열 될 것 입니다.

따라서 이러한 90일 동안만 메시지가 저장되는 정책은 강제 기능으로 작동합니다. 그것은 팀원들이 궁극적인 하나의 공식적인 출처(문서 작성이 이루어지는 곳)와 직접 연결된 위치에서 업무 문제를 논의하도록 유도하기 때문입니다. GitLab에서는 모든 작업, 프로세스 및 정책이 핸드북에 문서화됩니다.

인스턴트 메시징 도구는 대화에 사람을 추가하는 것이 어렵고, 모든 작업 기록은 해당 프로그램에 남겨져 있으며, 작업을 따라가는 맥락이 없어 결국 비효율적으로 다가올 수 있습니다.

슬랙과 같은 메시징 플랫폼을 비공식적인 커뮤니케이션에만 사용하기 위해 조직을 결집시키는 것은 어렵겠지만 확실히 노력할 가치가 있습니다. 그렇지 않으면 사람들이 업데이트, 정보 및 리소스 등을 위해 서로 끊임없이 핑하는(슬랙과 같은 플랫폼에서 다른 사람을 테그하거나 메시지를 보내는 활동) 패턴이 발행하고 혼란스러운 상황이 발생할 것 입니다.

차분한 접근 방식

기업이나 리더들은 주로 현실적인 두려움에 직면하게 되는데요. 핸드북에 전념하고 문서화를 하는 문화를 심어주는 것이 실제로 성취하기에는 너무 큰 과제라고 느껴지기 때문입니다. 여기서 중요하게 알아 두어야 할 점은, 목표는 회사의 존재를 알리기 전에 핸드북을 완성하는 것이 아니라는 것입니다.

설립된 조직의 경우, 기업 내에서 핸드북을 도입하는 문제에 반복을 적용하는 것이 요령입니다. 적절한 인프라를 구축하고 한 번에 하나씩 프로세스 문서화 작업을 시작합니다. 기업이 성장하기 시작한 지 얼마 되지 않아 핸드북을 만드는 것은 어려운 일일 수도 있습니다. 비즈니스 규모에 맞게 운영하면서 프로세스와 문화를 모두 바꾸고 있기 때문입니다. 그러나 훌륭한 리더는 핸드북에 문서 작성을 쉽게 할 수 있도록 기대치를 관리할 수 있습니다.

문서화는 지속되는 활동임을 인지

핸드북과 문서 작성은 완성되거나 하는 것이 아니라 끊임없이 지속적으로 해야 하는 일입니다. 그들은 진화하고 원격으로 포괄적이라고 느끼기까지 몇 달 또는 몇 년이 걸릴 수 있습니다.

위기가 닥쳤을 때 문서 작성 계획을 포기하려는 충동을 억제해야 합니다. 가장 강력한 문서는 실패에서 파생된 문서입니다. 실패에서 배운 교훈은 앞으로 피해야 할 사항과 더 나은 운영 방법에 대한 중요한 로드맵을 제공합니다.

회사 핸드북에 들어가야할 내용

그렇다면 회사의 핸드북에는 어떤 내용이 들어가야 할까요? 아래에 나온 사항을 최고 수준의 조직을 위한 초기 지침으로 고려하되, 회사의 규모, 범위 및 요구에 따라 다양한 내용을 추가하는 것도 생까해 보아야 합니다.

기업 & 빌딩 블록 (company & building block): 이 섹션에서는 조직의 대부분 또는 모든 부서에 적용되는 정책, 가치, KPI/OKR 및 문화 원칙을 설명합니다.

회사의 창립 스토리 및 이력
미션, 비전 및 가치
우리의 고객 (고객 페르소나)
우리가 다른 이유 (독특한 차별화 요소)
연간 목표
제품 원리
채용 방법

그룹 & 부서: 부서별로 핸드북의 나머지 부분을 작성하고 필요한 정보를 추가할 수 있습니다 (예: HR, 엔지니어링, 마케팅, 영업, 재무, 제품, 법률 등).

조직 구조
구성원 프로필
팀 프로필

일과 (The day-to-day)

정책
커뮤니케이션 방법
사용하는 도구 (tools)
표준 작동 절차
월별 또는 분기별 목표

처음에는 대부분의 섹션이 비어 있을 수 있지만 반복적이고 의도적으로 문서화를 실행하는 것이 중요합니다. 각각의 섹션이 얼마나 가벼운지 판단하기보다는 기여자가 이전보다 더 낫게 만들었다고 칭찬하는 것이 중요합니다.

편집 Flexwork

참고 Gitlab