의사결정과 업무 진행은 프로덕트를 사용하는 고객관점에서 시작한다.
고객관점이라는 말은 많이 하지만 실제로 이게 왜 사용되어야 하는지 두 가지 방면에서 설명한다.
1. 조직에서의 의사결정 측면
이런 상황은 자주 발생했을 것이라 생각한다. 서로의 팀원(혹은 조직)의 생각이 달라서 벌어진 상황이다. 각 팀원은 수단에 대해서 집착을 하게 되고 이야기가 평행선을 달리게 된다. 이때 어떻게 이야기를 하면 문제를 해결할 수 있을까?
고객이 겪는 문제 상황에 대해서 먼저 정확히 이해하는 게 필요하다. 혹은 고객에게 꼭 필요하다고 생각하는 것에 대한 정의가 필요하다. 이를 문서 최상위에 “목표”로 정의를 한다.
정의가 된다면 점진적으로 이야기를 풀어나갈 수 있게 된다. 이 고객은 이 문제를 해결하길 바란다. 이 수단이 더 적절한지 아닌지, Pros/Cons를 정의하는데 서로 적극적이 될 수 있다. 고객을 만족시키는 관점에서 정리하기 때문에 서로의 의견에 대해서 고객관점의 리뷰가 있을 뿐이다. 해야하는 일의 아웃라인이 더욱 분명해질 것이고, 점차 커뮤니케이션을 정리해서 함께 문제를 해결할 수 있는 상태에 도달한다.
주의하자. 고집과 아집에 빠지고 있지 않은지.
2. 프로덕트의 디테일 측면
프로덕트의 디테일에 대해 작업자는 욕심을 내기 마련이다. 이 기능도 넣고 싶고, UI를 좀 더 아름답게 만들고 싶다는 생각이 들기 때문이다. 그러나 고객 관점에서 프로덕트를 바라본다면, 더 단순하고 사용하기 쉽고 직관적인 것을 선호한다. 복잡한 서비스를 만드는 것에 대해서는 주의해야 한다.
더 단순하게 풀기 위한 고민을 하고, 이를 바탕으로 프로덕트를 리뷰하게 된다. UI/UX가 사용자 경험을 추구하고 있는데, 만약 프로덕트를 만드는 사람이 자신을 투영하게 된다면 엇나간 프로덕트가 나올 수 있다. 고객 관점으로 바라보고 리뷰하며 업무를 진행해야 더 날카롭게 프로덕트 디테일을 챙길 수 있다.
팀의 시야에서 벗어나 전체 프로덕트 관점의 시야로 문제를 해결해야 한다.
동기부여가 있다면 100%가 아닌 120%의 결과물이 나온다.
지시와 권위로 시키는 업무와 달리 자발적으로 하는 업무는 다른 성과를 낸다.
스펙이 정의되고 해야 할 일을 정해서 만약에 내려준다면? 모든 이슈를 미리 따두고, 팀원에게 할당한다면?
아마도 100%로 이슈가 완료되면서 일은 “정상적으로” 끝날 것이다. 그렇다면 실제 업무 환경을 지속적으로 이와 같이 유지하면 어떻게 될까? 정의되지 않은 일은 시작되지 않을 것이고, 팀원들은 정의된 일 이상으로 진행하지 않을 것이다. 왜냐하면 충분히 결과물과 팀의 성과가 있는 것으로 보이기 때문이다.
그러나 스타트업 생태계에서 이와 같은 업무 방식을 유지하면 지속 가능하지 않다. 일을 적절히 수행하는 사람만 남을 것이고, 120%의 성과를 내고 큰 성과를 내길 원하는 사람은 떠날 것이다.
문제 상황이 주어졌을 때, 이 문제를 해결해야 하는 궁극적인 목표(Objective)에 대해 공유하고, 이에 크게 공감하고 몰입할 수 있도록 한다면 어떨까. 아마도 궁극적인 목표를 위해 다방면의 노력을 기울일 것이고, 처음에 생각했던 100%의 결과 이상으로 120%의 디테일이 채워져 프로덕트에 녹아들 것이다.
실제로 채팅팀의 인원들에게 OKR의 Objectives와 Key Results를 공유하는 방식이 그렇다. 물론 중간에 공감하지 못하는 상황도 있고, 변경해야 하는 경우도 있다. 그렇지만 이는 결국 팀원들이 자발적으로 동기부여되어 더 몰입하고 결과를 내는 데 긍정적인 효과를 준다.
예를 들어, OKR이 동기부여의 원천이 되어 팀원들의 동기부여를 만들고 프로덕트 개선을 이끌고 있다.
달리는 기차를 멈추지 않는다. 바퀴를 교체한다.
워터폴 방식과 애자일 방식을 기반으로 생각하면 편하다. 처음부터 완벽하게 기획, 디자인, 개발이 진행된다면 얼마나 좋을까. 그렇지만 사람의 지식은 변화하고, 고객의 요구사항도 실시간으로 변하고 있다.
이 상황에서 처음부터 가장 정확하게 벡터값(방향 + 힘)이 변하지 않고 목표 지점에 도달할 방법을 정의할 수 있을까?
안타깝지만 아직까지 이 방법을 발견한 사람은 없다. 고객의 문제를 바라보고 업무를 진행하다 보면 비즈니스 도메인에 대한 이해도가 높아지고, 다른 방법으로 더 적절히 문제를 해결할 수 있다고 생각할 때가 있다. 그럼 이렇게 생각해보자. 레일을 먼저 만들고 손수레를 올려본다. 그러면 무엇이 문제인지 보일까? 엔진 동력에 문제가 있다는 것을 알 수 있을 것이고, 바퀴에 문제가 있다는 것을 알 수 있을 것이며, 브레이크에 문제가 있다는 것을 알 수 있을 것이다.
우리는 처음부터 이 문제를 전부 정의하고 해결할 수 없다. 그러나 일을 하다 보면 처음부터 유니콘을 생각하고 기획하고 문제를 해결하려 한다. 하지만 이렇게 하면 가장 좋은 기차를 만드는 데 어려움이 생긴다.
먼저 달릴 수 있는 조건만 바라보자. 채팅팀에서 검색 기능을 예로 들어보자. 최소한으로 검색이 가능하기 위한 조건은 무엇일까? 화면 단에서는 검색 창과 검색 결과 화면이 필요하다. 그리고 이를 동작시키기 위한 검색 API가 필요하다. 그리고 검색을 기본으로 처리하기 위한 쿼리 엔진이 필요하다. 이것만 준비되면 바퀴가 달리고 앞으로 달리는 기차가 된다.
그럼 교체할 바퀴와 개선해야 하는 것들을 생각해보자. 쿼리 엔진에 대한 성능 튜닝, 검색 알고리즘, 그리고 실시간으로 생성되는 메시지를 인덱싱하는 방식이 있다. 이는 변할 수 있고, 교체할 수 있는 것이다. 멈추지 않는 기차를 만든 것이다.
이를 해석해보면 두 가지 관점으로 문제를 해체하고 진행해야 한다.
- 필수적이고 기반이 되는 것.
- 선택사항이고 개선을 위해 교체할 가능성이 높은 것.
필수적이고 기반이 되는 것은 처음에 정의해야 한다. 이는 크게 복잡도가 높은 구성도 아닐 것이고, 근간이 되는 인프라와 API 스펙이다. 이는 초기에 정의되면 거의 프로덕트 라이프사이클과 함께 간다. 기차의 엔진은 개선할 수 있고 외형도 바꿀 수 있다. 달린다는 사실은 변하지 않는다.
내부 로직은 언제든 변경 가능하다. 교체할 가능성이 높고 지속적 개선이 가능하다. 이는 초기에 큰 노력을 들이지 않는 것이 낫다. 동작하게 만드는 것이 중요하다. 왜냐하면 지속적으로 개선되고 고도화될 것이기 때문이다. 처음부터 완벽을 기하지 않아도 된다.
위 두 가지를 구분하는 것이 중요하다. 이것도 필요하고 저것도 필요하다는 말을 하지만, 실제로는 “꼭” 필요한 것은 생각보다 많지 않다. 이를 정확히 정의하고 달린다면 기차를 만들어서 결과를 보고 하나씩 부품을 교체하면서 멈추지 않는 기차를 만들 수 있다.
고객은 문제를 가지고 있다. 그러나 고객이 직접 말한 해결책은 정확한 해결책이 아닐 수 있다.
고객의 목소리를 듣는 것은 중요하다. CS 및 팀간의 커뮤니케이션으로 고객의 목소리를 발견할 때가 있다. 다만 이때 주의할 것이 있다. 여기서 고객은 종종 구체적인 해결책(How to)을 제시할 때가 있다. 자신의 해결책을 적용하길 바란다는 목소리일 때가 있다.
고객의 How to에 집착하면 오히려 좁은 사고의 의사결정을 할 수 있다. 예를 들어 중고거래를 자주하는 유저는 중고거래를 위한 기능을 채팅 목록에 넣고 싶어 한다. 그러나 모임채팅 기능을 자주 쓰는 유저는 모임 관리를 편리하게 하기 위한 기능을 채팅 목록에 넣고 싶어 한다. 실제로 유저가 원하는 것은 채팅 목록에서 모아보는 걸 원하고 있고, 여러 채팅이 혼합되어 있는 것에 대한 불편함에서 의견을 남긴 것이다.
문제를 정확히 인지하는 게 중요하고, 가장 하위의 문제를 정의해야 상위 문제들을 정의할 수 있다. 큰 범위부터 하나씩 정의하고 개선해야 하는 문제를 좁혀나가면서 해결할 수 있다.
고객의 목소리에서 나오는 문제들의 요소를 분리하고, 각 문제들의 구조를 분석하면 좀 더 뾰족하게 성과를 낼 수 있다. 고객이 제시한 해결책이 아닌, 근본적인 문제를 파악하여 더 나은 해결책을 찾는 것이 중요하다.
신뢰와 충돌 그리고 더 나은 선택
신뢰와 충돌은 왜 발생할까? 고객의 문제에 깊이 들어가서 해결하고 싶은 열망 때문이다. 그러나 협업을 하다 보면 신뢰와 충돌이라는 키워드에 맞닥뜨리게 된다.
“내가 이런 이야기를 해도 될까? 반대하는데 충돌해도 되는 걸까?”
여기에는 전제조건이 깔려야 한다. 충돌의 목적은 더 나은 선택을 하고, 확실한 대안을 제시하기 위함이다. 또한, 상대방과 더 나은 선택을 할 수 있을 거라는 신뢰가 있기 때문에 기꺼이 충돌하는 것이다.
충돌은 단순한 반대가 아니다. 더 나은 선택을 하고, 고객에게 더 나은 가치를 전달할 수 있다고 믿기 때문에 충돌을 감수하는 것이다. 이는 상호 신뢰를 바탕으로 한다. 우리는 이렇게 서로 사고한다고 신뢰하고 기꺼이 생각을 공유한다.
쉬운 선택과 어려운 선택
업무를 하면서 쉬운 선택과 어려운 선택을 고민했다. 여기서 쉬운 선택이란, f(x)와 같이 방정식을 적용해 최선의 정답이라고 생각하는 상황이다.
예를 들어:
- 다른 회사에서 했으니까 우리도 한다.
- 여러 블로그를 보니 베스트 프랙티스라니 도입한다.
당근마켓에서는 프로덕트 관점, 기술적 관점, 조직적 관점에서 의사결정을 하며, 어디서 하는 것을 단순히 따라하지 않았다. 당장의 문제를 해결할 때는 작게나마 따라하는 모습이 있었지만, 실제로 도입하고 적용하는 과정에서는 “이렇게 결정했고 진행하세요”는 없었다. 몇몇 시도는 있었지만, 결과적으로는 과정을 보여주고, 사람들의 고민 수준이 비슷하게 올라올 때까지 기다렸다가 조직적인 의사결정을 했다.
기술적인 의사결정도 비슷하다. “이미 시장은 이걸 많이 쓰니까 씁시다”라는 말을 하지 않았다. Datadog, K8s, Golang 도입 사례가 그렇다. 다양한 개발 방법론을 적용하고, 자체 배포 시스템인 Kontrol을 만들고, 다양한 컨퍼런스에서 기술 발표를 통해 다방면의 인재를 끌어오는 것도 그러하다.
프로덕트 관점의 의사결정 또한 마찬가지다. 중고거래에서 좁은 지역을 선택한 것도, 매너온도라는 개념을 정의한 것도 그렇다. 기존의 별점제도를 도입할 수도 있었지만, 서비스를 사용하는 사용자를 관찰하고 그 고객들을 더욱 적절히 표현할 수 있는 단어(매너온도)를 찾아냈다. 전국 검색이라는 쉬운 선택이 있음에도 불구하고, 문제점을 고민하고 좁은 지역의 연결로 문제를 해결하는 최선의 방안을 찾아냈다.
따라하는 선택에서 더 나아가 고찰이 있는 선택을 함으로써 시장의 변화를 이끌어내고 있다. 누구나 쉽게 “이게 답이야”라고 말할 수 있는 것이 아닌, 실제로 깊게 고민하고 근본 문제를 발견할 때까지 시도하고 이를 통해 매력적인 서비스, 매력적인 조직, 매력적인 업무환경을 만들어냈다. 그로 인해 인재들이 다시금 찾아오고 떠나지 않는다고 생각한다.
고찰을 통해 느낀 점은 이전에 생각했던 게 정답일 때도 있지만, 같은 방법을 써도 정답이 아닐 때도 있다는 것이다. 이를 평소 업무환경에서 느끼게 하며, 해결해나가는 즐거움과 성과가 공존하게 만들어야 한다.
현실을 가장 잘 인지하고 있는 사람은 팀원이다.
큰 범위에서는 리더가 더 잘 이해할 수 있지만, 디테일에서는 팀원의 감각과 고민이 더 깊다. 예를 들어 채팅 기능을 프로덕트에 녹이는 상황에서는 디테일한 기술과 해결해야 하는 문제 상황에 대해 팀원이 더 상세하게 알고 있다.
디자인, 코드, 고객의 목소리에 대한 디테일은 팀원이 가장 섬세하게 이해하고 있다. 일반적인 고객 상황은 리더가 인지시킬 수 있지만, 실제 프로덕트에 녹이는 과정에서 필요한 디테일과 수준을 올리는 감각은 팀원이 가장 잘 알아야 하고 해내야 한다.
리더는 이를 적극적으로 인지하고, 팀원들이 유기적으로 움직일 수 있게 도와야 한다.
피드백은 2주 단위로, 잦은 작은 변화를 통해 큰 변화로 이끌기
성과평가 주기를 통해 피드백을 하는 것은 조심스럽다. 모든 내용에 대해 피드백을 하고 개선해달라고 하면 실제로 팀원이 개선할 수 있을까? 당연히 아니다. 우리가 워터폴 방식이 아닌 애자일하게 일하는 것과 같다. 코드 리뷰에서도 큰 Pull Request보다 작은 Pull Request를 선호하는 것과 같다.
프로젝트를 시작할 때 마일스톤을 정하는 것처럼, 피드백도 잦고 작은 변화를 통해 큰 변화를 이끌어야 한다. 팀원들이 작게 표현하는 만족감이나 불편감을 잘 읽고, 2주마다 피드백을 하면 6개월 동안 큰 변화를 만들어낼 수 있다.
완벽한 사람은 없다. 조금 더 완성도 있게 업무에 집중하고 성과를 내기 위해서는 조금씩 나아질 수 있는 것을 피드백하고, 결국 큰 변화를 이끌어야 한다. 예를 들어 한 달 동안은 기술 역량에 대한 피드백을 중점적으로 하고, 그다음 달에는 협업 역량에 대해 중점적으로 피드백하여 팀원이 한 역할에 집중하고 협업 관점에서 발전할 수 있도록 해야 한다.
주기적으로 변화를 감지하고 이를 기록하여 추후에 다시 피드백하면, 장기적으로 습관을 들일 수 있게 할 수 있다. 이렇게 조금씩 피드백이 작용된다면 1년이 지나면 팀원들은 이전보다 더욱 뛰어난 역량을 보여줄 것이다.
차분히 인내하고 조금씩 피드백하여 변화를 이끌어야 한다.
그리고 나 또한 피드백을 잦은 피드백을 들으면 긴 기간동안 크게 변화해야한다.