저번편에서는 과도한 압박이 실제로 어떤 부정적인 영향을 미치는지 알아보았습니다.
뭐 '좀비는 헤드샷'이라는 명쾌한 답을 제시해 주신 분들도 있고 스스로 좀비라고 자책하시는 분도 있었습니다.
제가 보기엔 스스로 좀비라고 자책하시는 분들은 약간의 보균자일뿐 아직 좀비는 아니실테니 걱정 안하셔도 될듯 합니다.(사실 진정한 좀비라면 이런 생각 이나 고민 자체를 하지 않습니다.)
사실 좀비는...
드마르코 형님의 책에서는 간단하게 나왔지만 많은 분들의 이해를 돕기위해 강조하였는데 의외로 좀비에 꽂히신 분들이 많아서 이걸 어떻게 풀어야 할지 많이 고민이 됩니다.
일단 이번엔 전편에 이어서 빨리 빨리와 압박을 실제로 구현하기 위해 관리자들이 저지르는 대표적인 바보짓 두개를 언급해 보겠습니다.
좀비들을 만들어내는 마스터(관리자)가 되는 법
첫번째는 공격적인 일정입니다.
6개월 짜리 일을 3개월로 줄이는 것이지요.
여기엔 두가지 부수적인 것을 동반하는데 바로 잘못된 믿음과 일정에 대한 책임입니다.
- 잘못된 믿음
많은 관리자들이 지니는 것인데 6개월 짜리 일을 3개월로 줄여서 하라고 해놓고 실제로 7개월이 걸리면 스스로를 합당화 시키는 것입니다.
바로 그나마 3개월로 줄이고 압박을 했기에 7개월로 잘 끝난것이라고요.
이게 되게 웃긴게 대부분의 관리자들이 신참시절에
'최대한 불가능한 일정을 세우고 거기에 분투하는 것은 결단코 손해 볼 수 없다라는 것이 옳다'
고 배운다는 것입니다.
근데 이것이 말이 안된다는 것은 소프트웨어가 아닌 건축으로 비유해보면 쉽게 이해 가능합니다.
건축을 예로 들자면 30일의 공사기간과 5명의 인력이 필요한 일을 50명으로 3일만에 하라고 한다면 아무도 가능하다고 하는 사람이 없을 것입니다.
최소한 기초 공사를 하는 기간이 필요하며 콘크리트 바를 시간도 필요한데 이건 단순히 사람만 늘리고 일정을 압박한다고 해서 해결되지 않습니다.
또한 결과로 보면 실제로는 훨씬 많은 비용을 치르게 되는 것이지요.
- 일정에 대한 책임
결국 일정은 지연되고 제대로 지켜지지 않습니다. (사실 제대로 된 일정이 아니기에 지키는 것이 불가능합니다.)
이때 관리자들은 책임을 모면하기 위해 그일을 수행하는 사람에게 책임을 돌리게 됩니다.
'아 왜 이 친구들은 일정을 제대로 못 맞추는 걸까?'
'이 사람들은 왜 이리 일을 못할까' 라고요.
일정을 못맞춘 이유가 일정 자체에 있음을 인정하지 못하고 오직 직원들이 일을 못한 탓이라고 생각합니다.
근데 일정을 맞추지 못한것은 잘못된 일정이기 때문인 경우가 많습니다.
일정이란 제대로 계획하는 것에 목적이 있는 것이지 단순히 목표만을 정하는 것이 아니기 때문입니다.
두번째는 바로 초과 근무 입니다.
일정이 지연되기 시작할때 관리자들이 직원들에게 강요하는 것은 바로 초과근무 입니다.(여기에는 이미 많은 분들이 이를 갈고 있을것이라 생각합니다.)
장기간의 초과근무로 발생하는 부정적인 결과는 다음과 같습니다.
- 품질의 저하
- 개인의 탈진
- 이직의 증가
- 정상 근무 시간의 낭비
네가지 모두 엄청나게 안좋은 결과 입니다.
이 부분은 다른 여러글에서도 많이 언급되고 있고 알고 계시리라 보이기에 설명은 하지 않도록 하겠습니다.
일정지연과 초과근무의 두가지 원투펀치를 맞게 되면 많은 직원들이 좀비로 변하게 됩니다.
즉 많은 직원들이 살아있는 시체들로 구성된 조직이 되는데 이런 조직은 갑갑하고 무기력한 느낌으로 가득차게 됩니다.(겪어 보신분들은 알고 계시리라 생각됩니다.)
일단 좀비를 안만드는 관리자가 되기 위해서는 위의 두가지 오류, 공격적인 일정과 장기간의 초과 근무를 지양하시면 됩니다.
그리고 아래의 내용을 참고하시기 바랍니다.
잘못된 압박을 행하는 방법들 (좀비 마스터의 핵심적인 스킬들)
- 완료일에 대한 부담을 준다.
- 추가 업무를 시킨다.
- 초과 근무를 장려한다.
- 실망할 경우 화를 낸다.
- 한 부하직원의 놀랄 만한 성과를 다른 부하직원들 앞에서 칭찬한다.
- 엄청난 성과를 제외한 모든 실적에 비판적인 태도를 취한다.
- 모든 직원에게 대단한 뭔가를 기대한다.
- 눈에 띄는 모든 시간 낭비를 꾸짖는다.
- 원하는 행동 및 결과를 장려하기 위해 사소한 인센티브 제도를 시행한다.
사실 뭐 여러 글들을 쓰곤 있지만 현재 잘못된 길을 향하고 있는 많은 관리자 분들이나 팀장분들이 바뀌긴 힘들 것이라 생각합니다.
어떤 사람의 마음가짐이나 행동 그리고 믿음을 바꾸기가 결코 쉽지 않다는 것은 요즘들어 특히나 느끼고 있으니까요.
제가 조금이라도 바라는 것은 이글을 읽고 현재 문제가 있다고 느끼는 많은 직원 분들이 나중에 관리자나 높은 위치에 이르렀을때 똑같은 오류나 실수를 범하지 않았으면 하는 것입니다.
비록 위에서 부터 바꾸진 못해도 조금씩 아래가 바뀌면서 올라가다 보면 언젠가는 위도 바뀔날이 오겠죠~
처음 글을 쓰기 느린자들을 위한 변명을 시작할때는 슬랙이 필요한 이유와 장점에 대하여 쓰기 위해서 시작했는데 이게 너무 일이 커졌네요...ㅡ.ㅡ;
일단 슬랙을 말하기 위한 내용의 핵심은 아래 그림과 같습니다.
효율성과 효과에 대한 단상
그림에서 오른쪽에 있는 퍼즐을 제대로 맞출수 있는 분은 좀 알려주시기 바랍니다.
근데 사실 오늘날 기업에서 강조하는 극단적인 효율성을 그림으로 표현한 것이 오른쪽의 그림입니다.(왼쪽은 정상적인 형태이고요.)
너무나도 효율성을 강조한 나머지 각종 문제를 해결할 수 있는 여유 공간 마저 없애버린 것입니다.
저 문제를 해결할 수 있는 여유 공간을 확보하자는게 슬랙의 요지라고도 볼 수 있습니다.
저런 공간을 없애는건 정말 말도 안되는것 같지만 실제로는 저런짓을 하는게 사람들이지요.
다음편에서는 조금더 효과적인 방법인 슬랙에 대해 전반적으로 적어 보도록 하겠습니다. (이 시리즈는 3편으로 마무리 짓도록 해야 겠습니다.)
- by 강태원(Meteor) -
'Programer Story > IT World story' 카테고리의 다른 글
프로젝트의 시작은 프로그램 소스의 관리. (0) | 2012.06.28 |
---|---|
2011 S/W 노임단가 (0) | 2011.11.24 |
12명의 아키텍트에게 물어본 "아키텍트의 길!" (0) | 2011.05.29 |
Nature of Order (질서의 본질)에 대해서.. [1편] (0) | 2011.05.29 |
코딩 잘하는 10가지 방법 (0) | 2011.05.29 |