[소프트웨어 스펙의 모든 것] 3장 스펙 작성의 현주소, 현실과 관행

 

01 현재의 관행과 문제점

• 스펙이 부실하다.
• 과도한 산출물을 요구한다.
• 고객이 요구사항을 잘 알려주지 않는다.
• 스펙 문서는 있지만 문서만 보고는 개발할 수 없다.
• 시니어 개발자는 관리자가 되어야 한다.

 

02 스펙에 대한 잘못된 통념

(경영자) 문서를 작성하느라 일정을 못 맞추는 것 아닌가?

: 스펙이 부정확하면 일정을 산정하는 의미가 없다. 

 

(개발자) 일정이 부족하니 당장 코딩부터 시작하자.

: 스펙과 설계가 충분할수록 코딩 기간이 단축되고 프로젝트 초기에 일정이 부족한 것을 알면 개발자를 더 투입할 수 있으며 일정 단축을 위해 일부 기능을 다음 버전으로 미루는 것도 가능해진다. 

 

(고객) 지금

 

은 잘 모르겠으니 일단 개발해주면 보고 나서 요구사항을 알려주겠다.

: 고객 자신이 원하는 것이 무엇인지 잘 모르면 개발자들은 난처해진다. 개발자의 주도 하에 개발 및 개선이 반복되면 아키텍처가 엉망이 될 수 있다.

 

(개발자) 일정이 정해져 있어서 어쩔 수 없다.

: 개발자들은 합리적으로 일정을 산정해 정확한 데이터를 근거로 제시할 때 경영자에게 일정에 대해 목소리를 높일 수 있다.

 

(개발자) 스펙은 문서만 보고 개발할 수 있을 정도로 자세히 적는 것이 좋다.

: 대부분의 경우 스펙을 너무 자세히 적는 것은 좋지 않다. 프로젝트 성격에 따라 기능을 간단히 적기도 하고 사용자 인터페이스를 상세히 적기도 하며 비기능과 전략을 잘 적어야 하기도 한다.

 

(개발자) 요구사항이 계속 바뀌니 스펙을 적을 필요가 없다.

: 요구사항은 시장 상황 변화, 경쟁 업체의 신제품 출시, 기술 변화, 비즈니스 요구사항 발견 등으로 변하기 마련이다.

스펙을 제대로 적어놓지 않으면 변경 요구를 제대로 관리하지 못한다.

반면에 변경 프로세스를 적용하면 좀 더 합리적인 변경 관리가 가능하다.

 

03 부실한 스펙 후 설계는 사상누각

스펙에서 요구사항이 누락되는 경우

• 현재 예상 사용자는 천명이지만 3년 안에 백만 명이 사용할 수 있다.
• 당장은 한국어만 지원하지만 1년 안에 30개의 언어를 추가 지원해야 한다.
• 절대로 크래시가 나서는 안 되며 크래시 발생 시 막대한 손해 배상을 해야 한다.
• 지금은 iOS만 지원하지만 1년 안에 안드로이드도 지원해야 한다.

이런 요구사항을 철저히 분석해 스펙에 기록해 놓지 않으면 설계 담당자가 요구사항을 놓치게 될 수 있다.

 

04 시간만 있으면 누구나 스펙을 쓸 수 있는가?

스펙도 써봐야 실력이 는다.

시행착오도 겪고 뛰어난 분석 아키텍트의 리뷰를 받으면서 배워야 경험치와 함께 실력이 쌓인다.

스펙 작성의 원리를 깨우친 사람은 어떤 방법으로든 스펙을 잘 작성한다.

 

05 소프트웨어 공학, 약인가? 독인가?

소프트웨어 공학은 소프트웨어를 최소의 비용으로 최단 기간에 개발하는 방법을 모아놓은 것이다.