결정교착상태

종종 문서를 작성하다 보면 하위 주제 중 어떤 것은 내가 결정하면 안될 것 같은 느낌이 올 때가 있습니다. 매번 정확한 원인을 판단하지는 않지만 이 결정을 내가 내리기에는 내 경험이나 지식이 부족하거나 이 결정은 내가 속한 부서가 아닌 다른 부서의 권한일 것 같거나 더 높은 분들이 결정해야 할 것 같은 등 다양한 원인이 있을 수 있습니다. 이런 주제는 종종 문서에 결정할 주제만 기입해 놓고 주제 근처에 콜아웃으로 ‘이건 논의가 필요함’이라고 적어 놓고 넘어가곤 했는데 이는 그리 나쁜 방법은 아니었습니다. 문서를 작성하던 내가 바로 결정하기에는 뭔가 더 많은 사람들의 의견을 들어야 할 것 같고 또 누군가 나보다 높은 사람이나 다른 부서에서 딴지를 걸면 결정이 되어 있는 상태보다는 결정이 안 되어 있는 상태가 내 책임을 회피하기에 훨씬 더 유리하기 때문입니다.

하지만 이런 방법은 시간이 흐르면서 나 자신에게는 나쁘지 않지만 프로젝트 전체 관점에서 보면 그리 좋은 습관이 아니라는 생각을 하기 시작했는데 일단 결정이 필요한 주제를 결정하지 않고 놔 둔다고 해서 어느 날 갑자기 결정이 되지는 않으며 결정을 요청 받은 다른 부서나 다른 높은 분들이 결정을 바로 내릴 만큼 시간을 바로 확보할 수 있지도 않았기 때문입니다. 또 내가 결정을 다른 사람이나 다른 부서에 미룬 것 처럼 다른 사람들 역시 똑같은 행동을 할 가능성이 높기 때문에 기획서에 포함된 결정이 필요한 사항은 이 결정을 내릴 권한이 있는 사람들의 손을 지나면서도 결정되지 않는 상황이 더 자주 일어납니다.

이렇게 결정되지 않은 사항은 나중에 모든 팀이 모여 협업을 시작하는 순간까지도 확정되지 않아 브리핑 하는 자리에서 결정이 필요한 사람들과 결정 권한이 있는 다른 사람이나 부서들이 서로 상대방의 얼굴을 바라보며 아무 말도 안 하는 상황을 겪게 만들기도 합니다. 개인적으로는 이런 상황을 결정교착상태라고 부르는데 누군가 첫 결정을 하기 전까지는 서로 결정을 할 수 있을 것 같은 서로 다른 부서의 눈치만 보며 아무 행동도 나서서 하지 않는 상태를 말합니다. 프로젝트 전체 관점에서 결정 권한을 가진 주체들이 결정되지 않은 사안 뒤로 쉽게 숨을 수 있는 여지를 남겨 두면 내 마음도 편하고 다른 사람들 마음도 편하겠지만 프로젝트 전체 관점으로 보면 의사결정 자체와 이 의사결정에 의존하는 개발이 밀리고 있다는 의미로 결코 좋은 상황이 아닙니다.

다행히 시간이 흐르며 개발팀 안에서 아주 작은 입지를 점할 수 있게 된 다음부터는 의도적으로 문서에 결정이 필요한 사항을 남겨두지 않으려고 하고 있습니다. 이렇게 말하면 그럴 듯 해 보이지만 있는 그대로 까 놓고 이야기하면 내가 결정하면 안 될 것 같은 사항이라도 내 기획서에 포함되어야 하면 어떤 방향으로든 일단 내 스스로가 옳다고 생각하는 방법을 미리 결정하고 그 방법을 제안하는 단계까지 기획서를 미리 작성해 놓는다는 이야기입니다. 이 의사결정을 해야 하는 다른 사람 관점에서 보면 기획팀 김아무개님이 내가 결정해야 하는 항목을 자기 멋대로 결정해서 이미 기획서에 적어놨다고 받아들일 수도 있고 실제로 몇몇은 그렇게 받아들이기도 합니다. 물론 이렇게 받아들인 분은 내가 그 사실을 알게 되는 시점부터 결코 그 분이 해야 하는 의사결정에 해당하는 부분을 내 멋대로 미리 작성하지 않았는데 그러면 그 분이 포함된 일이 진행되는 속도가 다른 일에 비해 현저히 느려지는 상황을 겪게 됩니다.

다른 부서에서 결정해야 할 것 같아 보이지만 내 생각에 먼저 결정하고 제안할 수 있을 것 같아 보이는 일은 내 스스로 판단해 제안을 만들어 놓습니다. 그렇게 판단하기 조금 더 어려운 주제는 미리 의사결정을 해야 할 것 같은 분을 직접 찾아 가서 상담을 하기도 하지만 이런 사례가 많지는 않습니다. 이렇게 미리 의사결정을 해 두면 그 의사결정이 잘못 되었더라도 아무것도 안 해 놓을 때에 비해 일을 빨리 처리할 수 있습니다. 그 의사결정이 가능한 사람이나 부서 구성원이 문서를 보고 그게 잘못 되었음을 빠르게 눈치 챌 뿐 아니라 이미 결정이 되어 있는 것 처럼 보이기 때문에 당장 개입해 문제를 바로 잡아야 한다고 생각하게 만들기 때문입니다.

또 결정을 바닥부터 할 때에 비해 이미 제안 모양으로 만들어져 있으면 제안의 잘못된 점을 지적하는 방식으로 의도한 의사결정 상태에 더 빨리 도달할 수 있기도 합니다. 다만 이런 방법을 사용하려면 내가 임의로 제안을 한 다음 그 제안이 다른 사람이나 부서에 의해 잘못을 지적 받는 식으로 의사결정을 진행하는 동안 여러 가지 방법으로 지적을 받게 되기 때문에 이 방법을 사용하는 나 자신에 어느 정도 맷집이 필요합니다. 그래서 책임이 더 적을 때보다 책임이 좀 더 늘어난 상태에서 이 방법을 더 원활하게 사용할 수 있었습니다. 내 임의로 초안을 작성한 다음 초안의 문제점을 지적 받는 식으로 다른 부서의 의사결정을 진행 시키더라도 다른 부서들이 내 방식을 존중하는 모양으로 의사소통 하기도 하고 또 내 결정이 어느 정도 신뢰를 얻어 종종 그 모양 그대로 다른 의사결정 시간을 완전히 없앤 채로 진행될 때도 있습니다.

종종 팀 문서로부터 앞에서 설명한 결정교착상태에 해당하는 부분이 나타나면 고민하게 됩니다. 내 방식으로 처리하면 더 빨리 처리할 수 있기는 하지만 그 과정을 정면으로 맞서야 하기 때문입니다. 근본적으로는 직접 욕을 다 먹는 입장에 서서 일을 빨리 처리하는 방법과 결정교착상태를 유발하도록 한 발 물러서서 의견을 제시하는 방법 사이에 적당한 중간 지점을 찾아야 한다고 생각합니다.