데모 중심 개발

일반적으로 SaaS 서비스는 데모 요청이라는 방법으로 고객을 확보한다. 그래서 솔루션 회사의 업무 방식 중에서 가장 큰 문제는 데모를 위한 보여주기식 개발을 하게 될 가능성이 높다는 것이다. SaaS 제품에 필요한 기능을 어느정도 사전에 고민해서 개발했음에도 고객 확보를 위한 라이브 데모에 있어서 필요하다고 생각되는 요구사항은 생각보다 많이 발생한다. 그러나, 이러한 데모 중심 개발(Demo Driven Development)의 단점은 갑작스러운 일정에 의해 진행되기 때문에 사이드 이펙트가 발생할 가능성이 상당히 높아진다.

기능 플래그로 확장되는 설정 지옥

데모 중심 개발에서는 고객마다 필요한 기능이 다양해지므로 기능 플래그를 가장한 설정 지옥으로 이어질 수 있다. 라이브 데모를 진행했던 잠재 고객이 서비스를 이용하지 않는다면 해당 기능 플래그는 잊혀지고 남아있게 될 가능성이 높아진다. 전혀 다른 잠재고객도 원할수도 있기 때문에 더이상 사용하지 않는다고해서 깔끔하게 삭제하기는 어렵다.

완성된 제품이라는 착각

사업팀에서 라이브 데모를 진행하고자 하는 경우 라이브 데모는 완성된 제품이라는 착각을 하기 쉽다는 것이다. 라이브 데모를 진행하는 이유에는 고객 확보도 있지만 잠재 고객의 빠른 피드백을 통해 부족한 기능을 확장하는 것이 포함된다. 하지만, 현실은 보여주기식 개발이 되기 쉬운데 라이브 데모를 진행하고나서 고객의 피드백이 전혀 전달되지 않거나 희망적인 내용만을 이야기하는 경우도 많다. 사업팀에서는 희망적인 부분에 관심이 많은 반면에 개발팀에서는 데모를 진행하는 제품에도 부족하다고 느끼고 있기 때문에 괴리감이 크다.

이처럼, 데모 중심 개발은 애자일 프로세스처럼 계륵인 것 같다.