[소프트웨어 스펙의 모든 것] 1장 소프트웨어 스펙의 개요

 

01 소프트웨어 프로젝트 실패의 원인

• 약속된 일정 내 제품 또는 서비스를 출시하지 못했다.
• 소프트웨어가 요구되는 품질(기능 요구사항, 성능, 안정성, 사용성, 확장성 등)을 충족하지 못했다.
• 프로젝트에 꼭 필요한 기술 개발에 실패했다.
• 아키텍처가 뒤죽박죽이 되어서 유지보수가 어려워졌다.
• 애초 예산보다 훨씬 더 많은 비용이 지출됐다.
• 연이은 야근으로 조직 사기가 떨어지고 많은 사람이 그만뒀다.

등등 실패 원인은 끝도 없이 많은데 이를 크게 나누면 스펙, 팀, 관리, 고객, 기술 등으로 분류할 수 있다.

이 중 가장 중요한 것은 '스펙'이다.

프로젝트를 성공하기 위한 최선의 방법은 '원칙만 지킬 수 있는 최소한의 프로세스 환경에서 좋은 문화를 공유'하는 것이다.

 

02 스펙에 대한 오해

스펙을 항상 일정한 절차를 걸쳐 상세하게 많이 작성해야 한다는 것은 오해다.

비즈니스 상황과 프로젝트 여건에 맞게 프로젝트를 가장 빨리 끝낼 수 있는 방법으로 작성하는 것이야말로 스펙을 제대로 작성하는 방법이다.

 

03 스펙의 역할

스펙은 모든 프로젝트 이해관계자를 연결하는 프로젝트의 중심이다.

스펙이 제대로 작성되지 않았다면 프로젝트 관리다는 일정을 예측하기도, 리스크를 파악하기도 어렵다.

개발팀은 정확하게 무엇을 개발해야 하는지 파악할 수 없고, 테스트 또한 체계적으로 진행되기 어렵다.

이렇기 때문에 스펙을 잘 작성해야 한다.

 

04 스펙을 제대로 작성하지 않으면

소프트웨어를 개발할 때 '1:10:100' 규칙을 알아야 한다.

스펙을 작성할 때 요구사항을 바꾸면 '1'이라는 비용이 들지만, 고객에게 전달된 다음에 바꾸면 수백 배의 비용이 들어간다.

요구사항이든 설계든 한 단계 뒤에서 고칠 경우 2~5배의 비용이 들어가서 단계를 거치고 시간이 흐를수록 수정 비용은 기하급수로 증가한다.

따라서 개발의 사전 단계인 기획과 분석, 설계가 적절하게 잘 돼야 한다.

 

05 스펙과 프로젝트의 성공

첫 번째 버전에서 성공한 많은 프로젝트가 이를 업그레이드하는 두 번째 프로젝트에서 실패를 맛본다.

이를 '두 번째 버전 신드론'이라고 한다.

첫 번째 버전은 소규모에 최소 인원으로 진행해서 성공 확률이 높았지만, 이를 기반으로 차기 버전을 만들 대는 규모가 커지고 첫 버전과의 호환을 위해 복잡성이 몇배로 증가하기 때문에 '실패' 확룰이 높아진 것이다.

스펙을 제대로 작성하면 프로젝트 규모가 커져도 프로젝트 성공 확률이 크게 줄지 않는다.