그냥 알아서 잘 되는 일과 그렇게 만드는 프로세스는 없다

트위터에 항상 강조하는건데 자리에 앉아서 그냥 진행되는 일은 없음. 일이 되고 있다면 누군가 조뺑이 치고 있는 거임이라고 말한 적이 있습니다. 지금 봐도 언어 생활에 문제가 있어 보이지만 이 상황에 마음속으로 가지고 있던 생각이 잘 반영된 결과입니다. 여러 직군에 속하는 사람 여러 명이 섞여서 일하며 동시에 한 가지 프로젝트를 수행하지만 그 프로젝트를 위한 서로 다른 여러 가지 목표를 동시에 수행해야 할 때 각각의 하위 목표들이 잘 달성 되고 있다면 그건 팀이 잘 하고 있어서라기보다는 팀에 속한 개인들 중 누군가가 각각의 목표를 달성하기 위해 서로 다른 직군의 팀원들 사이를 연결해 주고 있기 때문입니다. 여러 사람들을 거쳐야 완성되는 일이 그냥 잘 되는 일은 없습니다.

한번은 다른 부서의 팀장님으로부터 문제 제기를 받았습니다. 본인이 중요하게 생각하던 작업에 의사결정이 필요했는데 이 의사결정이 늦어지면서 의사결정이 어느 한쪽으로 이루어질 것으로 가정하고 진행한 업무가 쓸모 없게 됐다는 것이었습니다. 슬랙을 통해 여러 번 문제를 제기하고 또 여러 번 요청했지만 의사결정이 늦어져 지금과 같은 상황이 일어났고 재작업이 필요한 상황에 흥분해 계셨습니다. 또 이런 상황에 대비해 더 높은 분들에게도 이런 의사결정 업무를 잘 관리할 수 있는 프로세스를 수립해 달라고 요청했는데 그 역시 잘 진행되지 않아 이런 상황에 이르렀다는 말씀도 들었습니다.

일단 흥분한 상대를 대하는 건 어렵지만 또 쉽습니다. 일단 잘잘못은 나중에 생각하고 상황에 공감하면 됩니다. 표면적으로는 의사결정이 늦어진 결과로 재작업을 해야 하는 상황이 일어났고 팀장님 뿐 아니라 나머지 팀원 분들도 상심이 클 겁니다. 이를 이해하고 여기에 알맞는 이야기를 하면 됩니다. 혹시 그 안에 내가 할 수 있는 일이 있었다면 그 일이 일어났으면 좋았겠다고 이야기하며 다독일 수도 있습니다. 사람에 따라 이 틈을 비집고 들어오기도 하는데 그럴 땐 강하게 내동댕이 치면 되지만 그런 경험은 드물었습니다. 자. 다음은 문제 해결의 세 가지 단계를 떠올릴 때입니다. 일단 상황 인식과 문제해결 방안 제시, 다음은 문제해결 방안 실행, 마지막으로 재발 방지 대책 수립 및 실행입니다.

먼저 상황을 인식합니다. 의사결정이 늦어진 것도 맞고 의사결정이 이 업무에 중요했던 것도 맞습니다. 다만 의사결정자들에게 충분히 의사결정의 필요성이 전달되었을까요. 슬랙 같은 도구는 이론 상 타이핑 된 모든 말들이 채널에 포함된 모든 사람에게 전달되어야 하지만 실제로는 결코 그렇지 않습니다. 누군가는 메시지를 보기도 하지만 다른 누군가는 아예 못 보기도 합니다. 메시지를 본 누군가는 본인의 일이 아니라고 생각하고 지나갑니다. 사실 거의 모든 사람들이 이렇게 행동합니다. 그 중 극히 일부가 본인의 일이 아니더라도 당사자로 추정되는 사람들을 찾아 다니며 상황을 인식 시키고 필요한 업무를 수행하게 만듭니다. 이런 사람들이 없으면 채팅 만으로는 일이 쉽게 사라집니다.

의사결정이 필요함을 의사결정 당사자들에게 전달하고 또 의사결정을 진행 시켜야 할 사람은 누구일까요. 팀에 따라 PM이라고 할 수도 있고 또 해당 업무의 기획자라고도 할 수 있습니다. 전통적인 게임 개발팀에서 기획자들은 각 목표의 관리자 역할을 함께 수행하곤 합니다. 대체로 팀 내 의사소통은 이 두 부서 사람들이 담당합니다. 다른 부서에서도 적극적으로 참여하기도 하지만 때로는 수동적으로 일하기도 합니다. 목적 달성 여부에 관계 없이 그렇게 일하면 편하기 때문입니다. 당연한 행동입니다. 이 의사결정을 필요로 하는 본인이 움직이는 것이 가장 이상적입니다. 본인이 움직이는데 어려움이 있다면 위에서 말한 의사소통을 주로 담당하는 사람들에게 직접 도움을 요청할 수도 있습니다. 그러면 그 사람들이 실행할 겁니다. 그렇지만 여전히 실행 과정을 감독하고 의사결정 결과를 입수해 이후 업무를 진행해야 하는 사람은 의사결정을 필요로 하는 본인입니다.

그럼 누구 잘못일까요. 잘못한 사람 본인을 찾는 것은 좋은 접근 방법이 아닙니다. 누군가가 잘못을 하기는 했겠지만 그 잘못을 하게 만든 행동 양식의 부재를 잘못으로 꼽을 수 있습니다. 오랜 업무 경험을 통해 충분히 이런 상황의 업무 절차를 알고 있을 거라고 예상한 사람들도 종종 문제가 생기면 방어적으로 변해 다른 사람이나 다른 부서 또는 프로세스의 부재를 문제로 지적하기도 합니다. 틀린 말은 아니지만 이런 자세는 문제를 해결하는데 도움이 안 됩니다. 잘못한 사람은 이 문제를 재기한 본인입니다. 본인과 본인의 부서에서 수행할 업무에 필요한 중요 의사결정이 필요함을 팀에 알리고 의사결정 진행 과정을 관리 감독하며 결과를 파악해 이를 업무에 반영해 결과를 도출하는데 책임이 있는 자기 자신입니다. 우리들 각각은 프로젝트를 완수하는데 필요한 세부 목표를 달성할 책임이 있습니다. 각자의 책임을 완수하는데 필요한 활동을 위해 프로젝트 전체의 자원을 스스로 요청해야 합니다.

프로세스를 도입해 문제를 해결할 수 있을까요? 전통적인 제조업에서는 이런 프로세스 도입이 대단히 중요하다고 들었습니다. 소프트웨어 프로젝트에서도 이런 절차에 강하게 의존하는 분야들이 있다고 들었고요. 소프트웨어 프로젝트에서 세부 목표를 달성하기 위해 프로젝트 전체의 자원을 끌어내는 일은 상황에 따라 자원의 형태나 범위가 상당히 달라 프로젝트 완수 기간이 끝나기 전에 잘 반복되지 않기도 합니다. 그래서 상황이 발생할 때마다 각 목표를 담당한 책임자들이 협업 부서를 돌아다니며 직접 자원을 끄집어 내야 합니다.

분명 이 과정을 예쁘게 정리하고 굳이 의자에서 일어나 돌아다니지 않는 프로세스가 있을 수도 있습니다. 하지만 프로세스 개발과 실행과 관리감독을 기다려서는 안됩니다. 환경이 어떻든 각 목표의 책임자들은 목표가 달성되거나 달성되지 못하거나에 책임을 질 뿐입니다. 책임을 다른 사람에게 미룰 수는 있지만 책임으로부터 벗어날 수는 없습니다. 그저 자리에 앉아 조용히 진행되어 완수되는 일은 없습니다. 만약 그런 일이 있는 것처럼 보인다면 내가 모르는 어딘가에서 내가 모르는 누군가가 직접 사람과 사람 사이를 오가며 목적 달성에 필요한 자원을 끄집어 내고 있기 때문입니다.