🛎나만의 일 팁#4: Functional Specification (기능명세서) 작성 팁 IT 팀 또는 개발자와 함께 일한다면, 아마 Functional Specification / Docume

🛎나만의 일 팁#4: Functional Specification (기능명세서) 작성 팁 IT 팀 또는 개발자와 함께 일한다면, 아마 Functional Specification / Document (기능명세서) 를 들어보셨을 겁니다. 기능명세서는 구현해야 하는 기능 및 비즈니스 프로세스를 상세히 적어놓은 문서로 개발 전 꼭 필요한 문서중 하나입니다. 비즈니스 애널리스트로 일하면서 기능명세서 작성을 위한 몇가지 팁을 공유하고자 합니다. 1️⃣ Template 회사마다, 팀마다 또는 프로젝트마다 필요한 Template이 있습니다. 항상 매니저 또는 팀멤버와 소통하여 맞는 Template을 찾는것이 중요합니다. 모든 사람이 써 왔던 Template이 서로 보기도 편하고, 회사 문서관리 차원의 일관성을 위해서도 중요합니다. 2️⃣ Flowchart 기능명세서를 적기전에, Flowchart를 한번 구상해보는것이 좋습니다. 전체적인 As-is(현재) 와 To-be(미래) 를 그려보며, 현재 어디서 어떤 문제가 발생하고 앞으로 어디서 어떻게 프로세스가 바뀌는지 flowchart로 보면 프로세스와 구현해야 할 기능이 깔끔하게 정리되어 보여집니다. 3️⃣ Wireframe 필요한 기능과 프로세스를 글로 적는것도 좋지만, 실제 구현하고 싶은 기능 및 프로세스를 실제 화면으로 그려낼수 있다면 개발자들도 이해하기 훨씬 쉬울 것입니다. 이러한 기능 디자인은 디자이너와 함께 일하기도 하지만, 간단한 레이아웃은 엑셀, 워드 또는 Figma 같은 디자인 툴을 이용하여 직접 그릴수도 있습니다. 4️⃣ Communication (매니저, 비즈니스 팀 및 개발팀과 소통) 프로젝트는 혼자 하는것이 아닙니다. 기능명세서를 작성하는 중에도, 중간중간 내가 생각하고 구현하려고 하는 기능이 맞는것인지, 놓친 부분은 없는지 여러 팀들과 이야기하며 확립해 나가야 합니다. 문서를 다 작성하고 한번에 검토를 요청하는것 보다는, 중간중간 주기적인 미팅으로 구현하려는 기능이 맞는지, 빼먹은 프로세스는 없는지, 생각하고 있는 layout은 이 정도면 되는지, flowchart는 이게 맞는지 등등 소통을 하면서 서로가 생각하고 구현하려는 기능과 프로세스를 맞추도록 합니다. 어느정도 동의가 되었다면, 문서를 완료하고 매니저 및 비즈니스 팀들과 마지막 리뷰와 공식적인 sign-off 프로세스도 함께 마쳐야 합니다. *첨부된 사진은 MD-50 Functional Document 예시입니다. https://www.scribd.com/document/405528832/MD-50-Template