지금 다니고 있는 회사나 팀에는 어떤 방법론을 사용하시나요?

내가 학교에 다닐때 소프트웨어 개방방법론은 거의 관리기법/I 비슷한 얘기만 가득한 답답하고 지겨운 수업이었다. 이거를 어따쓰나 생각했는데, 나중에 직장생활하면서 SI 프로젝트를 하면서 지겹도록 사용하게 된다.

아마 왠만한 IT쪽 개발자들은 아직도 '분석 - 설계 - 구현 - 시험'으로 구성된 관리기업/I 프로세스를 경험하고 있을 것이다. 나중에 내가 PL을 거쳐서 PM이 되니까 아..이게 장난이 아닌 것이다.

내가 가끔 개발자들을 면접 볼 때 하는 질문이 뭐냐 하면, 'Due date와 Quality 중에 중요한 것이 무엇인가?'라는 질문이다. 내 생각에 이 질문은 별로 좋은 질문이 아니데, 왜냐하면 Due date를 맞추어 Quality가 보장된 결과물이 고객에게 전달되어야 하는 것이 정답이기 때문이다.

물론 SI 프로젝트도 위에서 언급한 위험요소를 안고 가지만, 정해진 기한과 협의된 스펙이라는 목적을 달성하기 위해서 어떻게든 처리를 하게 되는데, 문제는 회사 내에서 진행하는 개발에 대해서는 외부 프로젝트 만큼 긴장감이나 압력이 없어서 그런지 몰라도 쉽게 일정을 지연하게 된다. (Quality를 Due Date보다 중요하게 생각하는지 몰라도)

특히나 지금처럼 서비스를 하고 있는 사업부에서는 어떤 식으로 개발을 진행해야 할지가 골치아픈 문제이다. 대부분의 SI 프로젝트는 말 그대로 프로젝트이기 때문에 정해진 기한안에 처음에 협의된 스펙을 구현하면 된다.

그런데 서비스는 1) 기획의 변경, 2) 버그 픽스 등이 수시로 이루어지다보니 처음에 기획된 내용을 개발하다 보면 일정이라는 것이 쉽게 지연되게 된다.

또 하나는 팀원이 4명이면 최소한의 퍼포먼스는 1+1+1+1 = 4 즉, 4명분의 일을 해내는 것이다.(최소한의 퍼포먼스) 그런데 대부분의 개발팀은 1X1X1X1 = 1 이 되는 식으로 개발이 진행되는 경우가 많다. 왜냐하면 대부분의 개발자들이 혼자서는 잘 하는데 협업을 하는 것에 많은 사람들이 익숙하지 않다는 점이다.

수시로 변경되는 요구사항에 적절한 대응을 하고 버그가 거의 없는 안정된 서비스를 만들기 위해서는 어떻게 해야 할까?

삽질(rework)을 피하고 목표하는 품질을 계획하는 일정에 맞추어 만들어내고 싶다.

덧) 그래서 이번주에 사이냅소프트의 전경현 사장님의 배려로 사이냅소프트의 회고를 참관하러 간다. 다녀오면서 후기를 남기도록 하겠다.


 마루날의 雜學辭典|잡학사전을 RSS리더로 편하게 구독해서 보세요~