팀의 실행 방안 수행

업무 수행 중에 최초 계획했던 대로 일이 진행되지 않는 것은 10개의 일 중에 9개정도는 해당될 만큼 잦은 일입니다. 계획을 가지고 움직일 때 우리는 보통 3가지 선택사항에 놓이게 되는데 이중 올바른 답을 찾기는 쉬운일이 아닙니다.

1-1. 해당 이슈를 예외로 두고, 이번만 별개로 진행
1-2. 해당 이슈를 포함하는 계획을 재수립
2. 포기

포기는 많은 경우에 선택하는 그러나 정답일수도 오답일수도 있는 선택지이기에 논외로 두고자 합니다. 반면 1번에 위치한 2개의 답 사이에서 우리는 많은 고민을 합니다. 이번 이슈가 진행과정에서 또 발생할지, 또 발생한다고 해도, 별개로 진행할 수 있을지, 그 횟수는 얼마나 될지 등 고민해야 할 조건이 많습니다.

이러한 경우가 결정하기 가장 난감한 편입니다. 경우에 따라서는 팀 전체가 이번 이슈에 허덕일 수도 있습니다. 계획을 변경하거나 다시 수립할 경우, 우리는 일정과 리소스의 벽에 부딪히게 됩니다. 최초 계획시점과 현재는 다르고, 지금까지 했던 결과들이 유의미하지 않을 수 있습니다.

대부분의 경우 포기보다는 1번의 두가지 방향에서 선택합니다. (가끔 포기를 선택하는 팀장에게서 뿜어져 나오는 쿨내를 감당하지 못하기도 합니다.) 1-1과 1-2의 사이에서 팀장은 아래와 같은 상황들을 검토해야 합니다.

  1. 앞으로 동일한 이슈가 발생할 확률
  2. 현재 있는 계획안에서 해당 이슈를 포함할만한 대안이 있는지
  3. 계획 변경 시 고려되어야 할 현재까지의 투입 리소스 / 앞으로의 리소스
  4. 지금까지의 결과와 상태
  5. 이외에 또다른 이슈가 발생할 여지가 있는 취약한 부분
  6. 해당 이슈를 별개로 진행할 경우 리스크

이외에도 많은 사항들이 있겠지만 결국 이전과 같은 뻔한 이야기입니다.

정답이 없는 문제에 대해서 최종 결정에 대한 책임은 팀장이 지어야합니다.

실행 결과 확인

중간 중간 발생하는 이슈들을 넘어 최종적인 결과를 얻게 되었지만, 이 결과가 원하는 결과일 수도, 아닐수도 있습니다. 가시적인 성과가 나왔다 -> 보고한다 -> 행복하다 의 프로세스가 이루어지는 경우는 흔치 않습니다. 애매한 결과가 나왔다 -> 포장한다 -> 보고한다 -> 씁쓸하다 의 프로세스가 보통 친숙한 방식입니다.

결과가 나왔을 때 팀을 어느 방향으로 이끄느냐는 최종적으로 팀장이 수행해야할 가장 큰 결정입니다. 다른 결과를 얻기위해 새로운 프로젝트를 수행할지, 기존 결과를 가공하여 유의미한 다른 가치를 찾을지, 있는 그대로 보고할지 등 여러 방식이 또다시 산재합니다.

보통 이러한 상황은 팀원들의 의견을 얻기가 쉽지 않습니다. 보통 팀장의 업무 범위에 따라 진행되는 프로젝트인만큼 정해진 일정이 모두 지났거나, 혹은 애초에 일정이 없었거나, 유의미한 다른 결과값이 회사에 도움이 되거나, 타팀에서 감당할수 없는 결과이거나 등 여러 경우의 수를 알지 못하는 팀원이 의견을 주기는 쉽지 않습니다.

간단히 상상해보면,

마케팅팀에서 준비한 광고일정이 도래했을 때, 생산팀에서 목표 물량을 뽑아내지 못하는 경우
대규모 업데이트 시점을 고지하였으나, QA 결과 개발 결과물이 MVP 수준인 경우
500만건의 생산 물량을 확보하였으나, 100만건밖에 수주해오지 못한 경우

대부분 크리티컬 하거나, 상상하기도 싫은 경우가 많습니다.

결과가 나왔을 때 단순히 상사에게 까이거나, 회사에서 욕하는 상황을 걱정하는 것은 당연히 있을 수 있는 부분이고, 좋은 팀장에게는 더 나아가 이를 극복하기 위한 결정이 필요합니다. 애초에 결과가 목표치를 상회할 경우에는 팀 전체가 좋은 결과를 만들어 낸 부분이니 중대한 결정을 할 필요는 없습니다. 항상 문제가 되는 것은 결과가 나쁜 상황입니다.

예를 들어, 업데이트 시점을 고지한 후, QA 결과가 차마 업데이트 하기에 비참한 정도의 결과물이라고 가정해봅니다. 아래와 같은 고민들을 해볼 것 같습니다.

  1. 업데이트 시점을 조정하기 위해, 문제 상황들을 개선하는데 필요한 소요시간을 산정하고, 여유 일정을 감안하여 n일을 연기 요청한다.
  2. 현재 준비된 상태로 업데이트를 수행하고, 순차적 개선한다.
  3. 문제 상황들 중 야근 등 조금이라도 개선 가능한 부분들을 반영하여 약간이라도 퀄리티를 높인다.

마찬가지로 정답은 없고, 회사 상황과 타 팀과의 연계를 통해 최종 결정이 이루어집니다. 어떠한 결정을 하던 문책을 피할 수 없겠지만 회사의 분위기나 방향에 따라 앞으로 어떻게 할지는 팀장이 정해주어야 합니다.

그래서 결론은?

팀장은 어떠한 일 하나를 수행할 때 그 일의 경중과는 상관없이 시작부터 끝까지 결정하는 자리에 있는 사람입니다. 그 결정이 회사에 도움이 되는 방향으로 간다면 좋은 팀장이고, 팀원에게 도움이되는 방향으로 간다면 좋은 팀장이다 라는 이분법이 아닌, 매 순간 최선의 결정을 하는 팀장이 필요한 시기입니다.

때로는 팀원들을 다독여 일정을 맞추고, 때로는 회사에게 강하게 어필하여 일정을 확보하는 여러가지 결정을 그 상황에 맞추어 결정해야 합니다. 그러기 위해 팀장은 그팀의 메인 업무에 대하여 스페셜리스트여야 하면서, 동시에 회사 전체의 제너럴리스트여야 합니다.

타팀의 일정을 미뤄서라도 우리팀의 일정을 맞춰야 한다는 근거를 낼수 있거나, 반대로 우리팀의 일정을 앞당길수 있는지 판단할수 있어야 합니다.

경우에 따라서는 팀원들의 문제 상황들을 대신 해결해주어야 하고, 반대로 자신의 업무를 과감하게 팀원에게 넘겨줄 수 있어야 합니다.

결국 모든 것은 팀장의 결정에 의해 움직입니다. 회사와 팀 사이에서 최대한의 효과와 효율을 만들어 낼수 있는 신의 한수를 두는 사람이, 더욱 필요해지는 시기입니다.

A와 B가 있을 때 C를 이야기하는 사람이 팀장일 필요는 없습니다.

하지만, 팀장은 그 셋 중 한가지를 결정하는 사람이어야 한다고 생각됩니다.

과거와 미래, 현재를 감안하여 결정할수 있는 능력은 쉬운 일이 아닙니다.

좋은 개발자가 팀장이 되어도 좋은 팀장이 될수 없다는 것은 이러한 점이 영향을 주지 않을까 싶습니다.