<div id="readability-page-1" class="page"><div><h2 id="ba83">1. 목표를 어떤 식으로 정하나요?</h2><p id="8a51">딜라이트룸에서는 OKR 을 이용하여 목표를 관리하고 있으며, 분기별로 Company OKR 이 정해지면, 각 팀에서 Company OKR 을 달성하기 위한 Team OKR 을 설정하는 시간을 가진다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*CI6ljK_SM1cymHrBnz-RcQ.png" width="700" height="245" role="presentation"></p></div></figure><h2 id="887a">Company OKR</h2><p id="3600">여기서 중요하게 생각하는 부분은 <strong>Company OKR 이 먼저 정해진 후에 Team OKR 로 넘어가는 부분</strong>이다. 모든 구성원이 한 방향으로 나아가게 만들기 위해 회사가 중요하게 생각하는 방향성을 먼저 공유하고, 그 방향성에 대해 궁금한 부분이나 의견이 있다면 이야기를 주고받을 수 있는 피드백 기간을 가진다.</p><h2 id="144f">Team OKR</h2><p id="a292">Company OKR 이 정해진 후에 각 팀에서는 이를 달성하기 위한 Team OKR 을 설정한다. 이 과정에서 목표치와 세부 방향성은 팀에서 주로 정하고 회사와 싱크한다. 이렇게 설정된 각 팀의 OKR 은 분기별로 있는 전사 워크샵에서 공유된다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*HtlKbElLbXLSWtQKnTOFGA.png" width="700" height="508" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*HtlKbElLbXLSWtQKnTOFGA.png?q=20"></p></div><figcaption>각 팀별 분기 회고 &amp; 다음 분기에 중요하게 생각하는 부분들 공유 시간</figcaption></figure><blockquote><p id="dbd8">딜라이트룸에서는 분기별로 하루를 전사 OKR 리뷰&amp;플래닝 시간으로 사용하는데, 이때<strong>각 부서가 어떤 결과물을 만들어 왔고, 어떤 레슨을 얻었으며, 이를 바탕으로 다음 분기에는 어떤 방향으로 나아갈지를 싱크</strong>하는 의미 있는 시간이다.</p></blockquote><p id="0472">전사 OKR 리뷰 및 플래닝 시간을 통해 각 팀이 각자의 목표만을 추구하는 것이 아니라 <strong>모두 한 방향으로 잘 가고 있는지를 확인하고, 서로의 목표를 한층 더 잘 이해</strong>할 수 있다. 더 나아가 각 팀이 서로의 목표를 달성하기 위해 도움을 주는 분위기도 만들어진다.</p><h2 id="d43a">2. 업무 우선순위를 어떻게 정하나요?</h2><p id="0cef">OKR이 잘 설정되었다면, 이제 각 팀에서 OKR 달성을 위해 백로그를 만들고 우선순위에 맞춰서 진행할 차례다. 아무리 목표가 잘 정해져도 우선순위가 불명확한 채로 주먹구구식으로 이뤄지면 성과를 내기 어렵다. 딜라이트룸에서 각 팀이 업무의 우선순위를 정하는 방법은 크게 두 가지 키워드로 표현된다.</p><h2 id="e74c">ICE 프레임워크</h2><p id="c877">서로 중요도를 이야기 할 때 공통의 언어가 있어야 효과적으로 소통할 수 있다. 우리는 공통으로 업무 우선순위를 정하기 위해<strong> ICE 프레임워크</strong>를 사용하고 있다. 이는 주먹구구식으로 우선순위가 정해지지 않도록 방지하고, 제한된 리소스에서 가장 좋은 성과를 낼 수 있도록 만들어 준다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*IckOWjA5IsY97CZNTR6Adg.png" width="700" height="391" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*IckOWjA5IsY97CZNTR6Adg.png?q=20"></p></div></figure><p id="7f26">간단하게 말하면<strong> Impact, Confidence, Ease 세 가지를 고려하여 우선순위를 정하는 것</strong>으로 “얼마나 임팩트가 있는 일인지?”, “얼마나 이 일에 확신이 있는지?”, “얼마나 리소스가 적게 드는 일인지?” 세 가지 축으로 점수를 매긴다. (조금 더 상세히 알고 싶다면, <a href="https://brunch.co.kr/@jiyouk/2" target="_blank" rel="noopener ugc nofollow">이 글을 참조</a>)</p><p id="576c">ICE 를 사용해 우선순위를 맞추면서 팀 내 구성원들이 서로 각 백로그들이 왜 중요한지 쉽게 싱크하게 된다.</p><blockquote><p id="78ec">그 과정에서 자연스럽게 PM/개발자/디자이너가 서로의 관점으로 피드백을 주고받으며 <strong>서로가 공감하는 우선순위로 업무가 진행</strong>된다.</p></blockquote><h2 id="2282">유연함</h2><p id="8597">목표가 명확하게 싱크 되고 공통의 언어가 정해졌다면 목표를 달성하기 위한 디테일한 프로세스는 각 팀에게 맡긴다. 팀별로 처한 환경이 다르기 때문에 각 팀에서 효과적이라고 생각하는 방식으로 프로세스를 설립하고 개선한다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*5QWuD7M6UDfjSp4SHbdCMA.png" width="700" height="445" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*5QWuD7M6UDfjSp4SHbdCMA.png?q=20"></p></div><figcaption>2주 단위의 지속적인 플래닝&amp;회고를 통한 점진적 개선</figcaption></figure><blockquote><p id="ec05">여기서 <strong>핵심은 각 팀에 맞는 운영방식을 계속해서 찾아가는 것</strong>으로 팀별 스프린트 회고를 통해 각 팀에 최적인 프로세스를 만들어가는 것이다.</p></blockquote><p id="54d0">이를 위해 모든 팀은 2주 단위 스프린트로 회고를 하며 좋았던 점 아쉬웠던 점을 공유하고 다음 스프린트에서 새롭게 시도하거나 변경하고 싶은 것들을 이야기한다. 이렇게 지속적인 개선을 시도하면서 각 팀에 최적화된 업무 프로세스로 발전시키고 있다.</p><h2 id="a95c">3. 사용자 중심적인 제품 문화를 가지고 있다던데요?</h2><p id="e4c5">딜라이트룸에 합류하면 가장 많이 듣게 되는 단어 중 하나가 바로 <strong>“사용자”</strong>라는 단어일 것이다. 물론 모든 회사가 사용자를 중요하게 생각하겠지만, 우리는 어떻게 하면 사용자 입장에서 생각하고 행동할 수 있을지를 끊임없이 고민하며 여러 시도를 하고 있다.</p><h2 id="5bf1">VOC 미팅</h2><p id="2eb1">매주 CPO, PM, Dev lead, Design lead, POM(Product Operation Manager) 가 <strong>모두 모여 VOC 를 리뷰하는 시간을 가진다</strong>. 단순히 정리된 내용을 훑는 정도가 아닌 모든 VOC의 원문을 함께 확인하고 논의한다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*boVmK_E5iYDJxpnIp7LMfg.png" width="700" height="434" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*boVmK_E5iYDJxpnIp7LMfg.png?q=20"></p></div><figcaption>실제로 매주 모두가 함께 리뷰하는 VOC 원문 예시</figcaption></figure><blockquote><p id="728d">여기서 중요한 것은 단순히 사용자가 제기하는 문제와 제안을 100% 반영 하는 것을 목표로 두는 것이 아니다 .<strong>각 팀에서 해당 사안에 대해 어떻게 생각하는지 의견을 듣고 중요도를 싱크하여 온도 차이를 줄이는 것</strong>이다.</p></blockquote><p id="8bc9">실제로 처음 VOC 미팅을 진행하면 <strong>하나의 문제에 대해서도 어느 팀은 “빠르게 수정해야 한다"라고 생각하고, 어느 팀은 “다른 이슈가 더 중요하다”와 같이 말하는 온도 차이를 발견</strong>할 수 있다. 이렇게 되면 장기적으로 팀 간에 이해도가 떨어지고, 장기적으로는 제품이 삐걱 거리며 사용자를 잘 이해하지 못하는 제품이 나온다.</p><p id="8f47">VOC 미팅을 통해 이런 온도 차이를 줄이게 되면, 서로가 생각하는<strong> 우선순위에 대해 잘 이해하게 되면서 “왜 이 문제를 빨리 해결해주지 않는 거야!?”라는 말 보다는 “아.. 이 문제도 중요하지만, 우리는 더 중요한 문제를 해결하고 있지"라는 이야기를 하게 되는 것을 발견</strong>할 수 있다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*OHK5tpLMIJpfa8TxJ9E9ww.png" width="700" height="354" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*OHK5tpLMIJpfa8TxJ9E9ww.png?q=20"></p></div></figure><h2 id="c9cc">회의실 이름</h2><p id="4680">딜라이트룸에서는 어떻게 사용자들의 문제를 해결해주고 삶을 바꿔줄지에 대한 고민을 항시 하고 있다. 실제로 <strong>우리의 서비스 덕분에 삶이 바뀐 사용자들의 스토리</strong>를 자주 확인하게 되는데, 이런 사용자들을 위하는 마음을 항시 간직하기 위해 회의실 이름은 아래와 같이 사용자의 스토리 + 별명으로 이루어져 있다.</p><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/1*QzbBlR4_uT3OoP_ocbLu7Q.png" width="700" height="274" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/1*QzbBlR4_uT3OoP_ocbLu7Q.png?q=20"></p></div><figcaption>딜라이트룸의 모든 회의실엔 스토리와 별명이 붙어있다</figcaption></figure><h2 id="ed35">리텐션은 왕이다</h2><p id="e53e">사용자의 불편함은 곧 리텐션으로도 나타난다. 딜라이트룸에서는 <strong>제품을 개선하는 모든 실험에서 리텐션을 분석하고, 통계적으로 유의미하게 떨어지면 실험이 성공했더라도 다시 롤백하는 문화</strong>를 가지고 있다. 또한, 리텐션 만으로는 모든 사용자의 마음이 드러나지 않기 때문에, 변화로 인한 사용자 피드백을 항시 확인하고 있다.</p><h2 id="be97">4. 얼마나 데이터 친화적인가요?</h2><p id="f1e0">딜라이트룸에서는 단순히 감에 의존해서 제품을 개선하는 것이 아니라 실제로 우리가 세웠던 가설이 통계적으로 유의미하게 검증되었는지 확인하고, 지표를 통해 얻을 수 있는 인사이트를 뽑아내어 공유하는 문화를 가지고 있다.</p><h2 id="daa2">A/B 테스팅 + 전사 공유</h2><p id="ae32">2주 단위의 매 스프린트마다 수많은 A/B 테스팅이 이루어진다. 가설 검증 뿐만 아니라 다양한 지표 분석을 통해 <strong>사용자들이 우리가 추가한 기능이나 변화를 어떻게 받아들이고 사용하는지에 대해 인사이트를 얻는다 </strong>(참조: <a rel="noopener" href="/delightroom/알라미의-a-b-테스팅-일지-1-eb811fe72a17">알라미 A/B 테스팅 일지#1</a>).</p><blockquote><p id="1022">이렇게<strong> </strong>각 팀에서 얻은 인사이트를 타운홀 발표에서 <strong>전사에 공유함으로써, 모든 구성원이 제품과 사용자에 대한 이해도를 높일</strong> 수 있게 만든다.</p></blockquote><figure><div role="button" tabindex="0"><p><img alt="" src="https://miro.medium.com/max/1400/0*mTfA48ACfXHtV3wi.png" width="700" height="469" sizes="700px" role="presentation" data-old-src="https://miro.medium.com/max/60/0*mTfA48ACfXHtV3wi.png?q=20"></p></div></figure><h2 id="f9e7">WDAS (Weekly Data Analysis &amp; Seminar)</h2><p id="6562">딜라이트룸에서는 모든 구성원들이 Amplitude 를 통해 모든 데이터를 확인할 수 있다. 평소에 데이터를 보고 분석하다 보면, 진행하던 업무와는 별개로 다양한 궁금증이 생기게 되는데 WDAS 시간을 통해 평소에 궁금했던 데이터를 분석하고 공유한다.</p><blockquote><p id="56e1">실제로 데이터 분석가가 아니더라도 쉽게 데이터를 보고 발견한 재미있는 현상을 공유하며, 그 과정에서 새로운 인사이트를 얻는 데이터 친화적인 문화를 가지고 있다.</p></blockquote><p id="a940">예를 들면, 한/미/일 중 어느 나라가 평균 기상 시간이 빠른지와 같은 간단한 분석부터, 코로나가 한창일 때에 미국에서 락다운으로 인해 도시별로 평균 기상 시간이 얼마나 뒤로 밀렸는지와 같은 분석 등이 진행되었다. 이는 데이터 분석가가 아닌 구성원이 단순 궁금증에서 확인한 데이터였다.</p><figure><div><p><img alt="" src="https://miro.medium.com/max/1130/0*fAzjA1KwhgLh-4S2.jpeg" width="565" height="313" sizes="565px" role="presentation" data-old-src="https://miro.medium.com/max/60/0*fAzjA1KwhgLh-4S2.jpeg?q=20"></p></div></figure></div></div>

Stories by Jaemyung Shin on Medium

알라미는 어떤 문화에서 만들어지고 있나요?
딜라이트룸에서는 어떻게 목표를 정하고 우선순위를 정할까? 알라미를 만들어가는 문화에 대해 자주 들어오는 질문 Top4 를 간단히 정리해 보았다.
1. 목표를 어떤 식으로 정하나요?
딜라이트룸에서는 OKR 을 이용하여 목표를 관리하고 있으며, 분기별로 Company OKR 이 정해지면, 각 팀에서 Company OKR 을 달성하기 위한 Team OKR 을 설정하는 시간을 가진다.
Company OKR
여기서 중요하게 생각하는 부분은 Company OKR 이 먼저 정해진 후에 Team OKR 로 넘어가는 부분이다. 모든 구성원이 한 방향으로 나아가게 만들기 위해 회사가 중요하게 생각하는 방향성을 먼저 공유하고, 그 방향성에 대해 궁금한 부분이나 의견이 있다면 이야기를 주고받을 수 있는 피드백 기간을 가진다.
Team OKR
Company OKR 이 정해진 후에 각 팀에서는 이를 달성하기 위한 Team OKR 을 설정한다. 이 과정에서 목표치와 세부 방향성은 팀에서 주로 정하고 회사와 싱크한다. 이렇게 설정된 각 팀의 OKR 은 분기별로 있는 전사 워크샵에서 공유된다.
딜라이트룸에서는 분기별로 하루를 전사 OKR 리뷰&플래닝 시간으로 사용하는데, 이때각 부서가 어떤 결과물을 만들어 왔고, 어떤 레슨을 얻었으며, 이를 바탕으로 다음 분기에는 어떤 방향으로 나아갈지를 싱크하는 의미 있는 시간이다.
전사 OKR 리뷰 및 플래닝 시간을 통해 각 팀이 각자의 목표만을 추구하는 것이 아니라 모두 한 방향으로 잘 가고 있는지를 확인하고, 서로의 목표를 한층 더 잘 이해할 수 있다. 더 나아가 각 팀이 서로의 목표를 달성하기 위해 도움을 주는 분위기도 만들어진다.
2. 업무 우선순위를 어떻게 정하나요?
OKR이 잘 설정되었다면, 이제 각 팀에서 OKR 달성을 위해 백로그를 만들고 우선순위에 맞춰서 진행할 차례다. 아무리 목표가 잘 정해져도 우선순위가 불명확한 채로 주먹구구식으로 이뤄지면 성과를 내기 어렵다. 딜라이트룸에서 각 팀이 업무의 우선순위를 정하는 방법은 크게 두 가지 키워드로 표현된다.
ICE 프레임워크
서로 중요도를 이야기 할 때 공통의 언어가 있어야 효과적으로 소통할 수 있다. 우리는 공통으로 업무 우선순위를 정하기 위해 ICE 프레임워크를 사용하고 있다. 이는 주먹구구식으로 우선순위가 정해지지 않도록 방지하고, 제한된 리소스에서 가장 좋은 성과를 낼 수 있도록 만들어 준다.
간단하게 말하면 Impact, Confidence, Ease 세 가지를 고려하여 우선순위를 정하는 것으로 “얼마나 임팩트가 있는 일인지?”, “얼마나 이 일에 확신이 있는지?”, “얼마나 리소스가 적게 드는 일인지?” 세 가지 축으로 점수를 매긴다. (조금 더 상세히 알고 싶다면, 이 글을 참조)
ICE 를 사용해 우선순위를 맞추면서 팀 내 구성원들이 서로 각 백로그들이 왜 중요한지 쉽게 싱크하게 된다.
그 과정에서 자연스럽게 PM/개발자/디자이너가 서로의 관점으로 피드백을 주고받으며 서로가 공감하는 우선순위로 업무가 진행된다.
유연함
목표가 명확하게 싱크 되고 공통의 언어가 정해졌다면 목표를 달성하기 위한 디테일한 프로세스는 각 팀에게 맡긴다. 팀별로 처한 환경이 다르기 때문에 각 팀에서 효과적이라고 생각하는 방식으로 프로세스를 설립하고 개선한다.
여기서 핵심은 각 팀에 맞는 운영방식을 계속해서 찾아가는 것으로 팀별 스프린트 회고를 통해 각 팀에 최적인 프로세스를 만들어가는 것이다.
이를 위해 모든 팀은 2주 단위 스프린트로 회고를 하며 좋았던 점 아쉬웠던 점을 공유하고 다음 스프린트에서 새롭게 시도하거나 변경하고 싶은 것들을 이야기한다. 이렇게 지속적인 개선을 시도하면서 각 팀에 최적화된 업무 프로세스로 발전시키고 있다.
3. 사용자 중심적인 제품 문화를 가지고 있다던데요?
딜라이트룸에 합류하면 가장 많이 듣게 되는 단어 중 하나가 바로 “사용자”라는 단어일 것이다. 물론 모든 회사가 사용자를 중요하게 생각하겠지만, 우리는 어떻게 하면 사용자 입장에서 생각하고 행동할 수 있을지를 끊임없이 고민하며 여러 시도를 하고 있다.
VOC 미팅
매주 CPO, PM, Dev lead, Design lead, POM(Product Operation Manager) 가 모두 모여 VOC 를 리뷰하는 시간을 가진다. 단순히 정리된 내용을 훑는 정도가 아닌 모든 VOC의 원문을 함께 확인하고 논의한다.
여기서 중요한 것은 단순히 사용자가 제기하는 문제와 제안을 100% 반영 하는 것을 목표로 두는 것이 아니다 .각 팀에서 해당 사안에 대해 어떻게 생각하는지 의견을 듣고 중요도를 싱크하여 온도 차이를 줄이는 것이다.
실제로 처음 VOC 미팅을 진행하면 하나의 문제에 대해서도 어느 팀은 “빠르게 수정해야 한다"라고 생각하고, 어느 팀은 “다른 이슈가 더 중요하다”와 같이 말하는 온도 차이를 발견할 수 있다. 이렇게 되면 장기적으로 팀 간에 이해도가 떨어지고, 장기적으로는 제품이 삐걱 거리며 사용자를 잘 이해하지 못하는 제품이 나온다.
VOC 미팅을 통해 이런 온도 차이를 줄이게 되면, 서로가 생각하는 우선순위에 대해 잘 이해하게 되면서 “왜 이 문제를 빨리 해결해주지 않는 거야!?”라는 말 보다는 “아.. 이 문제도 중요하지만, 우리는 더 중요한 문제를 해결하고 있지"라는 이야기를 하게 되는 것을 발견할 수 있다.
회의실 이름
딜라이트룸에서는 어떻게 사용자들의 문제를 해결해주고 삶을 바꿔줄지에 대한 고민을 항시 하고 있다. 실제로 우리의 서비스 덕분에 삶이 바뀐 사용자들의 스토리를 자주 확인하게 되는데, 이런 사용자들을 위하는 마음을 항시 간직하기 위해 회의실 이름은 아래와 같이 사용자의 스토리 + 별명으로 이루어져 있다.
리텐션은 왕이다
사용자의 불편함은 곧 리텐션으로도 나타난다. 딜라이트룸에서는 제품을 개선하는 모든 실험에서 리텐션을 분석하고, 통계적으로 유의미하게 떨어지면 실험이 성공했더라도 다시 롤백하는 문화를 가지고 있다. 또한, 리텐션 만으로는 모든 사용자의 마음이 드러나지 않기 때문에, 변화로 인한 사용자 피드백을 항시 확인하고 있다.
4. 얼마나 데이터 친화적인가요?
딜라이트룸에서는 단순히 감에 의존해서 제품을 개선하는 것이 아니라 실제로 우리가 세웠던 가설이 통계적으로 유의미하게 검증되었는지 확인하고, 지표를 통해 얻을 수 있는 인사이트를 뽑아내어 공유하는 문화를 가지고 있다.
A/B 테스팅 + 전사 공유
2주 단위의 매 스프린트마다 수많은 A/B 테스팅이 이루어진다. 가설 검증 뿐만 아니라 다양한 지표 분석을 통해 사용자들이 우리가 추가한 기능이나 변화를 어떻게 받아들이고 사용하는지에 대해 인사이트를 얻는다 (참조: 알라미 A/B 테스팅 일지#1).
이렇게 각 팀에서 얻은 인사이트를 타운홀 발표에서 전사에 공유함으로써, 모든 구성원이 제품과 사용자에 대한 이해도를 높일 수 있게 만든다.
WDAS (Weekly Data Analysis & Seminar)
딜라이트룸에서는 모든 구성원들이 Amplitude 를 통해 모든 데이터를 확인할 수 있다. 평소에 데이터를 보고 분석하다 보면, 진행하던 업무와는 별개로 다양한 궁금증이 생기게 되는데 WDAS 시간을 통해 평소에 궁금했던 데이터를 분석하고 공유한다.
실제로 데이터 분석가가 아니더라도 쉽게 데이터를 보고 발견한 재미있는 현상을 공유하며, 그 과정에서 새로운 인사이트를 얻는 데이터 친화적인 문화를 가지고 있다.
예를 들면, 한/미/일 중 어느 나라가 평균 기상 시간이 빠른지와 같은 간단한 분석부터, 코로나가 한창일 때에 미국에서 락다운으로 인해 도시별로 평균 기상 시간이 얼마나 뒤로 밀렸는지와 같은 분석 등이 진행되었다. 이는 데이터 분석가가 아닌 구성원이 단순 궁금증에서 확인한 데이터였다.
끝으로 정리해보면, 딜라이트룸에서는 명확한 목표 설정을 통해 모두가 한 방향을 보게 만들고, 각 팀이 최적의 우선순위를 달성하는 기반으로 업무를 진행한다. 그러면서도 정량적&정성적 데이터를 기반으로 사용자 중심적으로 생각하는 제품 개발 문화를 가지고 있다.
이런 제품 문화에서 알람의 정의를 단순히 시간을 알려주는 도구가 아니라, 하루의 시작과 끝을 책임지는 웰니스 서비스로 바꿔나가는 것에 관심 있다면…
👇👇👇👇👇👇👇
알라미 팀 페이지
딜라이트룸에서 일하는 방식 was originally published in DelightRoom on Medium, where people are continuing the conversation by highlighting and responding to this story.

딜라이트룸에서 일하는 방식

댓글