프로젝트가 막바지에 이르면 개발자와 관리자 모두 패닉상태가 되기 쉽다. 이미 code freeze일정이 지나 validation team에게 이미지가 전달되었지만, 잇달아 발생하는 개발자의 sanity test failure report는 별다른 위기조차 되지 않는다. 왜냐면 곧이어 validation team에서 "진짜" 문제들을 쏟아낼 것이기 때문이다. 이쯤되면 이미 validation team으로 부터 몇번의 양해를 구해서 이미지를 다시 build하였기 쉽상이지만 아직 절망에 이를 단계는 아니다.
- (사실 validation team이 그나마 "진짜"문제를 쏟아내주면 그것만으로도 고마운 일이다. 최근에 투입된 "초짜" tester가 등록하는 수많은 "가짜"문제들의 홍수에 질식해 본 적이 있다면 "진짜"문제들은 차라리 고맙기까지 하다)
만일 최종 이미지가 빌드 후 제품 양산을 위해서 공장에서 라인이 기다리고 있는 상황이면 관리자들은 똥 마려운 강아지처럼 안절 부절 하면서 눈을 희번득거린다. 이들은 곧잘 개발자들의 경제 관념을 운운 하며 새로운 이미지를 제때에 만들지 못할 경우 생산 라인당 몇명의 작업자가 몇시간 동안 작업한 것이 날아가며, 이때 발생하는 손실 및 고객신뢰 실추등을 읊어대기 시작할 것이다. (이 단계에 이르면 관리자는 이미 패닉 상태에 있다고 보면 정확하다.)
이쯤 되면 개발 경력이 짧거나 소심한 개발자들은 서서히 관리자들과 함께 미쳐가기 시작하며 이때 누군가 중심을 잡아주지 않을 경우 개발팀 전체의 패닉으로 프로젝트가 산으로 가기 시작한다. ( 정말 최악의 시나리오군..)
어느정도 경력이 있는 개발자들은 이럴 때 빛을 발한다. 그들은 평정심을 유지하며 설령 마지막 순간에 발생한 문제의 모든 증상이 자신을 지목한다고 하더라도 최대한 객관적으로 문제를 살펴 정확한 원인을 찾아낸다. 일단 문제의 원인이 밝혀지면 (설명 문제의 원인이 자신이 짠 코드라고 하더라도) 현 상황에서 최대한 빨리 문제를 수습 가능한 대안을 찾고 제시한다. (나는 이런걸 알고 있으면서 왜 이렇게 못할까? 왜 나는 늘 전전긍긍하며 내 문제가 아니기만을 기도할까? 신앙심도 전혀 없으면서... ㅋ)
사실 이시점에서 개발자들이 할 수 있는 일은 별로 많지 않다. 다만 문제가 자신의 문제가 아니라 밝혀졌을 때 가슴을 쓸어내리며 문제를 만든 다른 개발자를 욕하는 대신에(이건 정말 최악이다 이런 개발자라면 짐싸라), 함께 다른 대안을 찾을 수 있도록 도와줄수 있을 따름이다.
그럼 이 시점에서 관리자는? 관리자는 이미 이 시점에서 문제를 만든 개발자보다 더 큰 원죄를 가지고 있다. 이를 인식하고 반성한다면 앞으로 훌륭한 관리자가 될 자질이 있는 사람이라고 생각한다. 만일 당신이 관리자인데, 문제 발생의 이유를 개발자에게서 찾고 있는 당신을 발견한다면 제발 프로젝트를 위해서 관리자 자리를 포기하여 주기 바란다. 어짜피 최종 프로젝트가 성공하고 못하고에 대한 평가는 팀원 모두가 나누어서 짊어지게 된다. 당신 혼자 욕 먹지도 당신 혼자 칭찬 받을 수도 없다는걸 항상 기억하라.
또한 만일 당신이 누구 한명에게 죄를 뒤집어씌워 당장의 비난을 피한다면 다음에 누가 당신이 돌격 앞으로를 외칠때 앞서서 뛰쳐나가려 할지 생각해 보기 바란다. 어짜피 당신의 관리자로서의 생명은 절단났다고 봐도 될 것 이다.
댓글 1개:
이글을.. Junny Kim, Nick Do, Harry Kim 등등에게.. 익명으로 보낼 수 없을까..?
- written by "build 후 문제를 자주 만드는 사람"
댓글 쓰기