절차에 대한 의사소통

제목에 포함된 ‘무엇무엇에 대한’이라는 말을 기준으로 앞에 오는 단어와 뒤에 오는 단어의 순서를 바꾸면 완전히 다른 의미를 가지는 제목을 만들 수 있습니다. 가령 ‘절차’와 ‘의사소통’의 위치를 바꾸면 ‘의사소통에 대한 절차’로 바꿔 약간 어색하긴 하지만 완전히 다른 의미를 가진 제목이 됩니다. 보통 의사소통 방법, 의사소통의 절차 같은 이야기를 많이들 하는 분위기여서 그런 의미로 오인될 수 있을 것 같아 이런 이야기를 하고 있는데 이 글을 통해 이야기하고자 하는 것은 ‘절차에 대한 의사소통’이 맞습니다. 절차는 어떤 일을 수행하는 순서나 방법을 의미하는데 바로 이 절차를 여러 사람들 사이에 전달하는 의사소통을 수행할 때 지향하는 방법과 절대적으로 지양하는 방법에 대해 이야기할 작정입니다.

오래 전 사전 정보가 충분하지 않은 상태로 어떤 개발팀에 조인했다가 화들짝 놀라 도망친 적이 있는데 이 과정은 도저히 어떤 경력으로 인정해 달라고 말할 수 없을 것 같아 이력서에도 기입하지 않습니다. 이후 다음 구직을 할 때 경영진으로부터 이력 사이에 빈 기간이 약간 길어 보여 이 기간에 대한 설명을 요구 받은 적이 있었고 이 때 겪은 이야기를 할 수밖에 없었는데 이 이야기는 경영진과 면접 중이라는 사실을 깜빡 한 채 긴 한숨으로 시작할 수밖에 없었습니다. 그 시점까지 제가 일하며 겪은 사람들이 어느 정도 업계에서 평균적으로 만날 수 있는 사람들이라고 생각해 왔습니다. 그 때도 종종 다른 회사에서 일하시는 분들과 만나 이야기하다가 제 경험과 이 경험에 기반한 함께 일할 분들에 대한 요구사항을 이야기하다 보면 종종 ‘너는 눈이 너무 높은 것 같다’는 평가를 받곤 했습니다. 하지만 제가 그 시점까지 함께 일해 오며 만난 거의 모든 분들은 제 눈이 높다고 하기에는 너무 당연하게 제가 마음속으로 생각한 기대를 충족하셨기 때문에 업계에 그렇지 않은 분들이 존재할 수도 있다는 사실 자체를 생각해본 적이 없었습니다. 그런데 사전 정보가 부족한 상태로 조인을 결정했던 그 개발팀에서 제가 가지고 있던 생각이 얼마나 좁은 시야와 얼마나 부족한 경험에 기반한 것인지 절실하게 느낄 수 있었고 지금도 비슷하지만 당시 제가 할 수 있는 역할과 수준으로는 도저히 앞으로 나아갈 수 없다는 판단을 내리고 빠르게 도망칩니다. 시간이 지난 다음 어느 병원에서 건강검진을 위해 환자복을 입고 복부초음파 대기 공간에 앉아 있다가 그 팀에서 만났던 분과 스쳐 지나갔는데 애써 서로를 외면했습니다.

그 프로젝트에서 짧은 기간에 걸쳐 제 기준에서는 ‘황당한' 경험을 여러 가지 했습니다. 가령 엑셀 데이터시트의 맨 첫 칼럼에는 딱 봐도 엄청나게 긴 숫자로 된 아이디가 늘어서 있었는데 자주 사용하는 데이터에 대한 접근성을 저해하고 있었습니다. 가령 전통적으로 엑셀 데이터시트에 기입한 숫자를 그대로 인게임에서 사용하는 시나리오에서 자주 사용하는 아이템이나 자주 사용하는 스킬을 개발환경에서 사용하다 보면 이들의 번호를 외우게 됩니다. 가령 어떤 프로젝트의 개발환경에서 체력을 1로 만들어 죽는 동작을 테스트 하기 위해 만든 포션은 37번 아이템이었는데 이를 의도적으로 외우려 하지 않았지만 너무 자연스럽게 죽는 상황을 테스트하기 위해 37번 아이템을 인벤토리에 추가하는 커맨드를 입력하고 있었습니다. 나중에는 이렇게 숫자를 외우기보다는 아예 숫자로 된 아이디에 대응하는 일종의 별칭을 만들어 개발환경에서 커맨드에 숫자로 된 아이디 대신 문자로 된 별칭을 입력하게 만들어 테스트 환경의 접근성을 올리기도 합니다. 그런데 그 프로젝트에서는 모든 숫자로 된 아이디가 열 자리도 넘어 도저히 작업을 반복하며 익숙해질 수가 없었습니다. 그때까지 이렇게 개발된 이유를 여러 사람들에게 물었지만 아무도 그런 히스토리를 기억하지 못했는데 시간이 지난 다음 생각해보면 또 다른 프로젝트에서 겪은 적 있는 겹치지 않는 UID를 수동 생성하는 요구사항 때문이 아니었을까 싶습니다. 기술적인 필요에 의해 겹치지 않는 아이디를 요구하면서도 이를 인간이 직접 관리하는 상황이었으리라 생각하는데 이는 기술적으로는 무난한 접근이었을 수 있지만 우리들의 테스트 퍼포먼스를 크게 저하합니다.

또 테스트를 위해 개인 서버를 사용할 수가 없었는데 멀티플레이 온라인 게임을 개발하면서 내가 방금 추가 및 수정한 데이터에 기반해 빠르게 서버와 클라이언트를 실행해 테스트를 할 수가 없었습니다. 프로젝트의 공식 절차는 데이터를 수정하고 나면 데이터가 의도에 맞게 동작하는지, 혹시 빌드를 망가뜨리지는 않는지 테스트가 안 된 상태로 일단 형상관리도구에 커밋 한 다음 이를 기반으로 프로젝트 공용 서버를 재시작하고 또 이 데이터에 맞는 클라이언트를 다시 업데이트 해서 테스트 해야만 했습니다. 제가 처음 이 상황과 마주했을 때는 단순한 데이터 수정이어서 이 절차를 따르기는 했지만 조금만 데이터가 복잡해져도 테스트 안 된 데이터의 커밋으로 인해 모든 사람들의 개발환경을 망가뜨릴 가능성이 있었습니다. 며칠 이런 방식으로 테스트 없는 데이터를 커밋하고 공용 서버가 재시작 되기를 기다리며 느릿느릿 테스트를 수행하다가 답답해서 왜 이런 절차를 따르고 있는지 여러 사람에게 질문했는데 이번에도 대부분은 이런 절차를 따르면서도 왜 이런 절차가 수립되었는지에 대해서는 알고 있지 않았고 또 딱히 관심이 있어 보이지도 않았습니다. 하지만 누군가는 이전에는 그렇지 않았다고 이야기하며 이전에 일했고 지금은 팀에 없는 누군가가 개인 서버에서 테스트를 진행하며 커밋 된 버전과 데이터 차이가 너무 크게 벌어진 상황에서도 테스트를 마친 데이터를 형상관리도구를 통해 공유하지 않아 큰 문제가 일어난 적이 있어 그 다음부터는 아예 테스트 없이 일단 수정을 형상관리도구에 반영하도록 절차를 수정했다는 설명을 듣습니다. 대략 어떤 상황이었을지 짐작은 되지만 문제를 해결하기 위해 사용한 방법은 제 입장에서 너무나 극단적이어서 암만 생각해도 그렇게까지 할 일이었나 싶었지만 이 절차를 제가 옳다고 생각하는 모양으로 수정하려면 얼마나 큰 어려움이 있을지 잠깐 생각해본 다음 이런 의문을 다시 가지지 않기로 합니다.

또 다른 당황스런 경험이 바로 이 글의 제목인 ‘절차에 대한 의사소통’에 대한 것인데 게임에 신규 캐릭터를 추가하기 위해서는 여러 가지 데이터를 준비해야 했습니다. 당시에 만들던 게임은 모바일 기계에서 돌아가는 몬스터헌터 비슷한 형식이었는데 다양한 플레이 특성을 가진 여러 캐릭터를 선택해 플레이 할 수 있었습니다. 캐릭터 추가가 잦았지만 캐릭터 하나를 추가하기 위해서는 아주 다양한 데이터를 준비해야 했기 때문에 신규 캐릭터를 온전히 추가하고 인게임에서 첫 번째 플레이 테스트를 할 수 있는 상태에 도달하기까지 꽤 복잡한 절차를 거쳐야 했습니다. 가령 언리얼 에디터 환경에서 신규 캐릭터가 사용할 여러 에셋과 데이터를 기록할 약속된 경로에 디렉토리를 만드는데서 시작해 여러 에셋을 형식에 맞게 준비하고 이 에셋들에 기반해 데이터 에셋을 만들고 이들의 존재를 서버가 알 수 있도록 엑셀 데이터시트에 이들이 추가되었다는 사실을 기입하고 또 캐릭터마다 다른 동작 방식에 기인한 서로 다른 애니메이션 시스템을 준비해야 합니다. 이 절차를 온전히 알고 있는 사람은 프로젝트 전체에 딱 한 명 뿐이었는데 이 절차가 복잡하고 이해하기 쉽지 않다는 사실은 이 절차를 알고 있는 사람이 한 명 뿐이라는 사실을 전해 듣기 이전부터 예상할 수 있었습니다. 여러 캐릭터를 적극적으로 테스트 해 플레이를 도출해야 하는 상황임에도 게임에는 이상할 정도로 테스트에 사용할 캐릭터가 없었습니다. 모두 실제 사용할 캐릭터만 인게임에서 사용할 수 있고 이들과 다른 형식의 플레이를 테스트하기 위한 캐릭터가 없었는데 이걸 보고 캐릭터를 추가하는 과정이 그리 사용자 친화적이지 않을 거라고 예상합니다.

이윽고 저는 아직 존재하지 않는 플레이 패턴을 인게임에서 테스트 해 보기 위해 제 의도를 반영한 캐릭터를 만들어 보기로 했고 이 의사를 전해 들은 프로젝트에 전체에서 유일하게 신규 캐릭터 데이터를 추가해 인게임에서 접근 가능한 상태로 만드는 절차를 알고 있는 분으로부터 절차를 배우기로 합니다. 제가 기대한 진행은 이 절차가 기입된 문서 위치를 공유 받는 것이었지만 그런 일은 일어나지 않았습니다. 만약 그 절차가 문서로 만들어져 있었다면 팀에 그 절차를 아는 사람이 한 사람 뿐일 리도 없고 또 복잡한 절차라도 일단 문서 모양으로 만들어지면 절차에 익숙해진 사람 관점에서 어지간한 절차는 그리 복잡하지 않은 모양으로 인식됩니다. 또한 문서를 통해 여러 사람들에게 절차가 퍼지면서 절차가 개선될 여지도 많아집니다. 하지만 절차가 복잡하고 이를 온전히 수행할 수 있는 사람이 프로젝트에 한 명 뿐이라는 사실은 이 절차가 문서화되지 않았거나 문서화가 잘 유지되지 않아 쓸모 없는 문서가 있을 뿐일 가능성이 높았고 어느 정도 이상한 일을 겪을 각오를 하고는 있었습니다. 어느 날 오후 한참 졸릴 시간에 회의 일정이 잡혔고 회의에 들어가 보니 회의실 모니터에 원격으로 접속한 이 절차를 설명해주실 분의 컴퓨터 화면이 떠 있었습니다. 이 절차의 최신 상태는 문서화 되어 있지 않을 뿐 아니라 그때그때 조금씩 변경됨에 따라 먼 과거에 마지막으로 작성된 문서는 현재의 절차를 전혀 반영하고 있지 않았습니다. 저는 자리에 앉아 모니터를 바라보며 그 분이 새 캐릭터를 추가해 가는 과정을 보여주시는 모습을 지켜봤고 중간 중간 뭔가 메모를 했지만 한참 설명을 들으면서도 각각의 절차가 가진 목적을 이해할 수 없어 절차 전체를 통합해서 이해하는데 실패하고 있었습니다.

중간에 살짝 졸았지만 다행히 들키지는 않았고 설명이 처음 시작되고 나서 약 40여분이 지날 무렵 드디어 테스트 데이터에 기반한 새 캐릭터가 인게임에 나타납니다. 저는 지금까지 40여분에 걸쳐 살펴본 과정을 모두 기억하고 각각의 과정에 따르는 주의사항을 다 외웠으며 지금 당장 자리에 돌아가 이 절차에 따라 신규 캐릭터를 만들 수 있을 것 같은 자세를 취했지만 실상 처음 한 15분 정도 설명을 따라가다가 그 다음부터는 설명을 따라가기를 포기하고 그냥 멍하니 모니터를 바라보고 있었을 뿐이었습니다. 개인적으로 절차를 이해하기 위해서는 전체 과정을 구성하는 각각의 절차를 목적 단위로 이해해야 한다고 생각합니다. 그러면 어지간히 복잡해 보이는 절차도 각각의 세부 목적을 달성하는 각각의 과정으로 이해해 긴 절차를 그렇게까지 길지 않은 각각의 세부 절차 별로 이해할 수 있어 무턱대고 전체 과정을 외우지 않더라도 자연스럽게 목적에 따라 다음 절차를 이끌어낼 수 있습니다. 하지만 이 날 제가 보고 들은 설명은 긴 절차가 목적에 따라 잘 분류되어 있지 않아 애니메이션 에셋을 준비하다가 갑자기 전혀 다른 맥락의 데이터를 입력하는 등 도무지 각 절차의 목적을 이해할 수가 없었습니다. 작업을 해 보고 모르는 것이 있으면 물어봐 달라는 그 분의 말로 회의를 마친 다음 자리로 돌아와 그냥 다른 일을 했고 저는 캐릭터를 만들어볼 시도를 아예 하지 않았습니다. 대신 그 날의 당혹스러움을 뒤로 하고 하루 자고 나서 다음 날 다른 캐릭터 데이터를 통째로 복사한 다음 이 데이터를 수정해 제 목적을 달성하기 시작합니다. 그 분은 드디어 절차를 알고 있는 사람이 두 명이 되어 기뻐하는 것 같았지만 실상은 전혀 그렇지 않았습니다. 저는 이 프로젝트로부터 도망치기 전까지 테스트 캐릭터 데이터를 만들어 다른 플레이를 개발하고 있는 것처럼 행동했고 실제로도 그랬지만 그 데이터는 바닥부터 만들어진 캐릭터가 아니었습니다.

이 경험을 하며 저는 이런 길고 복잡한 절차가 세부 목적 별로 정리된 모양으로 존재하지 않는다는 점에 놀랐지만 다른 한편으로는 이런 절차가 문서화 되어 있지 않다는 사실에도 놀랐습니다. 절차가 복잡하고 세부 목적 별로 정리된 모양이 아니라는 사실은 누군가 이런 긴 절차를 목적 별로 체계화 하지 않는 이상 서로 연관 없어 보이는 항목들의 긴 나열이 될 수밖에 없기 때문에 이해할 수 없지는 않았습니다. 이제부터 제가 이 긴 절차를 이해하고 각각의 절차를 세부 목적 별로 체계화 하면 될 일입니다. 하지만 극도로 중요하게 다뤄야 하고 또 절대로 유출되어서는 안되는 비밀도 아닌데 이 절차를 문서 대신 인간에게 저장해 놓고 또 이 정보를 공유하는 방법 역시 인간에 저장된 절차를 직접 설명하게 만드는 방식이라는 점은 납득할 수 없었습니다.

어떤 유출되어서는 안되는 비밀이 있다면 이를 꽤 안전하게 보관하는 방법은 종이에 기록하거나 컴퓨터에 저장하는 대신 그냥 인간의 머리 속에 저장하는 것입니다. 중요한 정보를 저장하는데 이 방법이 꽤 유용하다는 점은 영화 ‘미션임파서블 로그네이션’의 한 장면을 보면 이해할 수 있는데 비밀 자금을 획득할 수 있는 방법을 디스크에 기록하면 이 디스크를 물리적으로 안전하게 보관해야만 합니다. 하지만 이를 사람 머리 속에 보관해 버리면 그 사람을 통하지 않는 이상 현대 기술로는 그 정보에 온전히 접근할 방법이 없습니다. ‘코리안 구글’ 같은 접근을 시도할 수 있겠지만 정보를 획득하려다가 정보 전체를 망가뜨릴 위험을 감수해야만 합니다. 하지만 캐릭터를 추가하는 절차는 그런 대단한 정보가 아닙니다. 기껏해야 대외비 수준의 정보에 불과합니다. 굳이 사람 머리 속에 안전하게 보관할 이유가 없으며 이런 보관 방법은 오히려 프로젝트 전체의 효율을 심각하게 훼손합니다.

당연히 이 절차를 문서에 기록해 달라고 요구할 수 있었겠지만 이미 이 즈음에 이 프로젝트로부터 겪은 여러 가지 경험을 통해 그 전까지 제가 이 업계에 종사하는 사람들에 대해 가지고 있던 제 마음속의 기대와 요구가 완전히 망가진 상태였고 이 상황에서 프로젝트를 정상적으로 이끌어 가기 어렵겠다는 결론에 도달하는 중이었습니다. 그래서 문서를 만들어 달라고 말하는 대신 조용히 제 방식으로 문제를 해결했고 머리 속에 들어있던 정보를 복제한 두 번째 사람이 되기를 거절합니다. 프로젝트를 떠난 다음 이 팀에서 겪은 여러 에피소드는 그동안 제가 업계에서 일하는 동안 운이 얼마나 좋았는지 깨닫게 해 주었습니다. 온라인에서 만나는 여러 사람들은 다들 능력 있고 성실하고 또 자신의 일에 열정을 가지고 있는 것처럼 보입니다. 또 지금까지도 제가 참여하는 프로젝트로부터 함께하는 아주 많은 사람들은 그 일을 하기에 충분한 전문성을 가지고 있을 뿐 아니라 나날이 복잡해지고 또 변화하는 요구사항에 대응할 수 있도록 각자가 고민하고 또 각자의 고민을 서로 교환하며 나쁘지 않은 속도로 발전하고 있습니다. 하지만 어딘가에는 그렇지 않은 사례도 있으며 그렇지 않은 너무 많은 사람들이 한 자리에 모여 있을 때 상황을 해결하기 대단히 어렵고 또 오히려 제가 이상한 사람으로 지목될 가능성이 있음을 배웁니다. 선입견은 대체로 좋은 결과로 귀결되지 않지만 이 때의 경험을 통해 이후 구인을 위해 이력서를 살펴볼 대 특정 조합의 이력 조합에 몸이 본능적으로 반응하는 썩 유쾌하지 않은 흔적을 저에게 남깁니다. 그리고 이후 절차에 대한 의사소통에 철저하게 지키고 또 저와 함께 하는 모든 사람들이 지키도록 요구하는 원칙을 정립했습니다.

최근 다른 부서에서 요구하는 테스트 환경을 구축해야 할 일이 생겼는데 누군가에게 요청할 수도 있었겠지만 웬만하면 제가 그 절차를 직접 경험해 봐야 할 것 같았습니다. 그럭저럭 잘 구축된 개발환경이라면 이런 절차는 그렇게 복잡하지 않을 테고 또 여느 다른 프로젝트와 크게 다르지도 않을 가능성이 높습니다. 또한 그럭저럭 잘 구축된 개발환경이라면 그 절차를 설명하는 온전한 문서가 있을 가능성이 높다고 예상할 수도 있습니다. 그런데 회사 컨플루언스를 한참 검색해 보다가 그 절차가 정리되어 있기는 하지만 최신 상태는 아니며 서로 다른 시점에 일한 서로 다른 사람들에 의해 여러 차례에 걸쳐 절차를 정리하고 최신화 하려는 시도가 있어 왔다는 사실을 알게 됩니다. 하지만 그들의 노력에도 불구하고 여러 사람에 의해 개발이 진행되는 동안 절차는 조금씩 변경되어 매뉴얼과 실제 절차 사이에 차이가 생겨 최신 절차는 오래 전 경험과 마찬가지로 여러 사람들의 머리에 분산 저장된 상태였습니다. 그래서 팀의 누군가에게 최신 절차를 알려달라고 했는데 그 분은 제 쪽으로 걸어오셔서 시간 괜찮으시면 지금 알려드리겠다고 말씀하셨는데 이 행동의 선의를 이해하지만 머릿속에 빨간불이 켜지며 그 선의를 받아들여서는 안된다는 오래된 본능이 발동합니다.

비록 저는 지금 아무런 직책도 담당하고 있지 않지만 이제 나이 먹어서 미친개처럼 하지 않아도 됩니다에 설명한 대로 과도하게 공격적으로 행동할 필요가 없다는 사실을 이해하고 있습니다. 다만 평소 같으면 절대 사용하지 않을 단어인 ‘절대’를 사용해 절차를 전달할 때 저는 절대 구두 의사소통에 응하지 않는다고 설명하고 또 이 의사소통은 반드시 문서를 통해야만 하며 저는 문서 모양으로 된 절차만 접수할 거라고 설명했습니다. 그리 오랜 시간이 걸리지 않아 여러 사람들로부터 각자의 머리 속에 흩어져 있던 작업에 필요한 몇 가지 절차가 정리된 문서를 얻을 수 있었습니다.

모두에게 감사한다고 말했지만 사실은 이 글을 쓰는 지금까지 그 문서들을 살펴본 것은 아닙니다. 다른 우선순위가 더 높은 일이 있어 한 주 정도 그 일에 더 집중해야 할 것 같았기 때문에 제가 ‘절차를 절대 구두 의사소통 하지 않는다’며 심각하게 행동한 결과 모두를 약간 겁 먹게 만들어 빨리 문서를 획득한 것 치고는 그들의 속도에 어울리는 속도로 그 일을 진행하지는 않고 있습니다. 또한 직접 그 모든 절차를 경험해 보고 결과를 내고 절차에 대한 최소한의 전문성을 확보해야만 그 절차를 다른 프로젝트를 수행하던 경험으로부터 유추하기 어려웠던 원인을 알아내고 또 가능하다면 그 절차를 개선할 가능성이 생길 겁니다. 그래서 모두에게는 미안하지만 일을 한 주 이상 딜레이 시킬 예정입니다. 이 상황의 밝은 면을 살펴보면 앞으로 개발을 계속함에 따라 이번에 문서로 만들어진 절차는 또 실제 절차와 차이가 발생하기 시작하겠지만 이번 에피소드를 통해 그 절차가 한번 확실히 좁혀졌고 이 다음 누군가가 이번의 저처럼 컨플루언스를 몽땅 검색해 보고 서로 다른 사람들이 서로 다른 시점에 절차를 정리하려고 시도했던 흔적을 발견할 때 최신 흔적을 제공할 수 있게 됩니다. 항상 빌드가 가장 앞서 나가고 문서들은 빌드의 최신 상태를 따라가는 입장이기 때문에 어느 시점에나 모든 절차를 말끔히 정리한 문서를 유지하기는 거의 불가능합니다. 때문에 누군가 온보딩 하면 처음으로 할당하는 업무에 ‘기존 온보딩 문서의 동작하지 않는 부분을 발견하면 최신 상태로 업데이트 할 것’을 포함하곤 합니다. 아마 이 문서들은 한 주 정도 지난다 하더라도 바로 실제 빌드와 어긋나지는 않을 것 같으니 일단은 괜찮을 것 같습니다.

절차에 대한 의사소통 방법으로 말을 꺼냈고 결론은 팀에서 어떤 절차를 전달할 때 절대로 그냥 말을 통해 한 사람의 머리에 저장된 정보를 다른 사람 머리로 저장하는 일이 일어나도록 방치해서는 안된다는 것입니다. 보통의 인간은 기억력에 뚜렷한 한계가 있고 스스로는 그 모든 절차를 알고 있다고 생각하겠지만 실은 그렇지 않을 가능성이 높습니다. 이런 한계를 알기에 이 한계를 초월할 수 있는 현대적인 기록 수단이 있고 우리들은 컨플루언스 위키를 우리들의 한계를 초월할 정보시스템으로 선택했습니다. 이런 상황에서 절차 뿐 아니라 여러 가지 정보를 전달할 때 말로 전달하는 것은 전혀 좋은 선택이 아닙니다. 사람의 기억은 부정확하고 그런 부정확한 기억에 의지해 하는 말은 더더욱 부정확하고 위험하며 곡해될 수 있는 전달 방법입니다. 회사에서는 이런 우리들의 한계를 이해하기에 비싼 돈을 들여 정보시스템을 제공했고 우리들은 절차 뿐 아니라 어지간한 업무 의사소통에 이 정보시스템을 적극적으로 활용해야만 합니다. 이런 방법은 당장의 정보 전달을 느리게 만들 수 있지만 시간이 조금만 지나면 각자의 머리에 의존하는 정보를 줄이고 같은 정보를 여러 사람에게 전달하기 편하게 만들며 정보가 여러 사람에게 검토될수록 정보의 틀린 점, 최신 상태를 반영하지 않는 부분 따위를 더 쉽게 고칠 수 있게 됩니다.

절차에 대한 의사소통을 할 때 절대 그냥 말을 통해 전달해서는 안됩니다. 말로 그냥 하고 싶은 바로 그 기억을 문서 모양으로 만들어 그 문서 주소를 전달하면 지금 당장은 서로 조금 불편할 수 있지만 당장 며칠만 지나면 그냥 말로 전달할 때보다 훨씬 나은 프로젝트 전체에 대한 생산성 향상에 기여할 수 있습니다. 절차에 대한 의사소통은 반드시 문서를 통해 이루어져야만 합니다.