프로젝트 커뮤니케이션 계획은 프로젝트에 관해 누가 무엇을 알아야 하는지, 얼마나 자주, 어떤 채널로, 그리고 누가 책임지고 알릴지를 적은 짧은 표입니다. 제 건 한 페이지에 들어가고, 개발팀부터 CEO까지 대상마다 한 줄씩입니다. 아래에 소프트웨어 프로젝트를 시작할 때 제가 쓸 계획과, 프로젝트 커뮤니케이션이 실제로 돌아가게 하는 것들에 대해 모아 온 메모를 정리했습니다.
제가 수습하러 불려 갔던 프로젝트의 난장판들은 대부분 나쁜 코드 때문이 아니었습니다. 필요한 정보가 너무 늦을 때까지 필요한 사람에게 닿지 않아서였죠. 회사에서 프로젝트 리드를 맡게 된 뒤로 “언젠가 CTO 자리에 앉게 된다면 커뮤니케이션을 어떻게 굴릴까"를 메모해 두고 있는데, 그걸 한번 풀어 봅니다.
누구에게 무엇을 알릴지부터 정하기#
수수하지만 토대가 되는 건 커뮤니케이션 계획입니다. 누구에게 알려야 하는지, 어떤 정보를, 얼마나 자주, 어떤 채널로 전달할지. 프로젝트 시작 시점에 반드시 만들고, 담당자 이름까지 박아 두는 게 좋다고 생각합니다. “모두의 일"이 된 커뮤니케이션은 결국 아무의 일도 아니게 되니까요. 이해관계자도 마찬가지입니다. 이 프로젝트를 진짜 신경 쓰는 사람이 누군지 정리하고, 각자가 선호하는 보고 방식을 파악해 두세요. CEO에게 개발 채널에 올리는 것과 똑같은 업데이트를 보내면 안 됩니다. 그리고 명문화된 규칙 몇 가지. 답장까지 기대하는 시간, 무엇을 “긴급"이라 부를지, 어떤 채널을 어디에 쓸지. “커뮤니케이션 문제"의 실체는 대부분 입 밖에 내지 않은 기대의 엇갈림입니다.
소프트웨어 프로젝트 커뮤니케이션 계획 예시#
제가 일단 이걸로 시작해서 조정해 나갈 계획입니다. 각 줄은 회의가 아니라 대상입니다.
| 대상 | 알아야 할 것 | 빈도 | 채널 | 알리는 사람 |
|---|---|---|---|---|
| 개발팀 | 진행 중인 일, 막힌 일, 코드를 바꾸는 결정 | 매일 | 스탠드업과 팀 채팅 채널 | 테크 리드 |
| 프로덕트 오너 | 스프린트 목표 대비 진척, 범위 관련 질문, 새로 생긴 리스크 | 주 2회, 그리고 범위가 바뀔 때마다 | 짧은 통화나 채팅 스레드 | 프로젝트 리드 |
| 경영진 | 한 줄 현황, 일정이나 예산에 대한 리스크, 경영진이 내려야 할 결정 | 매주 | 한 문단짜리 서면 업데이트 | 프로젝트 리드 |
| 영업, 고객 지원, 운영 | 무엇이 언제 나가는지, 고객 입장에서 무엇이 바뀌는지 | 릴리스마다 | 릴리스 노트 | 프로덕트 오너 |
| 사용자나 고객사 | 새로 생긴 것과 곧 나올 것 | 릴리스마다 | 변경 로그나 앱 내 공지 | 프로덕트 오너 |
| 모두 | 무엇이 결정됐고 왜 그렇게 됐는지 | 결정될 때 | 이슈 트래커나 위키의 결정 로그 | 결정한 사람 |
표 아래에는 프로토콜을 최대한 평이하게 적어 둡니다. 긴급이란 릴리스나 고객을 막는 일이니 메시지 말고 전화할 것. 질문은 채팅에, 결정은 트래커에. 답장은 영업일 기준 하루 안에. 결정 로그로는 의사결정 문서를 쓰고, 이걸 GitHub Issues로 남겨서 작업 바로 옆에 둡니다.
이런 계획이 제대로 돌아가려면 두 가지가 필요합니다. 모든 줄의 마지막 칸에 누군가의 이름이 적혀 있을 것, 그리고 경영진 업데이트는 말이 아니라 글로 할 것. 글로 써 두어야 그대로 전달해도 빠지는 내용이 없습니다.
도구와 리듬#
도구는 사람들이 논쟁하는 것만큼 중요하지 않습니다. 채팅은 Slack, 태스크 관리는 Trello, 얼굴 보고 얘기해야 할 땐 Zoom. 팀에 맞는 걸 고르고 그냥 넘어가면 됩니다. 더 중요한 건 리듬입니다. 애자일로 일한다면 데일리 스탠드업, 호흡이 긴 프로젝트라면 주간 업데이트. 그리고 정한 리듬을 실제로 지키는 것. 기록도 빼놓을 수 없습니다. 결정 사항, 변경 사항, 액션 아이템을 Notion이나 Jira에, 나중에 몰아서 하는 일이 아니라 프로세스의 일부로 남기세요. 6개월 뒤에 남는 기억은 문서뿐입니다.
부드러운 부분이 제일 어렵다#
여기까지는 기계적인 부분입니다. 어려운 건 그다음이죠. 지금의 커뮤니케이션이 정말 돌아가고 있는지 팀에 묻고, 아니라면 바꾸는 것. 팀원 교육도 그렇습니다. 팀에는 다양한 배경의 사람들이 있고, 잘 굴러가는 프로젝트를 본 적이 없는 사람도 있으니까요. 말할 차례를 기다리는 대신 제대로 듣는 것, 갈등은 작을 때 일찍 다루는 것도요. 게다가 이런 문제는 한 번 풀었다고 끝나지 않습니다. 지난 분기에 통하던 방식이 어느샌가 안 통하게 되거든요. 주기적으로 점검하는 수밖에 없습니다.
분산·비동기 개발팀으로 일하기#
팀이 원격이거나 비동기 중심이라면 이 영상은 볼 만합니다.
저도 이걸 전부 완벽하게 하고 있진 않습니다. 그런 사람은 없겠죠. 다만 매끄럽게 굴러갔던 프로젝트에는 이 중 대부분이 갖춰져 있었고, 아팠던 프로젝트에는 최소 세 개는 빠져 있었습니다.