프로젝트 사고 다발구간

  차를 몰고 가다보면 가끔 '사고다발구간'이라는 표지판을 볼 때가 있다. 그 구간 또는 지역을 하나하나 살펴보면 별 문제가 없는 것처럼 보인다. 아마도 그 구간의 도로 여건, 신호체계, 교통량 등 여러 가지 주변 특성으로 인해 사고가 다른데 보다 빈번하게 일어나는 게 아닌가 싶다.

  마찬가지로 SI 프로젝트에도 '사고다발 프로젝트'가 존재하는 것이 아닌가 하는 생각이 든다. 정리한 것은 없지만 괘 경험이 있는 PM 이나 개발자들은 나름대로 사고다발의 조건을 알고 있을 것 같다. 물론 도로의 사정과 교통체계 등 여러 가지가 변하듯이, 프로젝트도 환경이 변함에 따라 그 조건도 변하고 있는 것 같다. 뻔히 보이는 위험이 있는 경우가 아니라 별개로 보면 문제가 없는데 사고가 발생하는 프로젝트의 경우 또는 조건을 정리해 보는 것도 의미가 있을 것 같은데 아쉽게도 정리해 놓은 게 없다. 이제라도 이런 불가사이한 '사고다발 프로젝트'의 조건을 보게 되면 꼭 정리해야할 것 같다. 원인까지 찾을 수 있으면 하는 바램에서이다.

 

  연말이라 다이어리가 생기고 해서 문득 든 생각이지만, 한창 개발을 할 때는 일반적인 사무용 다이어리 보다는 대학 노트가 정리하는데 더 좋았다. 그 노트 한권이 끝나면 대개 프로젝트도 마무리 되곤 했던 것 같다.

그 노트를 지금까지 보관했다면 하는 아쉬움이 든다. 

만약 지금 개발하거나 한참 설계를 담당하는 개발자가 있다면 대학 노트에 자신이 맡은 업무의 진행을 서브노트하길 권한다.

 

  또한 단순히 텍스트 위주로 기록하는 것 보다 시각적으로 표현하는 것이 좋을 것 같다. 그러면 나름대로 기호나 분류도 정해질 것이다. 

프로젝트가 끝나고 그 노트를 다시 복기하게 되면 분명 얻는 게 있다고 본다. 그것은 마치 고3이나 대학생이 선배에게서 얻는 귀중한 족보같은 자료로 쓰이지 않을까

 

  각설하고 다시 사고다발 프로젝트로 넘어가 보자. 아무리 정리한 게 없고 생각나는 게 없다고 하더라도 하나 쯤은 예를 들고 끝내야 되지 않겠는가.

고용노동부 산하 기관 프로젝트 였다.

 

[좋은 조건]

1. 고객의 담당자는 철저했다.

프로젝트가 시작되기 전에 개발자를 손수 지목했다.

그 담당자의 수첩엔 그동안 그 기관에 투입된 개발자의 정보가 빼곡히 기록되어 있었다.

단순히 업무 내용뿐만 아니라 성향이나 성격에 대해서도 기록하고 있었다.

따라서 가장 베스트한 인력이 투입되었다.

 

2. 고객의 담당자의 열정은 대단했다.

아예 책상을 개발실로 옮겨서 프로젝트가 끝날 때까지 거기서 업무를 보았다.

수행팀에게는 즉각 응답을 얻을 수 있었고,

발주처는 효과적으로 수행팀을 통제할 수 있었다.

따라서 진척율이나 문제 해결이 즉시적이었다.

 

3. 그 기관이 투입인력이 정규직인지 프리랜서인지를 바로 알 수 있는 능력이 있었다.

어느 정도 고객에게 증명이 된 업체라면 모를까, 처음 수행하는 경우 반드시 정규직으로만 투입되어야 한다.

따라서 개발 인력의 안정성이 보장되었다.

 

4. 투입된 PM 과 PL은 물론 개발인력도 해당 기관의 프로젝트와 동일한 업무를 구축한 경험이 있는 인력이었다.

그들은 팀워크도 좋았고,

고객의 성향도 잘 알고 있을 뿐만 아니라

심지어 유관기관의 담당자와도 두터운 친분이 있었고, 신뢰가 있었다.

따라서 그들은 이미 그 프로젝트의 성공 전략을 갖고 착수하였다.

 

그런데 이 프로젝트는 다음과 같은 결과를 낳았다.

 

- 프로젝트가 지연 되었고

- 예산이 오버되었으며

- 2 교대 야근을 장기간 하였다.

- 오픈 후 심각한 오류로 공문을 받기도 하였다.

 

  이 기관은 대부분 담당자들이 밀착해서 관리하는 특성이 있다. 위의 '좋은 조건'을 대부분 요구하고 그렇게 진행시킨다.

그럼에도 불구하고 대기업이든 중소기업이든 사고가 심심찮게 발생한다. 프로젝트의 '사고다발 기관'인 것이다.

정확한 원인은 모른다. 단지 추측할 뿐이다.

 

 

[어설픈 추측]

1. 고객의 담당자가 너무 깊숙이 관여를 하게 되면 수행팀은 지시만 기다리고, 그 오더만 할려고 하게 된다. 따라서 창의적인 새로운 생각이나 다른 관점에서 바라보는 일은 생겨나질 않는다.

고객 담당자는 직접 업무를 짜고 지시를 하니 피곤하고 짜증이 난다.

그리고 그 오더를 잘 이행하지 못하게 되면 화를 내게 되고, 수행팀은 점점 더 경색이 되어, 마침내 바보가 되고 만다.

이것이 악순환처럼 되풀이 된다.

 

2. 베스트 인력, 유능한 PM 과 PL, 고객의 열정 <= 이런 완벽한 궁합이 오히려 이슈나 위험관리를 등한시 하게 않나 하는 생각이 든다.

따라서 초기에 이슈가 발생되면 가볍게 보고 적당히 넘어가는 경향이 발생한다.

하지만 시간이 경과함에 따라 그 사이각의 거리는 엄청 벌어져 큰 문제가 되어 눈앞에 드러나기 마련이다.

 

3. 이 프로젝트의 결정적인 원인은 개발적 이슈보다 사업관리의 미스였다.

프로젝트 도중 관련 일부 시스템에 해당하는 부분의 법이 개정되었다.

투입된 인력들은 이미 이 시스템을 개발하고 구축한 경험이 풍부한 베테랑들이었다.

그러다 보니 쉽게 수정이 가능할 것으로 짐작하고,

이 추가 업무를 선뜻 수용해 버렸다.

고객 담당자도 이들의 능력을 잘 아는지라 꼼꼼히 다지지 않고 그냥 넘어갔다.

하지만 막상 파악에 들어가니 거의 새로 개발하는 수준이었던 것이다.

 

  문제를 해결할 기회가 없었던 것은 아니었다. 처음 식별되었을 때, 이 부분을 다시 이슈로 다른 해결책을 모색했어야 하는데, 파금 효과를 과소평가하고 그냥 진행하기로 한 것이었다. 자기들의 능력을 과신한 것 아니었을까 싶다.