wlgn***
2021-02-21

프로젝트 시작과 기준은 소프트웨어 스펙(SRS)이다. 제대로 작성된 스펙은 프로젝트를 성공으로 이끌 가능성을 높인다. 누구나 알고 싶어 하지만 쉽게 알 수 없는 소프트웨어 스펙 작성의 거의 모든 것을 정리했다.
해당 도서는 기획자 및 개발자(특히나 시니어 및 리더) 분들에게 강력하게 추천을 드립니다. 전 지금까지 리뷰했던 책들이 저 개인에게는 좋았지만 타인에게 추천해야겠다는 생각은 크게 생기지 않았었는데 이번 책은 꽤나 추천에 대한 욕구가 솟아났던 책이었습니다. 그래서 책을 읽는 중간에 이미 제가 알고 있는 기획자 및 PM분 2분에게 해당 도서를 추천해버렸습니다.
이 책은 SRS(Software Requirements Specification), 즉 스펙 작성에 대한 내용입니다. 책에 대한 내용은 목차 및 책을 훑어보시면 충분히 아실 수 있기에, 책을 읽으면서 느꼈던 감정 및 생각들을 공유하려고 합니다.
참고로, 저의 직업 및 경력 그리고 일해온 조직 등의 배경으로 인해서 무릎을 치게되고 "아!"를 외쳐가면서 읽게되었습니다.
✔️직업 : 개발자
✔️경력 : 6년
✔️환경 : IT 스타트업 경험이 전부
(첫 회사(약 6명) -> 두번째 회사(약 20명) -> 세번째 회사(약 120명))
책의 내용에 왜 공감이 가는 이유를 생각해보니, 작은 규모의 회사 혹은 IT관련 스타트업에서 일한 경험이 가장 크다고 생각합니다. 모든 IT 스타트업이 그런건 아니지만 주로 소규모의 혹은 수익을 내지 못하는 회사라면 주로 공감이 갈것 같습니다.
회사는 이익을 창출하는 곳인데 이익을 창출하기 위해서는 여러가지 서비스를 만들어내거나 혹은 하나의 서비스에서 다양한 기능을 만들거나 수많은 전략들을 시도하게 됩니다. 그리고 자연스럽게 이거저것을 많이 시도하면서 마감기한은 짧기에 주어진 시간이 늘 부족하게 되고 어쩔 수 없이 야근을 하게됩니다. 그러다보니 자연스럽게 문서를 작성한다거나 소프트웨어 혹은 기능을 만들기 위한 사전 작업에 소홀해지고 요구사항에 부합한 결과물을 만들어내지 못하게 됩니다. 더불어서 버그도 많이 양산하게 됩니다. 더불어서 제대로 스펙을 상정하고 아키텍트를 만들어가는 경험이 부족하게 됩니다. 일도 많이 하고 경력은 많아지는데 실력의 질은 비례하지 않게 되죠...
책을 읽으면서 지금까지 프로젝트를 진행하면서 부족했거나 아쉬웠던 부분들이 생각났고 이런 부분들이 제대로 수정이 된다면 더 즐겁게 일할 수 있지 않을까란 생각도 자연스럽게 하게 되었습니다.
책에는 소프트웨어 스펙이란 무엇이며 왜 필요한지에 대한 얘기가 자세히 설명되어 있으며 더불어서 SRS는 어떻게 작성해야하는지에 대한 도움을 받을수 있습니다. 개인적인 견해지만, 프로세스가 없거나 부족한 그리고 만들어가는 회사에서 일하고 있는 경력자인 개발자 및 PM 이라면 도움이 많이 될것이라고 생각합니다.
아 그리고 중요하다고 생각한 부분입니다.
해당 책은 혼자 읽으면 일하는 환경을 나아지게 만들기 어렵습니다. 최소한 팀 전체가 공감하고 실행할 수 있어야하며, 더불어서 회사 전체적으로 공감을 형성해야지 의미가 있다고 생각합니다. 아무리 프로젝트를 진행하는 팀이 괜찮은 방법을 적용시키려고해도 C레벨에 준하는 임원들이 공감을 해주지 않고 '그건 우리에게 맞지 않아' 같은 형태의 태도를 유지하고 명령(?)한다면 지킬 수 없기 때문입니다. 그럼에도 시작은 중요한 터닝포인트를 만들어줄 수 있기에 시작은 하는게 좋다고 생각합니다 ㅎㅎ