티스토리 뷰
언젠가 관리자란 주제로 글을 쓰리라 마음 먹었것만, 나를 관리해주시는 관리자도 몇 되지 않으셨었고 (지금도 많진 않지만), 그 분들과 이야기를 나누거나 회고하기에는 재직중인 상황이라 미루다 미루다 이제서야 쓰게 됐다.
사실 좋은 관리자=좋은회사라는 공식이 어느정도 성립한다고 생각이 든다.
그렇게 생각하는 데에는 여러가지 이유가 있다.
- 안타깝게도 대부분의 회사가 이렇다는 게 현실
2. 결정권은 관리자에게 있으므로 해당 파트 내지는 팀의 방향성도 관리자에게서 나오기 때문
- 물론 그 보다 위에 계신 분들이 방향성을 잡는 경우도 있지만, 그 마저도 관리자의 역량과 영향이 있다고 볼 수 있음
기본적으로 좋은 관리자라는 의미는 상당히 애매하다.
대부분의 관리자 (내지는 대다수의 사람이) 들은 장점만 갖고 있지 않기 때문이다. (정말 정분이 날 만큼 친해서 자신에게 모든걸 맞춰주는 관리자를 만나신 분이 있다면 연락주시길...)
내가 경험해보거나 듣게 된 관리자들의 성향은 대부분 몇가지로 분류 할 수 있다.
- 기본적으로 좋은게 좋은거라고 개개인의 성향을 존중하고, 판단을 존중한다.
- 장점 : 대부분의 이야기를 들어주고, 이해해주려 노력한다.
- 단점 : 의견 제시를 하는 사람이 여러명일 때 본인이 혼란에 빠지곤 한다. 또한 판단이 늦는 경우가 많다.
2. 현실파
- 회사의 입장이 최우선이다. 회사에 피해가 덜 가는 것을 우선적으로 생각한다.
- 장점 : 회사 입장에서 판단하기 때문에 결과적으로 회사와 갈등이 빚어지지 않는다.
- 단점 : 개개인의 판단이 무시되기도 하기에, 현실파 관리자와 개인간의 갈등이 빚어지곤 한다.
3. 독단파
- 자신의 판단이 최우선이다. 나를 따르라~~
- 장점 : 명확한 신념이 있기에 추진이 빠르다. 또한 설득을 위한 시간 소모가 없다.
- 단점 : 독단파 관리자의 판단이 잘못 됐을 때에도 여지가 없다. 다른 의견을 가진 사람들 사이에서 불만이 터져나오고 이를 수습하기도 어렵다.
어느 한 스타일의 관리자를 꼽기에는 상황에 따라 필요한 관리자 타입이 너무나도 다르다.
물론 나도 레아님이 말씀하신 빠른 의사 결정이 최고의 관리자라는 얘기(http://rhea1st.tistory.com/489)에는 어느정도 공감한다.
결과적으로는 나는 생각이 조금은 다른데, 빠른 의사 결정이 다는 아닌 경우가 많다는 점이다.
나는 서버 개발자기에 긴급한 상황을 다른 파트보다 조금 더 많이 맞이한다고 생각이 든다. (이로 인해 줄어든 내 수명은... 누가 늘려줄려나...?)
당연히 나의 관리자도 이런 긴급한 상황을 자주 맞이하게 되는 것이고.
이런 상황에서 빠른 의사 결정이 물론 중요하다.
허나 결정이 이럴 때만 이루어 지는가??
그렇지 않다는게 중요하다.
워낙에 팀 분위기도 좋고, 게임 방향성도 모두가 공감해서 트러블 슈트만 제대로 해내면 하하호호 할 수 있는 팀이라면 얼마나 좋겠는가?
하지만 현실적으로 그런 팀은 많지 않고, 풀어내야 할 문제가 기술적인 이슈나 서비스적인 이슈만이 아니라는게 중요하다.
사실 사람간의 갈등이 제일 어렵다. 이 문제까지 관리자가 해결하는 건 쉬운일이 아니라 생각하고, 경험해본 적이 없기에 넘어가보자.
내가 가장 많이 겪었던, 그리고 들어온 고충은 바로 업무 스타일과 퀄리티 문제다.
업무 스타일에 따라 서비스 시에 발생할 문제를 매우 많이 해결 할 수 있고, 퀄리티란 단순히 테스트 해보니 잘 되요가 아닌 함축적인 의미를 내포하기 때문이다.
서로 다른 환경에서 일해오던 여러 사람이 팀으로 묶였을 때, 다른 업무 스타일과 퀄리티를 조율 할 수 있는 관리자가 좋은 관리자라 생각한다.
사실 이걸 해낸 관리자는 거의 없고, 앞으로도 많지 않을 것이다.
대부분의 경우는 혼란 상태에 빠져서 좌초되거나, 혼란 상태로 연명하며, 그런 상황은 대게 독단파 한명이 팀을 휘어 잡을 때가 되서야 나름의 평온함을 찾게 된다. (억눌러서 얻은 평화는 오래가지 않는법...예외가 있다면 독단파가 뛰어난 자라면 좋은 결과를 내기도 한다.)
아주 운이 좋을 경우 업무 스타일이 흡사한 사람들끼리 평온한 팀이 만들어지기도 하고.
하지만 대게는 나쁜 팀으로 남는다. (혹은 여러가지 상황으로 인하야 버티거나)
이렇듯 현실적으로 어려운 이야기를 왜 하느냐고?
그런 어려운 일을 해내야 좋은 팀이 된다는 이야기를 해야 하는 것이다.
좋은 관리자가 되는게 그만큼 어렵지만, 그만큼 좋은 팀이라는 보상이 온다.
그런 관리자를 앞으로의 개발자 인생에서 만날 수 있을까? (내가 그런 관리자가 될 수 있을까란 질문은 던지지 않는걸로. 나는 관리자가 아닌 개발자로써 계속 남고 싶으니까)
뭐 꼭 내가 만나지 못하더라도, 그런 관리자가 하나라도 더 있었으면 하는 바램에서 이 글을 남겨본다.
'Software Engineering > Develop Theory' 카테고리의 다른 글
조엘 온 소프트웨어 - 손쉬운 기능명세 작성법 (0) | 2014.10.17 |
---|---|
좋은 엔지니어의 자세 (0) | 2012.07.01 |
좋은 프로그램 개발을 위한 원칙 (2) | 2010.08.20 |
조엘 테스트 (0) | 2008.02.24 |
코드 읽기에 대해서 (2) | 2008.02.13 |
- Total
- Today
- Yesterday
- 조엘 온 소프트웨어
- MS-SQL
- ftp
- 바로가기 프로그램
- 루비 온 레일즈
- SQLite Spy
- 리버스 엔지니어링
- 엘키
- 게임개발포에버
- NDC2013
- ruby
- EasyExec
- SDL
- CppSQLite
- Ruby on Rails
- 게임데브포에버
- 디자인 패턴
- TDD
- 루비
- 임백준
- c언어
- EzShortcut
- TraceRoute
- 디버깅
- 좋은 프로그래머
- svn
- RoR
- perfmon
- 멀티스레드
- Rails
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |