무언가 일을 하는데 있어서 '잘' 하는 것은 참 중요합니다.
그냥 빨리 하는 것이 중요할 때도 있지만, 기본적으로는 무언가 일을 할때 제대로, 잘 하는 것이 중요합니다. 적지 않은 기간동안 많은 비용을 치루고, 또 치루는 것을 보면서, 때로는 치루지 않고 잘 넘어가는 것을 보면서 느낀 점입니다.
제가 이렇게 말할 수 있는 데는 제가 하는 일과도 연관되어 있습니다. 저는 개인이나 조직이 일을 진행할때 어떻게 하면 '잘' 할 수 있는 지를 찾아내서 알리는 일을 하고 있기 때문입니다. : )
저는 뛰어난 개인 이나 조직의 특성을 연구하고 관찰하고, 그 안의 DNA를 발췌해서 전달한 다음 다시 관찰하고 다시 수정해서 반영하는 일을 합니다. 그러다보니 중간 중간 뽑혀져 외부로 나온 것이 Agile이고 TDD이고 Play Framework이었고 MongoDB였었습니다.
그런데 그건 외부로 드러난 현상에 가깝고, 실제로는 앞서 말했듯이 '잘' 하는 방법을 찾고 그걸 막는 문제(blocker)를 찾아서 사람과 조직을 좀 더 유연하고 우수하게 만드는 것이 제가 하는 일의 기본방향입니다. 그리고 실제로 그렇게 해서 절대 '생산량'이 아닌 상대 '생산성'을 높인 사례들을 만들어가기도 하고 때로는 제대로 하지 못해 혹독한 비용을 치루기도 하면서 자연스레 '잘' 하는 것이 '참' 중요하구나 라고 더더 느끼게 되었습니다.
그런데, 왜 잘하는 것이 중요할까요?
너무 뻔한 질문 처럼 들리기도 합니다만, 어쨌든 요즘 같은 급변하는 세상속에서는 '속도'가 훨씬 중요한것 아닐까요?
속도를 부정하는 건 아닙니다만, '잘'한다는 것은 기본적으로 '지속성'과 연관이 깊습니다. 한번 불타오르고 사그라들어 재가 되어버리면 '지속'가능하지 못한 방법일 뿐더라 부작용도 큽니다. 그래서 무언가 장기적으로 일을 할 때에는 당장의 효과에 앞서 '지속성'에 관심을 기울여야 합니다. 예를 들자면,
일을 많이 빨리 하는데만 집중한 조직은 '조직 이름'은 오래 갈 수 있어도 조직 구성원은 오래 남아 있기 어렵습니다. (물리적인 것 뿐아니라 정신적인 면까지 포함해서 말입니다. :)
또 프로그램의 작성법만 배워서 무조껀 열심히 프로그램을 짜면 결국 돌이킬 수 없는 기술적 빚더미(technical debt)위에 올라서서 현재를 버리고 새롭게 재개발 해야 하는 상황이 발생합니다. 대부분의 재개발은 원래 개발만큼의 비용이 들지만, 보통 그렇다고 기존보다 2배 더 많은 기능이 생기거나 2배 더 편해지진 않습니다.
이건 스포츠 경기와도 비슷한 데요, 축구의 경우 무조껀 열심히, 빨리 운동장을 뛴다고 결과적으로 좋은 경기가 되고 좋은 선수가 되지 않는 것과도 유사합니다. 물론, 경기 뒤에 고생했다면 등을 두드려주는 심정적인 위안은 될 수 있겠죠.
그런데 사실 여기엔 한 가지 결정적인 갈등적인 요소가 있는데요, 바로 '잘' 하려면 시간과 돈이 든다는 점입니다. 그리고 최초의 마찰력을 이겨내고 움직이는데까지는 시간과 돈 뿐 아니라 '좋은 자질'의 사람들도 함께 필요한데요, 마찬가지로 가속도가 생기기 전까진 계속 비용 투자가 필요합니다. 정지상태에 남으려는 관성을 이겨내서 계속 속도를 높여 앞으로 나갈 있게 되려면 개개인에게 속칭 Do Things Right DNA가 생겨야 합니다.
그걸 바탕으로 기술, 도구, 프로세스가 함께 발전되고 전달되어 세대를 거쳐 꾸준히 계속 계승되어야 비로서 그 사람의, 그 조직의, 그 회사 만의 고유한 DNA로 남게 됩니다. 한때의 유행이나 바람이 안되고 말입니다.
[....??]
여러모로 이런저런 생각을 해 봐도, 현재 일을 보다 '잘' 하기 위해 노력하는 일은 그냥 그대로 따르는 것에 비해 쉬운 일이 아니고 또한 그런 분위기와 문화가 조직의 DNA로 남는 데는 비용이 많이 드는 일인 건 맞습니다 : )
그러다보니 종종 비용논리, 시장논리, 효율논리로 무시되곤 합니다. 생산성보다는 생산량이 더 중요해지고 눈에 보이는 숫자들과 그래프등의 지표가 무기가 되어 공격을 받곤 하죠. 그리고 이런 숫자나 지표에 집중하게 되는데, 사실 이런 것들은 상대적으로 측정하기 쉽고 개선이 용의합니다. 즉, 어려운 환경에서 선택하는 손쉬운 방법 1번이 되는 거죠. 흔히 '측정할 수 없으면 개선할 수 없다'란 말이 정설처럼 받아들여지는 분야들이 있습니다만, 그렇다고 측정할 수 없는 것들은 중요하지 않다는 것은 아니란 걸 잊으면 곤란합니다.
그리고 한편으론 이렇듯 측정하기 쉬운 것을 목표로 삼는 건 매우 위험한 일이 되기도 합니다. 특히나 '조직'측면에선 더더욱 그런 위험이 큽니다.
이를테면 다음 중 어느것이 더 측정하기 쉬울까요?
**"2배의 비용을 들여서 2배 많은 물건을 만드는 것이 유리한가, 2배 더 감동적인 혹은 2배 편리한 물건을 만드는 것이 유리한가?"
당연히 2배 더 많은 물건을 만드는 것이 더 측정하기 쉽고 접근하기 쉬울겁니다만, 결국 조직을 가치 있는 조직을 만들고 더 멀리 더 오랫 동안 나아가게 만드는 건 제가 본 경우엔 측정하기 쉬운 쪽이 아니었습니다.
사실, 이런저런 이야기 계속해야 진부한 이야기이고요, 제가 하려는 이야기는 이렇습니다. : )
혹시라도 '잘'하는 것 보다 '많이 하는 것'에 시달리고 계시다면, 그리고 뭔가 석연치 않다고 느끼고 계시다면 기운내세요.
우리의 선배의 선배의 선배들이 이미 많은 비용을 치루고 그 댓가로 우리에게 전달해 준 이야기들은 그들이 우리에게 준 선물이고 가치 매기기 어려운 가치 있는 이야기들 입니다. 때로는 그게 'SW공학'이라는 이름으로 우리에게 전달 되기도 하고 엔지니어링 테크닉으로, 때로는 Agile이나 Entrepreneur 같은 가치와 단어로 전달되기도 합니다.
그리고 좋은 점은 마치 오랜 속담을 듣는데 돈을 내진 않지만, 값진 교훈을 주는 것 처럼 원한다면 언제든 자신에게 큰 가치를 주는 것이 될 수 있다는 점입니다.
@doortts (doortts) 님이 작성한 게시글입니다. ---
[Who Framed Roger Rabbit (1988)]
[관련글] 개발 생산성(productivity)을 높이라구요? http://blog.doortts.com/182
무언가 일을 하는데 있어서 '잘' 하는 것은 참 중요합니다. 그냥 빨리 하는 것이 중요할 때도 있지만, 기본적으로는 무언가 일을 할때 제대로, 잘 하는 것이 중요합니다. 적지 않은 기간동안 많은 비용을 치루고, 또 치루는 것을 보면서, 때로는 치루지 않고 잘 넘어가는 것을 보면서 느낀 점입니다. 제가 이렇게 말할 수 있는 데는 제가 하는 일과도 연관되어 있습니다. 저는 개인이나 조직이 일을 진행할때 어떻게 하면 '잘' 할 수 있는 지를 찾아내서 알리는 일을 하고 있기 때문입니다. : )
저는 뛰어난 개인 이나 조직의 특성을 연구하고 관찰하고, 그 안의 DNA를 발췌해서 전달한 다음 다시 관찰하고 다시 수정해서 반영하는 일을 합니다. 그러다보니 중간 중간 뽑혀져 외부로 나온 것이 Agile이고 TDD이고 Play Framework이었고 MongoDB였었습니다.
그런데 그건 외부로 드러난 현상에 가깝고, 실제로는 앞서 말했듯이 '잘' 하는 방법을 찾고 그걸 막는 문제(blocker)를 찾아서 사람과 조직을 좀 더 유연하고 우수하게 만드는 것이 제가 하는 일의 기본방향입니다. 그리고 실제로 그렇게 해서 절대 '생산량'이 아닌 상대 '생산성'을 높인 사례들을 만들어가기도 하고 때로는 제대로 하지 못해 혹독한 비용을 치루기도 하면서 자연스레 '잘' 하는 것이 '참' 중요하구나 라고 더더 느끼게 되었습니다.
그런데, 왜 잘하는 것이 중요할까요? 너무 뻔한 질문 처럼 들리기도 합니다만, 어쨌든 요즘 같은 급변하는 세상속에서는 '속도'가 훨씬 중요한것 아닐까요?
속도를 부정하는 건 아닙니다만, '잘'한다는 것은 기본적으로 '지속성'과 연관이 깊습니다. 한번 불타오르고 사그라들어 재가 되어버리면 '지속'가능하지 못한 방법일 뿐더라 부작용도 큽니다. 그래서 무언가 장기적으로 일을 할 때에는 당장의 효과에 앞서 '지속성'에 관심을 기울여야 합니다. 예를 들자면,
일을 많이 빨리 하는데만 집중한 조직은 '조직 이름'은 오래 갈 수 있어도 조직 구성원은 오래 남아 있기 어렵습니다. (물리적인 것 뿐아니라 정신적인 면까지 포함해서 말입니다. :)
또 프로그램의 작성법만 배워서 무조껀 열심히 프로그램을 짜면 결국 돌이킬 수 없는 기술적 빚더미(technical debt)위에 올라서서 현재를 버리고 새롭게 재개발 해야 하는 상황이 발생합니다. 대부분의 재개발은 원래 개발만큼의 비용이 들지만, 보통 그렇다고 기존보다 2배 더 많은 기능이 생기거나 2배 더 편해지진 않습니다.
이건 스포츠 경기와도 비슷한 데요, 축구의 경우 무조껀 열심히, 빨리 운동장을 뛴다고 결과적으로 좋은 경기가 되고 좋은 선수가 되지 않는 것과도 유사합니다. 물론, 경기 뒤에 고생했다면 등을 두드려주는 심정적인 위안은 될 수 있겠죠.
그런데 사실 여기엔 한 가지 결정적인 갈등적인 요소가 있는데요, 바로 '잘' 하려면 시간과 돈이 든다는 점입니다. 그리고 최초의 마찰력을 이겨내고 움직이는데까지는 시간과 돈 뿐 아니라 '좋은 자질'의 사람들도 함께 필요한데요, 마찬가지로 가속도가 생기기 전까진 계속 비용 투자가 필요합니다. 정지상태에 남으려는 관성을 이겨내서 계속 속도를 높여 앞으로 나갈 있게 되려면 개개인에게 속칭 Do Things Right DNA가 생겨야 합니다.
그걸 바탕으로 기술, 도구, 프로세스가 함께 발전되고 전달되어 세대를 거쳐 꾸준히 계속 계승되어야 비로서 그 사람의, 그 조직의, 그 회사 만의 고유한 DNA로 남게 됩니다. 한때의 유행이나 바람이 안되고 말입니다.
[....??]
여러모로 이런저런 생각을 해 봐도, 현재 일을 보다 '잘' 하기 위해 노력하는 일은 그냥 그대로 따르는 것에 비해 쉬운 일이 아니고 또한 그런 분위기와 문화가 조직의 DNA로 남는 데는 비용이 많이 드는 일인 건 맞습니다 : )
그러다보니 종종 비용논리, 시장논리, 효율논리로 무시되곤 합니다. 생산성보다는 생산량이 더 중요해지고 눈에 보이는 숫자들과 그래프등의 지표가 무기가 되어 공격을 받곤 하죠. 그리고 이런 숫자나 지표에 집중하게 되는데, 사실 이런 것들은 상대적으로 측정하기 쉽고 개선이 용의합니다. 즉, 어려운 환경에서 선택하는 손쉬운 방법 1번이 되는 거죠. 흔히 '측정할 수 없으면 개선할 수 없다'란 말이 정설처럼 받아들여지는 분야들이 있습니다만, 그렇다고 측정할 수 없는 것들은 중요하지 않다는 것은 아니란 걸 잊으면 곤란합니다.
그리고 한편으론 이렇듯 측정하기 쉬운 것을 목표로 삼는 건 매우 위험한 일이 되기도 합니다. 특히나 '조직'측면에선 더더욱 그런 위험이 큽니다.
이를테면 다음 중 어느것이 더 측정하기 쉬울까요?
**"2배의 비용을 들여서 2배 많은 물건을 만드는 것이 유리한가, 2배 더 감동적인 혹은 2배 편리한 물건을 만드는 것이 유리한가?"
**
[이미지출처: how-to-spark-employee-engagement-and-business-productivity]
당연히 2배 더 많은 물건을 만드는 것이 더 측정하기 쉽고 접근하기 쉬울겁니다만, 결국 조직을 가치 있는 조직을 만들고 더 멀리 더 오랫 동안 나아가게 만드는 건 제가 본 경우엔 측정하기 쉬운 쪽이 아니었습니다.
사실, 이런저런 이야기 계속해야 진부한 이야기이고요, 제가 하려는 이야기는 이렇습니다. : ) 혹시라도 '잘'하는 것 보다 '많이 하는 것'에 시달리고 계시다면, 그리고 뭔가 석연치 않다고 느끼고 계시다면 기운내세요.
우리의 선배의 선배의 선배들이 이미 많은 비용을 치루고 그 댓가로 우리에게 전달해 준 이야기들은 그들이 우리에게 준 선물이고 가치 매기기 어려운 가치 있는 이야기들 입니다. 때로는 그게 'SW공학'이라는 이름으로 우리에게 전달 되기도 하고 엔지니어링 테크닉으로, 때로는 Agile이나 Entrepreneur 같은 가치와 단어로 전달되기도 합니다.
그리고 좋은 점은 마치 오랜 속담을 듣는데 돈을 내진 않지만, 값진 교훈을 주는 것 처럼 원한다면 언제든 자신에게 큰 가치를 주는 것이 될 수 있다는 점입니다.
: )
--- attachments --- geek-girl.jpg Fotolia_14209170_XS.jpg rogerRabbit.jpg