일 잘하는 기획자는 어떻게 프로세스를 그릴까?
초보 기획자도 가능한 1,2,3단계 프로세스 작성법
기획 신입 때, 개발지식까지 알고 계신 한 기획자님의 프로세스에 대한 이야기를 들은 적이있다.
B1 용지를 빼곡하게 채운 자잘한 프로세스들 안에는 지금 내가 그리는 기획 프로세스에 DB, 모델, 뷰, 프로시저, 배치까지 모두 들어가 있었다고 한다. 전체 과정을 다 알고 있다보니, 개발에서도 업무를 함에 있어서 편하게 진행했다고 들었었다.
직접 프로세스를 그려보고, 위와 같은 일화를 듣고, 실제로 실무에서도 커뮤니케이션하는 데 많이 쓰다보니
이제는 나 역시도 기획자들에게 기획서 다음으로 많이 시키는 게 '프로세스'가 되었다.
그런데, 이 프로세스를 Front, Back(서버), DB에 대해 한번에 작성하기는 참 어렵다.
그래서 실제 내가 기획자들에게 지시했었던, 초보 기획자들도 프로세스를 잘 그릴 수 있는 방법에 대해 소개한다.
1단계 : 구분없이 쭉 그리기
예를 들어, 구청에 여권을 갱신하러 가는 프로세스를 그려보자.
집 출발 → 이동 → 구청 방문 → 번호표 뽑기 → 여권 갱신 서류 작성 → 여권 갱신 완료
이게 1단계 이다. 그냥 자연스러운 흐름대로 쭉 써내려가는 것이다.
1단계 프로세스 그리기주문/결제 프로세스라고 가정한다면, 아래와 같이 간단하게 끝날 것이다.
장바구니 메뉴 진입 → 주문상품 선택 → 결제하기 버튼 클릭 → 배송지 정보 입력/확인 → 결제수단 선택 → 결제 → 결제완료 확인
각 페이지에서 선택해야하는 요소를 각 프로세스 하단에 작성하는 것도 좋다.
주문/결제 화면에 보면 "고객 정보, 주문할 상품 목록, 쿠폰 목록, 포인트 사용/결제, 결제수단, 주문약관동의"
등 포함되어야하는 요소들이 있을 것인데, 이를 포함해서 작성하면 2단계를 그릴 때 좀 더 수월하게 그릴 수 있다.
2단계 : 상황에 따른 분기처리 포함하기
1단계는 정말 아무 변수 없이 상황이 순조롭게 흘러갔을 때를 단순하게 그린 것이다.
2단계에서는 상황에 따른 분기처리가 필요하다. 2단계부터는 시작과 종료를 함께 기입해
주문/결제 상황에서 가장 많이 고려할 수 있는 게 쿠폰 사용 여부, 포인트 사용 여부와 같은 복합 결제 상황,
카드결제 중에서도 자체 페이를 이용할건지, 카드사 앱을 쓸 건지, 또는 계좌이체를 할 건지에 대한 상황 분기가 필요하다.
분기 표시는 마름모로 표시하기도 하지만, 케이스가 여러개일 경우는 프로세스 장표를 아예 분리하는 게 좋다.
[결제 수단에 대한 분기]
1) 주문/결제 - 복합 결제 (쿠폰/포인트+카드결제)
2) 주문/결제 - 복합 결제 (쿠폰/포인트+계좌이체)
3) 주문/결제 - 카드 결제
4) 주문/결제 - 페이 결제
5) 주문/결제 - 계좌 이체
[상황에 따른 케이스 분기]
1) 주문/결제 - 주문 중 상품이 품절되었을 때
2) 주문/결제 - 결제 오류가 났을 때
...
보통 저 프로세스를 다 그리지는 않는다. 다만, 2단계를 그릴 때 중요한 점은 "케이스 분기" 이다.
어떤 케이스들이 있는지, 각 화면마다는 어떤 요소들이 들어가야하는지가 들어간다면
프론트 뿐만 아니라 관리자 페이지를 작성할 때도 용이하며, 개발에서도 고려해야하는 프로세스를 미리 제시할 수 있다.
2단계 프로세스 그리기프론트에서 일어나는 부분, 백 단에서 처리될 부분, 현장(오프라인)에서 일어나는 부분을
각 사각형마다 색상을 다르게 지정해 구분해 놓으면 3단계를 그릴 때 훨씬 수월하다.
3단계 : 최소 3가지 관점에서 프로세스 정의
3단계에서 분기처리를 마쳤으니, 이제는 관점별로 볼 차례이다.
서비스 되는 대부분의 프로세스들은 프론트, 서버, DB를 거치게 된다.
2단계에서 이미 사각형마다 색상을 다르게 구분해 놓았다.
이를 각 관점의 위치에 따라 프로세스를 옮겨주고, 화살표로 이어주면 된다.
*F : 프론트 / DB : 데이터베이스 / B : 백오피스(관리자페이지)
주문 완료[F] → 주문내역[DB] → 배송 내역[DB] → 주문내역 [B] → 배송내역[B]
(주문완료와 동시에 DB와 백오피스에 꽂히긴 하지만, 나는 DB에 적재가 된 이후 백오피스에서도 DB 정보를 끌어온다는 관점으로 보았기 때문에 순서의 차이가 좀 있다.)
PPT로 작성할 때는 한 페이지 안에 다 안담기는 경우가 있어서 [Link] 표시를 생성해, 다음장에 프로세스가 이어지도록 구성했다.
피그마가 프로세스를 한눈에 보기에 용이하지만, 나는 주로 PPT로 작성한다.
장표가 나눠져 있어, 크게크게 볼 수 있기도 하고 장표가 끊어져 있기 떄문에 약간의 쉼(?)을 준달까.
어떤 툴을 쓰느냐는 상관없다. 프로세스만 눈에 잘 보이면 된다.
이처럼 프로세스는 가급적 왼쪽 상단에서 오른쪽 하단으로 끝나는 대각선 구조를 띄면 좋다.
권장사항이기 때문에 상황에 따라 끝나는 지점은 달리해도 좋지만, 위 → 아래로 끝나는 구조로 하면 흐름상 자연스러울 것이다.
빨리 공유하고 바르게 수정하기
신입 뿐만 아니라, 주니어 기획자들에게 당부하는 게 있다.
기획 팀장 또는 개발자들에게 프로세스를 자주 확인해서 프로세스가 맞는지 확인하고 수정 하는 과정은 필수다.
기존의 프로세스를 보며 프로세스를 그렸다고 해도, 디테일한 부분이 빠질 수 있고, 잘못될 수 있다 라는 걸 스스로 잘 알아야한다.
"제가 업무 파악 위해서 프로세스를 그려보았는데, 이 구조가 맞는지 검토해주실 수 있나요?"
라고 요청하면 대부분 함께 고민해준다.
빠르게 공유하고, 바르게 수정하는 과정을 여러번 거쳐야 한다.
프로세스를 그리는 과정에서도 이런 부분은 어떻게 처리되는지에 대한 질문도 꼭 적어서
검토 요청 시 함께 논의하는 게 좋다.
프로젝트를 하며, 당시 팀원들에게 화면설계 보다도 프로세스를 정확하게 그리는 것이 중요하다며, 여러 케이스에 대해 고민해보라고 여러 번 수정 지시를 했었다. 나 역시도 처음 프로세스를 그릴 때 이걸 이렇게나 오래 걸려서 작성할 일이냐며 투덜거렸었는데, 고생한 만큼 더 넓은 관점을 가질 수 있었기를 바란다.
오랜만에 이전 프로젝트를 회고하며, 당시 나를 잘 따라와주었던 팀원들에게 고맙다는 말을 전하고 싶다.
