좋은 회고란 무엇일까?
IT플랫폼 PM의 회고 방법론
변호사가 [사건] 단위로 수임하고, 공인중개사가 [계약] 단위로 중개하듯, PM은 [프로젝트] 단위로 일합니다.
대개 짧으면 1달, 길게는 1년에 걸쳐 1) 문제를 찾고, 2) 솔루션을 만들어, 3) 세상에 선보이는 과정을 반복하죠. 이 과정에서 PM은 각 분야의 전문가들과 함께 일하는데, 중요도가 높은 프로젝트를 맡는다면 50명이 넘는 인원과 6개월 이상 함께하는 경우도 많습니다.
새 프로젝트를 런칭하면 PM은 이곳저곳 터지는 사건 사고에 빠르게 대처해야 합니다. 그렇게 1-2달 시간이 지나 제품이 어느 정도 자리 잡았다 싶으면 '회고'를 합니다. 과정이 즐거웠고, 결과까지 훌륭한 프로젝트라면 사실 이때만큼 기다려지는 시간도 없습니다.
이번 챕터에서는
1) PM의 회고란 무엇인지,
2) 어떻게 구성하는지,
3) 어떻게 하면 잘할 수 있는지
에 대해 이야기해보겠습니다.
1. 회고란 무엇일까?
회고(retrospective)란 본래 스프린트(Sprint)라고 부르는 개발 방법론의 마지막 단계입니다. 어원 그대로 프로젝트가 끝나고 ‘뒤(retro)를 돌아본다(spective)’는 뜻입니다. 쉽게 말해 프로젝트의 1) 성적표를 확인하고 2) 반성문을 함께 읽는 시간이라 하겠습니다. 빠르게 IT 회사에서 모든 동료가 한 시, 한 자리 모여 이야기할 기회는 꽤 드문 만큼 이 시간은 매우 소중합니다.
IT 산업도 이제 역사가 오래되어 회고에도 다양한 방법론이 존재합니다. 우선 KPT라고 해서 좋았던 것(Keep), 아쉬운 것(Problem), 앞으로 해볼 것(Try)을 간단하게 정리하는 방식. 5F라고 하여 사실(Fact), 느낌(Feeling), 교훈(Finding), 미래행동(Future Action), 상호 피드백(Feedback)으로 프로젝트 조망하는 방식. 이 외에도 YWT(도요타 방법론) 등, 각자 이름은 다르지만 구성은 비슷비슷한 회고법이 많습니다.
위 예시 모두 좋은 회고 도구입니다. 하지만 초보 PM이 저렇게 간단한 '한 줄 가이드'만 가지고 회고를 진행하면 오히려 안 하느니만 못한 회고를 할 수 있습니다. 아래 예시가 대표적으로 회고를 어설프게 진행한 케이스입니다.
프로젝트 오픈 후 1달이 지났습니다. 기획자는 즐거운 마음으로 회고를 시작합니다. 20명 정도 되는 기획, 디자인, 개발, 운영, QA 모두 대회의실에 모입니다. PM은 포스트잇, 사인펜을 하나씩 나눠준 뒤 말합니다. ‘오늘 회고를 할 겁니다. 우선 이번 프로젝트에서 좋았던 점부터 써주세요!’ 멤버들은 5분 정도 쭈뼛거리다, ‘좋았어요’, ‘보람 있었어요', ‘유저가 재미있어하니 기뻤어요'라고 씁니다. 기획자는 포스트잇을 화이트보드에 붙이고 득의양양하게 읽습니다.
회고를 “해야 하니까” 하는 회사에서는 위와 같은 겉핥기 회고가 흔합니다. 사실 안 하느니만 못합니다. 바쁜 사람들 불러서 뻔한 소리 하는 게 무슨 의미가 있을까요. 그렇다면 정말 좋은 회고는 어떤 모습일까요. 회고를 왜 하는지부터 순서대로 짚어보겠습니다.
2. 회고는 왜 할까?
회고를 하는 이유를 딱 1 문장으로 적어보면 ‘앞으로 일을 더 잘하기 위해서’입니다.
이를 위해서는 1) 일의 보람, 2) 제품 방향성, 3) 조직 문화라는 3가지 요소가 필요합니다.
첫째, 회고는 보람을 주어야 합니다. '앞으로 더 즐겁게 일할 수 있는 동력'을 만들어내야 합니다. 회사는 돈 때문에 다니는 것도 있지만 꼭 돈만 목적은 아닙니다. 일이 그 자체로 재미있고, 보람차야 앞으로 계속 나아갈 힘을 얻습니다. 여기서 [보람]이라면 ‘내가 만든 결과물이 세상을 더 긍정적으로 변화시켰을 때’ 느낄 수 있는 감정입니다. 조금 거창할게 말해 PM은 팀원들의 ‘자아실현’을 위해 팀이 만든 것을 잘 갈무리하여 공유할 의무가 있습니다.
둘째, 회고는 제품 방향성을 담아야 합니다. '앞으로 어디로 가야 할지' 알려줘야 합니다. 프로덕트 회고를 하면 성과 외에도 아쉬운 점이 반드시 생깁니다. 서비스 설계가 빗나간 경우, 디자인에서 주요 요소를 뺀 경우, 개발 과정에 피치 못하게 부채가 생긴 경우 등 다양한 케이스가 있죠. 더욱이 프로젝트이란 필연적으로 시간에 쫓기기 때문에 작업 중 캘린더 밖으로 던져버린 스펙도 많습니다. 회고를 하면서 제품의 부족한 점을 어떻게 발전시켜 나갈지 말해야 합니다.
셋째, 회고는 조직 문화를 점검합니다. '어떻게 협업할지' 짚어봅니다. IT회사는 정말 다양한 직군이 일합니다. 이 직군들은 대학 시절부터 별천지 경험을 가지고 있기 때문에 1) 중요시하는 가치, 2) 사고하는 방식, 3) 커뮤니케이션 스킬이 천차만별입니다. 때문에 아무리 부드럽게 진행된 프로젝트라고 하더라도 볼멘소리가 조금씩은 나오게 마련입니다.(만약 하나도 없다면 그건 PM이 잘한 것이 아니라 사람들이 솔직하지 않기 때문입니다.) 팀워크도 ‘정기 검진'이 필요합니다.
3. 회고는 어떻게 할까?
앞서 말했듯 회고에는
1) 일의 보람
2) 제품 방향성
3) 조직 문화
가 담겨야 합니다. 따라서 회고의 자료 역시 3가지 목적을 달성하는 방향으로 만듭니다. 자료는 대개 1) PM이 초안을 잡고 2) 데이터 분석가, 디자이너와 협업해서 내용을 채워 넣습니다.
3-1. 일의 보람
회고는 일의 보람을 상기시킵니다. 이 파트는 크게 4가지로 구성합니다.
1. 우리는 무엇을 만들었는가
2. 어떤 과정을 거쳤는가
3. 고객이 잘 쓰고 있는가
4. 목표를 잘 달성했는가
순서대로 정리합니다.
1. 우리는 무엇을 만들었나?
프로젝트의 런칭은 건물의 준공과 비슷합니다. 건물이 완성되면 입주 전 정면 사진을 찍어 두듯이, 회고도 우리가 만든 제품의 모습을 정리해서 보여주는 것부터 출발합니다. 이렇게 하면 회고를 시작하기 전 팀이 구체적으로 무엇을 했는지 다시 상기할 수 있습니다. 더욱이 1) 시간이 조금 지나 회고 자료를 다시 열어볼 때, 또는 2) 우리 프로젝트를 잘 모르는 사람에게 성과를 공유할 때도 자료를 쉽게 활용할 수 있습니다.
신규 프로젝트라면 새로운 화면과 주요 특징만 강조해서 보여주고, 기존 프로덕트를 개선하는 과제였다면 과거의 모습과 현재의 모습을 대조해서 보여줍니다. 핵심은 과거의 상태가 우리 손을 거쳐 현재는 어떻게 바뀌었는지 한눈에 보는 데 있습니다. 예시 그림처럼 좌우로 배치합니다.
전후비교 예시2. 우리는 어떻게 여기까지 왔나?
다음은 일해 온 과정을 보여줍니다. 문제정의 → 기획/디자인 → 개발 → QA → 런칭에 따라 타임라인을 씁니다. 프로젝트 진행 중 굵직굵직한 사건을 나열하여 한 줄의 일대기로 재구성합니다. 개인적인 팁이 있다면 팀원의 개인사도 군데군데 넣어주면 좋습니다. 프로젝트를 몇 달씩 만들다 보면 팀원들의 대소사나 재미있는 에피소드가 생기게 마련인데, 유연한 회고 분위기를 만드는데 도움이 됩니다. (ex. OO의 결혼)
발자취 예시3. 고객은 어떻게 쓰고 있나?
이 파트는 데이터 분석가와 함께 만듭니다. 고객이 제품을 의도한 대로 사용하고 있는지 같이 살펴봅니다. 신규 기능을 만들면 1) 어떤 것을 기획자의 의도대로 2) 또 어떤 것은 반대로 결과가 나옵니다. 대개 프로젝트를 오픈하기 전에는 여러 사람의 의견이 갈리며 걱정하는 포인트가 있게 마련인데요. 이런 포인트가 의도한 방향대로 흘러갔는지 확인하는 것이 핵심일 겁니다.
자료를 정리할 때는 아래 그림과 같은 포맷을 사용해 보면 좋습니다. 먼저 출시 1주 차, 2주 차, 3주 차 지표의 이동을 시계열 순으로 관찰합니다. 이때는 핵심지표와 보조지표를 종합해서 보여줍니다. 우측에는 해당 지표를 도식화하여 그려줍니다. 동료들이 제품을 출시 후 초기 지표를 한눈에 관찰할 수 있도록 정리하는 게 중요합니다.
지표 설명 예시지표 파트를 공유할 때는 퀴즈를 내보는 것도 좋습니다. 1만 원 스타벅스 커피 쿠폰 5장을 사두고 문제를 맞히는 사람에게 줍니다. 프로젝트에 참여한 구성원들이 초기 지표를 꿰뚫고 있다는 것은 그 사람이 몰입해서 일했다는 방증입니다. 특히 사업이나 서비스 기획 직군이 아닌 직군에서 지표까지 알고 있다면 굉장히 존중받을 동료입니다. 디자이너, 개발 직군도 흥미를 가지고 참여할 수 있도록 유도합니다.
가능하다면 오프라인의 목소리도 들려줍니다. 상당수 프로덕트는 고객이 경험하는 현장이 있습니다. PM은 새로운 기능이 출시되면 현장 그대로의 목소리를 들은 뒤 회사 안까지 가져와야 합니다. 커머스 업계라면 판매자와 구매자의 목소리, 콘텐츠 업계라면 창작자와 독자의 목소리, 제가 일하고 있는 모빌리티 업계라면 기사(택시, 대리)와 승객의 목소리를 동료들에게 육성으로 들려줄 수 있습니다.
4. 목표를 잘 달성했나?
회고의 하이라이트입니다. 프로젝트는 문제를 해결의 핵심 지표가 있습니다. PM은 이 목표가 잘 달성되었는지 단 하나의 숫자로 표현할 수 있어야 합니다.
핵심 지표를 확인할 때는 크게 2가지 방법이 있습니다. 하나는 전후 비교입니다. 프로젝트 런칭 전과 후를 비교하는 것입니다. 전후 비교는 '쉽다'는 장점이 있습니다. 똑같은 지표를 두고 기간만 수정하며 확인하면 됩니다. 단점은 정확성입니다. 지표가 개선되었다 하더라도 반박의 여지가 매우 많습니다.
그래서 제시하는 또 다른 방법은 A/B테스트입니다. 프로덕트 런칭 시 사용자의 50%에게는 새로 변경한 A안, 나머지 50%에게는 기존과 동일한 B안을 적용합니다. A/B테스트는 다른 모든 조건이 동일할 때 프로젝트의 성과만 정확히 측정되기 때문에 가장 확실한 목표 검증 수단입니다. PM은 제품이 처한 상황을 고려하여 적절한 테스트 방식을 활용합니다.
핵심지표 설명 예시3-2. 일의 방향성
다음은 일의 방향성입니다.
이 파트는 2개 순서로 구성합니다.
1) 마일스톤 설계
2) 동료들의 아이디어
순입니다.
1. 마일스톤은 무엇일까?
큰 제품을 만드는 데는 오랜 시간이 걸립니다. 성장 과정도 꽤 길고 고통스럽게 마련입니다. PM은 프로젝트 하나가 런칭하면 단숨에 회사를 일으킬 엄청난 성과가 나오지 않을까 기대하지만 실제로 그런 일은 없습니다. 대개 큰 규모의 조직에서 정말 준비를 많이 한 프로젝트도 런칭일에는 ‘아 이거 정말 망했나?’ 싶은 경우가 허다합니다.
PM은 동료들이 1) 단기 지표에 일희일비하지 않도록, 그래서 2) 긴 호흡으로 확신을 가지고 몰입해서 일할 수 있도록 거대한 그림을 제시합니다. 사업적으로는 이런 계획을 ‘프로덕트 마일스톤’이라고 표현합니다. 긴 여행길에 우리는 현재 어디까지 왔고, 앞으로 도달해야 할 목표지점은 어디인지 함께 확인하는 것입니다. 회고는 이런 마일스톤을 시각적으로 보여주는데 꼭 맞는 자리입니다.
마일스톤을 보여주는 방식은 다양합니다. 화면의 프로토타입일 수도 있고, 정확한 매출 목표, 혹은 시장에서의 위치가 될 수도 있습니다. 구간을 쪼개는 기준도 PM이 그때그때 알아서 정하면 됩니다. 다만 마일스톤이 꼭 한 가지 지켜야 하는 원칙이 있다면 여정의 끝에는 웅장한 목표가 있어야 한다는 점입니다. 그리고 그 목표지점에 도달했을 때 '우리 제품이 시장에서 제일 강력하겠구나'라는 확신이 들어야 합니다.
2. 동료들의 건의사항
두 번째로 동료들의 생각도 듣습니다. PM은 보통 프로젝트 전체를 전망하면서 누구보다 깊게 방향성을 고민하는 사람이지만 혼자 모든 미래를 예측할 수는 없습니다. 이때 훌륭한 팀이 있다면 PM이 아닌 동료들까지 제품의 방향성에 대해 조언할 수 있습니다. 회고를 시작하기 3-4일 전에 설문조사를 돌리고 모든 직군에게 ‘다음번에 해야 하는 일'을 물어본 뒤 이때 등장하는 화두를 중심으로 이야기를 풀어가 보면 수월합니다.
다만 현실적으로 20명 이상인 모인 회고에서 개발자나 디자이너가 손들고 먼저 의견을 말하는 희귀한(?) 장면은 쉽게 볼 수 없습니다. 때문에 필요하다면 회고 전후로 조그만 규모의 티타임을 잡아 캐주얼하게 이야기해 보는 것도 좋습니다. 그렇게 파악한 내용 중 좋은 의견이 있었다면 이 회고 시간에 해당 동료의 목소리에 힘을 실어주고, 훌륭한 의견이라고 다 함께 칭찬하는 것도 중요합니다.
쌍방향 소통이 되는 활성화된 조직은 우연히 외향적인 사람들이 모여 갑자기 만들어지는 것이 아닙니다. 누군가 한 명 끊임없이 노력할 때 아주 천천히 조성됩니다. PM은 곳곳에서 흘러들어온 동료들의 건의사항을 무시하지 않고 보다 큰 방향성 아래서 다양한 의견을 조합하여 마일스톤에 반영합니다. 이런 과정을 거치면 방향성 자체가 훌륭해질뿐더러, 조직도 훨씬 건강해집니다.
3. 일의 문화
마지막으로 일하는 문화를 점검할 차례입니다.
회고를 진행하기 3일 전 구글 폼으로 설문을 돌립니다. 회고 문화가 잘 갖추어져 있는 팀은 링크를 돌리는 즉시 답변이 술술 들어옵니다. 하지만 회고가 아직 익숙하지 않은 팀은 응답을 차일피일 미루는 경우가 많은데요. 이럴 때는 팀원들을 한 명씩 찾아다니며 독려하는 것도 필요합니다. 전체를 대상으로 툭 던져놓은 요청은 무시당하기 십상이지만 개인적인 부탁을 거절하는 동료는 없기 때문입니다. 앞서 말했듯 의견을 내는 문화를 조성하는 것도 PM의 일입니다.
회고 설문 예시이런 종류의 회고 설문은 흔히 익명으로 진행하는 경우가 많습니다. 꼭 익명을 추천하지는 않습니다. 굳이 고르자면 기명인 경우가 낫습니다. 회고는 누군가를 고발하는 자리가 아닙니다. 일하는 방식에 대해 솔직한 의견을 나누는 자리죠. 때문에 자기 이름을 밝혔을 때가 오히려 깊고, 생산적인 의견을 내는 경우가 많습니다. 굳이 사전 설문을 돌리는 이유는 ‘누가 썼는지 모르게 하는 것’보다 ‘혼자 종이 위에 생각해 볼 시간을 주기 위함’입니다.
설문은 간단하게 3개 파트로 구성합니다. 1. 좋았던 점, 2. 개선하고 싶은 점, 3. 하고 싶은 말 정도면 충분합니다. 질문을 많이 하는 것보다 중요한 것은 질문을 정확하게 하는 것이기 때문입니다.
좋았던 점은 달리 말해 ‘다음에도 이렇게 하고 싶다’를 적어야 합니다. 가이드라인 없이 팀원들에게 좋았던 점을 물어보면 대개 프로젝트 자체보다는 고마웠던 사람에 대해 쓰는 경향이 있습니다. 예를 들어 “OOO님이 과업을 잘 정리해 주셔서 일하는데 수월했습니다”, “OOO님 개발 짱이에요” 하는 식이죠. 물론 이런 응답도 소중하지만 회고의 의미에는 부합하지 않습니다. ‘1) 목표, 2) 일하는 방식, 3) 산출물 중심으로 작성해 달라’ 해야 합니다.
개선하고 싶은 점도 마찬가지입니다. ‘다음에는 이렇게 하고 싶지 않다’를 수집합니다. 가이드라인으로 ‘프로젝트 진행 중 아쉬웠던 순간을 떠올려보고, 돌이켜 보면 어떻게 하는 게 좋았을지 구체적으로 적어달라’해야 합니다. 그러면 팀원들이 의사소통, 일정관리, 시스템 설계, 목표 설정, 오픈 후 대응 등 다양한 상황에서 직군 별로 아쉬웠던 점을 구체적으로 적어줍니다.
마지막은 하고 싶은 말입니다. 여기는 가이드라인이 필요 없습니다. 각자 적고 싶은 대로 적으면 됩니다. 보람 있는 프로젝트를 진행했다면 팀원들 모두 마치 가이드라인을 받은 것처럼 구체적이고 생생한 답변을 써줍니다. 누군가에게 고마웠던 일이 있다면 이때 작성하면 됩니다. 경험상 꼭 1명의 감성적인 팀원이 장문의 편지를 쓰고, 이런 고백(?)이 회고의 마지막을 촉촉하게 만들어줍니다.
4. 회고를 계속하며
IT기업의 문화는 사실 회고에 달려있다고 해도 과언이 아닙니다. 기획, 디자인, 개발은 사실 퀄리티의 차이가 있을 뿐 누구나 할 수 있는 일입니다. 사실 대형마트 유통사, 스마트폰 통신사, 프랜차이즈 치킨집 모두 앱 하나씩은 만들 줄 아는 IT시대이니까요. 하지만 사용자들은 이런 회사가 만든 IT제품에 큰 기대를 갖지 않습니다. 실제로 대다수의 제품의 품질이 매우 낮죠. 그 이유는 회고의 유무에 있다고 생각합니다.
학교 다닐 때 흔히 공부를 잘하던 친구의 특징은 ‘한번 틀린 문제는 다시 틀리지 않는다’에 있습니다. 자기가 부족한 부분을 객관화하고 오답노트 형식으로 정리한 뒤 잘못되지 않도록 반복 숙달하는 것이 그들만의 경쟁력입니다. 당장 갈길이 멀다는 이유로 회고를 생략하고 개발에만 집중하는 조직이 있다면, 채점도 하지 않고 문제집만 쌓아가는 미련한 고등학생 같이 일하고 있다 하겠습니다.
회고는 꼭 거창할 필요가 없습니다. 당장 아주 작은 일이라도 문제 > 필요 > 해결의 3단계 과정이 있기 때문에 회고는 늘 시도할 수 있습니다. 회고가 한번 문화로 정착되면 기획자가 하고 싶지 않아도 주변 사람들이 회고는 언제 하냐고 물어보기 때문에 선순환이 생깁니다. 처음 수레바퀴를 돌리는 일은 어렵습니다. 그러나 이런 행동이 건강한 IT제품 문화를 만듭니다.
회고는 PM의 의무이자 동시에 권리입니다. 일의 보람, 제품의 방향성, 건강한 조직문화 이 세 가지는 함께 걸어온 길의 "뒤를 돌아볼 때" 찾을 수 있습니다.
yve.atelier