2022년 치열함 속에서 배운 것들

2021년에는 이직을 목표로 발버둥치는 한해였다면 2022년에는 일에 최선을 다해 몰입해보고자 했어요. 그만큼 치열한 한해를 보냈던 것 같아요. 그간 배운 것들을 공유합니다. 1. 융통성 있게 지표 대하기 2022년에 제가 배운 가장 큰 수확은 융통성입니다. 부끄럽지만 작년의 저는 상당히 단호박 같은 사람이었는데요. 책에 나온 이론과 실제가 다르면 왜 다른지를 묻고, 이론과 가까이 가기 위해 노력했어요. 한 동료는 저에게 교과서에 나온 사람 같다고 했어요. 특히 북극성 지표에 유독 집착했었는데, 시간이 지나고보니 하나만 알고 둘은 모르는 사람이더라구요. 마침 슬랙의 첫번째 PM이었던 분 kenneth berger 역시 똑같은 말을 하더라구요. 하나의 지표는 정말 매력적이지만, 그것에만 집중하면 놓치는 변수들이 많을 거라구요. 2. 본질을 잊지 않기 올해에는 신규 프로덕트를 런칭했기 때문에 프로덕트의 가격을 정했는데요. 가격 정하는 건 너무 어렵게만 느껴져서 저는 가격을 정할 때 주로 경쟁사 대비 어떻게 가격을 매기는게 좋을까? 고객이 어떻게 반응할까? 이렇게 주로 생각해왔었어요. 그런데 최근에 pricing이라는 책을 읽고 고객이 얻는(인지하는) 가치가 결국 가격이라는 사실을 잊고 있었어요. 경제학에서 Willing to pay라는 개념으로 고객이 인지하는 가치를 설명하고는 했었는데 기본적인 사항을 까맣게 잊고, 경쟁사 가격 구조만 따라가기 바빴습니다. 결국 가장 중요한 것은 본질이예요! 3. 효율적으로 QA 하기 위해 노력하기 2022년 이전에는 일해왔던 조직에서는 백엔드 개발자와 프론트 개발자의 역할만 있는 조직이었어요. 그래서 QA도 복잡하지 않았죠. 그런데 작년에 일했던 조직에서는 개발파트가 3파트 많게는 4파트까지 엮여있어 문제가 생기면 어떤 부분에서 문제가 있었는지 파악하는 데 시간이 너무 많이 걸렸어요. 그래서 QA를 할 때 최대한 변수를 줄인 상태에서 QA를 해서 최대한 작업을 효율적으로 하기 위해 노력했어요. 예를 들면 A파트의 API와 B파트의 API가 모두 화면에서 노출되는 상황을 가정해볼께요. 그러면 A파트의 API는 dummy값을 넣어서 프리징 시키는 거예요. 그러면 생기는 버그들은 B파트것이 됩니다. B파트의 QA가 일단락되면 더미값을 넣었던 A파트를 실제값으로 넣으면서 QA를 진행합니다. 이런식으로 단계별로 QA를 하게 되면 작업자의 효율을 훨씬 높일 수 있었어요. 4. 피드백에 피드백하기 많은 사람들이 저에게 피드백을 줍니다. 당연히 이걸 100% 반영할 수는 없죠. 중요한건 피드백을 수용하는 여부가 아니라 피드백을 어떠한 태도로 대하느냐가 중요합니다. 예룰 들어 이러이러한 이유로 반영이 안되었다, 현재 이 부분은 백로그에 넣고 다음 단계에서 추가될 예정이다. 아니면 반영되었으니 확인해봐달라! 라던가요. 피드백에 대해서 어떠한 리액션도 하지 않는다면 점점 피드백을 줄어들게 될거예요. 5. 글쓰기 많이는 못쓰고 있지만 짧게라도 경험들을 녹여 글로 쓰기 위해 노력했는데요. 글쓰는건 정말 좋아요. 장점이 너무 많아요. 생각 정리에도 도움이 되고, 기억이 휘발되지 않게 붙잡는 역할도 탁월합니다. 시간이 지나면 이게 내가 쓴 글인가?싶을 정도로 기억은 빠르게 휘발되더라구요. 더 나아가 글을 다른 사람과 공유하면서 얻을 수 있는 인사이트도 얻을 수 있어요. 완성된 형태가 아닐지라도, 글쓰기가 정말 중요하다는 걸 뼈저리게 실감한 한해였습니다. 아까도 잠깐 언급했던 최근에 인상깊게 본 영상 중 하나인 슬랙의 첫번째 PM의 강의를 첨부할게요. 꾹꾹 눌러담은 경험들이 녹아져들어있는 인상깊은 강연입니다.