하드코드에 "죽음의 행진, 관리층이 문제야!"에 있는 내용.

죽음의 행진.. 우리나라로 따지면 무한 야근 막 이런거 -ㅅ-;;
다행히 입사한지 1년이 넘었지만 야근은 한번도 안했다.
되도록 일찍 퇴근하려고 노력하고, 집에 가면 기술 서적이나 방법론 개념 책들을 조금씩 읽는다.
많이 읽으면 한달에 2~3권, 아니면 1권.. 출퇴근할때나 잠잘때는 소설 들도 읽고.

아무튼 아래 컬럼은 개발자나 PM등 관리층에게도 도움이 되는 글이다.
야근을 피하고 윤택하고 아름다운 개발자 생활을 만끽하자 :-)

실패하는 이유.
멍청하고 무지한 관리층에게 고하노라, 죽음의 행진은 다음과 같은 이유로 실패하느니...

* 실패를 목표로 삼는다 - 처음부터 할 일은 너무 많고 시간이 너무 없는 프로젝트다. 당연히 실패한다.
* 편법을 부추긴다 - 일정에 쫓기면 당연히 편법이 난무한다. 그런데 안타깝게도 편법은 품질을 낮추고 위험을 높인다. 단기간에 작은 업무라면 무사히 넘어갈지도 모르겠다. 그러나 프로젝트가 지연되면 품질은 낮아지고 위험은 커져 결국은 문제를 일으킨다.
* 생각할 시간이 없다 - 효과적으로 일하려면 여유 시간이 필요하다. 읽고, 생각하고, 토론할 시간이 있어야 한다. 이런 시간이 없으면 맨 처음 떠오르는 추측을 적용한다. 맨 처음 생각이 옳을 확률은 낮으므로 당연히 설계와 계획이 엉성해지고 품질이 떨어진다. 결국 치명적인 결함이 드러나거나 완전히 뒤엎어야 하는 사태가 발생한다.
* 대화할 시간이 없다 - 모든 문제는 대화 단절과 오해에서 비롯된다고 주장해도 과언은 아니다. 심지어 우수한 팀도 대화 부족으로 실패하는 경우가 흔하다. 업무량이 과도하고 여유가 없는 환경에서는 대화가 줄어들고 대화의 효율성도 떨어진다. 대화 단절이 심할수록 프로젝트는 성공하기 어렵다.
* 긴장, 스트레스, 기능 장애가 발생한다 - 일정에 쫓겨 마음이 급하면 가장 먼저 너그러움이 사라진다. 업무에 사적인 감정이 개입된다. 다른 팀원의 실수를 부풀리고 곡해한다. 목소리가 높아지고 급기야는 대화가 끊긴다.
* 사기가 떨어지고 팀이 와해된다 - 가족과 친구들에게 소홀하면서 긴장과 스트레스 속에서 장시간 이하면 팀이 신체적으로나 정신적으로 지친다. 프로젝트가(당연히) 일정과 품질 목표를 못 맞추면 팀원들은 한순간 인내심을 잃는다. 운이 좋으면 프로젝트가 끝날 즈음 그룹을 옮기느 정도로 그친다. 운이 나쁘면 회사를 뜨거나, 이혼을 당하거나, 건강을 해치거나, 위험한 뭔가에 중독되는 지경에 이른다.
참고로, 팀원이 자발적으로 늦게 남아 일하는 경우를 죽음의 행진으로 오해하는 관리자도 많다. 죽음의 행진은 역학이 전혀 다르다. 죽음의 행진에 내몰리는 팀원은 어쩌 수 없이 늦게까지 일한다. 반면, 스스로 늦게까지 일하는 팀원은 대개 일이 좋아서다. 필요하면 여유 시간도 충분히 갖는다. 일정에 쫓기지 않으므로 편법으로 땜질할 이유도 없다.
* 회사를 불신하게 된다 - '죽음의 행진 = 뭔가 잘못되어 나타나는 현상'이라는 공식은 두말하면 잔소리다. 죽음의 행진을 지켜보는 직원과 고객과 협력업체는 팀에게서 헌신이 아니라 무능함을 느낀다. 진짜 문제는 덮어두고 죽어라 일해 봤자 회사 위신과 이미지만 구겨진다.
* 문제를 해결하지 못한다 - 컴퓨터 앞에 오래 앉아 있다고 근본적인 문제, 즉 '할 일은 많은데 시간이 부족하다' 라는 문제가 사라지지 않는다. 근본적인 문제를 해결하지 않는 한 상황은 나아지지 않는다.
* 선택의 여지가 줄어든다 - 시간을 들여서 제대로 설계하고 계획하지 않으면 제품에 치명적인 결함이 생기고 대다수 작업을 다시 해야 한다. 팀은 대화가 끊기고, 오해가 난무하며, 서로 잡아먹으려고 으르렁거린다. 사기는 떨어지고, 출시 능력을 의심받으며, 그러고도 일정과 품질 목표를 놓친다. 물론 원래 문제는 그대로 남아 있따. 이런 지경에 이르면 프로젝트는 선택의 여지가 줄어든다. 결국 품질을 낮추고, 일정을 늦추고, 죽음의 행진을 계속 하는 수밖에 없다. 멋지지 않은가?

전환점
자, 할 일은 너무 많은데 시간이 너무 없다. 어떻게 해야 할까? 현실적인 측면에서 답은 대단히 쉽다. 할 일이 너무 많은 이유와 시간이 너무 없는 이유를 찾아내면 된다.
"일정와 요구사항이 위에서 내려왔거든요"는 답이 아니다. 왜 그런 일정과 요구사항이 내려왔을까? 일정과 요구사항을 지키지 못하면 관리층은 어떻게 대응할까? 일정을 늦춰줄까? 얼마나? 요구사항을 쳐낼까? 어떤 기능을? 프로젝트 역학을 근본적으로 바꿀 방법은 없을까? 일단 위에다가는 주어진 날짜와 요구사항을 목표로 삼겠다고 말한 후 자체적으로 최악의 상황을 계획한다.
즉, 최악의 상황을 고려해 계획을 세운다. 반드시 지킬 최후 일정과 반드시 넣을 최소 기능을 계획으로 세워본다. 그래도 시간이 부족하다면 관리층에게 경고한다. 이런 프로젝트는 애당초 가망이 없다. 최악의 시나리오가 충분히 달성 가능하다면 여기에 총력을 기울인다. 팀원들에게 목표를 초과하면 3.5점 이상을 목표에 못 미치면 3.0점 미만을 주겠다고 말한다.(마이크로 소프트에선 4.5점 만점)

남들이 가지 않은 길
이로써 팀은 죽음의 행진에서 벗어나고, 상황을 개선할 여유 시간이 생긴다. 십중팔구 목표도 초과 달성한다. 그러면서도 편법을 쓰거나, 미숙한 결정을 내리거나, 서로 잡아먹는 일도 없다. 필요한 기능을 기한 내에 완료하면서 동시에 협력업체와 고객에게서 신뢰도 얻는다.
그럴 듯하게 들리지만 감정적으로 쉽지 않은 일이다. 최악의 상황을 계획하려니 프로젝트를 포기하는 느낌이 든다. 유약한 겁쟁이가 되는 듯하다. 난관을 극복할 능력이 없다고 자인하는 꼴이 아닌가? 역설적이게도 실제는 정반대다.
위험을 회피하는 행동이 오히려 유약하고 비겁하다. 최악의 가능성을 무시하는 태도가 오히려 기만적이고 무책임하다. 용기를 보여라. 진신을 인정하라. 영리한 태도로 협력업체와 고객과 직원을 고통에서 구하라. 팀과 삶과 자신감을 보호하면서 프로젝트를 성공으로 이끌어라.