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

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

유명한 맛집일수록 메뉴가 간단합니다. 메뉴가 많은 음식점일수록 재료의 신선도가 낮고 맛도 별로일 가능성이 높습니다. 한 두 개의 메뉴 만으로 오랫동안 유지해온 음식점의 맛은 기본 이상이라고 인정해야 합니다.

기업도 마찬가지입니다. 상품 개수가 적을수록 영업, 마케팅, 구매, 생산, 조직 역할, 고객지원이 간단하여 상품원가도 낮아지고, 품질유지도 쉬워집니다. 반대로 상품 개수가 많을수록 상품 운영이 복잡하여 직원이 실수할 가능성이 높아 고객에게 나쁜 경험을 제공하기 쉽습니다. 신상품을 기획하고 개발하는 노력이 1이라면 상품 운영은 고구마 줄기와 같아 거의 10에 가까운 노력을 필요로 합니다. 기업에서 출시하는 상품보다 단종하는 상품이 적다면 상품 개수는 증가할 수 밖에 없습니다. 상품을 단종하기 어려운 이유는 다음과 같이 정치적인 요인 때문입니다.

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

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

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

출시된 상품의 단종은 관련된 이해관계자들에게 감당하기 힘든 상처를 주기 때문에 경영층이 아니면 결정하기 힘듭니다. 경영층의 통찰력이 높고 상품 단종에 엄격한 규율이 있을 때 상품 개수를 일정 수준 이하로 유지할 수 있습니다.

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

신상품 개발 프로젝트는 투자에 대한 승인을 받기 힘들기 때문에 가급적 많은 기능을 기획하는 경우도 있습니다. 10억 규모의 개발 투자를 1억으로 나누어 10번 승인 받기보다 10억의 투자를 한 번에 승인 받는 것이 쉽기 때문입니다.

한꺼번에 많은 기능을 개발할 때 부작용은 다음과 같습니다. 

·  가치를 창출하지 못하는 기능이 많아집니다.

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

·  요구사항들은 시간에 취약합니다.

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

·  상품기능의 수가 많을수록 상품개선이 어려워집니다.

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

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

- 사용성의 복잡도 : 사용자가 편하려면 프로젝트 팀이 고생해야 합니다.

사용자가 특정 기능 수행을 위해 클릭하는 횟수가 많고 입력하는 데이터의 양이 많을수록 사용성의 복잡도가 증가합니다. ‘결재하기’ 버튼을 누른 후 결재완료까지 클릭 또는 입력하는 데이터가 대표적입니다.

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

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

보고받는 사람의 입장에서 좋은 보고란 명료하고 간단한 보고입니다. 그러나 보고서를 작성하는 사람의 입장에서는 보고서 내용이 적으면 성의가 없어 보인다는 두려움 때문에 많은 내용을 작성하고, 그 결과 보고 내용이 명료하지 않고 복잡해집니다. 두꺼운 SI 프로젝트의 제안서가 대표적입니다.

제안서, 상품기획서, 중간보고서 등 대부분의 보고서는 페이지를 줄이는 것이 늘리는 것보다 어렵습니다. 보고서 양을 줄이기 위해서는 삭제하고 축약할 수 있는 절제감과 자신감이 있어야 합니다. 보고서 양을 줄이는 것이 부담된다면 별첨을 많이 만드는 것이 좋습니다. 명료하고 간단한 보고서를 작성하기 위해서는 보고받는 사람의 입장에서 내용을 삭제하는 연습을 많이 해야 합니다. 

=======================================================
제가 삼성 SDS에서 30년동안 경험하고 체득한 교훈을 정리한 <슬기로운 PM 생활>을 25년 1월 출간한 소식을 공유합니다.

https://product.kyobobook.co.kr/detail/S000215148133