2007년 2월 14일 수요일

What not to do list as a manager

항상 객관적으로 자기 자신을 평가하기는 어려운 일이다. 지금 개발자로써 내가 관리자에게 느끼는 점을 모아 적어 놓는다면, 나중에 반면교사의 교재로 사용할 수 있을 것이다.
이 게시물은 생각이 날때마다 update할 계획이며, 혹시 누군가 댓글에 좋은 내용을 추가하여 준다면 이 또한 게시자의 id와 함께 추가하도록 하겠다.

1. 책임을 개발자에게 떠넘기기
한두가지 문제에 대한 책임을 개발자에게 떠넘긴다고 프로젝트 실패의 책임이 개발자에게 넘어가는 것은 아니다. 이런 행동은 최악의 경우 개발자의 사보타지를 부추길지도 모른다. 당신의 프로젝트는 실패하고 당신은 신망을 잃고 앞으로 누구도 당신 밑에서 일하려 하지 않을 것이다.

2. 개발자에게 자신의 방법을 강요하기
개발자가 어려운 디버깅 문제에 봉착하였을 때 이에 대해 적절한 코멘트를 통하여 디버깅을 도와줄 수 있다면 정말 훌륭한 관리자가 아닐 수 없다.(물론 이것은 개발에 대한 경험이 있는 관리자의 경우에만 해당된다) 하지만 개발자가 아주 초짜라 별도의 코칭이 필요한 경우가 아니라면 디버깅을 위한 의견 제시나 방향만 제시하여 주는 것이 좋다. 사사건건 간섭하여 이거 해 봐라 저거 해 봐라 하는것은 별로 좋은 방법이 아닌것 같다. 당신은 (한국사람이라면 특히나 더 ) 개발자로써 화려하게 성공하여 관리자로 진급하였는지도 모른다. 이 경우 당신은 자신만의 화려한 개발 실력을 무기로 삼아 문제를 빨리 해결할 수 있는 수만가지 방법을 알고 있겠지만, 문제 해결을 위하여 이러한 무기를 사용하고자 한다면 자신의 손으로 직접 행하기 바란다. 이것은 당신의 손에서 사용된다면 문제 해결을 위한 훌륭한 무기이지만, 당신의 입에서 사용된다면 개발자의 마음을 찟는 무기로 돌변 할 것이다. 괜시리 개발자의 마음들 다치게 하여서는 문제 해결에 도움이 되지 못한다. 사람에게는 자신만의 무기가 있는 법이다. 다른 사람에게 자신의 무기를 강요할 필요는 없다. 특히나 이것 저것 시켜보고 안되면 은근슬쩍 발을 빼려 한다면 당신은 좋은 매니져가 아니다. 해당 문제를 자신의 책임하에 끝까지 해결할 마음의 자세가 되지 않았다면 개발자에게 자신의 방법을 강요하지 않는 것이 좋다.

댓글 2개:

sweetsora :

으흠..
어째.. 딱 한사람이 떠오르오만.. -_-;;
홍선임님..
왜 홍선임님 글 읽으면.. 이렇게 한숨이 나오는걸까..?
좀 밝은 글 없수?

Hong, Doo Eui :

내가 "에너지 뱀파이어"는 아닐까?
다시 이 게시물에 내용을 추가할 때까지 좀 시간을 가져야 할 것 같아.