brunch

You can make anything
by writing

C.S.Lewis

by 한나 Dec 12. 2023

03. TOAST! 프로젝트 구워내기

프로젝트를 맛있게 구워내는 기획자의 역할

1부 - 개발자와 협업하기

에이전시, 스타트업을 거쳐 중견 IT기업으로 이직 후, 많은 개발자들과 함께 일하게 되었다.

이전까지는 개발자 1,2명 정도와의 협업이 전부였다면 이곳에서는 팀 단위의 여러 파트 개발자들과 아주 긴밀히 협업해야 했다.


이직 후 처음 담당하게 된 프로젝트는 개인용 클라우드 서비스로 주요 기능에 대한 기술적인 이해가 필요한 상황이었다. 기술에 대한 이해가 전무한 상태에서 개발자들과 부딪히며, 모르는 부분은 물어 물어가며 서비스를 기획해나갔다. 어떻게 보면 이때부터가 처음으로 개발자와 제대로 협업하게 된 시점이 아닐까 생각한다.


돌이켜 보면 그전까지의 기획은 User Side에서의 UX/UI에 대한 고민이 전부였다.

주요 시나리오가 아닌 예외 케이스나 개발 구현이 어려운 기획에 대해서는 개발에서 알아서 처리하시는 경우가 많았다. 에이전시에서는 외주 개발사의 몫이었고, 스타트업에서는 Full Stack 개발자분께서 주도적으로 서비스 개발을 책임져 주셔서 크게 신경 쓸 일이 없었다.


이곳에서는 하나부터 열까지 기획자가 정의해야 할 일이 넘쳐났다.

기본적인 정책과 User Flow는 물론이고 여러 가지 예외 케이스들에 대한 정의가 중요했다.

개발 과정에서 개발자분이 현재 구현 상태에서 변경이 힘든 부분들에 대해서 의견을 제시하면 대안을 마련하고, 도저히 양보할 수 없는 경우엔 설득시키고, 그래도 어려우면 Plan B로 타협하며 기획의도를 관철시켜 나가야 하는 새로운 미션에 부딪혔다.


창피한 이야기지만 그전까지는 Clinet와 Server / Front-end와 Back-end의 개념조차 명확하지 않았다. 클라이언트가 어쩌고, API가 어쩌고, 서버가 어쩌고 하는 이야기들이 외계어처럼 어렵게만 느껴졌다.

개발 공부까지는 아니더라도 개발자들과 소통이 되려면 어느 정도의 지식이 있어야겠다고 생각하고, 기본적인 개발 용어와 개념에 대해 공부하기 시작했다.


https://opentutorials.org/course/1

개인적으로 도움을 많이 받은 사이트 '생활코딩'
기본적인 클라이언트/서버의 개념부터 웹의 전반적인 개념을 공부할 수 있는 좋은 커리큘럼이 많다.


개발자와의 협업은 서로 다른 언어를 이해하는 것에서부터 시작해 서비스 구현 방식의 개념을 이해해야 하는 일들이었다. 물론 1순위는 User의 사용성에 집중해서 서비스를 만들지만, 그 UX/UI를 구현하기 위한 개발팀의 구현 과정에서 타협이 필요한 순간도 있었다. 그럴 때는 개발이 가능한 범위에서 최대한 사용성을 해치지 않을 plan B를 고민하고 문제를 해결해 나갔다.


그 과정에서 중요한 것은 ‘신뢰’라는 생각이 들었다.

각 팀의 전문성을 신뢰하고 모두가 좋은 서비스를 만들겠다는 하나의 목표를 바라본다는 신뢰가 있으면, 기획 의도에 대해 설명했을 때 피드백에 대해서도 잘 받아들일 수 있고, 더 좋은 방향을 찾거나 개발이 어렵다고 해도 함께  해결책을 고민하며 더 좋은 서비스가 만들어질 수 있다.


이런 신뢰를 쌓아가며 일을 하기 위해서 중요한 것이 커뮤니케이션(소통)이다.

서로의 입장에 대해 이야기하고 피드백을 주고받는 과정에서 커뮤니케이션은 함께 일하는 구성원들 간의 신뢰의 환경을 만들어 가는데 중요하다는 생각이 들었다.


단순히 상대방이 듣기 좋은 소리를 하는 커뮤니케이션 스킬을 말하는 것이 아니라,

이슈나 현상에 대해 투명하게 공유하고 명확하게 본인의 의견을 전달하면서 상대방의 입장도 고려하여 대화를 주고받는 대화의 기술을 말하는 것이다. 서로 의견이 다른 부분에 대해서는 갈등에 초점을 맞추는 것이 아니라 문제 해결에 집중한다. 이런 커뮤니케이션 방식과 본인의 작업 결과물들이 쌓여 신뢰를 만들어 가는 것이 아닐까.

거기에 분위기를 부드럽게 해주는 캐주얼한 스몰토크 스킬까지 더해지면 협업을 위한 소통에 도움이 되리라 생각한다.


결국은 사람들이 하는 일이다. 개발자와의 협업이건 다른 팀과의 협업이건

프로젝트 성과만큼이나 구성원들과 즐겁게 일하는 것 역시 일하는 맛이 나게 하는 이유이다.



2부 - 디자인 개발 빼고 다 합니다만


이직한 회사에서의 기획 업무는 스타트업에서의 업무보다는 범위가 축소되어 기획 전문성을 기를 수 있었으나, 여기서도 제너럴리스트로 서비스 기획과 관련된 전반적인 다양한 업무를 하게 되었다.

특히 이전까지 내가 기획이라고 생각했던 프로세스(요구사항 분석 > 상위기획 > IA / 정책 > 서비스 flow / 상세설계) 이후에 프로젝트를 매니징 하는 부분에서의 역할이 커져갔다.


사업에서 어떤 서비스 혹은 기능을 개발해야 할지에 대한 미션이 떨어지면, 만들어야 하는 서비스에 대한 방향성을 설정하고 콘셉트를 정리하고(상위 기획) 상세 정책과 주요 Flow를 그려 유관 부서에 리뷰 후 피드백을 반영하여 법무 검토를 받고, 상세 설계 후 실제 디자인, 개발, QA, 배포에 이르는 과정을 매니징하고 마케팅을 고민하는 부분까지… 흔히들 서비스 기획이라고 생각하면 포함되는 광범위한 범위의 일을 배포 주기에 맞춰 하나의 사이클로 스프린트를 진행하였다.


흔히들 기획자는 뭘 하나요?라고 했을 때 우스갯 소리로 디자인, 개발 빼고 다 합니다.라는 말을 할 수 있는 정도의 업무 스콥이었다.


그러다 보니 각 과정에서 나의 강점이 어디에 있는지, 내가 어떤 부분에서 더 재미있게 일하고 있는 지를 전체적으로 알아볼 수 있는 좋은 경험이었다고 생각한다.

내가 잘하는 일, 해야 하는 일, 하고 싶은 일에 대해 명확히 알 수 있었다.


내가 잘하는 일, 나의 강점은 구조화하는 능력.

서비스의 방향이나 큰 그림을 그리고 시각적으로 표현하는 비주얼 싱킹 능력이었다. 사실 예전에는 이런 작업으로 칭찬을 받아도 이게 무슨 강점인가라고 생각을 했는데, 펼쳐진 생각들을 정리하고 그것을 시각화할 수 있다는 것이 큰 강점이 될 수 있다는 걸 서비스 앞단에서 방향성을 잡는 상위 기획 작업을 하면서 알게 되었다.


여러 부서와 협업하면서 기획자로서 해야 하는 일은 프로젝트를 매니징 하는 일.

WBS(Work Breakdown Structure)를 통한 스케줄 관리와 유관 부서와의 커뮤니케이션 능력이 중요하게 요구되었다. 혼자서 작업하는 걸 좋아하던 터라 사실 이런 PM의 역할은 나와 맞지 않는다고 생각했다. (협업과 프로젝트를 매니징 하는 일은 또 다르니까) 그러나 여러 서비스를 배포하고 진행해 가면서 프로젝트를 매니징 하는 과정에서의 뿌듯함과 성과를 맛볼 수 있었다. 다행히 해야 하는 일이 하기 싫은 일이 되지는 않았다.  하지만 프로젝트 매니징 업무에만 몰두해 있게 되면 공허함이 찾아왔다. 하루종일 이 팀, 저 팀을 쫓아가며 진행 상황을 확인하고, 이슈를 체크하고 난 이후에 퇴근 시간이 되면 실제 내 작업물로 남아 있는 작업이 없었다.

디자이너 출신이다 보니 눈에 보이는 작업물이 없으면 왠지 모르게 불안한 마음이 드는 것도 사실이었다.


가장 재미있고 하고 싶은 일은 역시 UX/UI를 설계하는 일.

어떤 날은 하루 종일 잡히는 회의를 다른 날로 몰아서 온전히 업무에 집중하는 하루를 만들고, UX/UI 기획 작업에만 몰두하다 보면 하루가 금방 지나갔다.

User Flow를 고민하고, 화면에 배치되는 UI를 고민하는 시간들이 재미있었다. 그렇게 만든 기획서를 디자인, 개발팀에 넘겨 구현된 서비스를 보는 일이 즐거웠다.


결국 그 당시 시점에서 가장 하고 싶은 일은 UX Design이었고, 좀 더 UX에 집중하는 업무로 다음 직장을 선택하게 되었다.



3부 - 프로젝트 맛있게 구워내기

프로젝트를 배포하는 과정은 토스트를 굽는 것 같다.

재료(기획, 디자인, 개발)를 넣고 필요한 일정 시간(WBS)에 맞춰 뜨겁게 달리다 배포 일정에 맞춰 탁하고 내놓는 순간의 성취감이 있다.


물론 그 과정이 마냥 순탄한 것만은 아니다.

몇 번이나 기획 리뷰를 진행했음에도 서로 생각하는 바가 다른 결과물이 나올 때도 있고, 타이트한 일정에 기존의 기획서를 몇 개씩 쪼개가며 배포를 진행해야 할 때도 있다.

정해진 일정(기한) 안에서 얼마큼의 업무를 소화해서 일을 할 수 있을까를 계속해서 체크하고 관리해야 한다.


PM(여기서의 PM은 Projet Menager를 말한다)은 그런 일을 잘 해내야 하는 사람이다.

 

프로젝트 매니저는 프로젝트가 성공할 수 있도록 업무를 지휘하는 지휘자이자 선장과 비슷한 역할이다. 이해 관계자 간의 원활한 커뮤니케이션을 주도하며 의견을 조율하고, 팀 단위의 업무별 진척 사항과 일정, 이슈를 관리하는 일이 주요 업무이다.  


몇 번의 배포와 신규 서비스 론칭을 거치고, 업무에 익숙해졌을 때쯤 또다시 이직에 대한 고민이 찾아왔다.

이곳에서도 역시 번 아웃이 왔었고, 사람 때문에 힘들어도 봤고, 그럼에도 대외적으로 좋은 성과도 거둬보고, 여러 성장을 할 수 있었다.


일을 지속할 수 있는 원동력 중 가장 중요한 것은 결국 성장이다.

성장하고 있다는 생각이 들고 앞으로도 성장할 가능성이 있다고 판단되면 계속 머물렀다.

그러다 어느 시점에서 채워지지 않는 포인트를 발견하고 성장의 가능성을 보지 못하면(이 부분은 굉장히 주관적이지만) 이직을 결심했던 것 같다.


좀 더 변화가 빠른 트렌드 한 마켓, 더욱더 성장할 수 있는 환경에 대한 갈망이 생기기 시작했다.

그렇게 새로운 도메인, 보다 전문적으로 세분화된 업무 범위, 글로벌한 마켓에서의 경험을 두루 가지고 성장할 수 있으리라 판단된 다음 회사에서 나의 다음 커리어를 이어가게 되었다.


기획자로서 할 수 있는 A부터 Z까지의 경험을 이곳에서 진하게 경험해 보았다.

요즘은 PM 혹은 PO처럼 좀 더 사업 쪽으로 포커싱 된 전문성을 부각하는 업무 포지션도 늘어나고 있다.

어떤 이름으로 불리건 간에 프로젝트의 처음과 끝을 끝까지 책임지고 마무리 짓는 사람, 그 과정에서 동료들과 함께 뜨겁게 열정적으로 맛있게 프로젝트를 구울 수 있는 사람이 되고 싶다.


매거진의 이전글 02. 몰입, 차이의 START UP!
브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari