프로젝트를 성공으로 이끌기 위한 스펙 작성

스펙이라는 사전적 정의는 설명서, 사양(Specfication)이다. 일반적으로 직장을 구하는 구인인력이 필요한 학력, 학점, 토임 점수 따위를 합해서 말하는 경우가 더 익숙하다.

이 책에서 스펙은 '프로젝트의 모든 요구사항을 취합해 프로젝트의 중심이 되는 문서'로 정의하고 있으며(p.33), SRS(software requirements specification)와 거의 동의어로 사용한다. 2.4절에서는 흔히 혼용해서 사용하고 있는 스펙(specification)과 요구사항(equirement(s))를 명확히 해준다.

다년간의 개발경험과 프로젝트를 경험한 두 베테랑에게 책을 통해 듣는 스펙의 중요성과 각종 프로젝트 경험들. 구구절절 옳은 말과 가슴에 남는 메세지들이다.

특히, 1.2절의 '스펙에 대한 오해'편의 내용이 특히 가슴에 와 닿는다.

-스펙을 적는 것이 좋은 줄 몰라서 안 적는게 아니다

-소프트웨어를 만들어보기 전에는 천재도 그 내용을 다 알 수 없다

-나도 작성할 줄 아는데 쓸 시간이 없다

-나도 작성해봤는데 우리 경우는 달라서 적기 어렵다

-기획팀에서 주는 문서로는 스펙을 적을 수가 없다

-폭포수 모델과 달리 우리는 애자일이라서 잘 적을 필요가 없다

-잘된 샘플을 보고 싶다

-실리콘밸리에서는 한번 적으면 스펙이 변경되지 않는가?

위의 내용중 절반이상 언급해 본적이 있다면, 이 책은 소프트웨어/프로젝트와 연관된 당신에게 큰 도움을 줄 수 있다.

소프트웨어 공학 : 소프트웨어를 최소 비용으로 최단 기간에 개발하는 방법이다.

4장의 '사례 연구'편은 skip해도 좋고, 가볍게 읽어 보기 좋다. 스펙의 중요성을 일깨우는 계기가 될 수 있었으면 좋겠다.

경험이 적은 엔지니어에게는 좋은 안내서가 될것이며, 이미 개발, 프로젝트 많은 이들에게도 책 여러곳에서 도움될만한 내용들이 하나 가득들어 있다. 책에서 여러차례 설명하고 있듯이 바쁘다는 핑계로 스펙을 기재하는데 투자하는 시간을 아까워하지 말고, 오늘 당장 스펙을 남겨보는 것이 어떨까 싶다. 내가 읽을 글이 아닌 남이 읽을 글이자 내가 다시 필요해 의해 찾아 볼 수 있는 글 말이다.

"한빛미디어 <나는 리뷰어다> 활동을 위해서 책을 제공받아 작성된 서평입니다."