개발일을 하다 보면 이거 좀 급한데 빨리 좀 해줄 수 있냐는 요청을 자주 받는다. 이미 계획된 일을 하고 있고, 거기에 모두의 동의가 있다고 해도 '급함' 딱지를 달은 일들은 아랑곳 않고 전달된다. 이 때 개발자 자신이 하든 아니면 팀 단위 또는 보다 큰 조직단위에서 하든 우선순위에 대한 논의를 할 수 밖에 없다. 태스크들의 우선순위 충돌은 자연스러운 일이나, 그 충돌을 해결하는 건 쉽지 않다. 충돌이 일어나는 원인에는 여러가지가 있을 수 있다.
- 둘 다 중요한 일인 경우
- 둘 다 급한 일인 경우
- 중요한 일과 급한 일인 경우
- 우선순위와 상관 없는 충돌인 경우
여기에서 각 케이스에 대한 가치 판단을 해야 하는데, 판단이 어려운 경우는 '둘 다 급한 일인 경우' 와 '우선순위와 상관 없는 충돌인 경우' 이다. 이 중에서 '우선순위와 상관 없는 충돌' 은 조직의 문제인 경우가 많다. 이미 개발의 영역을 벗어난 문제이니, 상위 매니저에게 넘기거나, 다른 해법을 찾아보는 것이 좋다.
만약 서로 충돌한 두 업무가 각자가 중요하다 라는 주장을 하고 있다면, 생각보다 우선순위를 정하기가 쉽다. 업무의 중요성에 대해서는 담당 개발팀이 스스로 가장 잘 알고 있을 테니까 말이다. 또한 위급의 정도에 따라 다르겠지만, 대체적으로 급한 일과 중요한 일 사이에서는 중요한 일에 시간을 투자해야 낭비가 덜 발생한다.
그렇다고 급한일들을 외면할 수는 없으니, 이 일들에 대한 관리나 대처가 필요하다. 바로 이 지점이 개발팀을 이끄는 핵심 포인트가 있는 곳이다. 다시 말해 위급의 형태를 띄는 일들을 중요한 일의 모습으로 탈바꿈 시키는 게 개발팀 관리자의 핵심 역량이다. 그리하여 개발 작업들이 중요도에 의한 경쟁을 하는 구도를 만들어야 한다. 예를 들어 자주 발생하는 급한 일들에 패턴이 있다면, 이를 잡아내어 제품의 기능으로 만들어 추상화 시키는 식이다.
때로 당장 시급함을 요구하는 일들이 있다면, 그 일이 왜 시급한지 알아봐야 한다. 의외로 많은 '급한' 일들이 사실 급하지 않은 경우가 많다. 사람의 심리, 변덕스러운 일정 등이 추가되면 멀쩡한 일이 지금 당장 파이프라인을 멈추고 해야 하는 급한 일로 둔갑한다. 하지만 이런 일들은 마찬가지로 일정이나 이해관계 등을 조절해 쉽게 조정가능한 경우가 있다.
모든 방법을 동원해도 여전히 '급함' 딱지가 안 떨어지고 있으면, 해당 업무를 진행하는 것 밖에 도리가 없다. 우선 해당 업무의 Goal & Non Goal 을 명확히 하는 작업을 한다. 업무의 목표와 범위가 명확해지면, 이제 어떤 비용을 들일지 정한다. 해당 업무를 진행할 수 있는 리소스를 확보하고, 해당 인력들이 급한 일을 처리하기 위해 지불해야 하는 반대급부를 보고 판단을 내리면 된다.
하지만 이 모든 과정을 상대방과 진솔하게 진행하는 것이 중요하다. 자칫 잘못하면 상대방으로 하여금 조금만 더 버티면 다음 스테이지로 넘어갈 수 있다는 생각을 심어 줄지도 모른다.