brunch

You can make anything
by writing

C.S.Lewis

by 파이온티어 사나 Sep 14. 2024

기획서, 이 정도면 괜찮을까? 신입 IT 기획자의 고민

기획서 작성법부터 개발팀과의 협업 노하우까지, 실무에서 바로 써먹는 팁!

"내가 어디까지 책임져야 하는지 모르겠어. 화면 설계만 하면 되는 건지, 아니면 개발자가 이해할 수 있도록 세부적인 기술적 사항까지 다 준비해야 하는 걸까?"


신입 IT 서비스 기획자로 처음 일을 시작하면, "내가 어디까지 책임져야 하지?"라는 고민이 생길 수 있습니다. 기획서를 작성할 때, 화면 설계만 하면 되는지, 아니면 개발팀이 이해할 수 있도록 세부적인 요구사항까지 모두 정리해야 하는지 헷갈릴 때가 많죠. 이번 글에서는 이런 고민을 해결하기 위해 기획의 범위와 책임을 명확히 하는 방법을 구체적인 예시를 통해 설명하겠습니다.


1. 기획의 핵심은 ‘의도’ 전달하기

기획자는 제품이 왜 필요한지, 사용자가 어떤 경험을 할 것인지를 분명하게 전달해야 합니다. 기획서의 핵심은 기능의 의도와 사용자가 겪을 상황을 명확히 설명하는 데 있습니다.

예를 들어, 회원가입 기능을 기획할 때 단순히 "이름, 이메일, 비밀번호 입력란을 만든다"라고만 작성하면 개발팀이 그 기능의 의도를 제대로 이해하기 어렵습니다. 왜 이 기능이 필요한지, 사용자가 어떻게 이 기능을 사용할 것인지를 충분히 설명해야 합니다.

나쁜 예시: 회원가입 페이지에서 이름, 이메일, 비밀번호를 입력하고 가입 버튼을 누른다.
좋은 예시: 사용자가 이름, 이메일, 비밀번호를 입력한 후 가입 버튼을 누르면, 이메일 중복 확인을 거친다. 만약 이미 등록된 이메일일 경우 ‘이미 사용 중인 이메일입니다’라는 메시지가 표시된다. 비밀번호가 규칙에 맞지 않으면 ‘비밀번호 조건을 충족해 주세요’라는 메시지를 보여준다.

위의 좋은 예시는 사용자가 어떤 경험을 하게 될지를 구체적으로 설명하고, 개발팀이 의도를 파악해 기능을 구현하는 데 도움이 되는 내용을 담고 있습니다.


2. 개발팀과의 협업: 기획과 기술의 균형 맞추기

기획자가 모든 기술적 세부 사항을 다 알아야 할 필요는 없습니다. 그러나 개발팀이 필요한 정보는 명확하게 전달해야 합니다. 예를 들어, API 통신이 필요한 기능을 기획할 때 기획자가 모든 기술적인 세부 사항을 적으려 하면 오히려 혼란을 줄 수 있습니다. API가 언제, 어떻게 작동해야 하는지만 간단하게 정의하면 됩니다.

나쁜 예시: 로그인 버튼 클릭 시 서버와 통신하여 로그인 처리
좋은 예시: 사용자가 아이디와 비밀번호를 입력하고 로그인 버튼을 누르면, 입력된 정보가 서버로 전송된다. 서버에서 로그인 성공 여부를 확인한 후, 성공 시 대시보드로 이동하고, 실패 시 ‘아이디 또는 비밀번호가 잘못되었습니다’ 메시지를 표시한다.

위의 좋은 예시는 로그인 기능이 언제 어떻게 동작하는지를 명확히 설명해 개발팀이 그 흐름을 쉽게 이해할 수 있도록 돕습니다. 기획자가 모든 기술적인 사항을 정리하기보다는, 핵심 흐름을 중심으로 기획서를 작성하는 것이 중요합니다.


3. 기획서 작성: 적절한 깊이로 작성하기

기획서 작성 시, 모든 세부 사항을 다 적어두기보다는 중요한 흐름과 기능을 설명하는 데 집중해야 합니다. 화면 설계와 주요 기능 흐름은 반드시 포함하되, 세부적인 기술 구현 방법까지 기재할 필요는 없습니다.

나쁜 예시: 댓글을 작성하면 서버와 통신하여 데이터베이스에 저장되고, 페이지를 새로 고침해 댓글을 표시한다.
좋은 예시: 사용자가 댓글을 입력한 후 ‘댓글 작성’ 버튼을 누르면, 댓글이 실시간으로 화면에 추가되고 입력란이 초기화된다. 댓글은 서버에 저장되며 페이지를 새로 고침하지 않고 바로 표시된다.

위의 좋은 예시는 댓글 기능의 흐름을 명확히 설명하면서도, 개발팀이 필요한 부분을 빠르게 파악할 수 있도록 도와줍니다. 기획서에서는 기능의 의도와 흐름에 집중하고, 기술적인 구현은 개발팀이 처리할 수 있도록 맡겨야 합니다.


4. 우선순위 설정: 핵심 기능부터 시작하기

기획할 때, 모든 기능을 한 번에 다 포함하려고 하면 기획서가 방대해지고 중요한 부분을 놓치기 쉽습니다. 가장 중요한 핵심 기능부터 정의하고, 추가적인 기능은 나중에 단계적으로 도입하는 것이 더 효율적입니다.

나쁜 예시: 게시판 기능에 글 작성, 수정, 삭제, 댓글 작성, 댓글 수정, 답글 작성 기능을 모두 구현한다."
좋은 예시: 우선 게시판의 글 작성, 수정, 삭제 기능을 구현하고, 이후 댓글 작성 기능을 추가한다. 피드백을 바탕으로 댓글 수정 및 답글 기능을 추가할 예정이다.

위의 좋은 예시는 핵심 기능부터 구현하고 이후 단계적으로 확장할 계획을 세워, 팀이 중요한 기능에 집중할 수 있도록 돕습니다. 이렇게 하면 개발 일정도 효율적으로 관리할 수 있습니다.


5. 기획과 개발은 팀워크로 완성된다

기획자가 모든 것을 혼자서 해결하려고 하면 부담이 커지고, 기획의 질이 떨어질 수 있습니다. 기획은 팀워크로 이루어집니다. 개발팀, 디자인팀과 긴밀하게 소통하며 기획서를 수정하고 발전시키는 과정이 필요합니다.

나쁜 예시: 기획서만 전달하고 개발팀이 알아서 구현하게 맡긴다.
좋은 예시: 기획 초안을 작성한 후 개발팀과 논의하며 피드백을 받는다. 디자인팀과는 화면 설계를 조율하고, 개발팀과는 기능 구현 가능성을 지속적으로 확인한다.

위의 좋은 예시는 정기적으로 소통하며 피드백을 주고받는 과정을 강조합니다. 기획자는 팀원들과 협력하면서 기획서의 완성도를 높여야 합니다.


신입 IT 서비스 기획자로서 기획의 범위와 책임을 고민하는 것은 당연한 일입니다. 그러나 기획의 핵심은 사용자 경험과 기능의 의도를 명확히 전달하는 것이며, 개발팀과 협력해 기획과 기술 사이에서 적절한 균형을 찾는 것이 중요합니다. 기획서를 작성할 때는 핵심적인 사용자 흐름을 구체적으로 설명하고, 팀원들과 긴밀하게 협력하면서 점점 자신만의 기획 방식을 찾아나가길 바랍니다.


IT PM/PO/서비스 기획자 단톡방 오픈
정보 교류와 소통, 직무 스킬 강의 및 웨비나
파이온티어 단톡방 바로가기
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari