넣는 것 보다 빼는 것이 더 어렵다.
RSS Feed
초창기에 좋은 소프트웨어로 성공하는 업체들이 지속적으로 성장하지 못하고 고전을 면치 못하는 이유는 여러가지가 있다. 그중 하나가 제품이 점점 과도하게 비대해지는 것을 꼽을 수 있다.
성공하는 회사들의 초기 제품은 간략하고 핵심적인 기능으로 사용자들의 요구를 만족시켰다. 하지만 시간이 흐를 수록 경쟁상대가 많아지고 선두를 유지하거나 따라잡기 위해서 제품은 기능은 경쟁 제품들의 모든 기능을 다 포함하기 시작하곤 한다.
고객이 많아질수록 고객들의 요구사항도 다양해지고 하나의 고객도 놓치기 싫어서 가능하면 모든 요구사항을 신제품에 다 우겨 넣으려곤 하다.
이렇게 온갖 기능이 다 포함된 제품을 우리는 "Kitchen Sink"라고 한다. 설거지통에 닦아야 할 그릇들이 잔뜩 쌓여 있는 모습을 상상해보라.
기본적으로 영업은 한명의 고객도 놓치기 싫어서 무조건 고객의 요구사항을 다 들어달라고 요청을 한다.
이것을 조정해서 새로운 제품의 전략을 수립하는 부서는 마케팅부서이다. 하지만 내 경험에 의하면 우리나라의 많은 소프트웨어 회사들은 마케팅보다 영업에 가깝다. 소프트웨어 제품 전략에서 중요한 것은 많은 기능을 넣는 것보다 얼마나 적은 기능으로 최대한의 고객을 만족시키느냐이다. 경쟁제품을 모두 조사해서 슈퍼세트의 제품을 기획하는 일은 쉽다. 어려운 일은 기능을 빼는 것이다.
기능을 빼는 과정에서 기존의 고객을 잃을 수도 있다. 하지만 이것이 두려워서 "Kitchen Sink" Software를 만든다면 더 큰 것을 잃을 수도 있다.
하지만 많은 사람들이 기능을 빼는데는 익숙하지 않다. 영업, 마케팅은 물론이고 마음씨 좋은 개발자들이 기능을 빼는 것을 주저하기도 한다. 그러면 제품의 아키텍처는 점점 복잡해지고 회생 불가능한 상태가 되곤한다.
스펙을 적을 때도 지원할 기능 외에 뺄 기능도 잘 기술해야 한다. 스펙에 지원하지 않을 기능을 적는 것은 지원할 기능을 적는것보다 더 중요할 때가 많다. 물론 모든 미지원 기능을 적는 것이 아니고 기존에 있던 기능을 빼거나 누구나 능히 포함될 것으로 생각하는 기능을 뺄때는 꼼꼼히 적어줘야 한다.
그래서 마케팅팀의 역할이 더욱 중요하다고 할 수 있다.
1%의 사용자도 쓰지 않는 수많은 기능을 개발하느라고 개발 비용은 훨씬 많이 들어가고 프로젝트가 망가져가는 것을 흔히 볼 수 있다. 중요한 것은 넣은 것이 아니고 빼는 것이다.
image by Kingfox
'프로젝트 > 요구사항분석' 카테고리의 다른 글
| 넣는 것 보다 빼는 것이 더 어렵다. (2) | 2013/05/14 |
|---|---|
| [공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다. (5) | 2013/03/14 |
| 소프트웨어 개발시 일을 작게 쪼개야 하는 이유 (0) | 2012/09/24 |
| 요구사항이 계속 바뀌기 때문에 스펙을 적을 수 없다. (4) | 2012/08/30 |
| 개발자의 취향 (0) | 2012/08/02 |
| 스펙을 제대로 작성하는 것은 구식이다? (2) | 2012/01/27 |
![[공지] 요구사항 분석 세미나를 실시합니다. - 마감되었습니다.](http://cfile23.uf.tistory.com/image/2317374851416CBC04B5EC)
저는 하위버전 호환성을 유지하는 것이 매우 중요하다고 생각합니다.
고객사에서 제품을 상위버전으로 업그레이드 했을 때 서비스가 안되는 부분이 생긴다면 이는 재앙에 가깝습니다.
조엘이 쓴 책에서도 MS 가 하위버전 호환을 유지하기 위해 얼마나 노력을 많이 했는지 언급되었던 것으로 기억합니다.
새버전 출시 시 마케팅 자료나 영업자료에서 그 기능을 삭제하는 것은 가능하지만 제품에서 물리적으로 삭제가 되는 것은 아니라고 생각합니다.
공감합니다.
소프트웨어 업그레이드 시 하위호환을 유지하기 위해서 많은 노력을 들이게 됩니다. 정말 잘 설계를 해서 꾸준히 하위 호환성을 유지하기도 하고 Migration 기능을 제공하기도 합니다.
여기서 지적하는 것은 기존의 기능을 무작성 빼자는 것이 아니고 전략적인 생각없이 경쟁 회사들의 기능과 특정 고객이 원하는 기능을 잔뜩 포함해서 키친씽크를 만들지 말자는 얘기입니다.
하위호환성을 유지하면서도 기존 기능을 없애거나 새로운 형태로 진화시키는 일은 종종 있습니다. 결국 기획팀에서 전략을 제대로 수립해야 겠죠.