프론트엔드 개발자가 작성하는 기능 기획 문서

프론트엔드 개발자가 쓰는 기능 기획 문서는 어떤 방식일까?

개요

업무적으로 사용자가 활용하는 대시보드를 개발하다 보니, 다양한 기능을 추가하고자 제안했다. 하지만, 개발 리소스보다 기획 리소스의 부족으로 인해 반려되는 경우가 잦았다.

그래서 결국 직접 기획부터 초기 디자인, 개발 플로우 기획, 데이터 구조 확정, 개발 및 구현까지 모두 맡아 진행하고, 이후에 디자이너의 손을 거쳐 디자인 수정을 진행 하는 방식으로 하게 되었다. 기획의 시작부터 개발의 마지막까지 명확하게 진행하려면 철저히 공유하여 기획자 - 디자이너 - 개발자 간의 이후 커뮤니케이션을 효율적으로 유도해야겠다는 생각이 들어, 기능 기획 문서의 템플릿을 고민하고 작성하게 되었다.

초기 기능 기획 문서

초기 문서는 사실 템플릿이라고 말할 것도 없었고, 크게 다음과 같은 내용만 포함하게끔 파편화하여 작성하곤 했다.

• 해당 기능의 필요성
• 해당 기능을 사용하는 사용자의 플로우
• 필요한 데이터 구조에 대한 제안 및 설명

다만, 우선 파편화된 문서는 결국 이후에 직접 취합하여야 하고, 취합하는 과정에서 유실되거나 업데이트되지 않을 가능성이 존재하기 때문에 한 문서에 모두 작성해야 한다는 생각이 들었다. 또한, 기획자 - 디자이너의 경우 개발과 관련된 단어가 많으면 가독성이 떨어질 수 있고, 이는 문서에 대한 이해도를 낮춰 추가적인 설명이나 미팅 시간이 필요하게 되는 경우가 많아 기능에 대한 배경 지식이나 용어에 대해 명확히 정의하는 것이 중요하다고 느꼈다.

추가적으로 해당 기능에 대한 사용자 플로우나 데이터 구조, 상세한 기능 명세 등을 작성하다 보면, 발생할 것이라고 예상되는 이슈들이 존재했다. 그러나 이를 미리 정리하고 대안을 찾아 논의를 하지 않으면 결국 나중에 내 손으로 개발한 것을 롤백하고 다시 개발해야 하는 상황이 발생할 것이고, 이는 데드라인에 맞추기 위해 결국 내가 야근을 해야하는 것이기 때문에 해당 부분에 대해서도 최대한 미리 논의할 수 있도록 해야겠다는 생각이 들었다. 물론 직접 개발을 시작하고 나서 발생한 이슈들에 대해서 처리하기만 하면 이후에 개발 가능성 검토 및 개발 시간 산정 등에서 제대로 감을 못잡을 것 같아 미리 기획 문서에 최대한 녹여내는 것이 좋다고 생각하기도 했다.

결국 이러한 생각들을 반영하여 새롭게 기능 기획 문서의 템플릿을 만들었다.

기능 기획 문서 템플릿

배경

주로 기획자 - 디자이너 - 개발자 사이의 해당 기능에 대한 배경 지식의 차이를 줄이기 위한 섹션으로, 다음과 같은 내용을 작성한다.

• 문서의 주요 주제인 새로운 기능 혹은 수정될 기능
• 해당 기능이 포함될 프로젝트의 상황 및 흐름
• 기존 사용자 플로우에서 어떤 부분에 새로운 기능이 추가될 것인지
• 해당 기능에 관련된 용어의 정의 및 정리
• 기타 이해를 도울 수 있는 참고자료

기능 상세

해당 섹션에서는 논의할 기능의 주요 기능과 그 상세에 대해 설명하고, 대략적인 와이어프레임에 대해 설명한다.

개발 요구 사항

해당 기능 기획 문서는 기획자 혹은 디자이너만 보는 것이 아니라 앱 개발자 혹은 다른 웹 개발자가 확인하고 개발할 수 있는 부분이기 때문에 개발적으로 필요한 사항을 개발 요구 사항 섹션에 작성하게 된다.

• 주요 기능에 대한 스펙, 활용 라이브러리, 개발 예상 시간
• 웹, 앱, 서버 등 개발이 필요한 사항에 대한 개괄적인 사항
• 개발 플로우에 대한 설명
• 서버, 데이터베이스, 웹, 앱 간의 기본적인 다이어그램

데이터 구조 설정

특히 앱과 상호작용이 필요한 기능에 대해서는 데이터 구조를 섬세하게 기획하고, 관련된 API 또한 직접 만들어야 하기 때문에 데이터 구조에 연결하여 API를 깔끔하게 디자인해야 한다.

이슈 및 대안

이제, 배경부터 기능 상세와 개발 요구 사항 등을 작성하다 보면, 해당 기능을 구현하는 과정에서 발생하는 이슈들이 보이고, 그에 따라 해당 이슈를 해결하기 위한 여러 대안을 고민 혹은 검색을 통해 찾아내는 과정을 거쳐야 한다.

• 발생하리라 예상되는 이슈
• 해당 이슈에 대한 대안(다양할수록 긍정적인 피드백이 올 가능성이 높다.)
• 가장 효율적이고 상식적이라고 생각되는 대안

부족했던 점

해당 기획 문서를 세네번 활용해보면서 부족하다고 생각했던 것은, 우선 기능 기획 문서를 작성하고, 논의하고, 업데이트한 후 막상 개발을 시작하고 해당 기능이 배포된 이후에 이와 관련해서 회고하지 않았다는 점이었다. 해당 기능을 배포한 것은 충분히 회고할 만한 부분이 많았지만 그에 대해 회고할 시간도 없이 다음 버그를 수정하거나 새로운 기능에 대해 기획해야 하는 긴박한 일정 속에 있었기 때문도 있겠지만, 일단 회고에 대해 부정적이었다.

지나간 일을 돌아보고 그것을 타산지석으로 삼아 보다 나은 업무 방식, 보다 나은 커뮤니케이션, 보다 나은 협업, 보다 나은 개발 등을 추구할 수도 있겠지만, 이전의 내가 그렇지 않았기 때문에 너무 부정적으로만 회고를 바라본 것 같다. 따라서, 해당 기능의 기획부터 개발, 배포와 그 이후까지 과정에 대한 회고가 필수적이라고 생각되어 템플릿에 추가해야 한다.