소프트웨어 엔지니어로 10년 가량 직장생활을 하면서 R&R(Role And Responsibility)에 대한 고민은 항상 있어 왔던 것 같다.
블로그에 R&R에대한 다른 포스트들도 여럿 더 있고...
뭐, 사실 이런 류의 논의는 정답이 없기 때문에 더욱 곤란한 경우가 많은데, 각설하고, 한가지 경우에 대한 장단점을 이야기 하고자 한다.

R&R에 대해 이야기 할때, 가장 주로 사용되는 방식이...

너의(혹은 너의 팀의) 주 임무(Main Role)은 'xxx'이다. 그렇지만, 거기에 국한되지는 않는다(not limited). 그러므로 경우에 따라서는 다른 사람(팀)의 일을 도와 주어야 하는 경우도 있을 것이다.


이런 식인데... 과연 이게 적절한 방식인가에 대한 이야기이다

물론, 일 자체가 너무 달라서, 서로의 영역을 서로 도와 줄 수 없는 경우는 고민할 거리도 없지만... 개발 조직 내에서는, 특히 소프트웨어 에서는, 다른 영역에 contribution하는게 충분히 가능하기 때문에 위와 같은 정의가 자주 사용되는 것 같다.


사실 "너는 이 일만 해!"는 현실적으로 불가능하다. 그래서 "거기에 국한되지는 않는다.(not limited)"라는 말이 항상 들어가게 된다.

왜 현실적으로 불가능한가?

일이라는게, 항상 고정되어 있는 것도 아닐 뿐더러, 어떤 때는 이 일이 많았다가, 어떤 때는 저 일이 많았다가... 이런 식이기 때문이다.


장점이라면, 당연히, 남는 자원을 적절히 분배할 수 있다. 특정 일이 많을때는 그 일을 서로 나누어서 할 수 있으니, 인적자원의 효율적인 활용이 가능해 진다.

단점이라면? 사실 이 부분이 이 글에서 이야기하고 싶은 부분인데... 예를 들어 A, B 두 팀이 있다고 생각해 보자.

A팀은 굉장히 적극적이고 또 능력도 뛰어나서 맡은 일을 빠른 속도로 처리해 나가는 팀이고. B팀은 A팀과 반대되는 성향을 가진다고 생각하자.

이 경우, 위와 같은 R&R의 정의를 적용하면, B팀은 항상 제 시간에 일 처리를 끝내지 못하기 때문에 A팀은 항상 B팀을 도와주는 형태로 업무가 진행되게 된다.

A팀은, 비록, 열심히 부지런히, 그리고 소위 '스마트'한 방법으로 자신들의 역할을 다 했음에도 불구하고, B팀의 상황이 안 좋기 때문에 B팀을 도와 주게 되는 것이다.

만약 B팀 역시 A팀과 비등한 정도의 열정/성실/능력 을 가진 팀이라면, 이런 상황은 어쩔 수 없고, A팀 역시 커다른 불만 없이 B틈을 도와 줄 것이다.

왜냐하면, 이 경우는 명백하게, 순간적으로 B팀에게 일이 몰리는 상황이고 이것은 어떻게 처리할 수 없는 형국이기 때문이다.


그렇지만 많은 경우, B팀의 불성실/게으름 등등의 이유로 절대적인 일의 양은 A팀에 비해 많지 않았음에도(혹은 오히려 적었음에도) 불구하고 이런 일이 일어나게 된다. 그리고 이런 경우, A팀에서 이런 사실을 모를리 없다. 이는 당연히 불만으로 이어지고, A팀의 사기를 떨어뜨리게 된다. A팀 역시 일을 부지런히, 빨리 끝낼 이유가 없으니까... 빨리 끝내봤자 B팀의 일을 해야 하니...

B팀 역시, 어차피 A팀이 도와줄테니, 최선을 다해서 현 상황을 이겨나갈려고 하지도 않는다.

즉, B팀 입장에서는 Role은 있으되, Responsibility는 없는 형국이랄까... (A, B팀 공동 책임이다.)


자... 이 두 가지 장/단점 중에서 어느쪽에 손을 들어주어야 하는가?

물론, 항상 어느 한 팀의 일이 많다면, 이것은 일의 양을 잘못 판단한 관리자의 책임이고, 팀 구성을 새롭게 가져 가야 한다.


개인적으로는 지금까지, 위와 같은 R&R의 정의만 보아 왔다. 따라서, 위와 반대되는 R&R을 정의하고 조직이 흘러가는 경향을 관찰해 보고 싶은 호기심을 느낀다.

긍정적인 방향이라면, 각 팀의 자신의 일을 최대한 효율적을 빨리 끝내려고 '스마트'한 일 처리 방식을 끊임없이 연구할 것이고, 일의 전반적인 효율이 증대될 것이다.(일을 빨리 끝내면, 놀 수 있으므로...)

부정적인 방향은, "왜 우리만 항상 고생하는데!"와 같은 불만으로 팀웤이 손상되는 방향이 있을 수 있겠다.


일의 영역이 장기간 고정적이고 변화가 적다면, 유연성이 없는 엄격한 R&R정의도 고민해 볼 필요가 있지 않을까?


+ Recent posts