얼결에 팀에서 PM을 맡게 되었다. 실제 PM이 하는 업무랑은 좀 다르지만 어쨌든 Project Manager라는 게 좀 두리뭉실한 분야 아닌가?
무튼! 내가 맡게 된 역할은 이렇습니다.
- 스케줄 관리
- 회의 주최
- 기획 및 각종 서류 업무 주도
- 팀원 사기(?) 관리
- 팀워크 관리
- 전반적인 프로젝트 추진
이게 맞는진 모르겠지만 , 아무튼간 이런 역할을 하고 있다고요~
팀장님이 준 역할이고, 다들 추천해줬다. 그런데 아무래도 적성에 잘 맞는듯 하다. 사실 여태까지 총학이나 위원회 하며 하던 일이 전부 관리직이었으니... 항상 팀원들을 이끌고, 탈주하지 않게 하나로 잘 뭉쳐서 목표로 가게 하던 게 내 일이긴 하다. 실무는 재능보다 노력으로 커버하는 편이고, 사실 창작보다는 검수가 적성에 맞는 편이라... ㅎ
하지만 이젠 내가 가진 실무적 기술로 돈을 벌어보기로 결심했고! 말이 PM이지 어차피 개발은 다같이 하는 것이기에~ 부수적인 역할을 하나 더 한다고 보는 게 맞다. 그럼 오늘도 블로깅 시작!
팀별 진행 상황
BE
- 사용자 요구사항 정의서 작성 완료
- API 명세서 작성 중
- 테이블 명세서 작성 중
FE
- 사용자 요구사항 정의서 작성 완료
- 유저 플로우 차트 작성 중
- UI 디자인 매뉴얼 작성 완료
오늘 배운 것
1. 유저 플로우 차트 작성 방법
유저 플로우 차트는 FigJam으로 만드는 게 가장 간단해보인다. 우리는 FigJam으로 모두가 참여해 기획을 하고 플로우 차트를 만들고 있다.
우선 플로우 차트는 마땅한 방법이랄 게 없이 예시를 보고 최대한 비슷하게, 그리고 우리 팀의 로직에 맞게 구현하면 된다만... 개인 프로젝트를 하는 사람이라고 해도 유저 플로우 정도가 git에 업로드 되어 있으면 훨씬 완성도 있는 앱이 될테다.
그래서 개발 단계에 들어가기 전에 작성하면 좋을 서류들과 설명을 적어보고자 한다. 유저 플로우 차트 작성 방법도 아래에 자세하게 적어두겠다.
2. 개발 단계 이전에 작성하면 좋을 서류들
이 서류들은 우리 팀을 기준으로 작성한 거라 팀의 구성이나 프로젝트의 진행에 따라 추가하거나 뺄 수 있음을 알고 계시길!
- 사용자 요구사항 정의서(Front End)
사용자 요구사항 정의서는 고객이 요구한 사항을 정의하는 서류라는 게 기본 개념이지만, 사실은 개발자와 기획자, 고객 중에서도 실제 사용할 고객과 서비스를 수주할 자본회사 등 많은 사람들이 이 서류를 기반으로 어떤 앱이 만들어질지를 가늠한다.
절대적으로 정해진 양식이 있지도 않고, 완벽한 요구사항 정의서가 생길리도 만무하다. 만들다 보면 계속해서 새로운 기능 요청이 올테고, 그렇지 않더라도 개발 도중에 세부 사항들이 바뀔 수 있으니... 또 양식도 참 다양하다. 아래 예시에 다양한 요구사항 정의서와 출처 링크를 첨부해두었으니 참고하기에 좋다.
실제 개발자들은 이 요구사항 정의서를 보며 개발하다 빼트린 기능은 없는지 확인하기도 하고, 우리처럼 기획과 개발까지 함께하는 팀에서는 어떤 기능을 제공하기로 했는지 헷갈릴 때 확인하는 용도로 쓰기도 한다. 사실상 스스로 만든 교과서인 셈! "시험은 꼭 여기서 나온다~~!"
ex)
ㄴ 출처: 이새봄 님의 브런치
ㄴ 코스에서 공유해준 요구사항 정의서! 본 출처를 아시는 분 있으시다면 댓글 부탁드립니다.
ㄴ 출처: monica 님의 티스토리
보면 알겠지만 인터페이스를 기반으로 한 팀도 있고, 기능 위주로 작성한 팀도 있고... 잘 짬뽕해서 각자 팀에 맞게 쓰시길! 한 가지 초보자의 짧은 경험으로 느낀 점은, 중요도 항목을 넣으면 개발할 때 훨씬 부담도 덜고 집중할 곳을 찾기 쉽다.
- 화면 정의서(Front End)
화면 정의서는 사용자 요구사항 정의서를 보완하기에 참 좋다. 사용자 요구사항 정의서는 엑셀 기반이기도 하고 글로만 되어 있어 직관적으로 이해하긴 어렵다. 그리고 기능 위주로 정의해두었다면 어떤 화면에 어떤 기능이 들어갈지가 명확하게 보이지 않는다.
그를 보완하기 위해 화면 정의서는 대체로 페이지 기반의 양식을 가지고 있다. 이거야말로 양식이 훨씬 더 다양하다. 예시와 출처를 달아둘테니 원하는 양식의 화면 정의서를 제작해보길!
ex)
ㄴ 출처: 야메군 님의 티스토리
ㄴ 출처: 그냥 우리 팀 Pre 때 사용했던 화면 정의서임... 우리 팀은 당시 작성했던 사용자 요구사항 정의서가 페이지 기반이라 마땅히 여기 적을 내용이 없었지만, 보완을 위해 앞으로 Main에서 작성하는 사용자 요구사항 정의서는 기능 위주로 적을 예정이다. 따라서 화면 정의서가 더 필요해지는 시점!
아까 사용자 요구사항 정의서에 있던 의미없어보이는 요구사항 ID들이 여기다 쓰이는 거다. 또 이걸 만들려면 와이어 프레임도 필수!
기능 정의서(Front End)
아까의 화면 정의서는 화면 구성에 따른 API 주소나 요구사항ID 등이 적혀있었다면, 이건 기능과 그 설명이 훨씬 직관적으로 들어있다. 사실 기능 정의서란 사용자 요구사항 정의서와 크게 다르지 않아야 하는데, 이건 팀장님이 가져온 기능 정의서 양식이다. 와이어 프레임으로 짠 페이지에 넘버링을 해서 플로우가 훨씬 명확하게 보이는 장점이 있다.
이게 보편적인 양식인지는 아직 알 수 없다만... 아무튼 이런 식이고, 우리 팀에게는 많은 도움이 됐다! 고로 공유합니다.
ex)
유저 플로우 차트(Front End)
화면의 로직을 한 눈에 볼 수 있다. 대개 메인 페이지에서 다음 페이지로 넘어갈 수 있는 경우의 수만큼 연결하고, 그게 트리구조처럼 쭉 가지치기를 해나가는 식이다. 시니어 개발자 분들은 마인드 맵이라고도 하던데... 아무튼 모양과 색에 의미를 두고, 라인에다 글을 추가하려면 Y or N 등의 조건(?)을 추가하거나 홈 화면으로 회귀하도록 하는 플로우를 가시적으로 보여줄 수 있다. 또 작성하다 보면 혼자 동떨어진 페이지는 없는지, UX는 어떻게 설계할 것인지를 쉽게 파악할 수 있다.
이 글의 썸네일로 붙어있던 사진이 우리 팀의 Main-Project 플로우 차트인데, 가시성이 키포인트인만큼 최대한 라인을 깔끔하게 하면 좋다. 아래에 예시를 붙여둘테니 참고하기!
ㄴ 출처: 요즘IT의 기획 포스트 / 플라이북의 플로우 차트라고 한다.
API 명세서(Back End)
솔직히 백엔드 쪽은 몰라서 이 글을 적기 위해 공부해봤다. 직접적으로 배운 게 아니니 참고만 하시길.
테이블 명세서(Back End)
오늘 한 것
- 사용자 요구사항 정의서 작성 완료
- 기능 정의서 작성 중
- 와이어 프레임 제작 중
- 유저 플로우 작성 중
최종 회고
실수는 최대한 빨리 발견할 수록 좋다. 덮어두다 나중에 발견하면 일만 커진다. 사용자 요구사항 정의서와 기능 정의서를 만들다 보니 완벽했다고 생각했던 기획에도 참 수상쩍은 부분들이 많았다. 다행히도 팀장님이 프로젝트가 처음인 팀원들도 잘 가르쳐주고 이끌어줘서 좋다. 나는 나름 PM 역할을 하며 밀어주고 서포트하는 역할을 하고 있다. 적성에 잘 맞기도 하지만, 그래도 진~짜 코드 잘 짜는 개발자, 좋은 서비스를 만드는 개발자가 되기 위해 팀장님을 따라 팀원들과 으쌰으쌰 해야겠다. 오늘도 잘 자고 잘 일어나서 화이팅 하기!
