대부분의 사람들은 메일을 작성할 때 마음과 메일을 읽을 때 마음이 다르다. 메일을 작성할 때는 사람들이 나의 의도를 정확하게 이해하고 나아가 동의하기를 원한다. 사람들의 이해를 돕고자 중요한 내용은 굵은 글씨체로 강조하기도 한다. 그러나 다른 사람이 작성한 메일을 읽을 때는 이야기가 달라진다. 메일 내용에 집중하기 힘들고, 집중해도 어떤 내용인지 파악하기 힘든 경우가 많다. 많은 첨부를 보고 ‘이 많은 파일을 모두 읽으라는 건지?’라는 생각도 든다.
내가 보낸 메일을 사람들이 이해할 것이라고 믿고 말하면 실수하기 쉽다. 예를 들어 회의석상에서 프로젝트 관리자가 “지금 물어보시는 내용은 제가 보낸 메일에 다 있는 내용입니다.”라고 말하면 회의에 참석한 이해관계자들은 프로젝트 관리자를 ‘이기적이고 공감능력이 부족한 사람’으로 평가할 것이다. 혹시 “메일을 읽지 않고 회의에 참석하셨습니까?”라고 말하면 그야말로 최악이다.
프로젝트 관리자는 90% 이상의 시간을 의사소통에 사용하기 때문에 소통역량이 중요하다. 소통의 수단은 메일, 메신저, 전화, 화상회의, 대면 등 다양하지만 소통의 기본은 같다. 상대방의 마음에서 출발하는 것이다. 상대방의 마음을 먼저 헤아린 뒤 소통할 메시지와 소통방법을 정하면 전하고 싶은 메시지를 성공적으로 전달할 가능성이 높다. 메일을 활용하는 소통을 잘하기 위해서는 두 가지 관점에 유의해야 한다.
회의 일정, 회식 일정과 같이 간단한 내용은 메일로 정확한 내용 전달이 가능한다. 그러나 얼굴을 보고 설명해도 소통이 어려운 보고서 설명, 복잡한 백데이터 요청을 메일로 전달하고 상대방이 정확하게 이해하길 바라는 것은 무리한 욕심이다. 물론 현실에서는 소통의 난이도가 중간인 내용이 많다. 보고서 검토의견, 중간보고 준비를 위한 책임과 역할 정의가 그 예이다. 상대방은 내가 다른 사람의 메일을 읽는 것과 비슷하게 나의 메일을 읽는다.(여기서 나는 평균적인 사람이다)
대부분의 사람들은 매일 많은 메일을 수신하고 그 메일을 다 읽지 않는다. 깜빡하고 메일을 읽지 않을 수 있지만, 중요하지 않다고 판단하는 메일은 의도적으로 개봉하지 않는다. 따라서 메일을 꼭 읽어봐야 하는 사람이 메일을 개봉하지 않았다면 메신저로 시간 될 때 메일 개봉을 부탁한다.
내용이 단순하고 짧은 메일은 예외이겠지만 대부분의 메일은 집중해서 읽기 힘들다. 메일을 보낸 사람의 의도와 상관없이 메일을 읽는 사람이 관심 있는 내용을 스캔하듯이 읽고 내용을 이해한다. 필자의 경험으로는 회의 내용을 요약하는 메일이 아니고 업무 설명 또는 협업을 요청하는 메일은 메일만으로 내용을 어느 정도 정확하게 이해하는 사람이 30%를 넘지 않는다. 메일을 보낸 뒤 사람들이 메일의 내용을 이해했다고 생각하는 것은 메일을 보낸 사람의 자만이다.
메일의 내용을 이해하는 것과 동의하는 것은 다르다. 팩트 공유만이 목적이라면 동의까지 필요하지 않지만 업무협조나 협업을 위한 메일은 동의가 필요하다. 많은 사람들이 자기만의 논리에 몰입하여 메일 내용의 이해와 동의를 같은 것으로 생각한다. 메일만으로 업무에 대해 동의하는 것은 애초 기대하지 않는 것이 좋다. 동의가 필요한 업무를 추진할 때 메일은 보조수단으로 활용해야 한다. 회의 결과를 요약하거나, 회의취지나 검토자료를 회의 전에 공유하는 용도로만 메일을 사용해야 한다. 프로젝트 업무에서는 메일만으로 사람들이 나의 의도에 공감하는 것은 불가능에 가깝다.
상대방이 나의 의도를 잘 이해하고 공감하기를 바란다면 상대방을 고려하여 메일을 작성해야 한다. 메일과 일반 보고서의 공통점은 제외하고 메일만이 가지는 특수성을 고려한 유의사항은 다음과 같다.
특수한 경우 메일을 보는 사람이 을의 입장이 되기도 하지만, 대부분 메일은 보내는 사람이 을의 입장이다. 따라서 메일을 읽는 사람의 시간을 절약해주기 위해 메일을 간결하게 작성하고 읽기 쉽게 작성해야 한다. 간결한 메일을 작성하기 위해서는 노트북 기준으로 메일 본문에 스크롤을 만들지 않아야 한다. 모바일로도 메일을 많이 보는 추세이기 때문에 메일 내용의 간결함은 정확한 내용 전달에 있어 매우 중요한 요소이다.
메일을 간결하게 작성하기 위해서는 두괄식으로 메일을 작성해야 한다. 협조를 요청하는 메일은 요청 내용을 구체적으로, 현황 분석 결과를 공유하는 메일은 분석 결과를 요약해야 한다. 요약을 잘하는 사람이 아니라면 간결한 메일을 작성하기 위해 여러 번 검토하고 수정하는 방법밖에 없다. 모든 메일을 이렇게 노력하여 작성할 필요는 없다. 그러나 프로젝트 관리자에게 큰 영향을 미치는 내용을 전달하는 메일은 핵심 내용을 간결하게 요약하기 위해 노력해야 한다.
핵심 내용을 다시 요약한 것이 메일의 제목이다. 가장 좋은 제목은 구두로 보고할 때 첫마디와 같다. 예를 들어 ’ 00 프로젝트 일정 지연 만회대책을 보고 드립니다.’와 같은 문장이다. 물론 제목이 길어 잘린다면 ‘00 프로젝트 일정 지연 대책 보고’와 같이 줄일 수도 있다.
날짜는 숫자로 적는 것이 명확하다. 상대방이 메일을 언제 개봉할지 모르기 때문이다. 메일을 작성하는 사람은 메일 발송일을 기준으로 내일이라고 했지만 메일을 개봉하는 사람에게 내일은 혼란스럽다.
메일을 읽을 때 주로 사용하는 디바이스(모바일, 노트북, 태블릿)와 메일 수신자들의 연령대를 고려하여 한 줄의 길이와 글자크기를 결정해야 한다. 메일의 주요 수신자가 모바일을 자주 사용하는 50대의 경영층이라면 메일 발송 전에 본인의 휴대폰으로 내용을 확인하는 것이 좋다.
읽기 쉬운 문장은 구두로 읽었을 때 호흡이 자연스럽다. 메일을 보내기 전에 메일 내용을 소리 내어 읽어보고 호흡이 부자연스러운 문장이 있다면 수정한다.
상대방이 보낸 메일 내용에 대해 논쟁하는 메일을 답장으로 보내는 것은 금기사항이다. 논쟁할 일이 있다면 전화나 대면이 좋다. 문자로 논쟁하면 근거가 남기 때문에 나의 의도와 다르게 내가 작성한 답변이 편집되어 유통될 수 있다. 많은 사람이 수신하는 메일에서 프로젝트 관리자의 의견을 비난하는 내용이 있더라도 바로 답장을 하지 않는 것이 유익하다. 사람들은 의외로 그러한 논쟁에 관심이 없다. Re:re:re로 시작되는 핑퐁식의 논쟁은 사람들을 피곤하게 하거나 프로젝트 관리자의 리더십을 훼손시킬 뿐이다.
메일을 발송한 후 중요한 이해관계자는 전화나 메신저로 메일 내용에 대한 상대방의 의견을 청취한다. 메일로는 답장하지 못했지만 개별적으로 문의하면 피드백을 받을 수 있다.
김병호 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.