'개발 프로세스'에 해당되는 글 1건

  1. 2009.02.23 1.1 소프트웨어 프로세스 모델 (2)

 


 

마이크로소프트 PLC(Product Life Cycle)에서는 Product – Project – Feature 로 나누어서 접근하고 있다.

 

아무래도 마이크로소프트는 서비스 보다는 패키지 소프트웨어를 개발해서 판매하는 것을 주 업으로 하고 있어서 패키지 소프트웨어 개발 라이프 사이클을 잘 표현해 주고 있다.

그렇다고 꼭 패키지 소프트웨어에서만 적용이 가능한 것은 아니다.

어느 정도 차이는 있지만 인터넷 서비스에 적용하기에도 무난할 것 같다. 그리고 SI개발에도 도움이 될 것이다.

 

앞의 글에서 언급한 것처럼 항상 시작은 무엇(What)을 만드냐에서 시작한다.

하나의 제품(인터넷 기업에게는 서비스가 제품이 될 것이다.)을 만들기 위해 무엇을 만드냐는 것은 회사 전체의 전략이나 비전에 따라 결정이 될 것이다.

자동차회사에서 세탁기를 만든다면, 아무래도 좀 이상할 것 같다.

 

그럼 제품이 회사의 방향과 전략에 다르지 않다면, 왜 만들어야 하는지 당위성이 있어야 할 것이다. 우리가 살아가면서 필요하다고 무조건 물건을 구입하지 않는 것처럼, 기업 또한 필요하다고 무조건 만들지는 않을 것이다. “필요는 하지만 우리가 지금 정말 만들어야 하나?”

분명 여기서 생각해야 하는 것이 ROI(Return Of Invest) 일 것이다. 지금 수익성은 떨어지더라도 향후 회사의 전략상 필요한 것이라면, 당연히 모험을 해서 투자를 해야 할 것이다. 이 외에도 고려 해야 할 것이 훨씬 만을 것이다.

 

자 이제 만들기로 결정을 했다면, 개발의 입장에서는 전체 개발 공정을 어떻게 할 것인지, 업그레이드를 위한 장기 계획도 있어야 할 것이지만, 만들 무엇(What)에 대해 몇 가지 원칙이 필요할 것 같다.

 

고객, 비전, 방향, 책임

 

고객에게 전달할 제품의 가치는 무엇인지, 다양한 각각의 고객에게 줄 수 있는 비전은 무엇인지, 제품의 발전 방향에 대한 일관되고 신뢰할 수 있는 로드맵제품으로 인한 책임은 무엇인지를 개발에 앞서 결정해야 할 것이다.

 

SI 개발자들은 이런 이야기에 대해 이건 영업이나 PM이 할 일이고, 내 일은 아닌 것 같다고 대부분 생각하는 것 같다. 지금 맡겨진 일만 해도 태산이고, 스트레스 많은데 머 이런 것까지 라고 이야기 할 것이다. 다른 건 다 필요 없고, 내가 만들어야 하는 모듈이나 프로그램에 대해서만 정확히 이야기 해 주고 뒤에 다른 말만 안 해줘도 정말 고마울 다름이다.

그런데, 이렇게 일을 하면, 재미가 없다. 옆에서 보기만 해도 참 재미 없을 것 같다.

 

제가 만난 분 중에 SI 개발만 15년 이상 하신 분도 더러 있다. 비슷한 경력을 일 했으면, 실력도 비슷할까? 그건 아닌 것 같다. 정말 천차만별이다. 정말 하기 싫은 일을 밥벌이로 15년을 해도 생각해도 실력이 5년 정도 개발한 개발자와 별 차이를 못 느낀다. 거기에 비해 10년 정도 했는데도 진짜 대단하다는 생각이 드는 분들 또한 많다.

왜 이런 차이가 생기는지 한번 생각해 보시고, 그게 무엇일지도 한번 생각해 보시면, 내가 어떤 개발자가 될지 모습이 보일 것이다.

 

이외에도 제품에서 고려 하고 계획 해야 할 것들은 더 많을 것이지만, 이제 Project를 보자.

Value Proposition에 대해서 프로젝트 계획을 시작하면, 먼저 프로젝트의 최종 목표가 있을 것이다. 이 목표를 달성하기 위해 마일스톤과 기능에 대한 일정 그리고 기능의 우선 순위 리스트를 정한 후 엔지니어링 표준을 정해야 한다. 이제 우리가 앞 글에서 이야기 했던 구현에 대한 방법론 적용부터 디자인 등 이제 개발자들이 본격적으로 해야 할 일들이 슬슬 늘어나기 시작한다.

 

Feature 에서는 각 피처 팀들이 혼자 개발을 하는 것이 아니라 다른 팀과 지속적으로 상호작용하면서 애자일 방법을 사용해 개발을 진행하게 된다. 물론 지속적인 반복을 통해 각 빌드마다 QG(Quality Gate)를 통과 해야만 외부에 자신들이 자신 있게 만든 기능들을 공개하고 평가 받을 수 있다.

 

이런 과정을 거치면서 개발자들은 자신이 만들고 있거나 만들고 있는 제품에 대해 그리고 그 프로젝트에 작게는 자신이 참여한 피처에 자부심을 가지게 되는 것 같다.

아무래도 패치지 소프트웨어나 큰(사용자가 많은) 웹사이트의 개발자들이 이런 부분에 있어서는 자부심을 가질 수 있는 여건이 되는 것 같다. 게임의 경우에는 게임 마지막이나 중간 인트로 부분에서 개발에 참여한 사람을 영화처럼 보여주는데 이것 또한 개발자들에게 동기 부여가 되는 것 같다.

마이크로소프트에서는 제품 개발에 참여한 개발자에게 제품 출시와 관련해 특별한 기념품이나 제품의 버전 별로 참여한 사람의 이름을 돌에(?) 새겨 주는 것도 한다.

 

개발자에 대한 대우는 단지 높은 급여뿐만 아니라, 자부심을 가지고 일을 할 수 있는 환경 또한 절 때 무시 할 수 없을 것이다.

 

이렇게 하고 PLC를 넘어가기에는 아쉬움이 남는 것 같다.

실제 개발 중 개발자에게 가장 많은 스트레스를 줄 QG(Quality Gate)에 대해 알아보고, 품질 프로세스에 대해 살펴보자.

 

 

Posted by SF공장장

티스토리 툴바