brunch

매거진 성장하는 UX Designer

라이킷 82 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 서혜림 Feb 13. 2022

야근하지 않는 디자이너

디자인 기반 PO의 첫 걸음

얼마 전 새해가 밝아 (혼자 하는) 회고를 했다. 분기를 보내고 가장 크게 변한 점은 팀을 위한 일정 관리 능력이 피어나기 시작했다는 점이다. 물론 러닝 커브의 앞 단계라 타의 추종을 바라거나 이걸 스크럼 매니징이라 부를 만큼 멋지지는 않을 수도 있다.

그동안 스스로 필요한 능력을 '빠르고 논리적으로 사용자의 문제를 정의하는 능력' '뻔하지 않은 솔루션을 찾아내는 힘'이라 정의했지만, 그다음 스텝으로는 '내 일정과 팀의 일정을 파악하고 조율해내는 능력'에 집중했던 것 같다. 힘들게 찾아낸 솔루션을 실제 서비스에 녹여내려면 개발자와 매니저, 이해관계자들과 합을 맞추는 게 필요했기 때문이다.

스크럼 매니징 : 스크럼 매니저와 프로덕트 오너가 다르다고도 하는데, 대개 PO가 해내는 것 같다. 프로젝트 마감까지 목표 도달을 이룰 수 있도록 코칭하거나 가이드를 제안하는 스케줄 매니징이라고 보면 된다.

이 글이 도움 될 사람은,

- 업무 계획을 세우지만 항상 일이 급한 디자이너

- 혈혈단신, 회사의 디자이너라곤 나뿐인 디자이너

- 디자이너가 아니더라도 바빠서 눈물 나는 사람들

왜, 하루도 빠짐없이 바쁠까?

회사의 모두가 각자의 이유로 바쁘지만, 프로덕트 디자이너는 일(기획 및 배포)과 일(개발 및 배포) 사이에 끼어있는 사람이라 바쁘다. 본업인 기획/디자인도 급한데 타 부서에서 들어오는 질문도, 요청사항도 많다. 압박을 견디지 못한 프덕 디자이너는 예민해짐과 동시에 일을 마구 해치우다 실수를 연발한다. ASAP이라며 들어오는 각 부서의 요청사항들을 들어주다 내 일을 마치지 못해 연일로 야근을 밥 먹듯 하고 가장 중요한 테스크가 지진부진, 도무지 끝나질 않아 개발이 밀리는 상황도 초래하는 것이다.

(참고로 나는 야근을 했다는 건 오늘 나의 하루, 혹은 팀의 업무 체계가 효율적이지 못했다는 뜻 이외엔 그 무엇도 갖지 않는다고 생각한다...)

숨 쉴 틈이 없다.

앞선 문제들이 발생하는 이유는 다음과 같다.

1. 내 앞에 놓인 테스크의 양과 중요도를 간과했다.
2. 회사 전체의 디자이너 리소스가 너무 부족하다.
3. 명확한 마감 기한이 있었으나 완성도에 집착했다.
-> 이건 여러 번 실수하고 자중하며 완벽주의를 놓는 수밖에 없다.
4. 팀원들이 어디까지 뒤쫓아 왔는지 모른다.

놀랍게도, 2번을 제외하곤 경력을 웬만큼 쌓은 시니어들은 겪지 않는 문제들이다. 그분들도 매일 시간에 쫓기긴 하지만 팀에 제동이 걸릴 만큼의 실무 문제를 일으키거나 '아차, ' 하지 않는다. 비결은 뭘까. 동년배(?) 주니어와 시니어/매니저들을 관찰하고 알게 된 차이에서 비롯해, 나와 팀의 깔끔한 일정관리를 위한 팁을 정리해보았다.

'작은 일, 작은 성과'에 중독되지 않기

이해관계자들의 필요에 비해 디자이너 리소스가 부족하면 야근이 잦아지거나 미치도록 바쁠 수 있다. 기획, 디자인, Align 미팅, 마케팅 컨텐츠 디자인, 기사나 IR 자료에 필요하다는 장표 등... 그러나 시즌 없이, 항시 야근이나 잔업이 많다면 그 이유가 정말 리소스가 부족하기 때문인지 반추해보자.

신수정 님의 <일의 격>에서는 이렇게 말한다. '스스로 쉬운 일이나 빠르게 마칠 수 있는 일, 결정을 내리기 위한 제반 회의에 지나치게 많은 시간을 쏟고 있는 경우가 많다. 쉽게 일을 해결하고 느끼는 성취감 때문에.' 자신이 '작은 일'의 처리하며 따라오는 필연적인 만족감, 안녕감에 중독되어 있지 않은지 점검해볼 필요가 있다. 팀의 문샷 씽킹은 자그마한 테스크나 고민으로 이루어지지 않는다. 내가 하는 지금 하는 일의 결과가 무엇일지 항상 생각하자.

문샷 씽킹 (Moon Shot Thinking) : 1960년 미국 케네디 대통령이 달에 우주선을 쏘아 올리기 위해 한 지면을 뒤집는 생각. 천문학적인 비용이나 대가를 감수하더라도 이루기 어려운 것도 달성하게 만드는 목표

"우선순위대로 합니다"

'나'에게 가장 중요한 건 내가 속한 부서의 OKR과 KPI이다. 당연한 말이지만 끝없이 잡히는 부서별 미팅으로 코어를 (잠시) 잃는 프로덕트 디자이너를 종종 봤다. 위에서 언급한 작은 일, 작은 성과와 무관하게 말이다. 타 팀의 OKR과 KPI 달성을 위한 테스크가 내 목표를 앞질러서는 안 된다.

팀을 버리지 않습니다

Silo(부서 개인주의)를 지향하라는 말은 아니다. 타 부서의 요청사항을 처리할 수 있는 사람이 나밖에 없다면 더 말할 것도 없이 내가 해야 한다. 다만 한 발을 어딘가에 걸치더라도 나머지 한 발은 나의 팀에 있어야 하고, 여유가 있을 때 영역 밖의 것들을 해결해주는 게 이롭다.

물론 요청한 당사자에게 '결과물이 만들어지기까지의 시간을 고려해서 요청해달라', '이건 ~로 인해 바로 하기 어렵겠다'라고 말할 수 있는 완곡한 거절의 기술 정도는 있어야 한다. 말하지 않으면 이 마음을 영원히 모르고 싶어 할 것이기에. (내가 요청을 해야 하는 반대의 상황에서 역지사지할 줄 아는 건 아주 당연한 기본 마인드셋이다.)

내 업무 패턴과 한계 알기

내가 만난 일잘러들은 그들의 업무 패턴과 한계를 기반하여 전략적으로 일하는 사람들이었다. 본인이 언제쯤 집중이 잘 되는지, 온전히 사용할 수 있는 본인만의 시간이 얼마나 되는지를 대강이라도 안다. 그들은 감각적으로 일의 효율을 알아낸 걸까? 그렇지 않다. 패턴을 찾을 때까지 시행착오를 감내했을 것이다.

시간 안에 한정적인 리소스로 목표를 달성하길 원한다면, 필요한 절대적인 시간을 측정하고 스스로의 패턴과 한계를 인지할 필요가 있다. 한계는 전략을 짜도록 돕는다. 시험공부도 전략이 필요한 것처럼 말이다. 다행스럽게도 21세기의 IT 씬에는 이 둘을 알 수 있도록 돕는 툴이 꽤 있어서, 측정에 큰 어려움이 없다.

<'애자일' 굴에 들어가서 정신 똑바로 차리는 법>에서도 다뤘던 툴이지만, Jira는 팀이 할 수 있는 일의 '양과 속도를 측정'할 수 있도록 도와준다. 보통 팀의 Sprint(스프린트) 성패를 확인하거나 다른 팀원이 무슨 일을 하고 있는지 확인하기 위해 사용한다. 하지만 본질적으론 일의 양과 속도를 측정해, 다음 스프린트를 성공으로 이끌 수 있도록 돕기 위해 만들어졌다.

나는 내가 해낼 수 있는 능력이 얼마나 되는지 보고 싶어서 팀 스프린트와 별개의 새로운 칸반을 파서 관리하고 있다. 근로기준법을 신경 쓴 건 아닌데, 신기하게도 나는 주 40 point(=시간) 정도의 테스크만 핸들 할 수 있었다.

Tasks와 끝내기까지 필요한 시간 측정을 위한 햄 보드

이 40시간 중 10시간 정도는 (참여할 수밖에 없는) 회의 시간이 포함되어 있다. 실질적으로는 최대 30시간만 OKR을 향해 달릴 수 있는 것이다.

이 30시간은 귀중하다. 때문에 30시간을 최대한 잘게 잘라 운용한다. 혹시 모를 인터럽션이나 갑작스레 생길 회의 시간을 고려해 구글 캘린더에 Focus time의 명목으로 빈칸을 확보해 두는 식이다. 이 회의실, 저 회의실, 이 일, 저 일 왔다 갔다 하며 발생하는 Switching cost를 줄이는 것이 집중에 도움이 된다.

Jira를 사용할 때의 원칙 다섯 가지

1. 팀의 스프린트 기간과 내 스프린트의 기간은 달라도 상관없다.

2. 최대한 잘게 쪼개서 Task를 구분한다. 최대한!

3. 중요도가 높고 시간이 많이 걸리는 내 팀의 일을 가장 우선해서 처리한다.

4. 한 주의 스프린트가 시작하거나 종료했을 때, Meeting 시간을 포함한 내 업무 처리 가능 시간이 얼마인지 측정한다.

5. 스프린트 달성에 실패했다면 좌절하지 않고 이유를 파악한다. (테스크가 많았는지, 가장 중요한 일이 한참 남았는지)

팀 스크럼, 회고 주도하기

우리 팀에는 PM, PO가 없어서 주에 한 번 만나는 미팅으로 팀의 방향성이나 서로의 스케줄을 확인'만'하고 뿔뿔이 흩어졌었다. Nice to have보단 오로지 프로덕트의 필요, Must에 의해 움직이는 집단이었는데, 이런 집단은 더 급한 필요가 나타날 때마다 흔들릴 수밖에 없고 그때마다 디자이너(나)는 만들어지지 않을 시안을 잔뜩 만들어버린 채 추풍낙엽처럼 지쳐버렸다. 주니어더라도 PM 역할의 일부를 자처해야 하는 상황이 왔다면, 스크럼 미팅과 회고는 꼭 주도해서 진행해보는 것을 추전 한다.

나와 팀원의 업무 현황을 공유하는 데에 스크럼 미팅이 가장 좋기 때문이고, 이 미팅을 주도하게 되면 적어도 팀의 흐름을 놓치는 일은 없게 된다. 그 말인즉슨, 타 부서의 요청사항의 디자인, 개발은 언제 시작할 수 있을지 어느 정도는 예상할 수 있게 된다는 뜻이다. (뇌에 자동으로 업데이트 되는 달력이 있으면 좋겠다.)

대신 부서를 막론하고 부탁했던 개발이 언제 끝날 것 같냐는 모든 질문이 나한테 오게 된다. 방금 처음 들은 거라 모르겠어요...!

잠시 앞으로 돌아가서,

1. 쉬운 일이 아닌 문 샷 씽킹부터,

2. 타 팀이 아닌 우리 팀의 목표부터,
3. 내 한계를 벗어나지 않는 한도의 분량으로 일하기

이 기본 전제들을 스크럼 미팅을 통해 자주 공유하는 것도 주도자의 몫이 된다. 그러면서 쉬운 일, 타 팀의 테스크는 자연스럽게 후순위를 갖게 되는 것을 볼 수 있을 것이다.

이 외에도

아젠다 없는 회의는 안녕,

일이 바빠지는 이유엔 눈 깜빡하면 생겨 있는 미팅의 탓도 있다. 보통 미팅을 잡은 사람이라면 아젠다를 가져오는 건 당연한 수순 같겠지만, 놀랍게도 그렇지 않은 경우가 허다하다. 이 건 비록 디자이너만 느끼는 페인 포인트가 아닐 것이다. 추측하건대 회의의 안건을 너무 깊게 생각해버린 나머지, 참석자와는 달리 본인은 이 미팅의 골조를 이미 다 알아버려서가 아닐까.

이런 미팅은 첫 20~30분은 주최자의 이야기를 가만히 들으며 시작한다. 시간이 지나고 나면 '그래서 이 미팅 뭘 정하려고 모인 거지'하는 생각이 든다. 아 의미 없어라. 그냥 미팅 시간 동안 내 일을 하면서 Wrap up 노트만 봐야겠다, 하고 마는 것이다. 잠시 회의를 멈추고, '그래서 회의를 통해서 이야기하고 싶으신/결정하고 싶으신 주제가 어떤 것일까요?'라고 물어볼 필요가 있다.

의미 없는 인사이트 (~는 별론 거 같은데 이렇게 해보면 어떨까요? 하는 누구나 생각했을 내용)가 나오는 미팅을 경계하고, 스스로도 그런 미팅은 만들지 않도록 하자. 미팅도 목적은 명확히 공유할 필요가 있다.

스스로에게 하는 잔소리이자 모종의 회사에 다니고 있을 일정 관리에 허덕이는 누군가에게 폭풍 잔소리를 하는 글을 작성했다. 물론 이런 고민을 하는 지점을 이미 지난 주니어도 있고, 멋진 PM, PO의 주도 아래 문제를 느끼지 못했을 사람도 있을 수 있다. 말은 쉽게 썼지만 자그마치 반기를 구르며 얻어낸 뼈저린 인사이트이기에 누군가에게는 꼭 필요한 조언이 되길 바라며...

이상 2021년의 회고를 마친다!

keyword