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