요구사항정의서와 기능명세서의 차이
개발자와의 본격적인 커뮤니케이션 시작_문서로 알.잘.딱.깔.센!
개발자가 보는 기획자의 첫인상은 문서?
프로젝트 구성원들이 꾸려지고 난 후, 프로젝트와 관련된 모두 이해관계자들이 모여서 프로젝트 킥오프 미팅 때 업무적으로 처음 만나서 서로 인사를 하게 된다. 이때 프로젝트의 방향을 비롯해 목표, 일정 등을 전반적인 것들을 논의하게 되는데 기획자가 주로 리딩을 하면서 미팅을 진행한다.
에이전시 회사인 경우에는 클라이언트(고객)와 개발사와의 만남이 되고, 인하우스인 경우 회사 내부에서 프로젝트를 담당하게 된 각 기획자, 디자이너, 개발자들이 모여서 진행하는데 디테일한 것을 의논하는 실무적인 얘기보다는 큰 틀을 다지는 시간이다.
대부분 사람들은 킥오프 미팅 때 처음 만나서 인사하고 얘기를 나누기 때문에 이때가 첫인상이 된다고 한다. 물론 그 말도 맞다. 하지만 개발자 입장에서는 자신들과 직접적으로 연관된 개발해야 할 기능을 얼마나 정확하고 깔끔하게 정리해서 알려주냐에 따라 기획자의 첫인상이 좌우되지 않을까 싶다.
요구사항정의서
킥오프 미팅이 끝나면 기획자는 본격적으로 어떤 기능이 왜 필요하고, 어떻게 구현해야 하는지 문서작업을 해야 하는데 이것이 바로 요구사항정의서이다. 주로 에이전시 회사인 경우 클라이언트와의 미팅을 통해서 그들이 원하는 기능에 대해 요구사항정의서를 작성한다. 요구사항정의서에 리스트 된 기능들은 모두 개발이 확정된 기능이 아닌, 말 그대로 클라이언트가 원하는 기능들이 때문에 수정이 가능하다.
인하우스나 사이드 프로젝트에서는 요구사항정의서를 거의 작성하지 않는다. 다른 특정한 고객의 요청이 없이 자체적으로 고객의 니즈를 파악해 스프린트 단위로 프로젝트를 진행하기 때문에 요구사항정의서를 작성해야 할 이유도 없을뿐더러 오히려 작성하는 것이 비효율적이기 때문이다.
기능명세서
프로덕트에 어떤 기능이 필요한지, 즉 개발자들이 어떤 기능들을 개발해야 하는지에 대한 문서이다. 말 그대로 기능에서 대한 설명이 담겨있는 문서다. 기획자가 초안 기능명세서를 작성하고 개발자에게 공유해 실제 구현이 가능여부와 해당 기능을 작업하는데 얼마나 공수가 드는지 논의한 다음 최종적으로 기능명세서를 확정한다. 최종 확정된 기능명세서를 가지고 개발자는 작업을 하는데 사실 워터폴방식으로 일하는 회사에서 주로 작성한다.
아래 표와 같이 기능들에 대한 리스트가 담긴 문서 작성하고, 와이어프레임 옆에 디스크립션으로 기능에 대한 자세한 설명이 담긴 스토리보드를 개발자에게 전달하면 그때부터 개발이 시작된다.
애자일하게 일하는 스타트업의 경우, 기능명세서보다는 유저스토리를 사용해 유저에게 이 기능이 왜 필요한지 한 문장으로 기능을 정의해서 지라나 노션의 칸반보드를 이용해 티켓을 생성해 개발을 진행한다.
노션을 활용한 기능명세서(프로덕트 백로그라고도 부른다)
유저스토리로 작성한 기능명세서