복잡한 것을 복잡하게 만드는 것은 쉽지만 단순하게 만드는 것은 어렵다. 기업에서 판매하는 상품의 수, 상품의 기능 수, 보고서 양, 소프트웨어 아키텍처, 특정 기능 실현을 위한 클릭 수 등이 그 예다. 사무실이나 집이 별도의 노력이 없어도 쉽게 지저분해지지만, 정돈된 상태를 유지하는 것은 힘들다. 상품을 개발할 때 복잡성의 결과는 치명적이기 때문에 단순해지기 위해 많은 노력을 해야 한다. 상품개발 과정에서 발생하는 복잡도의 유형은 다음과 같다.  

 

 

 

상품의 복잡도 : 선택과 집중은 항상 옳다.  

 

 

 

 

유명한 맛집일수록 메뉴가 간단하다. 메뉴가 많은 음식점일수록 재료의 신선도가 낮고 맛도 별로일 가능성이 높다. 한 두 개의 메뉴만으로 음식점을 오랫동안 유지해왔다면 그 집의 음식 맛은 기본 이상이라고 인정해야 된다. 기업도 마찬가지이다. 상품 개수가 적을수록 영업, 마케팅, 구매, 생산, 조직 역할, 고객지원이 간단하여 상품원가도 낮아지고, 품질유지도 쉬워진다. 반대로 상품 개수가 많을수록 상품 운영이 복잡하여 직원의 실수할 가능성이 높아 고객에게 나쁜 경험을 제공하기 쉽다. 신상품을 기획하고 개발하는 노력이 1이라면 상품 운영은 고구마 줄기와 같아 거의 100에 가까운 노력을 필요로 한다.  

기업에서 출시하는 상품보다 단종하는 상품이 적다면 상품 개수는 증가한다. 상품을 단종하기 어려운 이유는 여러 가지 정치적인 요인 때문이다.

첫째, 특정 상품을 단종하면 그 상품에 관련된 사람들의 업무가 없어지기 때문에 관련 이해관계자들이 상품의 단종을 방해한다.

둘째, 단종 대상이 되는 상품이 어느 정도의 매출이나 이익이 있다면 그것을 포기하기 쉽지 않다.

셋째, 상품 세분화를 위해 구색 갖추기 식의 상품이 필요하다는 논리이다. 구색 갖추기 식의 상품은 상픔세분화의 논리로 살아남기도 한다. 

출시된 상품의 단종은 관련된 이해관계자들에게 감당하기 힘든 상처를 주기 때문에 경영층이 아니면 결정하기 힘들다. 경영층의 통찰력이 높고 상품 단종에 대한 조직원들의 공감을 얻을수록 상품 개수를 일정 수준 이하로 유지할 수 있다. 물론 단종보다 쉬운 것은 고객가치를 검증하기 전에는 상품개발을 하지 않는 것이다. 

 

 

 

상품기능의 복잡도 : 작게 개발한 후 검증된
요구사항을 추가한다.   

 

 

 

 

신상품 개발 또는 프로젝트는 투자에 대한 승인을 받기 힘들기 때문에 가급적 많은 기능을 기획하기 쉽다. 10억 규모의 개발 투자를 1억으로 나누어 10번 승인받기보다 10억의 투자를 한 번에 승인받는 것이 쉽기 때문이다. 한꺼번에 많은 기능을 개발할 때 부작용은 다음과 같다. 

 

첫째, 의도했던 가치를 창출하지 못하는 기능의 비율이 높아진다.

신상품 개발 또는 프로젝트에서 의도했던 가치 창출을 확인하는 방법은 직접 사용해보는 것이 가장 좋다. 따라서 투자의 낭비를 줄이기 위해서는 핵심 아이디어를 먼저 구현하여 사용해 보고 방향성을 확인해야 한다. 100개의 기능을 개발할 때 핵심기능 10개만 먼저 적용하면 나머지 90개 기능의 가치도 짐작할 수 있다. 

 

둘째, 요구사항들은 시간에 취약하다.

상품기획부터 출시까지 리드타임이 길수록 기획 시점에는 맞지만 출시 시점에는 틀릴 가능성이 있다. 뿐만 아니라 출시 전에 기능변경 가능성도 높아진다. 상품기능 개수가 적을수록 상품개발 리드타임이 짧아지기 때문에 요구사항 변경가능성이 낮다. 

 

셋째, 기능의 수가 많을수록 상품개선이 어려워진다.

상품 출시이후 기능을 개선할 때 기존 기능에 미치는 영향력을 분석해야 하는데 관련된 기능이 많을수록 기능개선 시간이 많이 걸리고 품질이슈가 발생할 가능성도 높아진다. 특히 사용자에게 가치제공도 미흡한 기능 때문에 상품개선이 어려워지는 것은 이중의 낭비다. 

 

넷째, 프로젝트 규모가 커질수록 추정의 신뢰도가 낮아지고 개발비용은 기하급수적으로 증가한다.

프로젝트 추정의 신뢰도가 낮아지면 프로젝트 성공의 가능성이 낮아진다. 개발규모가 커지면 검증되지 않은 기능개발에 많은 예산을 투입한다.

상품 개수는 프로젝트 관리자가 영향을 미치기 힘들지만, 상품 기능 수는 프로젝트 관리자가 영향을 미칠 수 있다. 프로젝트 규모를 줄이는 것이 바람직하지만, 그것이 힘들다면 스프린트로 나누어 개발하고 검증하는 방식을 취할 수도 있다. 출시를 하지 않아도 고객이 사용할 수 있는 수준의 결과물을 나누어 개발하고 고객 의견을 피드백받고 반영하는 것이 중요하다.  

 

 

 

보고서의 복잡도 : 더 이상 뺄 내용이 없을 때
보고서는 완성된다.  

 

 

 

 

보고받는 사람의 입장에서 좋은 보고란 명료하고 간단한 보고이다. 그러나 보고서를 작성하는 사람의 입장에서는 보고서 내용이 적으면 성의가 없어 보이기 때문에 많은 내용을 작성하고, 그 결과 보고 내용이 명료하지 않고 복잡해진다.

제안서, 상품기획서, 중간보고서 등 대부분의 보고서는 페이지를 줄이는 것이 늘리는 것보다 어렵다. 보고서를 검토하는 이유는 논리를 확인하고 보고서 양을 줄이기 위함이다. 보고서 검토 과정에서 만연체의 긴 문장은 짧게 만들고, 중요하지 않는 내용은 별첨으로 돌린다. 보고서 양을 줄이기 위해서는 삭제하고 축약할 수 있는 절제감과 자신감이 있어야 한다. 보고서 양을 줄이는 것이 부담되는 상황이라면 별첨을 많이 만드는 것이 좋다. 명료하고 간단한 보고서를 작성하기 위해서는 많은 훈련을 해야 한다. 가장 효과적인 방법은 보고받는 사람의 입장에서 보고서를 작성하는 것이다. 

 

 

 

사용성의 복잡도 : 사용자의 복잡도를 상품이
줄여준다.

 

 

 

 

사용성의 복잡도는 사용자가 특정 기능 수행을 위해 클릭하는 횟수가 많고 입력하는 데이터의 양이 많을수록 증가한다. ‘결재하기’ 버튼을 누른 후 결재완료까지 클릭 또는 입력하는 데이터가 대표적이다. 생체인증으로 비교적 간단하게 끝나는 결재도 있지만, 휴대폰을 사용한 인증은 통신사 인증번호뿐만 아니라 잘 보이지 않는 숫자를 보고 등록해야 하는 불편도 있다. 아마존은 최초 구매 시 회원등록, 카드정보, 주소를 등록해 두면 다음부터는 ‘구매하기’ 버튼만 누르면 별도의 인증 절차 없이 결재가 완료된다. 아마존의 인증절차가 간단해서 보안이 허술할까? 특정 기능을 수행하기 위한 작업은 큰 차이가 없다. 그 작업을 상품이 처리할지, 사용자가 처리할지 다를 뿐이다. 인증절차뿐만 아니라 이미 등록된 데이터를 중복하여 등록받거나 또는 활용도가 낮은 데이터를 요구하는 것도 사용 복잡도를 증가시키는 요인이 된다. 사용자가 편해지려면 프로젝트 팀이 고민해야 한다. 프로젝트 팀이 고민하지 않으면 사용자가 고생한다. 사용성의 복잡도를 줄이기 위해서는 UX 디자이너의 역할이 중요하다.

 

 

 

 

 

김병호 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.