한빛미디어

이 책은 한빛미디어에서 협찬 받았습니다.

1.책을 읽기 전에

전 소프트웨어 자문 및 개발을 하는 소프트웨어 사업자입니다.

그래서 책 제목이 아주 마음에 들었습니다. 소 제목을 소개하자면

"프로젝트를 성공으로 이끄는 소프트웨어 스펙 작성법"입니다.

저 같은 소프트웨어 사업자는 꼭 읽어야 하는 필독서처럼 보였고 설레임으로 다가왔습니다.

내 돈 주고 산 책은 아니고 한빛미디어 리뷰어로 참여해서 받은 책입니다.

여러 종류의 책 중에서 다른 책은 관심 밖이었고 이 책을 제일 먼저 선택했습니다.

왜냐하면 수 년간 이 업을 해오면서 고충사항이기도 한 스펙 작성"에 대한 내용이기 때문입니다.

제가 하는 일에 직접적으로 도움이 되겠구나 생각했습니다.

2.책을 읽고 난 후

  책을 읽기 전에도 예상했지만 다양한 프로젝트의 실패 사례를 소개하고 있습니다.

저도 실무에서 직접 겪었던 일이기에 공감되는 부분이 많았습니다.

프로젝트는 사람이 하기에 결국은 그 프로젝트를 이끄는 매니저(PM,PL이라고 많이 부름)의 역량에 따라 성공과 실패로 나뉘기도 합니다.

저는 ERP 프로젝트를 여러차례 수행한 프로젝트 매니저이기도 합니다. 

이 책에서 다루는 SRS 템플릿과도 사뭇 다른 문서이지만 스펙을 작성했었습니다.

단지 덜 체계적이고 그 핵심 포인트가 빗나갔던 것 같기는 합니다.

전산정보처리 업종에서 년수만 따지면 28년이라는 시간이 흘렀습니다.

꽤 긴 시간동안 성공적인 프로젝트를 수행하기 위한 다양한 방법론을 공부했습니다.

저자 두 분 역시 개발을 한 경험자분이기에 책의 내용 또한 충실하다고 생각하고 신뢰합니다.

  1부에서는 SRS에 대해서 이야기 하는데 전체 페이지중 25쪽부터 250쪽까지입니다. 

상당히 길게 이야기 합니다.1부는 다소 지루한 면도 있었습니다.

작성하는 방법은 언제 나오나하고 상당히 조바심도 생겼습니다.

드디어 2부는 SRS 작성법입니다. 251쪽부터 347쪽인데 1부에 비해 상대적으로 내용이 많지 않습니다. 

전부 읽고 나니까 굳이 첫 페이지부터 읽을 필요나 있었나 하고 후회가 됩니다.

예비 독자분들은 2부인 SRS 작성법부터 먼저 읽어도 좋을 것 같습니다.

그리고 1부로 넘어와도 내용 연결에는 큰 불편함이 없을 것 같습니다.

  책을 전부 읽고 난 후 느낀 점을 한 마디로 표현하자면 이렇습니다.

SRS라는 용어는 처음 접했고 그 중요성을 새삼 다시 깨닫게 되었다는 것입니다.

그리고 고민거리도 생겼습니다.스펙을 언제 작성해야 하냐는 것입니다.(외주 프로젝트의 경우를 말합니다.)

물론 이 책에서는 스펙에 대해서 긴 지면을 통해 많은 이야기를 하고 있고 작성법 또한 상세하게 적혀 있습니다.

  매번 고객들과 상담할 때 했던 이야기가 떠오릅니다.

고객들은 간단한 정보만 주고 견적서를 요구합니다.

저는 그때마다 항상 똑같은 이야기를 합니다. 대략적인 견적을 드릴 수는 있지만 추후 변경될 수 있습니다.

대략적인 견적이든 확정 견적이든 한번 견적서를 제출하면 금액이 내려 갈 수는 있지만 올리기는 어렵다고 생각합니다.

그렇다고 처음부터 변동될 것을 대비하여 높은 견적을 내기도 어렵습니다. 업체 선정 검토 대상에서 제외될 수 있기 때문입니다.

  이와같은 고민때문에 저는 상세한 요구사항을 요구하지만 이에 호응하여 대응하는 고객은 그리 많지 않습니다.

입장을 바꿔 놓고 생각해 보면 그 이유를 알 수 있습니다.

최소한의 정보만을 제공하고 대략적인 견적을 복수의 업체에게 받아서 1차 검토대상 업체를 선정할 수도 있겠다는 생각이 듭니다.

  소프트웨어 프로젝트 실패의 원인은 많지만 제가 생각하는 원인 하나는 견적 관리입니다.

프로젝트의 시작은 견적인데 첫 단추부터 제대로 처리하지 못하는 것입니다. 

두번째 실패의 원인이 부실한 스펙의 작성이라고 생각합니다.

3.스펙 작성의 중요성과 현실

  책을 읽다 보면 스펙 작성은 꼭 필요하다고 공감합니다.빠르게 그리고 품질은 좋게 만들어야 겠지요?(다 알고 있는 사실입니다)

하지만 문제가 하나 있습니다. 바로 스펙을 작성하는 시점입니다.(외주 프로젝트의 경우)

더 구체적으로 이야기하자면 계약 전에 하느냐 아니면 계약 후에 하느냐의 문제입니다.

전 이 이야기를 꼭 하고 싶습니다.

구매 발주자가 아닌 소프트웨어 사업자 입장에서는 계약 이전 단계에서 스펙을 작성하는 게 맞다고 생각합니다.

이런 이야기를 하는 이유는 종종 견적단계에서는 대략적인 내용만 파악하고 계약 후에 상세한 스펙 작성을 하는 경우가 있어서입니다.

(계약 전에 작성해야 상호 피해가 줄어 든다는 표현이 더 맞을 수도 있겠다는 생각이 듭니다.)

쉽게 말해 프로젝트의 성패가 갈릴 수도 있을거라 생각합니다.

  책에서는 요구분석 단계에서 SRS 작성을 한다고 말하고 있습니다.

물론 자사 제품을 만들 경우에는 큰 문제가 없겠지만 프로젝트를 외주업체에 맡기는 경우는 다르다고 생각합니다.

아웃소싱의 경우에는 이 단계에서 작성하면 안된다고 생각합니다. 

  프로젝트의 크기도 제대로 파악하지 못하고(스펙도 모른체) 계약을 할 수 있냐는 것입니다. 

이미 계약금은 입금되었을테고 알수 없는 리스크를 안고 프로젝트가 시작된 것이라 생각합니다.(프로젝트 중단 또는 실패로 끝날 수 있을 것입니다.)

그렇다면 요구분석을 다 끝내고 계약을 하면 되지 않느냐고 되물어 볼 것 같습니다.

이 문제는 한번 심도있게 생각해 봐야 할 것 같습니다. 

  긴 시간동안 고객(발주자)과 대면하면서 무상으로 분석을 해 줄수 있느냐,

아니면 분석비용을 받고 요구분석을 하느냐의 선택이 필요합니다.

그리고 발주자 입장에서 프로젝트를 수행업체 선정여부도 결정하지 않은 상태에서

기업의 상세한 정보를 제공할 수 있느냐의 문제도 생길 수 있습니다.(보안상의 문제가 발생하는 것입니다.)

4.마무리

  그렇다면 프로젝트 성공을 위해 어떻게 해야 할까요? 어려운 문제입니다.

전 계약하지 않고도 간단한 핵심 데모를 만들어 시연해 주기도 했습니다.

그리고 요구 분석은 1도 하지 않고 계약서에 도장부터 먼저 찍고 프로젝트를 진행한 적도 있습니다.

그렇다고 해서 제가 기술적으로 뛰어나지도 않고 영업적인 테크닉도 전혀 없습니다.

어려운 환경속에서 어떻게 살아남을 지를 고민하고 스펙 작성의 노하우를 터득하기 위해

노력하고자 합니다.

이 책은 저 같은 소프트웨어 사업자분들께서 한번쯤 읽어 보셔도 좋을 것 같습니다.

긴 글 읽어 주셔서 감사드립니다. 대한민국에서 소프트웨어 개발을 해 본 솔직한 후기였습니다.

2021.02.16