What not to do list as a manager

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

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

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

악몽의 순간에 발생하는 일들

프로젝트가 막바지에 이르면 개발자와 관리자 모두 패닉상태가 되기 쉽다. 이미 code freeze일정이 지나 validation team에게 이미지가 전달되었지만, 잇달아 발생하는 개발자의 sanity test failure report는 별다른 위기조차 되지 않는다. 왜냐면 곧이어 validation team에서 "진짜" 문제들을 쏟아낼 것이기 때문이다. 이쯤되면 이미 validation team으로 부터 몇번의 양해를 구해서 이미지를 다시 build하였기 쉽상이지만 아직 절망에 이를 단계는 아니다.

- (사실 validation team이 그나마 "진짜"문제를 쏟아내주면 그것만으로도 고마운 일이다. 최근에 투입된 "초짜" tester가 등록하는 수많은 "가짜"문제들의 홍수에 질식해 본 적이 있다면 "진짜"문제들은 차라리 고맙기까지 하다)

만일 최종 이미지가 빌드 후 제품 양산을 위해서 공장에서 라인이 기다리고 있는 상황이면 관리자들은 똥 마려운 강아지처럼 안절 부절 하면서 눈을 희번득거린다. 이들은 곧잘 개발자들의 경제 관념을 운운 하며 새로운 이미지를 제때에 만들지 못할 경우 생산 라인당 몇명의 작업자가 몇시간 동안 작업한 것이 날아가며, 이때 발생하는 손실 및 고객신뢰 실추등을 읊어대기 시작할 것이다. (이 단계에 이르면 관리자는 이미 패닉 상태에 있다고 보면 정확하다.)

이쯤 되면 개발 경력이 짧거나 소심한 개발자들은 서서히 관리자들과 함께 미쳐가기 시작하며 이때 누군가 중심을 잡아주지 않을 경우 개발팀 전체의 패닉으로 프로젝트가 산으로 가기 시작한다. ( 정말 최악의 시나리오군..)

어느정도 경력이 있는 개발자들은 이럴 때 빛을 발한다. 그들은 평정심을 유지하며 설령 마지막 순간에 발생한 문제의 모든 증상이 자신을 지목한다고 하더라도 최대한 객관적으로 문제를 살펴 정확한 원인을 찾아낸다. 일단 문제의 원인이 밝혀지면 (설명 문제의 원인이 자신이 짠 코드라고 하더라도) 현 상황에서 최대한 빨리 문제를 수습 가능한 대안을 찾고 제시한다. (나는 이런걸 알고 있으면서 왜 이렇게 못할까? 왜 나는 늘 전전긍긍하며 내 문제가 아니기만을 기도할까? 신앙심도 전혀 없으면서... ㅋ)

사실 이시점에서 개발자들이 할 수 있는 일은 별로 많지 않다. 다만 문제가 자신의 문제가 아니라 밝혀졌을 때 가슴을 쓸어내리며 문제를 만든 다른 개발자를 욕하는 대신에(이건 정말 최악이다 이런 개발자라면 짐싸라), 함께 다른 대안을 찾을 수 있도록 도와줄수 있을 따름이다.

그럼 이 시점에서 관리자는? 관리자는 이미 이 시점에서 문제를 만든 개발자보다 더 큰 원죄를 가지고 있다. 이를 인식하고 반성한다면 앞으로 훌륭한 관리자가 될 자질이 있는 사람이라고 생각한다. 만일 당신이 관리자인데, 문제 발생의 이유를 개발자에게서 찾고 있는 당신을 발견한다면 제발 프로젝트를 위해서 관리자 자리를 포기하여 주기 바란다. 어짜피 최종 프로젝트가 성공하고 못하고에 대한 평가는 팀원 모두가 나누어서 짊어지게 된다. 당신 혼자 욕 먹지도 당신 혼자 칭찬 받을 수도 없다는걸 항상 기억하라.

또한 만일 당신이 누구 한명에게 죄를 뒤집어씌워 당장의 비난을 피한다면 다음에 누가 당신이 돌격 앞으로를 외칠때 앞서서 뛰쳐나가려 할지 생각해 보기 바란다. 어짜피 당신의 관리자로서의 생명은 절단났다고 봐도 될 것 이다.