<div id="readability-page-1" class="page"><div data-id="4b124337" data-element_type="widget" data-widget_type="text-editor.default">
				


<p>안녕하세요, 리멤버에서 CPO를 맡고 있는 정현호 입니다.<br><span>이번 글에서는 리멤버 제품 크루들이 일하는 방식에 대해 소개드릴까 합니다.</span></p>
<p>리멤버의 제품 크루들은 [사용자 스토리] 기반으로 기획서를 작성하고, 팀과 공유하여 제품 개발을 진행하고 있습니다.</p>


<p>사용자 스토리 기반의 기술 방식은 일반적으로 생각하는 기능명세서와는 사뭇 다른 형태를 띄고 있어서 이런 형태의 문서를 처음 접하는 분들에게는 꽤나 생소하게 느껴질 수 있습니다.<br>가끔씩 드라마앤컴퍼니에 새롭게 합류하신 분들이 사용자 스토리 기반으로 기술된 문서를 처음 접하면서, “읭? 이게 기획서야?” 라는 반응을 보이는 경우들도 있는데요.</p>


<p>일하는 방식에 있어서 항상 정답이란게 있을 수는 없겠지만, 저희는 아래 두 가지 가치에 중점을 두고 현재와 같은 업무 방식을 유지해오고 있습니다.</p>


<ol>
<li>우리는 고객의 가치에 초점을 두어야 한다. 고객에게 가치를 전달하는 일은 우리 모두의 역할이자 책임이다.</li>
<li>우리는 대화를 지향한다. 대화를 통해 더 좋은 방향으로 발전할 수 있다고 믿는다.</li>
</ol>


<p>많은 분들이 드라마는 제품 개발이 어떤 프로세스로 진행되는지 궁금해하시고, 특히나 기획 단계에서부터 어떤 식으로 문서를 만들고 프로세스가 진행되는지 궁금해하셔서 사용자 스토리에 기반한 드라마의 제품 개발 프로세스를 소개드리면 좋겠다고 생각했습니다.</p>


<p>그럼 사용자 스토리란 무엇이고, 리멤버에서 어떻게 제품 개발 프로세스가 진행되는지 설명해보겠습니다.</p>





<h3>사용자 스토리란?</h3>


<p>사용자 스토리는 <strong>사용자나 구매자에게 가치를 줄 수 있는 소프트웨어의 기능을 서술한 것</strong>입니다.<br>쉽게 얘기하면, 사용자가 소프트웨어를 통해 무엇을 할 수 있는지를 사용자 관점에서 서술한 것이라고 할 수 있습니다.</p>


<p><strong>&lt;사용자 스토리의 예시&gt;</strong></p>


<figure>
<blockquote>
<p><em>사용자는 자신의 프로필을 특정 기업이 검색하지 못하도록 제한할 수 있다</em></p>
<p><em>사용자는 자신의 프로필을 채용 기업들이 검색, 열람할 수 있도록 허용할 수 있다</em></p>
</blockquote>
</figure>


<p>이렇게 사용자 관점으로 서술하면 사용자 스토리만 보아도 사용자가 서비스에서 어떤 것들을 할 수 있는지 쉽게 이해할 수 있습니다.<br>사용자 스토리는 기술적인 세부사항이나 구현의 용이성 보다는 ‘사용자 가치’에 초점을 두고 있기 때문에, <strong><span>이 스토리가 사용자에게 필요한가, 가치가 있는가를 우선적으로 고려</span></strong>하게 합니다.</p>


<p>사용자 스토리는 “대화”라는 측면을 특히 강조합니다.<br>스토리는 처음부터 그 기능의 동작과 예외사항을 모두 포함하지 않으며, 스토리를 구현하기 위해 고려해야할 사항들은 제품팀 안에서 <strong><span>“대화”를 통해 완성해나가는 방식을 지향</span></strong>합니다.</p>





<h3>왜 사용자 스토리인가?</h3>


<h5><strong>고객 관점으로 서술하여 누구나 이해하기 쉽다</strong></h5>


<p>앞서 보았듯이, 사용자 스토리는 소프트웨어, 시스템을 통해 사용자가 무엇을 할 수 있는지를 기술한 것이기 때문에 사용자 스토리만 읽어보아도 어떤 기능들이 있는지를 쉽게 이해할 수 있습니다.</p>


<p>제품 개발팀이 아닌 영업담당자가 보더라도 혹은 새로 합류한 사람이 보더라도 이해하기 쉽기 때문에 “이 스토리가 고객에게 정말 필요한가? 가치있는가?” 라는 관점으로 모두가 함께 고민할 수 있고 얘기를 나누기가 용이합니다.</p>


<p>기술적인 구현 난이도나 예외사항에 대해 집중하기 전에 사용자가 필요로 하는 스토리인가, 사용자의 문제를 해결해줄 수 있는 스토리인가로 초점을 맞추어 고민할 수 있습니다.</p>




<h5><strong>대화를 유도하고 참여적인 설계를 이끌어낼 수 있다</strong></h5>


<p>Waterfall 방식의 제품 개발 프로세스에서는 기획 단계에서 굉장히 구체적인 사항을 결정하고 기술해야 합니다. 각 단계에서 다시 역행하는 논의를 최소화해야 합니다.</p>


<p>이 과정에서 대체로 사용자의 가치를 우선하기보다는 기술적인 구현 용이성을 고려하게 되기 쉽고, 필요한 모든 세부사항을 이미 포함하고 있기 때문에 더 의논할 필요가 없을 거라는 그릇된 믿음으로 이어지게 되어 대화를 단절한다는 점이 있습니다. (항상 그런 것은 아닙니다만)</p>


<p>제품 관리자(또는 기획자)는 기술적인 배경 지식이 완벽하지 않기에, 기획자가 생각한 예외사항에는 누락된 사항이 발생할 수 있습니다. 이런 세부적인 고려사항을 채워나가는 것의 책임은 기획자 뿐만 아니라 제품팀 모두에게 있으며, 디자이너, 개발자도 이 스토리를 구현하기 위해 필요한 사항을 함께 고민하고 대화를 통해 완성해나가야 합니다.</p>


<p>일단 “이 스토리가 사용자에게 가치있는 것”이라는 공감대를 가진 후에는 이를 구현하기 위해 고려해야할 사항을 함께 질문하며 대화를 통해 구체화해나갑니다.<br>결과적으로 스토리가 구현되어 고객에게 릴리즈되는 시점에는 모든 사항들이 정리되어 완성되겠지만, ‘점차적으로 채워지며 보완되는’ 문서라는 측면에서 차이가 있습니다.</p>


<p>스토리 작성의 목적은 구현할 기능을 논의하기 위한 단서 역할입니다.</p>




<h5><strong>반복적인 개발에 효율적이다</strong></h5>


<p>스토리는 대부분 독립적이며, 나누기 용이합니다.<br>기술된 여러 개의 스토리 중에 고객 가치에 따라 우선 순위를 부여하고 우선 순위에 따라 스토리를 구현해나가는 방식으로 진행합니다.</p>


<p>스토리는 하나하나가 가치 단위로 서술된 것이므로 모든 스토리가 완료되어야 고객에게 릴리즈할 수 있는 것이 아닙니다. 때문에 우선 순위에 따라 스토리를 구현해나가며 새로운 스토리를 추가할 수도, 스토리의 우선 순위를 변경할 수도 있습니다.</p>


<p>하나의 예로, 리멤버의 채용 공고에는 검색 기능을 아직 지원하지 않고 있습니다.<br>“구직자는 회사명이나 공고명으로 게시된 공고를 검색할 수 있다” 라는 스토리가 검색을 해야할만큼 충분히 공고가 많아져야 사용자에게 가치있는 스토리일 것이라는 판단 하에 우선 순위가 낮았었던 겁니다. (물론 현재는 공고가 충분히 많아져서 이 스토리가 고객에게 매우 가치있는 스토리가 되어버렸습니다.)</p>


<p>이렇듯, 사용자 스토리는 스토리 단위로 우선 순위를 부여하여 반복적으로 제품을 보완하고 개선해나가는데에 효율적이라고 생각합니다.</p>





<h3>어떻게 업무가 진행되는가?</h3>


<h5><strong>문제 정의 및 가설 수립</strong></h5>


<p>제품관리자는 다양한 소스(VoC, 관찰, 설문, 사용자 로그 등)를 통해 문제를 발견하고 이를 구체화합니다.</p>


<p>제품관리자가 집중해야하는 것은 <b>사용자가 실제 겪고 있는 문제가 무엇인지를 발견하고 이를 명확히 정의하는 것에서 출발</b>합니다.<br>현재 발생하는 현상이나 고객 의견 등을 토대로 어떤 문제가 존재하고, 그 문제의 원인이 무엇인지 분석하여 우리가 해결하고자 하는 문제와 이를 해결함으로써 달성하고자 하는 목표를 명확하게 기술합니다.<br>이 단계를 탄탄하게 다져놓지 않는다면, 이후 이 스토리가 정말 가치있는 것인지, 이 스토리가 정말 문제를 해결하는 것인지 여러 논의를 거치며 다시 원론으로 돌아오게 되는 과정을 반복하게 될 수 있습니다.<br>단순한 아이디어에서 출발한 기획일지라도, 이것이 사용자의 어떤 문제를 해결할 수 있을 것인지 명확히 정의하지 않는다면 스토리의 우선 순위를 부여하기도 어렵거니와 이 스토리에 가치를 부여하기도 어렵습니다.</p>


<h5><strong>스토리의 작성과 논의</strong></h5>


<p>정의한 문제를 해결하기 위한 사용자 스토리를 기술합니다.</p>


<p>제품관리자가 고객의 입장을 대변하여 1차적으로 스토리를 기술하는 책임을 가집니다. 물론 이 과정에서 필요하다면 영업담당자, 마케터 등과 함께 스토리에 대해 논의하기도 하고, 직접 고객의 의견을 참고하여 반영합니다. 이 단계에서는 스토리의 구현을 위한 구체적인 사항에 집중하지는 않습니다.</p>


<p>1차적인 스토리 작성이 완료되면, 제품팀과 공유하여 아래의 순서대로 논의를 진행합니다.</p>


<ul>
<li>문제에 대한 명확한 이해 (모두가 동일한 이해를 가져야 합니다)</li>
<li>이 스토리가 사용자의 문제를 해결해줄 수 있을 것인가?</li>
<li>스토리가 빠짐없이 기술되어 있는가? 추가해야할 스토리는 없는가?</li>
<li>스토리의 중요도는 각각 어떠한가? 중요도에 따라 우선 순위를 부여할 수 있는가?</li>
<li>스토리를 구현하기 위해 고려해야할 요소가 있는가?</li>
</ul>


<p>스토리를 구현하기 위해 고려할 사항은 질문 사항으로 기록해두며 결정한 사항이 있다면 이를 함께 기록합니다.</p>


<h5><strong>디자인, 설계, 구현</strong></h5>


<p>충분한 대화를 통해 모두가 스토리에 대한 동일한 이해를 가졌다면, 디자인/개발 파트에서 스토리 구현을 위한 설계를 진행합니다.</p>


<p><strong>디자인 파트</strong>에서는 user flow를 고려하여 디자인을 진행하면서 드는 질문 사항을 수시로 팀과 공유하며 구체화하고, 제품 관리자는 과정마다 나오는 질문과 결정 사항들을 스토리에 주석으로 기록합니다.<br><strong>개발 파트</strong>에서는 스토리를 구현하기 위한 DB구조와 API 스펙 등 필요한 사항들을 설계하고 문서화하여 팀에 공유하고 피드백을 받아 보완해나갑니다.<br>모든 설계 내용은 초안 단계에서부터 팀에 공유됩니다.<br><strong>데이터 분석 파트</strong>에서는 기술된 문제와 가설, user flow를 참고하여 검증해야할 지표를 정의하고 이를 측정하기 위한 이벤트 로그를 설계합니다.<br><strong>QA 파트</strong>에서는 설계된 user flow를 바탕으로 누락된 시나리오나 예외사항이 없는지 점검하며 테스트 시나리오를 세웁니다.</p>


<p>위의 모든 과정은 순차적으로 진행된다기 보다는 동시에 진행되는 경우가 많습니다. 계속해서 대화를 통해 질문하고 의견을 나눠가며 진행되기 때문에 반드시 디자인 &gt; 개발설계 &gt; … 순으로 진행될 필요는 없습니다</p>


<p>어느 정도 설계와 디자인이 구체화 되면 우선순위에 따라 스토리를 구현해나갑니다. 매일매일 Daily-scrum과 slack을 통해 각자의 진행상황과 진행과정에서의 장애요소를 공유하고 놓쳤던 사항이 있다면 바로 관련한 사람들과 대화하며 결정하고 기록합니다.</p>


<p>우선 순위가 높은 스토리 위주로 순차적으로 진행되기 때문에 연관된 모든 스토리를 포함한 디자인, 설계가 아닌 경우가 많고 이는 이후 스토리들을 구현하면서 계속 보강되어갑니다.</p>


<h5><strong>테스트 및 배포</strong></h5>


<p>우선 순위에 맞춰 세워진 배포 계획에 따라 필요한 스토리의 구현이 완료되면 테스트 과정을 거쳐 고객에게로 릴리즈됩니다.</p>


<p>테스트 과정에서도 예외적인 시나리오가 발견되거나, 크고 작은 수정사항들이 발생하게 되지만 모든 사항을 다 한번에 대응하기 보다는 팀에서 이 시나리오가 얼마나 발생하게 될지, 발생했을때 얼마나 크리티컬할지를 판단하여 릴리즈에 포함할 대응사항인지, fast follow로 가져가야할 사항인지를 결정합니다. 거의 일어나지 않을 시나리오를 대응하기 위해 고객에게 가치를 딜리버리하는 시간이 늦어져서는 안된다고 전제하고 이에 맞춰 판단하고 있습니다.</p>


<h5><strong>가설 검증 및 모니터링</strong></h5>


<p>배포한 후에는 예상하지 못한 크래시나 버그가 발생하지는 않는지, 응답 속도에는 문제가 없는지 등을 모니터링하면서 이벤트 로그를 확인하며 처음에 세워뒀던 가설이 맞는지 검증하거나 실제 문제가 해결되었는지 확인합니다.</p>


<p>미리 설정한 가설을 검증하면서, 가설과 다르다면 원인을 찾아보고 보완하면서 위의 iteration을 다시 반복합니다.</p>





<h3>무엇을 유의해야 하는가?</h3>


<p>사용자 스토리를 기반으로 제품을 구현해나갈 때 몇 가지 유의사항이 있습니다.<br>사용자 스토리와 관련한 책들에서 이 외에도 얘기하는 것들이 더 있지만, 제 생각에 특별히 유의하면 좋을 세 가지를 꼽아보았습니다.</p>


<h5><strong>처음부터 너무 세부적인 사항을 기술하지 않는다</strong></h5>


<p>두 가지 측면이 있습니다.</p>


<ol>
<li>스토리가 사용자에게 가치 있는 것인가 라는 본질적인 논의에서 벗어나게 될 수 있다.</li>
<li>대화를 단절하고, 필요한 사항이 모두 포함되어 있어 더 논의할 필요가 없다는 그릇된 믿음을 줄 수 있다.</li>
</ol>
<p>가장 명심해야할 것은, 세부적인 사항에 집중하기 전에 이 스토리가 사용자에게 중요한 것인지를 우선 적으로 고민해야한다는 것입니다.</p>




<h5><strong>되도록 사용자 인터페이스를 배제한다</strong></h5>


<p>첫 번째 유의사항과 비슷한 맥락입니다.<br>사용자 인터페이스가 처음부터 스토리에 반영되어 있다면 구성원들의 창의적인 생각과 논의를 방해할 수 있고, 제품 디자이너가 더 나은 UX를 위한 고민을 하지 않게 될 수 있습니다.</p>
<p>제품관리자가 스토리를 정의하며 머릿속에 어느 정도 user flow나 좀 더 구체화된 wireframe이 있을 수 있지만 제품 디자이너가 그 wireframe에 생각이 고정되어 버릴 수 있기 때문에 기술된 스토리를 기반으로 구체적인 대화를 하기 전에 wireframe부터 제시하지 않을 것을 권장합니다.</p>




<h5><strong>사용자 역할(User role) 모델을 명확히 정의한다</strong></h5>


<p>서비스(제품)를 이용하는 사용자 유형은 매우 다양할 수 있습니다. 한 유형의 사용자를 생각하고 스토리를 기술하는 경우, 일부 사용자 유형의 요구를 무시하는 결과를 낳을 수 있습니다. 다양한 사용자 역할을 정의하여 각각마다 적절한 속성을 정의하고, 이들 간의 차이를 충분히 이해한 후 스토리를 생각해보면 자칫 지나칠 수 있는 사용자 스토리를 발견할 수도 있습니다.</p>


<p>필요하다면 persona를 정의해서 특정 사용자 역할을 대표하는 인물을 설정해둔다면 커뮤니케이션이 훨씬 수월해지기도 합니다.</p>





<h3>마치며</h3>


<p>이상 리멤버의 제품 크루들이 사용자 스토리에 기반하여 어떻게 제품을 만들어나가는지 간략히 설명 드렸습니다.<br>아직 부족한 부분도 많고, 계속해서 보완해나가고 있지만 서두에서 말씀드린 “고객 가치”와 “대화” 라는 두 가치를 기반으로 한다는 것에는 변함이 없는 것 같습니다.</p>


<p>많은 회사에서 이미 비슷한 방식으로 업무를 진행하고 있기도 하고, 그렇지 않은 곳들도 있으실텐데요. 정답은 없다고 생각합니다.<br>이런 식으로 일하는 곳도 있구나 라고 생각하고 참고해주시기를 바랍니다.</p>


<p>혹시라도 이런 방식으로 저희와 함께 일해보고 싶은 분이 계시다면, <br>드라마앤컴퍼니의 채용은 항상 열려 있으니 주저말고 연락 주세요!</p>


<p><a href="https://hello.remember.co.kr/" target="_blank" rel="noreferrer noopener">https://hello.remember.co.kr</a></p>


					</div></div>

DRAMA&COMPANY

안녕하세요, 리멤버에서 CPO를 맡고 있는 정현호 입니다.
이번 글에서는 리멤버 제품 크루들이 일하는 방식에 대해 소개드릴까 합니다.
리멤버의 제품 크루들은 [사용자 스토리] 기반으로 기획서를 작성하고, 팀과 공유하여 제품 개발을 진행하고 있습니다.
사용자 스토리 기반의 기술 방식은 일반적으로 생각하는 기능명세서와는 사뭇 다른 형태를 띄고 있어서 이런 형태의 문서를 처음 접하는 분들에게는 꽤나 생소하게 느껴질 수 있습니다.
가끔씩 드라마앤컴퍼니에 새롭게 합류하신 분들이 사용자 스토리 기반으로 기술된 문서를 처음 접하면서, “읭? 이게 기획서야?” 라는 반응을 보이는 경우들도 있는데요.
일하는 방식에 있어서 항상 정답이란게 있을 수는 없겠지만, 저희는 아래 두 가지 가치에 중점을 두고 현재와 같은 업무 방식을 유지해오고 있습니다.
우리는 고객의 가치에 초점을 두어야 한다. 고객에게 가치를 전달하는 일은 우리 모두의 역할이자 책임이다.
우리는 대화를 지향한다. 대화를 통해 더 좋은 방향으로 발전할 수 있다고 믿는다.
많은 분들이 드라마는 제품 개발이 어떤 프로세스로 진행되는지 궁금해하시고, 특히나 기획 단계에서부터 어떤 식으로 문서를 만들고 프로세스가 진행되는지 궁금해하셔서 사용자 스토리에 기반한 드라마의 제품 개발 프로세스를 소개드리면 좋겠다고 생각했습니다.
그럼 사용자 스토리란 무엇이고, 리멤버에서 어떻게 제품 개발 프로세스가 진행되는지 설명해보겠습니다.
 
사용자 스토리란?
사용자 스토리는 사용자나 구매자에게 가치를 줄 수 있는 소프트웨어의 기능을 서술한 것입니다.
쉽게 얘기하면, 사용자가 소프트웨어를 통해 무엇을 할 수 있는지를 사용자 관점에서 서술한 것이라고 할 수 있습니다.
<사용자 스토리의 예시>
이렇게 사용자 관점으로 서술하면 사용자 스토리만 보아도 사용자가 서비스에서 어떤 것들을 할 수 있는지 쉽게 이해할 수 있습니다.
사용자 스토리는 기술적인 세부사항이나 구현의 용이성 보다는 ‘사용자 가치’에 초점을 두고 있기 때문에, 이 스토리가 사용자에게 필요한가, 가치가 있는가를 우선적으로 고려하게 합니다.
사용자 스토리는 “대화”라는 측면을 특히 강조합니다.
스토리는 처음부터 그 기능의 동작과 예외사항을 모두 포함하지 않으며, 스토리를 구현하기 위해 고려해야할 사항들은 제품팀 안에서 “대화”를 통해 완성해나가는 방식을 지향합니다.
 
왜 사용자 스토리인가?
고객 관점으로 서술하여 누구나 이해하기 쉽다
앞서 보았듯이, 사용자 스토리는 소프트웨어, 시스템을 통해 사용자가 무엇을 할 수 있는지를 기술한 것이기 때문에 사용자 스토리만 읽어보아도 어떤 기능들이 있는지를 쉽게 이해할 수 있습니다.
제품 개발팀이 아닌 영업담당자가 보더라도 혹은 새로 합류한 사람이 보더라도 이해하기 쉽기 때문에 “이 스토리가 고객에게 정말 필요한가? 가치있는가?” 라는 관점으로 모두가 함께 고민할 수 있고 얘기를 나누기가 용이합니다.
기술적인 구현 난이도나 예외사항에 대해 집중하기 전에 사용자가 필요로 하는 스토리인가, 사용자의 문제를 해결해줄 수 있는 스토리인가로 초점을 맞추어 고민할 수 있습니다.
대화를 유도하고 참여적인 설계를 이끌어낼 수 있다
Waterfall 방식의 제품 개발 프로세스에서는 기획 단계에서 굉장히 구체적인 사항을 결정하고 기술해야 합니다. 각 단계에서 다시 역행하는 논의를 최소화해야 합니다.
이 과정에서 대체로 사용자의 가치를 우선하기보다는 기술적인 구현 용이성을 고려하게 되기 쉽고, 필요한 모든 세부사항을 이미 포함하고 있기 때문에 더 의논할 필요가 없을 거라는 그릇된 믿음으로 이어지게 되어 대화를 단절한다는 점이 있습니다. (항상 그런 것은 아닙니다만)
제품 관리자(또는 기획자)는 기술적인 배경 지식이 완벽하지 않기에, 기획자가 생각한 예외사항에는 누락된 사항이 발생할 수 있습니다. 이런 세부적인 고려사항을 채워나가는 것의 책임은 기획자 뿐만 아니라 제품팀 모두에게 있으며, 디자이너, 개발자도 이 스토리를 구현하기 위해 필요한 사항을 함께 고민하고 대화를 통해 완성해나가야 합니다.
일단 “이 스토리가 사용자에게 가치있는 것”이라는 공감대를 가진 후에는 이를 구현하기 위해 고려해야할 사항을 함께 질문하며 대화를 통해 구체화해나갑니다.
결과적으로 스토리가 구현되어 고객에게 릴리즈되는 시점에는 모든 사항들이 정리되어 완성되겠지만, ‘점차적으로 채워지며 보완되는’ 문서라는 측면에서 차이가 있습니다.
스토리 작성의 목적은 구현할 기능을 논의하기 위한 단서 역할입니다.
반복적인 개발에 효율적이다
스토리는 대부분 독립적이며, 나누기 용이합니다.
기술된 여러 개의 스토리 중에 고객 가치에 따라 우선 순위를 부여하고 우선 순위에 따라 스토리를 구현해나가는 방식으로 진행합니다.
스토리는 하나하나가 가치 단위로 서술된 것이므로 모든 스토리가 완료되어야 고객에게 릴리즈할 수 있는 것이 아닙니다. 때문에 우선 순위에 따라 스토리를 구현해나가며 새로운 스토리를 추가할 수도, 스토리의 우선 순위를 변경할 수도 있습니다.
하나의 예로, 리멤버의 채용 공고에는 검색 기능을 아직 지원하지 않고 있습니다.
“구직자는 회사명이나 공고명으로 게시된 공고를 검색할 수 있다” 라는 스토리가 검색을 해야할만큼 충분히 공고가 많아져야 사용자에게 가치있는 스토리일 것이라는 판단 하에 우선 순위가 낮았었던 겁니다. (물론 현재는 공고가 충분히 많아져서 이 스토리가 고객에게 매우 가치있는 스토리가 되어버렸습니다.)
이렇듯, 사용자 스토리는 스토리 단위로 우선 순위를 부여하여 반복적으로 제품을 보완하고 개선해나가는데에 효율적이라고 생각합니다.
 
어떻게 업무가 진행되는가?
문제 정의 및 가설 수립
제품관리자는 다양한 소스(VoC, 관찰, 설문, 사용자 로그 등)를 통해 문제를 발견하고 이를 구체화합니다.
제품관리자가 집중해야하는 것은 사용자가 실제 겪고 있는 문제가 무엇인지를 발견하고 이를 명확히 정의하는 것에서 출발합니다.
현재 발생하는 현상이나 고객 의견 등을 토대로 어떤 문제가 존재하고, 그 문제의 원인이 무엇인지 분석하여 우리가 해결하고자 하는 문제와 이를 해결함으로써 달성하고자 하는 목표를 명확하게 기술합니다.
이 단계를 탄탄하게 다져놓지 않는다면, 이후 이 스토리가 정말 가치있는 것인지, 이 스토리가 정말 문제를 해결하는 것인지 여러 논의를 거치며 다시 원론으로 돌아오게 되는 과정을 반복하게 될 수 있습니다.
단순한 아이디어에서 출발한 기획일지라도, 이것이 사용자의 어떤 문제를 해결할 수 있을 것인지 명확히 정의하지 않는다면 스토리의 우선 순위를 부여하기도 어렵거니와 이 스토리에 가치를 부여하기도 어렵습니다.
스토리의 작성과 논의
정의한 문제를 해결하기 위한 사용자 스토리를 기술합니다.
제품관리자가 고객의 입장을 대변하여 1차적으로 스토리를 기술하는 책임을 가집니다. 물론 이 과정에서 필요하다면 영업담당자, 마케터 등과 함께 스토리에 대해 논의하기도 하고, 직접 고객의 의견을 참고하여 반영합니다. 이 단계에서는 스토리의 구현을 위한 구체적인 사항에 집중하지는 않습니다.
1차적인 스토리 작성이 완료되면, 제품팀과 공유하여 아래의 순서대로 논의를 진행합니다.
문제에 대한 명확한 이해 (모두가 동일한 이해를 가져야 합니다)
이 스토리가 사용자의 문제를 해결해줄 수 있을 것인가?
스토리가 빠짐없이 기술되어 있는가? 추가해야할 스토리는 없는가?
스토리의 중요도는 각각 어떠한가? 중요도에 따라 우선 순위를 부여할 수 있는가?
스토리를 구현하기 위해 고려해야할 요소가 있는가?
스토리를 구현하기 위해 고려할 사항은 질문 사항으로 기록해두며 결정한 사항이 있다면 이를 함께 기록합니다.
디자인, 설계, 구현
충분한 대화를 통해 모두가 스토리에 대한 동일한 이해를 가졌다면, 디자인/개발 파트에서 스토리 구현을 위한 설계를 진행합니다.
디자인 파트에서는 user flow를 고려하여 디자인을 진행하면서 드는 질문 사항을 수시로 팀과 공유하며 구체화하고, 제품 관리자는 과정마다 나오는 질문과 결정 사항들을 스토리에 주석으로 기록합니다.
개발 파트에서는 스토리를 구현하기 위한 DB구조와 API 스펙 등 필요한 사항들을 설계하고 문서화하여 팀에 공유하고 피드백을 받아 보완해나갑니다.
모든 설계 내용은 초안 단계에서부터 팀에 공유됩니다.
데이터 분석 파트에서는 기술된 문제와 가설, user flow를 참고하여 검증해야할 지표를 정의하고 이를 측정하기 위한 이벤트 로그를 설계합니다.
QA 파트에서는 설계된 user flow를 바탕으로 누락된 시나리오나 예외사항이 없는지 점검하며 테스트 시나리오를 세웁니다.
위의 모든 과정은 순차적으로 진행된다기 보다는 동시에 진행되는 경우가 많습니다. 계속해서 대화를 통해 질문하고 의견을 나눠가며 진행되기 때문에 반드시 디자인 > 개발설계 > … 순으로 진행될 필요는 없습니다
어느 정도 설계와 디자인이 구체화 되면 우선순위에 따라 스토리를 구현해나갑니다. 매일매일 Daily-scrum과 slack을 통해 각자의 진행상황과 진행과정에서의 장애요소를 공유하고 놓쳤던 사항이 있다면 바로 관련한 사람들과 대화하며 결정하고 기록합니다.
우선 순위가 높은 스토리 위주로 순차적으로 진행되기 때문에 연관된 모든 스토리를 포함한 디자인, 설계가 아닌 경우가 많고 이는 이후 스토리들을 구현하면서 계속 보강되어갑니다.
테스트 및 배포
우선 순위에 맞춰 세워진 배포 계획에 따라 필요한 스토리의 구현이 완료되면 테스트 과정을 거쳐 고객에게로 릴리즈됩니다.
테스트 과정에서도 예외적인 시나리오가 발견되거나, 크고 작은 수정사항들이 발생하게 되지만 모든 사항을 다 한번에 대응하기 보다는 팀에서 이 시나리오가 얼마나 발생하게 될지, 발생했을때 얼마나 크리티컬할지를 판단하여 릴리즈에 포함할 대응사항인지, fast follow로 가져가야할 사항인지를 결정합니다. 거의 일어나지 않을 시나리오를 대응하기 위해 고객에게 가치를 딜리버리하는 시간이 늦어져서는 안된다고 전제하고 이에 맞춰 판단하고 있습니다.
가설 검증 및 모니터링
배포한 후에는 예상하지 못한 크래시나 버그가 발생하지는 않는지, 응답 속도에는 문제가 없는지 등을 모니터링하면서 이벤트 로그를 확인하며 처음에 세워뒀던 가설이 맞는지 검증하거나 실제 문제가 해결되었는지 확인합니다.
미리 설정한 가설을 검증하면서, 가설과 다르다면 원인을 찾아보고 보완하면서 위의 iteration을 다시 반복합니다.
 
무엇을 유의해야 하는가?
사용자 스토리를 기반으로 제품을 구현해나갈 때 몇 가지 유의사항이 있습니다.
사용자 스토리와 관련한 책들에서 이 외에도 얘기하는 것들이 더 있지만, 제 생각에 특별히 유의하면 좋을 세 가지를 꼽아보았습니다.
처음부터 너무 세부적인 사항을 기술하지 않는다
두 가지 측면이 있습니다.
스토리가 사용자에게 가치 있는 것인가 라는 본질적인 논의에서 벗어나게 될 수 있다.
대화를 단절하고, 필요한 사항이 모두 포함되어 있어 더 논의할 필요가 없다는 그릇된 믿음을 줄 수 있다.
가장 명심해야할 것은, 세부적인 사항에 집중하기 전에 이 스토리가 사용자에게 중요한 것인지를 우선 적으로 고민해야한다는 것입니다.
되도록 사용자 인터페이스를 배제한다
첫 번째 유의사항과 비슷한 맥락입니다.
사용자 인터페이스가 처음부터 스토리에 반영되어 있다면 구성원들의 창의적인 생각과 논의를 방해할 수 있고, 제품 디자이너가 더 나은 UX를 위한 고민을 하지 않게 될 수 있습니다.
제품관리자가 스토리를 정의하며 머릿속에 어느 정도 user flow나 좀 더 구체화된 wireframe이 있을 수 있지만 제품 디자이너가 그 wireframe에 생각이 고정되어 버릴 수 있기 때문에 기술된 스토리를 기반으로 구체적인 대화를 하기 전에 wireframe부터 제시하지 않을 것을 권장합니다.
사용자 역할(User role) 모델을 명확히 정의한다
서비스(제품)를 이용하는 사용자 유형은 매우 다양할 수 있습니다. 한 유형의 사용자를 생각하고 스토리를 기술하는 경우, 일부 사용자 유형의 요구를 무시하는 결과를 낳을 수 있습니다. 다양한 사용자 역할을 정의하여 각각마다 적절한 속성을 정의하고, 이들 간의 차이를 충분히 이해한 후 스토리를 생각해보면 자칫 지나칠 수 있는 사용자 스토리를 발견할 수도 있습니다.
필요하다면 persona를 정의해서 특정 사용자 역할을 대표하는 인물을 설정해둔다면 커뮤니케이션이 훨씬 수월해지기도 합니다.
 
마치며
이상 리멤버의 제품 크루들이 사용자 스토리에 기반하여 어떻게 제품을 만들어나가는지 간략히 설명 드렸습니다.
아직 부족한 부분도 많고, 계속해서 보완해나가고 있지만 서두에서 말씀드린 “고객 가치”와 “대화” 라는 두 가치를 기반으로 한다는 것에는 변함이 없는 것 같습니다.
많은 회사에서 이미 비슷한 방식으로 업무를 진행하고 있기도 하고, 그렇지 않은 곳들도 있으실텐데요. 정답은 없다고 생각합니다.
이런 식으로 일하는 곳도 있구나 라고 생각하고 참고해주시기를 바랍니다.
혹시라도 이런 방식으로 저희와 함께 일해보고 싶은 분이 계시다면, 
드라마앤컴퍼니의 채용은 항상 열려 있으니 주저말고 연락 주세요!
https://hello.remember.co.kr
					
The post 사용자 스토리 기반의 제품 개발 appeared first on DRAMA&COMPANY.

사용자 스토리 기반의 제품 개발

댓글