개발방법론 유감 3/3

  그동안 개발자들이 자기의 권익을 제대로 찾기 위해 여러가지 움직임이 일고있다.
2013년도에는 서울시에서 IT 개발자들을 모아 그들의 의견을 청취하기도 했는데, 깜작 이벤트로 끝난 것 같다. 그 뒤 개발자에게 직접 의견을 청취하는 노력을 별로 보지 못했다.

 

  그러나 내가 보기엔 다른 분야는 모르겠으나 공공 SI 분야의 개발자들은 그 능력이 예전만 못하다는 느낌을 받는다. 물론 여기엔 여러가지 이유가 있다. 나중에 시간이 되면 이 부분에 대해서도 얘기를  해보고 싶다.

개발자로써 당당한 권리와 정당한 대가를 받고 싶다면 능력을 우선 보여줘야 한다. 잘 알다시피 코딩 실력외에 철저히 업무를 분석하는 능력과 설계 능력을 갖춰야한다. 이럴려면 문서 작성 능력과 리뷰하는 능력도 잘 갖춰져야 한다. 말도 안되는 표현으로 설계서를 작성하거나, 회의록조차 제대로 정리할 줄 모르면서 좋은 분서과 설계 산출물이 나올리 만무하다. 이것들은 전에도 말했듯이 결코 며칠간의 세미나나 강의로는 물론 대학에서 몇 학기를 배운다고 해서 얻어지는 것이 아니라, 실무를 통해서 오랜시간에 걸쳐 자기도 모르는 사이에 싸여가는 것이다. 해서 프로젝트에 임할 때는 이 부분을 명심하여 의식적으로 프로젝트 진행을 바라봐야 한다. 아울러 회사에서는 단순히 프로제트에 투입만 시킬레 아니라
별도로 이 프로젝트가 의미하는 것과 이번 프로젝트를 통해서 무엇을 얻을 건가를 일깨워 본인 스스로 별도의 미션을 수행할 수 있도록 도와 줘야 한다.

 

  지금까지 개발방법론에 대해서 말했다. 한편으로는 개발방법론이 과연 필요한가를 역설했다. 마지막으로 다시한번 강조하지만 개발방법론은 결코 그 자체가 목적이어선 안된다. 프로젝트의 시간과 자원을 줄여줄 수 있다면 그게 그 프로젝트에 가장 적합하고 훌륭한 방법론임을 명심하자.

그래서 그리 크지 않는 규모의 프로젝트에는 PM 의 능력에 따라 굳이 개발방법론이 적용되지 않더라도 성공할 있다고까지 생각했다. 여기서 하나 간과한 부분이 있는데 바로 관리방법론이다.

 

  사실 개발방법론은 제대로 적용하지도 않으면서 발주처든 회사든 PM이든 다들 신경쓰면서 관리방법론은 제안서의 한 장(chapter)을 차지하면서도 그렇게 신경쓰지 않는다. 나는 오히려 개발방법론보다 관리방법론이 어쩌면 프로젝트 성공에 더 중요한게 아닌가 생각한다. 프로젝트에 문제가 발생했을 때 그 원인을 개발방법론을 통해서 찾기 보다는 오히려
관리적인 측면에서 찾는 편이다. 그럼에도 관리방법론을 그만큼 중요시 하거나 추적하지는 않는다.

 

  이 관리방법론에 대해서 여기서 이어서 얘기하는 것은 무척 곤할 것 같다. ㅠㅠ
관리방법론에 기초한 여러가지 이슈를 얘기하겠지만, 관리방법론 자체를 갖고 나중에 다시 이야기해 보도록 하자.