마지막 업무 일지를 쓰고나서 9개월이 지났다..!
그동안 참 다사다난한 일들이 있었는데..
기승전을 건너 뛰고, 결만 말하자면
22년도 9월부터 원래 다니던 회사에서
개발자에서 기획자로 직무변경을 하게되었다ㅏㅏㅏ
비록, 회사의 필요에 의한 직무 변경이었지만
현재 직무가 훨씬 적성에 맞고 능률이 오름을 느끼고 있어,
앞으로는 기획자로서의 스킬을 늘려나가보려고 한다ㅏㅏㅏ
직무변경에 대한 자세한 사항은 아래의 서론을 통해 확인하시길!
+++ 서론
내가 기획자로 전향하게 된 계기는
1차로 마케팅팀에 대한 불신 때문이었다ㅏㅏ!
자세한 사내 사정을 전부 이야기할 순 없지만,
현 회사의 프로젝트들은 담당 마케터들이 주도하여 프로젝트가 진행되는 구조였는데,
현재 회사의 마케터분들께선 서류를 작성하는 것을 극히 꺼려하셨고,
서류 작성 숙련도 또한 매우 저조한 상태였다ㅏㅏ ㅠ
(pdf 파일을 변환하는 법을 몰라 요청할 정도...)
아주 예전부터 해당 문제에 대해 직/간접적으로 회사에 개선요청을 드려왔으나
해결되지 않았고, 결국 큰 규모의 프로젝트들에서
프로젝트 담당 마케터의 기획누락과 IT 서비스의 기능 이해도 낮음으로 엉뚱하게 기능이 구현되는 등의
문제가 발생했고, 결국 회사가 소송에 휘말릴 수도 있을 정도의 수준이 되었다....ㅠ
(물론 개발자로 있었던 당시를 회상했을때,
스스로의 개발 숙련도가 높지 않았다는 것도 프로젝트 진행의 더딤에 일조했을 수 있다고 생각한다!!
하지만 계속 바뀌는 DB와 요구사항들... 그 모든게 뒤죽박죽 섞인 파일을 고객사께 받아서 전달만하고 정리도 안하는
담당 마케터들을 보며.... 차마 내탓이다! 라는 말이 나오지는 않는다 ㅠ)
해당 일이 있고나서,
회사 임원분들께서는 프로젝트 진행방식의 근본적인 문제가 있다는 것을 느끼셨고,
여러 방법을 찾던 중 기획부서의 신설과 더불어,
나의 해당 부서로의 편입요청을 받아주셨고,
그렇게 개발기획팀부서가 생기고, 나는 PM이 되었다ㅏㅏㅏㅏㅏ
위의 글을 쓰면서 눈물이 흐르려고.... 하는 이유는.... 껄껄
현재 나의 프로젝트 매니징 (PM) 업무 프로세스는 아래와 같다
*** 본인은 스타트업 특성상 공식적인 회사 프로세스가 있었던 적이 없다 ㅠㅠ
때문에 해당 블로그에 적힌 모든 업무 프로세스들은 (살아남기 위해) 스스로 만든 업무방식이니 참고만 해주시길..! ***
먼저, 프로젝트의 시작과 끝까지를 각 시점별 대분류로 나눌 수 있다
1. 고객사 미팅 단계
2. 프로젝트 계약 확정 단계
3. 프로젝트 중간 점검 단계
4. 프로젝트 마감 단계
그리고 각 단계별 내가 하는일은 아래와 같다
고객사 미팅 단계
- 고객사가 기획 / 디자인 등의 구체적인 서비스 기획 산출물이 있으신 경우 or 고객사가 곧 협력사일 경우
a. 고객사의 서비스 기획을 확인하고, 서비스 제안서를 작성
- 서비스 제안서에는 보통 서비스 세계관, 로드맵, 주요 기능, 개발견적 등이 종합적으로 들어가있다
b. a가 마련되어 있을경우, 회사 소개 파일 (기존에 개발된 프로젝트들의 예시모음집과 비전 등이 담겨있다)을
전달
c.고객사 미팅 직접 참여 또는, 프로젝트 담당 마케터에게 프로젝트 정보받기
d. 위의 정보로 고객사 정보, 프로젝트 의뢰 형태와 레퍼런스 등을 파악해서 노션차트 작성
e. 고객사 미팅 중 발생한 기술적 문의 또는 기존 자사 서비스 시연 요청 응대
프로젝트 계약 확정 단계
- 임원 분들이 결정한 계약 내용에 따른 금액과 고객사 요청사항을 정리한 견적서 작성
- 계약완료 직후부터 프로젝트 기획 산출물 작업 후, 디자인팀에 전달드리고 디자인 의뢰
기획 산출물의 종류는 프로젝트마다 다르나, 대부분 아래와 같다ㅏㅏ
a. 플로우 차트 : 서비스에 필요한 페이지 단위 혹은 기능단위로 작성하며,
보통 유저 / 어드민 각각으로 구분해서 작성
b.와이어프레임 / 스토리보드 : 와이어프레임은 대강의 UI만 잡는 것,
스토리보드는 해당 페이지가 존재하는 이유부터,
페이지 플로우, 디자이너님, 개발자님께 전달드릴 디테일한 요구사항 등을 전부 작성
- SI 특성상 내가 하나의 프로젝트만 맡고 있을 수가 없기 때문에, 보통은 스토리보드만 작성하며,
나는 보통 Pigma / whimsical 툴을 사용하고 있다 - 임원분들과 상의하여, 프로젝트 팀 편성
- 해당 프로젝트를 참여하고 싶으신 개발자님이나 디자이너님이 있으시면 우선 추천!! - 노션차트의 프로젝트 정보와 마감 일정 등을 요약 정리하여 슬랙 채널에 공유
- 디자인팀에 의뢰드린 1차 디자인 고객사 전달,
1차 수정사항 디자인팀에 전달드리고 2차 디자인 시안 대기 - 5번과 같이 2차 디자인 시안 전달 후,
2차 수정사항 받고, 해당 수정사항 적용된 최종시안 고객사 컨펌받기 - 컨펌 완료된 디자인과 프로젝트 스토리보드 개발팀에 전달드리고 개발 의뢰
프로젝트 중간 점검 단계
프로젝트 중간 점검 단계는 보통 프로젝트 마감일에서 한달 정도의 간격을 두고 정한다
(프로젝트 규모에 따라 2번의 중간점검을 거치기도 함!)
1. 개발자님들이 작성한 작업일지를 통해 중간 점검 단계까지 생각해둔 기능들이 잘 작동하는지, 앞으로 마감까지 남은 기간동안 남은 기능들을 쳐낼 수 있는지 파악
- 프로젝트의 진행도는 개발자님들께서 스스로 그날 작업한 분량을 슬랙 채널 or JIRA에 올려두시기 때문에
해당 사항들을 확인하고 혹시나 생각치 못한 공수 기간이 오래 걸리는 작업이 있지는 않은지 개발자님 자리로 직접가서 간간히 여쭙는게 좋다ㅏㅏㅏ!
2. 완성된 기능들 테스트 / 오류 발견 시 개발팀에 수정요청
3. 고객사 요청이 따로 있을 시, 미완성 단계의 도메인 전달
- 종종 고객사께서는 개발 진행도의 파악을 원하신다ㅏㅏ!
때문에, 개발 기능의 차트를 작성하여 완료 / 미완료, 에러사항과
+++ 추가 요청사항 등을 정리한 개발 현황 리스트를 작성하여 두면 좋다ㅏㅏㅏ
프로젝트 마감 단계
프로젝트 마감단계에서는 프로젝트의 기간 내 마감을 최우선 목적으로 두어야한다ㅏㅏㅏ!
- 이때 정신을 바짝 차리지 않으면.. 추가요청의 굴레에서 벗어날 수 없다...ㅎㅎㅎ
- 프로젝트 마감기한의 약 2-3주 전 전체 기능에 대한 내부 QA를 진행 / QA 차트 작성
프로젝트 규모에 따라 다르지만
통상 1달짜리 플젝의 경우 1주-몇일
3달 이상의 플젝의 경우 2-3주 정도 넉넉하게 기간을 잡아두면 좋다 - 내부 QA가 얼추 끝났을 경우, 고객사에 유저 / 어드민 도메인 전달 후, 외부 QA 진행
유저 / 어드민 각각에 등급이 존재할 경우,
등급별로 미리 계정 생성 후, 계정정보도 함께 전달하면 좋다!
+++ 외부 QA가 수월할 수 있게 시간의 여유가 있다면,
특정 페이지들은 (대부분 어드민 페이지) 가이드 작성 후 함께 전달한다ㅏㅏㅏ
사실 더 세부적으로 작성하면 위의 내용보다 더 많은 업무가 있지만!!!
일단 여기까지 작성해본다ㅏㅏㅏ
우여곡절 끝의 서비스기획자, PM 직무 전환이었지만,
앞으로 나의 주니어 PM으로의 성장여행이 기대되는 중이댜ㅑㅑㅑㅑㅑ
마지막으로,
모든 스타텁/ IT 산업직군의 사회인 여러분들
화이티이이이이잉!!!!!!
'portfolio' 카테고리의 다른 글
| 나의 개발 업무 프로세스 2 (2) | 2022.03.15 |
|---|---|
| 나의 프론트 업무 프로세스 (0) | 2021.04.02 |
| HKLMart 웹 쇼핑몰 구현 (0) | 2021.01.14 |