블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 

'방법론'에 해당되는 글 2

  1. 2015.05.07 린 스타트업 #2-린 스타트업 프로세스에 대한 개요
  2. 2008.04.04 Scrum 기반 개발 방법론 (1)
 

린 스타트업의 프로세스 개요

일단 현재 이해한것 까지 중간 정리, 린스타트업은 도요타의 린 방법론을 기반으로 IMVU CTO인 에릭리스가 정리한 스타트업의 프로세스이다.

기본적으로 스타트업의 제품 및 서비스 개발의 행위를 학습으로 정의하고 있으며, 빠르게 최소한의 기능을 가지고 있는 서비스를 빠르게 개발하여 시장에 릴리즈한 후 고객의 반응을 수치화한 데이타를 기반으로, 판단하여 이를 기반으로, 제품의 개발 방향이 맞는지를 학습하여 끊임없이 서비스를 수정/개발해 나가는 프로세스이다.

전체적인 프로세스를 도식화 하자면 다음과 같다.


※ 이 그림은 일반적으로 소개되는 린스타트업의 프로세스가 아니라, 본인이 이해하고 내용을 가감한 프로세스이다.

 



가설과 구현


먼저 가설을 세우고, 이 가설(아이디어)를 기반으로 서비스를 개발한다. 이때, MVP (Minimum Viable Product)이라는 개념을 사용하는데, 컨셉을 구현하기위한 최소한의 기능만을 가지고 있는 제품(또는 서비스)를 정의한다.

일반적으로 고객은 자신이 무엇을 원하는지를 잘 모른다. 소프트웨어 개발에서 요구 사항 분석이 실패하는 이유중의 대부분이 고객이 요구 사항을 제대로 정의하지 못하기 때문이다. 왜냐? 고객도 무엇을 원하는지를 모르기 때문에, 그렇지만, 고객은 자기가 좋아하는 것과 좋아 하지 않는 것에 대한 구별할 수 있는 능력은 있다. 그래서, MVP를 가지고 고객에게 제시하면 그때 부터 고객은 그 제품이 좋은지 나쁜지에 대해서 이야기할 수 있고, 그 피드백을 기반으로 제품을 개선할 수 있다.

제품이 개선될것을 전제로 하기 때문에, 커다른 덩치 큰 제품을 만들지 않는다. 다 만든 다음에, 나중에 그 방향을 바꾸게 되면, 다 만드는데도 많은 시간이 소요될뿐더러 만든 다음에, 전체 기능을 폐기 하게 되면 그 비능이 크기 때문이다.

MVP 부터 시작해서 고객의 피드백과 반응을 통해서 제품의 방향을 유연하게 설정하면서 고객이 만족할만한 제품을 진화적으로 만들어 나간다.


지표의 정의와 측정


고객의 피드백과 반응을 수집하고 이를 제품에 반영하려면, 이를 수치화 즉 지표화할 필요가 있다. 지표화를 하기 위해서는 무엇을 지표화 해야할지를 결정해야 한다.

서비스 기능 추가 개선후, 가입자 수가 증가 했는지? 아니면 서비스 사용 시간이 늘어났는지? , 어떤 작업을 했으면 그것이 어떤 효과를 나타내는지를 정량적으로 수치화해야 한다.

일반적으로 스타트업이 실패하는 이유중의 하나가, 이 정량화를 기반으로한 측정을 하지 않거나, 적절하지 않은 지표를 정했기 때문인 경우가 많다. 이를 허수지표라고 하는데, 이 허수 지표에 대해서는 뒤에서 다시 언급하도록 한다.


1) AB 테스트

지표 측정 방식에서 효과적으로 활용할 수 있는 추가적인 기법중의 하나가 AB 테스트이다. AB테스트는 같은 서비스를 두개의 고객군을 나눠서 A고객과 B고객에 서로 다른 기능을 제공하여 그 피드백을 살펴보는 방식이다.

신규 기능을 개발했을때,  새로운 기능을 무조건 운영 시스템에 반영을 하는 것이 아니라, 일부고객군에게만 적용한 후에, 그에 대한 반응을 정량적으로 측정한 후, 반응이 좋은 경우에만 그 기능을 운영시스템에 전체 반영하는 기법인데, AB 테스트를 위해서는 먼저, 여러개의 고객군에 서비스를 차등 제공할 수 있는 개인화 기능이 제공되어야 하며, 또한 기능 구현시 마다 배포를 할 수 있는 자동 배포 (Continues Delivery : aka. CD) 프레임웍이 준비되어야 한다.

그리고, 각 테스트 표본집단 별로 신규 기능에 대한 고객 반응을 측정할 수 있는 리포팅 시스템 개발이 전제되어야 한다.

자동화나 리포팅 시스템은 이러한 AB 테스트를 효율적으로 할 수 있는 도구에 불과하다. 무엇보다 중요한것은 AB 테스트를 위한 표본 집단의 선출 방식과, 고객의 반응을 어떤 지표로 정의할 것인가가, 가장 중요하다.


 2) 빅데이타 분석

린 스타트업 프레임웍에서 가장 중요한것은 가설에 대한 테스트 결과를 지표를 통해서 분석해야 하는 것인데, 이를 위해서는 데이타 분석이 필요하다.

단순히 정형화된 데이타를 수집해서 간단한 리포트만을 뽑아내는 것이 아니라, 방문로그,체류 시간, 광고 집행 시기, 마케팅 시기등 다양한 소스에서 오는 데이타에 대한 상관 관계 분석을 통해서 지표를 재정의 및 발전 시켜 나가야 하는데, 이를 위해서는 향후 분석과 데이타에 숨어있는 상관 관계 분석을 위해서 가급적 많은 데이타를 저장할 필요가 있다. 이런 많은 데이타를 정재되지 않은 상태로 저장하기 위해서는 큰 데이타 저장소가 필요한데, 이러한 개념은 과거의 데이타 웨어 하우스와 유사한 data lake 라는 곳에 데이타를 모으고, R등의 데이타 분석 언어를 이용하여 데이타에서 지표를 산출해내고, 이를 리포팅 시스템을 통해서 뽑아낼 수 있다. (이구조에 대해서는 이전 포스트 http://bcho.tistory.com/984 를 참고하기 바란다.)

결과적으로, data lake 나 리포팅등 지표를 확인할 수 있는 통계 시스템이 필요한데, 기존과 데이타의 양이 틀리기 때문에, 빅데이타 기반의 분석 시스템은 린 스타트업 프레임웍에서 대단히 필요한 부분이 된다.

그렇다고 스타트업에서 Spark,Hadoop, DW와 같은 고급 기술을 기반으로 대규모 분석 시스템을 만들 수 는 없는 노릇이고, 가급적이면 처음에는 구글 애널러틱스나, 클라우스 SaaS또는 PaaS형태의 데이타 분석 시스템을 이용하여, 유효 지표를 뽑아내서 사용하는 것이 더 바람직하다.


결국은 학습의 반복


린 스타트업의 핵심 프레임웍은 학습이다. 가설을 세우고 가설을 테스트하고 검증한후, 가설이 틀린 부분을 수정해나가면서 고객의 needs를 알아가는 학습의 과정이며, 회사의 비지니스 모델이 무엇이 적절하고, 어떤 기능이나 서비스가 핵심인지를 계속해서 배워나가는 학습의 반복이다.

새로운 이벤트, 새로운 기술을 넣는 것이 아니라, 이러한 지루한 반복을 통한 학습과 개선을 통해서 서비스(제품)을 개선해나가고 가치를 부여하는 과정이 스타트업이 아닌가 싶다.

※ 린 스타트업 책에서는 제품 개발에 대해서의 학습을 강조했지만, 인사나, 팀 문화, 재무 까지 스타트업에서는 학습의 반복이 아닐까 한다. 처음부터 모든 부분을 알거나 해당 분야에 대한 전문가를 영입해서 사업을 시작할 수 없는 만큼, 스타트업 기업이 성장해감에 따라 회사 경영에 대한 부분도 계속해서 학습하면서 만들어 나가야 한다.

다만, 이 학습은 계속 되고 학습에 따라 회사가 발전해나가야 하지, 이 학습이 목표와 방향성을 잃고 학습이 정체되는 순간, 스타트업은 퇴락의 길을 걷지 않을까?

 

혁신 회계와 지표


앞서 설명한 지표에 대해서는 조금 더 깊게 생각해볼 필요가 있다.


혁신 회계                              


린스타트업에서는 혁신회계라는 재미있는 개념을 소개하는데, 전통적인 기업이 매출과 손익이라는 금전적인 지표를 회계의 지표로 삼는데 반해서, 린 스타트업의 혁시 회계에서는 금전적인 지표 보다는 서비스 성장을 판단할 수 있는 지표를 회계의 지표로 삼는다.

이는 아마도, 스타트업의 모델이 대부분 성장 후에, 상장, 매각, 유료화등의 다양한 출구 전략을 선택하기 때문에, 출구 전략전 사업을 확장을 주요 지표로 하기 때문이 아닌가 싶다. 실제로 대부분의 서비스 기반의 스타트업은 가입자수나 액티브 사용자 수 또는 LTV (Life time value : 사용자당 평생 기대 수익)등을 기반으로 가치를 평가 받아서 투자를 받거나 상장을 하는 모델이기 때문에, 이러한 혁신 회계 지표가 오히려 적절하지 않은가 한다.


지표의 개념이 없는 스타트업


많지는 않지만, 가끔 스타트업의 시스템 구조를 진단 해주다보면, 이런 혁신 지표를 정의하지 않고 경영을 하는 경우가 많은데, 초반에는 그럴 수 있다고 치더라도, 이는 위험한 방식이 아닌가 싶다.

지표에 대한 개념이 없이 수~수십억의 마케팅 비용을 집행하면서, 마케팅을 통한 사용자 유입률이나 사용시간 증가분을 측정하지 않는 등이 대표적인 예인데이는 투자 대비 효과에 분석 준비 없이 비용을 집행하기 때문에, 잘못하면 효과없이 소중한 비용만 낭비하는 결과를 일으킬 수 있다.

앞에서도 설명하였듯이, 린 스타트업 프레임웍에서는 아이디어가 제품화/서비스화 된 결과에 대한 측정을 할 수 있는 유효 지표를 정의하는 것이 선행되어야 한다.


허수 지표에 대해서


그러면 이러한 지표 정의에 있어서 가장 경계해야할것이 허수 지표인데, 예를 들어서 설명하자 A사의 서비스의 가입자수가 꾸준히 늘어나고, 1억 이상의 가입자를 가지고 있다고 할때, 이 서비스가 성공적인 서비스일까? 지표상으로 봤을때는 그럴 수 있다.

그러나 몇가지 현실적인 가정을 만들어보자, A사는 핸드폰을 만드는 회사이고, 음악을 들려주는 앱을 단말이 판매 될때 이 서비스를 프리로드하였다. 그리고, 핸드폰을 초기화할때 이 서비스가 자동으로 가입되도록 하였다. 그렇다면 이 서비스를 실제로 사용하지 않지만 가입한 사용자 수는 많아지게 되고, 가입자 지표는 많지만 서비스가 실제로 사용되지 않기 때문에, 이 지표를 기반으로 1억 이상의 가입자를 처리할 수 있는 시스템을 확장하는 등의 비용이 투자될 수 있고, 또한 사업이 잘된다는 착각에 빠질 수 있다. 가입자 수 보다는 사용자의 재방문율 또는 주별 사용시간등을 측정하는 것이 오히려 현실적일 수 있다.

또 다른 허수 지표의 예를 들어보자, 스마트폰 유료앱을 판매하는 서비스라고 할때, 판매되는 라이센스 수 만 측정하면 될까? 끼어 팔기나 정치적인 원인에 의해서 라이센스가 판매되는 경우는 비지니스에서 흔한 케이스이다. 1000만 라이센스가 판매되었다고 하더라도, 그중에 실제로 사용되는 라이센스가 100만이라면, 이 사업이 제대로 가고 있다고 할 수 있을까? 제대로된 지표는 판매된 라이센스가 아니라 사용되고 있는 (액티베이션된) 라이센스이다.

이 밖에도 잘못된 지표를 양산 하는 경우는 많다. 광고나 이벤트로 인해서 반짝 가입자수가 늘었다가 사용자가 사용하지 않는 서비스등도 그러한 예에 속할 수 있다.

이렇게 일반적으로 생각할 수 있는 가입자 수, 라이센스 판매량등을 지표로 삼아서 사업을 꾸려나갈 수 있지만 실제로 사업에서 유효하 지표가 무엇인지를 제대로 판단하여 정의하고, 이를 기반으로 사업의 방향을 정해야 한다.

이렇게 사업의 진정한 가치와 동떨어지고, 잘못된 판단을 유발할 수 있는 지표를 허수 지표하고 한다.


결론


지금까지나마 간략하게 린 스타트업으 대략적인 프로세스에 대해서 살펴보았고, 그 중에서 가장 중요한 지표(혁신회계)에 대해서 살펴보았다. 무엇보다 중요한 것은 스타트업 서비스에 새로운 가설을 기반으로 한 서비스나 기능을 추가했을 때 이를 측정할 수 있는 지표를 정의하고 측정하는 것이 중요하며, 특히 이 지표 정의시, 스타트업의 성장을 제대로 측정할 수 있는 유효 지표를 정의하고 허수 지표를 제거하는 것이 중요하다.

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

Scrum 기반 개발 방법론

ALM/Task Management | 2008. 4. 4. 18:06 | Posted by 조대협

본 개발 프로세스는 애자일 방법론중에서 Scrum 개발 방법론을 기반으로 한 방법론이며, 방법론의 개념과 함께, Atlassian社의 JIRA 이슈 추적 시스템을 이용하여 실제로 팀 프로젝트를 관리하는 방안을 설명한 구체적인 실용주의 방법론이다.

사용자 삽입 이미지

<그림. Scrum 프로세스 >


전체 시나리오

  • 고객 또는 분석가는 시스템에 구현되어야 하는 기능을 최종 사용자 입장에서 "기능"으로 서술한다. 이를 Product BackLog라고 하고, 각각의 기능에 대한 사용자 스토리등이 구체적으로 기입되어야 한다.
    이 과정에서 Product BackLog는 기능별로 하나의 카드에 작성될 수 도 있고 또는 UseCase Diagram에서 Use Case로 작성될 수 있다.
  • 이렇게 작성된 각각의 Product BackLog에 대해서 오픈 일정에 따라서 우선적으로 구현해야 할 기능들을 선출한다.
  • 애플리케이션 아키텍트 또는 디자이너는 이 Product BackLog를 검토하여, 실제 시스템에 구현될 세부 기능으로 분할한다. 이 기술적으로 분할되고 재해석된 기능들을 Sprint라고 정의한다.

    예를 들어 고객이 사이트에서 쇼핑몰 기능에 대한 시나리오를 작성하였을때, 쇼핑몰에 장바구니,카드결재,채팅,배송조회 등의 기능이 들어있다고 했을때, 카드 결재나 배송 조회와 같은 경우는 기술적으로 구현에 많은 시간이 소요된다고 판단이 되면 (외부 연계 때문에...) 이를 별도의 Sprint로 나누어 낼 수 있다. Sprint는 실제 개발팀에서 분석->설계->구현->테스트->배포까지 수행해야 하는 일련의 프로젝트 단위로 일반적으로는 고객의 Product BackLog가 하나의 Sprint로 맵핑될 수 있으나, 기능의 크기에 따라서 크기가 클 경우에는 여러개의 Sprint로 분할 할 수 있다.

  • 이렇게 분할된 Sprint들은 PM에 의해서 각 프로젝트 수행팀으로 배분된다. 프로젝트 수행팀을 스크럼팀이라고 하고, 이 팀은 PL과 개발원들로 구성된다. PM은 Sprint의 규모에 따라서 PL과 상의하여 적절한 일정과 Resource 투입을 결정하고, Sprint 수행중 일정이 늦어지거나 문제가 있을 경우 기능을 다음 Release로 넘기거나 또는 Resource를 더 투여하는 일련의 작업을 수행한다.
  • Sprint를 받은 Scrum Leader는 Sprint를 구현하기 위한 세부 기능과 작업을 Task라는 이름으로 작성하고, 이를 각 개발원에게 분배한다.

이런 일련의 사이클을 반복하면서 고객의 요구 기능은 각 Scrum 팀에서 개발되게 되고 릴리즈 주기별로 마무리되어야할 Sprint를 PM이 관리하여 정해진 시간내에 릴리즈를 맞출 수 있게 진행한다.

만약에 고객의 추가 요구사항이 있을 경우 고객이 Product BackLog에 이를 반영하고, 추가 요구 사항에 대해서 우선 순위를 조정함으로써 이번 릴리즈에 포함될지 다음 릴리즈에 포함될지를 결정한다. 이때 주의할 점은 기능의 추가나 변경이 있음에도 불구하고 Resource의 할당이나 시간이 변함이 없다면 기능을 다음 버전으로 미뤄야지 무리하게 넣을 경우 과도한 일정으로 인하여 품질 저하등의 문제를 야기 할 수 있다.

Task의 관리

각 개발원에게 할당된 Task에 대해서는 "화이트 보드 + 포스트잇" 을 이용하여 스크럼팀 별로 스케쥴을 관리할 수 있다.
처음 생성된 Task는 "TO DO" 상태로 지정되고, 이 Task를 개발자에게 할당이 된 후.. 개발자가 진행을 시작했을때 "IN PROGRESS" 상태로 옮긴다. 그리고 해당 Task에 대한 작업이 완료되었을때 "DONE"으로 이동된다.

이는 화이트 보드에서 3개의 섹션을 만들어서 관리할 수 도 있고, 또는 이슈 트랙킹 시스템에서 Task의 상태를 지정하는 방법으로도 가능하다.(이를 TaskBoard라고 한다.) 아래 그림은 Atlassian사의 JIRA의 상용 플러그인 GreenHooper의 화면이다.

사용자 삽입 이미지

<그림. GreenHooper를 이용한 JIRA의 TaskBoard 구현 >
 GreenHooper는 JIRA의 이슈를 본 방법론에 맞게 TO DO,IN PROGRESS,DONE 상태로 비주얼 하게 표시할 수 있게 해주며, 개발자별 Task Board를 관리할 수 있게 해준다.

다음 문서에서는 본 방법론을 기초로 하여 JIRA와 GreenHooper를 통한 자바스터디 개발 프로세스에 대해서 설명한다

본인은 구글 클라우드의 직원이며, 이 블로그에 있는 모든 글은 회사와 관계 없는 개인의 의견임을 알립니다.

댓글을 달아 주세요

  1. 2011.09.21 02:29  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다