[TIL] 21년 4월 1주차 - 기분 나쁘지 않게 거절하려면 논리적인 이유를 대라

기분 안 나쁘게 거절하는 방법

다른 팀 팀장님이 우리팀에 요청할 거를 나한테 다이렉트로 물었다. 우리 팀 입장에선 사소한데 거기서는 중요한 사항일 수 있는 문제였고, 우리 팀 입장에선 기존 거를 고수해도 전혀 상관없는 문제였다. 버그도 아니라 바꿀 명분도 없었고 더구나 리소스도 없는 상황이기 때문에 개발자한테 섣불리 요청할 수가 없는 상황이었다.

어떻게 대답할지 고민하다가, 위와 같은 이유로 일단 지금은 안고치겠다고 답변했다. 꼭 변경해야 한다면 그만한 명분을 전달해달라고 요청했다. 명확한 이유가 있어야 개발자들도 움직이기 때문에..

예전에는 관계가 안좋아질까봐 혹은 태도가 불량하다고 여겨질까 봐 예스맨이었다면 지금은 그냥 솔직하게 대응하고 있다. 장기적으로 보면 나에게도 회사에게도 이 방법이 더 좋을 거라 믿는다.

 

개발자 입장만 고려하지 말고 적당히 리소스 조율하기

특정 버튼이 잘 안눌린다는 사소한 VOC가 들어왔다. 아예 오류도 아니고 가끔 안 눌렸다. 디바이스마다 차이가 있는 것 같기도 하고. 문제점을 인지하지도 못한 상황에서 개발 고쳐달라고 요청할 수도 없는 노릇이라 일단 스크럼 때 운을 띄워서 이슈가 뭔지 파악했다. 일단 무턱대고 고쳐달라고 하는 것보다 훨씬 더 나은 접근법이었던 것 같다.

한편으로, 개발 리소스 관리에 너무 치중해서 고쳐야할 문제를 그냥 넘어가지 않아야겠다는 생각이 들었다. 고객은 불편해서 VOC를 표현한 것이었을 텐데 너무 개발자 입장만 고려해서 안 고치고 넘어가면 그게 더 문제라는 생각이 들었다.

 

나중에 온 사람을 위해서 완성도 있는 서비스 만들기

배송 과제 수행하다가 미처 챙기지 못했던 사소한 오류를 발견했다. 근데 이미 해당 과제 인력들은 이 문제를 인지하고 있었기 때문에 굳이  당장 고치지 않아도 됐다. 하지만 나중에 신규 인력이 왔을 때 오해하지 않도록 고쳐달라고 요청했다.

너무 사소해서 개발 요청하기 민망했지만, 막상 하니까 술술 풀렸다. 개발 리소스를 나 혼자서 끙끙 고민했다는 생각이 들었다. 개발 리소스를 배치하는건 개발 팀장님의 역할이다. 나는 그저 나의 역할에 충실하면 된다. 너무 많은 문제를 짊어지지 말자.

 

히스토리가 많아질 기획이라면 버전별로 구분해서 잘 기록해놓기

히스토리가 계속 바뀌었다. 그러다 보니까 예전에 왜 그렇게 결정했는지 기억이 안나고, 어떻게 의사 결정했는지 가물가물했다. 미리미리 업데이트를 해뒀더라면 덜 고생했을 텐데 지금부터 변경사항만 기록하기도 참 애매하다.

히스토리가 자주 바뀌고, 기획 내용이 많을 땐 피피티로 기획서 쓰는게 더 낫다. 위키가 편하긴 해도, 버전별로 표시하긴 불편하다. 피피티로 하면 나중에 바뀐 페이지 숫자만 개발자한테 공유하면, 어떤 내용이 업데이트되었는지 구분하기도 쉽더라.

 

구두로 확정된 정책은 잘 기록해두기

회의 시간에 구두로 결정된 정책은, 그 배경이랑 결정 내용 잘 기록해두기. 나중에 떠오르려고 하니까 잘 안난다.

 

도그냥님 인터뷰 내용

역시 도그냥님은 배울 점이 정말 많고 닮고 싶은 분이라는 생각이 든다. 이름 모를 후배들을 양성하기 위해 좋은 영상 찍어주는 것도 너무 멋있고 존경스럽다. 

https://www.youtube.com/watch?v=iymVma5AlFA&list=PLtvexwasN8FwCIFPEEkmZgcNPwbYkJV7L&index=2

• 기획자는 남의 말을 들었을 때 듣고 이해하고 요약할 수 있는 능력 중요. 마케터의 말, 개발자의 말 등 서로의 언어를 치환해서 설명할 수 있어야 함. 나의 언어로 바꿔서 각각 목표와 대상에 맞게 다시 설명할 수 있는 능력이 중요.
• 활발한 성격은 중요하지 않음. 외향적이라고 많은 대회를 하는 것도 아니고, 내향적이라고 해서 핵심을 집어내지 못하는 것도 아니기 때문. 필요한 말을 정리할 수 있으면 어떤 성격이든 괜찮음.
• 질문을 잘할 줄 아는 능력이 가장 중요함. 상황에 대해서 논리적으로 이해할 수 있는 수준만 있으면 됨.
• 사이트를 다 통합하는 프로젝트에서 큰돈을 들여서 500-600명의 개발자랑 같이 일할 수 있는 경험은 대기업이 아니고선 할 수 없는 경험. 그래서 이것까지 했을 때 '나는 더 이상 이 회사에서 이거보다 더 큰일을 할 일은 없겠다.'라고 생각. 개인 성장의 차원에서 봤을 때, 내 지식이 이만큼 쌓인 걸 더 가치 있고 소중하게 쓸 곳을 찾아야겠다고 생각. 내가 잘하는 건 복잡한 걸 기획하는 것. 그렇기 때문에 단순함에서 복잡함으로 넘어가는 단계의 회사를 찾았기 때문에 스타트업으로 감.
• 제 스스로에 대해 정확하게 판단하려고 노력하고 있는데 저는 시스템 복잡도가 최고로 복잡한 상태의 회사에서 점점 더 복잡해지는 일을 했기 때문에 현재의 유효자원을 가지고서 굴러가게만 만드는 시스템에서는 제가 만족을 못 할 거란 생각을 되게 많이 했고 복잡하고 모든 케이스가 굴러갈 수 있는 그런 시스템을 만드는 역할을 내가 하고 싶다, 그리고 그 역할을 한번 해 보고 나면 더 많은 스타트업이나 주니어 기획자들한테 이런 정보를 나눠주는데도 더 도움이 되겠다는 생각을 했어요.
• 현재 스타트업은 규칙이 많이 없는 상황이기 때문에, 문제들이 발생할 때 예전의 그 규칙이 왜 있었는지를 역으로 알게 됐어요.