10년 차 IT 기획자의 노트_1

저자_한성규/좋은습관연구소/약3주읽음

 

한번 더 읽었다. 이 전에 읽었을 때에도 배운 게 많았다. 업무에서 어떻게 적용해볼지 고민했었고, 나는 어떤지 되돌아보게 되는 부분이 많았다.

하지만 이전에는 개발자였고, 이제는 PM이 되었으니 다시 읽어보면 또 다른 시각으로 보일 거고, 또 다른 시각으로 배울 부분이 있을 듯 했다. 역시나였다.

---

1. 시간 관리 - 일의 순서를 통제하는 법

“시간에 끌려 다니지 않기 위해 내일 해야 할 일과 예상되는 소요 시간을 적어보기”

내일 해야 할 일의 작성은 습관이 들여진 것 같은데 소요시간에 대한 부분은 아직까지 어렵다. 업무시간 예상을 측정하는 것이 아직은 어렵고, 큰 단위로 생각해서 예상하곤 한다. 또한 하나가 밀리면 나머지 것들의 순서는 아무렇게나 정해서 행하는 편. 아직 까지는 순서를 아무렇게 정하는 것에 불편함이 없으나, 한번씩 혼란이 있긴하다. 이 혼란이 불편함으로 작용할지도 모르겠다

 

2. 배움 노트 - 배움을 구체화하는 법

“제안 받는 사람의 상황과 입장을 전혀 고려하지 못한 실수 였다.”

나 또한 언제나 제안 받는 사람의 입장을 고려해야겠다는 다짐을 해본다. 제안하기 전에, 내 제안을 받아들일 상대의 입장과 상황을 생각해보기.

“지금도 나는 노션에 작성한 <배움노트>를 확인하는 것으로 하루를 마무리한다.”

직전 회사에서 배움 노트를 틈틈이 써내려갔으나, 어느샌가 적기만 하고 자주 확인하지 않는 것을 발견했다. 배운 것을 체득하려면 더 자주 확인해야겠다고 생각한다. 내 아침 루틴에 배움노트 읽기를 추가 한다.

 

3. 데이터 분석 - 기획자의 데이터 분석 루틴

“데이터는 설득의 근거가 된다.”

PM업무를 시작하면서 고작 몇주사이 여러번 체감했던 문장이다. 결정을 할 때, 협의를 할 때 등 모든 상황에서는 항상 뒷받침할 데이터가 필요했다. 데이터라는 근거가 부족하면 앞으로 나가기 어렵다는 것을 체감중이다.

 

“다만, 우리가 늘 조심해야 하는 것은 보고 싶은 대로 데이터를 해석해서는 안 된다는 것이다. (생략) 데이터를 해석하는 주관자의 시선에 따라 데이터는 얼마든지 다르게 사용된다.”

개발자로서 데이터를 해석하는 것과 PM으로서 데이터를 해석하는 것에 차이가 있는 듯 하다. 개발자였을 때는 맞냐틀리냐 식의 접근이었던 것 같은데, 이제는 데이터를 해석하고 활용해야 하는 상황. 업무를 하면서 ‘보고 싶은 대로 데이터를 해해석 할 수 있겠는데?’라는 생각을 이미 했다. 내 멋대로 해석해놓고 실수한지도 모르고 넘어가는 경우가 있을 것 같고, 지난 뒤에 이 해석이 아니겠구나. 하고 느끼게 되는 시기가 올 것 같다.

문장이 무엇을 뜻하는지는 알겠지만, 직접 경험해보지 않아서 아직은 어렵다. 내 것으로 만들기는 아직 어려운 문장.

 

4. 인터뷰와 대화 - 기획자로서 신뢰를 얻는 소통법

“혼란을 얼마나 잘 정리하고, 참여자로부터 최대치의 노력을 이끌어내느냐가 기획자의 역할이었다.”

“우리가 가장 먼저 해야 할 일은 함께 프로덕트를 구축하고 그 과정을 함께 할 팀 빌딩을 잘하는 것이다.”

 

5. 업무 리스트 - 필요한 일을 주도적으로 찾는 법

“왜 내가 아니라 팀에게 필요한 일을 찾아야 하는가?”

‘팀에게 필요한 일’이라는 단어를 보고 어? 나는 준비가 되어있나. 하고 돌아 보게 되었다. 그리고 ‘팀에게 필요한 일’이라는 개념에 대해서 생각해 본 적이 없어서 순간 벙쪘다. 시도 하고 싶은 것도 해보고 싶은 것도 있는데 ‘팀에게 필요할까’라는 접근으로 생각해본 적이 없는 듯 했다. 그래서 많이 와닿은 문장이었고, 내 업무 방식과 제안에 대한 피드백을 환영한다고 동료들에게 말을 전해야겠다. (이번주)

 

“내가 하는 일이 무엇인지 살펴보고, 그 일이 가진 역할과 가치 등을 살펴보는 시간을 꼭 가져야 한다.”

 

“정말 중요하게 챙겨야 하는 것은 할 수 있는 일과 할 수 없는 일을 구분하고, 팀에게 꼭 필요하고 도움이 되는 내용인지 판단하는 일이었다. 욕심으로 무리하게 일을 잡다보면 업무는 밀릴 수밖에 없고 무엇보다 팀원의 불만과 일정에도 계속 영향을 줄 수밖에 없었다.”

 

“우리가 편하게 일하도록 업무 조율을 해주고 있구나”하는 인식을 줄 수도 있다.”

이 두 문장을 읽고 마음이 뜨끔했다.

현재 4월 이벤트를 앞두고, 사용자 유입 전에 꼭 해결해두고 싶은 업무가 두 가지 있었다. 사용자 경험을 더 잘 얻고, 데이터 분석에도 도움이 될 거라는 나름의 명분을 갖고 개발자에게 요청한 작업들이었다. 그런데 돌이켜보면, 3월 일정이 이미 가득한 상태였고, 그 상황에서 나는 좋은 근거를 앞세워 결국 ‘확정’까지 받아냈다. 그래서 더 찔렸던 것 같다. 좋은 이유가 있다고 해서, 결국엔 내 욕심을 팀에 전가한 건 아닐까?

이후 이 생각을 다음 날 개발자와 솔직하게 나눴고, 아니나 다를까, 결국 두 가지 중 하나의 업무는 우선순위를 조정하기로 했다. 정말 시급한 일이라면 다시 논의할 필요도 없었겠지만, 충분히 조정 가능한 일이었다. 결과적으로 내가 과했던 거다. '이건 분명 좋은 기획이다' 라는 생각이 ‘지금 꼭 해야 하는 일인가?’라는 질문보다 앞서 있었던 셈이다.

“스타트업에서 일하는 주니어들이 입사 초반에 늘 하는 질문 중 하나가 “뭘 하면 좋을까요?”이다. (생략) 일정 기간 이상 근무했다면 팀이 지금 무엇을 하고 있고 무엇을 예정하고 있는지부터 살펴보라고 말한다.”

 

6. 스펙 노트 - 프로젝트 시작을 잘 하는 법

“동료의 공감을 이끌어 내는 방법은?”

“함께 일할 사람을 움직이지 못한다면 아무런 의미가 없다.”

“자발적으로 참여하도록 하는 방법을 갖고 있어야 한다.”

현재 내가 쓰고 있는 방법은 동료에게 먼저 의견을 제시하고, 그에 대한 동료의 생각을 진심으로 경청하는 것이다. 이후 서로의 의견 사이에서 합의점을 찾아가며, 자연스럽게 공감과 참여를 이끌어낸다. 지금까지 몇 주간은 이 방식만으로도 충분했다.

하지만 만약 동료가 내 의견에 공감하지 못한다면? 혹은 애초에 움직이고 싶어 하지 않는다면? 그럴 땐 나는 어떤 방식으로 동료를 설득하고, 함께 갈 수 있을까?

 

“프로젝트가 필요한 이유부터 우리가 무엇을 얻을 수 있는지”

“새로운 일에 대한 설득은 ‘왜’보다 ‘어떻게’가 동료의 부담을 줄일 수 있는 방법이다.”

“우리가 만들고자 하는 기능, 해결하고자 하는 문제, 해결을 위해 필요한 기능, 기능에 대한 소개”

왜 해야하는지, 왜 필요한지에 대한 부분은 데이터와 근거를 바탕으로 충분히 설명할 수 있다. 하지만 어떻게에 대한 부분을 담당자의 책임과 몫으로만 남겨두지 말자. 우리가 어떤 것을 얻을 수 있는지도 설명하자.

꼭 기억하고 안고 가고 싶은 나의 업무 방식이다.

 

“중요한 역할 중 하나는 일이 진행되도록 하는 것”

 

7. 운명 매뉴얼 - 나 없이도 서비스가 돌아가는 법

“업무를 표준화하고, 누가 와도 이 일을 그대로 이어서 문제없이 하려면 매뉴얼 만한 것이 없다.”

이 문장은 지금 내가 겪고 있는 현실과 정확히 맞닿아 있다. 현재 우리 서비스의 고객 응대에는 별도의 메뉴얼이 존재하지 않는다. 지난 3주간 두 건의 고객 문의가 있었고, 모두 내가 만든 공통적인 폼을 바탕으로 응대했다. 하지만 만약 내가 자리에 없다면? 대응 방식의 일관성이 무너지고, 사용자에게 혼란을 줄 가능성이 크다.

더 나아가, 나를 대신해 고객 응대를 맡게 된 사람이 이전 메시지를 하나하나 뒤져가며 답변을 재구성하게 된다면 이는 매우 비효율적인 구조다. 결국 담당자의 리소스 낭비로 이어질 수밖에 없다. 이러한 점에서 고객 응대 업무를 표준화하고, 매뉴얼을 구축하는 일은 서비스의 신뢰도와 운영의 안정성을 위한 토대가 된다.

또한 현재 고객문의 통로가 우리 앱 서비스와 옆팀의 컨설팅 서비스가 함께 쓰는 구조인데, 이 또한 혼선을 유발하는 문제다. 옆팀 서비스는 특성상 저녁과 주말에도 응대가 필요한 경우가 많지만, 우리는 습관형성 기반의 앱이다. 앱 오류와 같은 긴급 상황이 아닌 일반 문의에 대해까지 실시간 응대를 해야 할 필요가 있을까?

고객 만족을 위해 빠른 응대는 중요하지만, 그렇다고 해서 모든 시간대에 즉각 대응을 하는 것은 자원의 낭비일 수 있다. 문의 접수 시 ‘응대 가능 시간’과 ‘답변이 지연될 수 있음’을 사전에 안내하는 것만으로도 사용자 경험을 해치지 않으면서 효율을 높일 수 있다.

물론 지금은 고객 문의량이 매우 적기 때문에 굳이 채널을 분리할 필요가 없다는 의견도 이해된다. 하지만 바로 이런 ‘문의량이 적을 때’야말로, 매뉴얼을 마련하고 고객 응대 체계를 분리해두기에 가장 적절한 시기라고 생각한다. 지금 준비해두어야 고객이 늘어났을 때 혼란 없이 대응할 수 있다.

 

8. 기능 가이드 - 서비스 기능 변경이나 업데이트를 잘하는 법

“기능 가이드는 1) 개요 2)배포 계획 3) 기능 안내 4)기능 FAQ 5)담당자 6)참고 문서 등의 순서로 정리한다.”

‘기능 가이드’라니, 듣자마자 나도 갖고 싶다는 생각이 들었다. 하지만 현재 우리 서비스에는 그런 것이 없다.

그리고 마침, 최근 계속해서 고민 중이던 부분이 있었다.

우리 팀은 배포 요일이 정해져 있다고는 하지만, 실제로는 유동적으로 움직이고 있었다. ‘고정 요일로 하겠다’는 결정은 있었지만, 어떤 시간에, 어떤 기능이, 누가 추가한 건지, 그걸 어떻게 확인할 수 있는지에 대한 정보는 전혀 공유되고 있지 않다.

개발 일정은 늘 촉박하고, 요청되는 개발 건도 수시로 바뀐다. 그런 상황에서 “월요일에 배포합니다”라는 말만 들었을 때, 내 머릿속에는 물음표가 가득 찼다. “어떤 기능을 배포하는 거지?”

며칠 전 개발자분이 찾아와 “지금 이 기능을 개발하고 있어요. 그 옆 부분은 이렇게 바꿔볼까요?”라고 논의했던 부분까지 포함된 건가?

나는 지금 입사한 지 3주차. 내가 제안한 기획이 개발까지 이어지기까지는 아직 멀었다. 당연히 우선순위는 이전에 확정된 개발 건들이다. 그렇다 해도, 나는 너무 손을 놓고 있었다.

‘아무것도 몰랐다’는 건, 결국 ‘아무것도 체크하지 않았다’는 말일지도 모른다.

이 상황을 겪고 나서야 확신이 들었다. 기능 가이드를 당장 써야겠다. 우리 팀은 지금, 기능 개발과 배포에 관해 아무것도 체계적으로 공유되지 않고 있다. ****지금부터라도, 누가 어떤 기능을 만들고 있고, 그것이 언제 어떤 방식으로 배포되는지를 기록하고 공유하는 문서를 만들어야 한다. 그래야 기획도 협업도 제대로 이루어질 수 있다.

 

9. 변수 통제 - 실수를 줄이는 법

“서비스를 구성하는 요소는 매우 다양하고 복잡하다. 기획자에게 변수 통제란 바로 일이 물 흐르듯 흘러가도록 하는 것을 말한다. 제공하고자 하는 기능 자체를 잘 설계하는 것도 중요하지만, 사후 관리와 운영은 더 중요하다. 언제나 예상하지 못한 일은 터지기 마련이고, 이를 잘 통제하지 못하면 팀 전체의 일정이나 업무에 많은 영향을 준다는 사실을 꼭 명심해야 한다.”

 

10. 공유 - 해야 할 일을 정하고, 정보와 지식을 관리하는 법

“보통 ‘백로그’에는 팀원의 의견이나 이슈, 사용자 피드백, 기능 개선 등 다양한 성격의 ‘할일’이 저장된다. (생략) 그런데 기록만 있고 구분도 안 되고 중복 여부 체크도 쉽지 않았다. 한마디로 관리 기준이 없었다. 구체적 내용 없이 제목만 달랑 있는 것도 많았다. 그러다 보니 수없이 많은 항목들을 보는 것 자체가 하나의 압박이었다.”

 

11. 회고 노트 - 더 나아짐에 목표를 둔 회고

“구제적인 상황이나 사례를 기반으로 회고가 진행되어야 다음 주제로 논의가 이어지는데”

매우 공감하면서 읽었다. 좋았다, 좋지 않았다 정도의 평가 위주의 회고는 큰 의미없다고 느낀다. 회고가 아니라 그냥 평가와 결과발표가 아닐까. 어떤 상황에서 어떻게 행동했는지 그리고 어떤 생각을 했는지 어떤 결과로 이어졌는지 구체적인 상황이나 사례가 있어야 회고가 가능하다고 생각한다. 그렇게 해야 의미있는 방향으로 갈 거라고 생각한다. 평가만으로도 의미를 발견할 수는 있지만, 구체적인 회고가 있어야 뾰족한 의미를 발견할 수 있다고 생각한다. 정확히 어떤 부분이 문제였는지, 다음에는 어떤 방식이 필요할지. 구체적인 회고여야 구체적으로 발견할 수 있다고 한다. 개인회고를 쓰면서도 분명히 느꼈던 부분이다.

현재 회사의 회고는 구체적인 회고의 방식으로 이루어져있지 않은데, 나부터라도 시작해볼까 하다가 나만 그렇게 하고 있는 게 부끄러워서 하지 않았다. 방식을 제안하는 것도 쉽지 않았다. 아직 초반이니, 회사와 어우러지는 것이 우선이었고, 다른 사람과 다른 방식을 행하는게 튀는 방식이라고 생각했다. 일단은 회사에 어우러지고 내가 녹는게 우선이라고 판단했다. 다음번 분기 회고에는 도전해봐야겠다. 조금이라도. 조금만이라도.

 

12. 제안서 - 제안서 작성이 쉬워지는 법

“일하다보면 ‘불확실성’이라는 단어가 늘 따라다닌다. 나에게 이 단어는 두려움 보다 더 잘 해야 한다는 결심에 가깝다.

이 말에 깊이 공감했다.

일을 오래 할수록, 나는 내 업무 스타일을 더 잘 이해하게 된다. 그리고 나에게도 ‘불확실성’은 늘 “해내고 싶다”라는 결심으로 이어지는 걸 많이 경험해봤다. 안 될 가능성이 높고, 앞이 잘 안 보이는 상황에서도 나는 어떻게든 될 방법을 찾으려 애쓴다. 무진장 애쓴다.

최근, 내가 반대했던 프로젝트가 추진됐다. 현재와 과거를 비교했을 때 달라진 것이 없는 제품인데, “일단 사람을 모으고 다시 의견을 들어보자”는 주장이 나왔고, 나는 반대했다. 현재의 문제점을 우리가 아는 상태에서, 그것을 고치는 것 보다 사람을 모으는 게 우선이라는 것에 동의하지 못했다. 같은 행동과 인풋으로는 새로운 결과를 기대할 수 없다고 생각했다.

그래서, 적어도 제품의 변화를 먼저 만들어야 한다고 생각했다. 조금만 미루고 싶었다.

하지만 결국 프로젝트는 시작되었고, 나는 그 안에서 최선을 다하는 중이다. 이미 돌아가기엔 늦은 상황이었으니까.

되도록 만들어야 했다. 되도록 만드는 중이다. 그 과정은 버겁다.

내가 “될 거다”라고 판단한 게 아닌, 내가 원하지 않았던 것들까지 되도록 만드는 건 버겁다. 하지만 그게 이 자리, 이 역할임을 뼈저리게 느꼈다.

그리고 더 힘든 건, 되도록 만들어가는 과정 속에서 또 다른 반대에 부딪힌다는 것이다.

정말 쉽지 않다. 웃음만 난다. 허허허.

 

“문서의 핵심은 포멧이나 디자인이 아니라 나와 우리가 하고자 하는 이야기를 최종적으로 써내려 가는 공간임을 잊어서는 안된다.”

 

“억지스럽게 들어간 항목은 없는지 상대방에게 이야기하듯(발표하듯) 쭉 읽어보면 쉽게 판별이 된다.”

 

13. 커뮤니케이션 - 혼란을 초래하지 않는 커뮤니케이션

“프로젝트 진행 상황을 모두가 잘 알고 있는데 굳이 모두에게 알림이 가는 곳에서 이야기할 필요가 있을까 생각할 수도 있지만, 사람의 기억이 항상 체계적이고 완벽하지는 않기 때문에 가능한 모두가 참여하는 공간에서 대화하는 것이 가장 좋다.”

정말이다. 프로젝트 진행 상황을 모두가 잘 알고 있다, 라고 생각하는 것 또한 믿을 수 없더라. 모두의 기억이 항상 체계적이고 완벽하지 않다. 심지어 모두가 참여하는 공간에서 대화하더라도. 심지어 회고록을 공유페이지에 각자가 작성했더라도…

어제, 금요일에 딱 그런 상황이 있었다.

몇 주 전 스프린트 회의에서 결정된 사항이 있었고, 그 기록은 회의록에도 있다. 하지만 결정된 사항에 대해서 몇은 기억하고 몇은 기억하지 못하고 있더라. 회의에서 회의록을 작성하더라도, 회의내에서 뭔가가 결정된 사항이 있다면 정리해서 한번 더 결정사항을 공유해야겠더라.

이 부분은 개발자로 일할 때 분명히 했던 부분인데, 새 회사와서 잠시 놓치고 있었다. 회의 후 결정된 사항을 다시 정리해서 공유하는 것 !!!

 

“1:1 대화에서의 결정은 언제나 확정이 아니라는 생각을 하는 것이 좋다.”

“게다가 여러 명과 1:1로 대화를 진행하면 수많은 버전이 만들어진다.”