결과

주요업무     서비스 전략수립 및 서비스 기획
데이터 분석
경쟁사 분석 및 시장 리서치
자격요건  데이터 기반으로 업무
• 주도적으로 문제를 정의하고 목표 및 전략 수립하여 업무 추진
• 적극적인 커뮤니케이션으로 협업능력이 좋은 사람
우대사항 • 서비스기획 또는 스타트업 경험이 있는 사람
• 데이터툴을 잘 다루는 사람
혜택 및 복지 • 자유로운 연차 사용
• 워라밸 중시
• 유연한 근무
• 최신 업무 장비 지원

기술스택, 툴
Excel
PowerPoint
SQL

 

 

 

 

 

 

협업 능력

1. 업무 방식을 존중하고 효율적으로 일할 수 있도록 돕는다.

2. 중요한 파트너로 대한다.

3. 제대로 일할 수 있도록 충분한 시간을 준다.

4. 프로젝트 초반부터 개발자와 디자이너가 참여하도록 독려한다.

5. 전문가에게 권한을 위임한다.

 

커뮤니케이션능력

1. 커뮤니케이션이일관적이고 명확하다.

2. 팀원의 의견을 경청하고, 다양한 의견을 취합하여 실행방안으로 만들어 낼 수 있다.

3. 오버커뮤니케이션 > 언더커뮤니케이션

4. 지속적인 소통을 통해 팀원들이 무엇을 하고 있는지, 앞으로 무엇을 해야하는지 잘 알고 있다.

 

업무 범위 및 리스크 관리 능력

1. 중요한 것에 집중한다.

2. 무자비할 정도로 불필요한 것을 걸러낸다.

3. 업무 범위 조정과 실험을 통해서 리스크를 관리한다.

 

의사결정 능력

1. 사용자와 비즈니스 결과를 최우선으로 고려하여 일관적이고 투명한 결정을 내린다.

2. 소비자, 비즈니스, 팀을 위한 결정을 한다.

3. 데이터에 기반한 결정을 내릴 줄 안다.

 

업무지식

1. 정성적 / 정량적 리서치 방법에 대해서 이해한다.

2. 데이터를 활용하고, 데이터를 이해하는 사람과 협업할 수 있다.

3. 어떤 결정을 내릴 때 기술적으로 무엇을 의미하고 오래 걸릴지 이해하려고 노력한다.

4. 최소한의 개발지식 및 디자인 지식을 보여하고 있다.

 

목표와 비전 설정

1. 왜 이 일을 해야하는지 그 비전과 목표를 제대로 설명할 수 있다.

2. 지속해서 사용자, 경쟁사, 시장조사를 하고 이를 제품에 반영한다.

3. 해결책보다는문제가 무엇인지에 대해서 더 깊이 고민한다.

 

Biz Stakeholders 와 건설적인 의견 교환 능력

1. 경영진에게서오는 압박을 잘 수용하고 이를 해결하기 위해 어떤 업무를 해야하는지 알고있다.

2. 제품을 더 좋게 만들기 위해서 회사 경영진에 이의를 제기할 수 있다.

3. 해결책보다는문제가 무엇인지에 대해서 더 깊이 고민한다.

 

개방적 태도

1. 피드백을 사적인 감정으로 받아들이지 않는다.

2. 자기 아이디어와 사랑에 빠지지 않는다.

3. 팀원이 답변을 요구하면, 제때 제대로된 답변을 할 수 있다.

 

Product Requirement Document

  • 신규 서비스 업데이트 및 기존 서비스의 변경 등 서비스의 변화를 가져오기 위해 변경 요구사항을 정의하는 것
도입배경 및 목적 문제가 무엇이며, 이를 통해 어떤 개선을 원하는지
타겟 고객(내부 사용자 포함) 해당 문제를 겪고 있는 타겟 고객이 누구인지
기대 효과(매출, 생산성 향상) 이를 통해 예상하는 효과
고객 기준의 Flow-chart 변경 이후, 고객은 서비스를 어떻게 사용할 수 있을지?
기능 정의 실제로 문제를 해결하기 위한 방안, UI를 제안하면 안됨

요구사항 정의서 구성

요구사항 구분 프로젝트 규모가 크면 클수록 확인해야 할 요구사항이 많음.
요구사항 ID 화면 멸 화면 ID를 부여하는 것처럼 요구사항들을 관리하기 위한 ID 부여
요구사항 명 어떤 요구사항인지 요약하여 기재
요구사항 상세 설명 요구사항에 대한 상세한 내용에 대해 기재
요청자 요청한 요청자 정보 기재
비고 참고할 만한 레퍼런스를 전달받았거나, 확인 요청을 할 때에 비고에 내용 기재

요구사항 정의서 작성 순서

  • 요구사항 정의 -> 초안 작성 -> 협업 논의(법무, 재무, 디자인, 개발 등) -> 초안 수정 -> 개발조율(UI설계, 개발일정 조율)

요구사항 정의서가 중요한 이유

  • 요구사항이 명확해야 현실적인 개발 견적을 알 수 있음.
  • 프로젝트 분쟁 확률을 대폭 낮출 수 있음.
  • 프로젝트에 딱 맞는 개발 회사를 쉽게 찾을 수 있음.
  • 서비스의 용어 및 기본 운영 정책을 정의한 프로젝트 산출물
  • 회원가입 정책, 포인트 정책, 배송 정책, 교환/환불 정책, 상품 구매 정책 등

정책서 작성 

  • 불가항력적인 요소를 우선 고려하며 정책을 경정하고 문서로 작성
  • 작성된 정책 문서를 공유하며 합의를 이룰 때까지 수정 및 피드백을 반복
  • 한 번에 모든 정책을 정의할 수 없음. 

관련 법령 국내법은 대륙법 계통의 열거주의로 대다수 법에서 정하고 있기 때문에 서비스 기획 시 관련 법령을 먼저 찾아보는 것이 중요
산업 생태계 대기업이 아니고서야 산업 생태계를 담숨에 바꾸기 어렵기 때문에 산업 생태계를 살핌
경쟁사 경쟁사를 살펴보며 Pain Point를 분석하고, 관련 법령 및 타사 정책을 살피고 경쟁력 등을 확보
내부 환경 및 리소스 개발, 디자인 리소스 등

정책 결정이 중요한 이유

  • 같은 정책이라도 여러 경우의 수가 있어 손해를 보는 일이 발생하여 모든 경우의 수를 고려해야 하는 까다로운 작업
  • 운영 기준을 명료하게 정의해 놓아야 관리자가 여러 명이거나 담당 관리자가 바뀌더라도 고객에게 동일한 경험을 제공할 수 있음.

  • 어떤 지표를 측정하느냐에 따라서 어떤 개선을 이뤄낼 것인가 결정되므로, 수많은 데이터 중 적절한 지표를 설정하는 것은 기업 및 서비스 기획자에게 매우 중요한 일
  • 올바른 지표 설정과 추적을 위해서는 지표들을 잘 이해하고 지표를 통해 제품(서비스)의 요소들이 어떻게 작동하는지, 고객들이 제품에서 원하는 것이 무엇인지에 대한 전반적인 이해를 해야함.
  • 추측과 직감이 아닌 정확한 데이터를 통해 제품을 분석하고 올바른 방향을 설정해야함.

지표를 통해 알아야 할 것

  • 어떤 기능이 가장 인기 있는지, 자주 혹은 아예 이용되지 않는지를 이해해야 한다.
  • 사용자가 제품이 참여하는 방법을 알아야 한다.
  • 가입 후 얼마나 많은 유저가 다시 돌아오는지 확인해야한다.
  • 제품 내에서 고객 만족도를 측정한다.
  • 핵심 유저와 그 외 유저 집단을 식별한다.

좋은 지표

  • 상대적임. 어떤 지표를 놓고 시대별, 사용자 그룹별, 경쟁자별로 비교 가능 함.
  • 이해하기 쉬움. 구성원 모두가 지표를 기억하고, 대화를 나눌 수 없다면 지표를 바탕으로 행동을 할 수 없음.
  • 비율로 표현됨. 비율은 다소 대조적인 요소들이나 갈등이 있는 요소들을 비교하기 좋음.
  • 행동방식을 바꿈. 해당 지표의 변화를 위해 다음에 어떤 행동을 해야할지 알려줌.

지표 선택 시 염두해야 할 사항

  • 정성적 지표 / 정량적 지표
  • 허상 지표 / 실질 지표
  • 탐색 지표 / 보고 지표
  • 선행 지표 / 후행 지표
  • 상관 지표 / 인과 지표

핵심 지표 카테고리

  • 참여(Engagement) : 핵심 작업의 빈도와 주기
  • 수익(Revenue) : 발생 수익
  • 전환(Conversion) : 구매 유도, 가입, 폼 채우기, 등
  • 리텐선(Retention) : 재방문
  • 활동(Activation) : 유저의 첫 번째 가치 있는 활동 순간
  • 활성 유저(Active Usage) : 일, 주, 달, 년간 활성유저
  • NPS : 고객만족

인바디

선택한 이유

코로나 시대 이후로 사람들이 운동에 대한 관심이 많아졌다. 위험한 살상력까지 갖춘 바이러스로부터 몸을 지켜내고 보호하기 위함도 있겠지만 코로나로 여러 활동에 제약이 생겨나면서 즐길 수 있는 것들이 줄어들었다. 그런 지루함 속에서 운동, 바디프로필이 어떻게보면 새로운 놀잇거리로 생겨나게 되었다. 많은 관심들이 계속 이어지는 현 상황에서 국내 기업이 만들어낸 세계적인 체성분분석 기계인 인바디를 뜯어보고 싶었다.

 

기획

인바디를 통해 각자의 몸의 체중, 골격근량, 체지방량을 측정한다. 본인의 눈으로 몸의 변화를 볼 수도 있지만 대부분은 정확한 수치화로 된 데이터를 가지고 싶어한다. 인바디 어플은 인바디 기계로 측정한 데이터들을 측정 때 기계에 입력한 간단한 사용자 정보만으로 어플에 기록해준다. 어플을 통해 더 정확한 자신의 몸 변화를 파악할 수 있고, 목표 설정과 다른 사용자들의 점수들과 비교하면서 동기부여도 가질 수 있다. 

이렇게 어플을 통해 사용자들 본인의 데이터들을 기록하기 위해 인바디 기계와 어플을 계속 사용할테고, 이러한 경험들은 해당 서비스에 대한 충성도로 꾸준한 서비스 이용으로 이어질 것이다.

UX

인바디 기계를 통해 측정하면 모든 데이터들은 날짜 별로 기록되어있다. 그래프로 데이터들의 비교를 편리하게 볼 수 있으면 그 전 측정과의 비교로 얼마나 상승하고 하락했는지 보여준다. 여기서 중요한 점은 단순히 측정 된 값들만 보는게 아니라 사용자들 스스로 목표 설정과 가이드 생성을 하여 목표 달성에 대한 동기부여를 가질 수 있다. 이렇게 목표 달성과 데이터들의 비교를 통해 오프라인에서 운동이라는 활동이 온라인이라는 어플로 넘어와서도 사용자들이 계속 운동을 이어가고 있다는 것이다. 

또한 혼자만의 활동이 아니라 런바디/다이어리를 통해서 인바디에 다른 사용자들과 운동, 목표 등을 공유하면서 단체 활동도 할 수 있다는 것이다.

비즈니스 모델

인바디의 비즈니스 모델은 단순하고 직관적인 것 같다. 

운동에는 당연하게 식단 관리가 따라 올 수 밖에 없다. 그래서 운동 관련 뿐만 아니라 식단 관리로도 콘텐츠를 제공하면서 음식 쇼핑으로 구매를 유도한다. 운동에 필요한 기구와 옷들도 동일하다고 볼 수 있다.

또 런바디챌린지를 통해 운동 프로그램 상품을 판매하고 있다. 혼자서 운동에 대한 의지가 약하거나 운동 초심자들을 타겟으로 하였다.

그래도 무엇보다 핵심은 인바디를 측정하기 위한 인바디 기계이다. 작은 가정용으로도 판매하여 어디서나 쉽게 인바디를 접하고 경험할 수 있도록 되어있다.

스크럼 어원

  • 스크럼은 럭비용어인데, 모든 팀원들이 한 덩어리로 뭉쳐서 서로 공을 주거니 받거니 하며 함께 밀고나가는 럭비 경기와 같은 형태가 바람직하다고 느껴 스크럼이라는 용어가 쓰이게 됨.

스크럼이란?

  • 스크럼은 복잡한 제품을 개발하고, 유지하기 위한 프레임 워크
  • 비즈니스 요구를 충족시키는데 초점을 맞추기 위해, 작은 목표를 짦은 주기로 점진적이며 경험적으로 제품을 지속적으로 개발하는 관리 프레임워크

주요 특징

  • 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여하라.
  • 개발 주기는 1~4주 정도로 하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
  • 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
  • 매일 15분 정도의 회의를 가져라.
  • 항상 팀을 우선으로 생각하라.
  • 원활한 의사소통을 위하여, 구분없는 열린 공간과 마음을 유지하라.

스크럼 원칙

  • 투명성
    팀으로 일하는 환경에서는 다른 팀원이 겪을 수 있는 문제를 인지할 수 있다.
  • 반성
    팀 구성원이 진행 상황을 검토할 수 있도록, 자주 반성하게 되는 점이 프레임워크에 포함된다.
  • 적응
    팀원은 변화하는 고객 요구 사항에 따라 작업의 우선 순위를 조정할 수 있다.

스크럼 가치

  • 헌신
    스크럼 팀원은 시간이 정해진 작업과 목표에 전념하고 최상의 솔루션을 찾기 위해 지속적인 개선에 전념한다.
  • 용기
    스크럼 팀은 개방적이고 도전적인 질문을 함으로써 용기를 보여준다.
  • 집중
    팀원은 주어진 기간 동안 작업의 제품 백로그를 바탕으로 작업을 수행한다.
  • 열린 자세
    스크럼 팀원은 개별 학습과 전반적인 프로젝트 품질을 뒷받침하는 새로운 아이디어와 기회를 열린 자세로 수용한다.
  • 존중
    팀원은 프로젝트 관리자, 다른 팀원, 스크럼 프로세스를 존중한다.

스크럼 아티팩트

  • 제품 백로그
    제품 백로그는 프로젝트가 성공하기 위해 완수해야 하는 기능, 요구 사항, 개선 사항 및 수정 사항의 동적 목록
  • 스프린트 백로그
    스프린트 백로그는 개발 팀이 현재 스프린트 주기에서 완료해야 하는 항목의 목록
  • 증가분
    증가분은 목표 또는 비전의 실현에 한 발짝 다가가는 것

스크럼 이벤트

  • 스프린트 계획
    이 이벤트에서 팀은 다음 스프린트에서 완료되는 작업을 예측
  • 스프린트
    스프린트는 스크럼 팀이 함께 협력하여 증가분을 완성하는 실제 기간
  • 일일 스크럼 또는 스탠드업
    일일 스크럼은 팀원이 체크인하고 하루 업무를 계획하는 짧은 미팅
  • 스프린트 리뷰
    스프린트가 끝나면 팀은 비공식 세션을 위해 한자리에 모여 완료된 작업을 검토하고 이해 관계자에게 보여줌.
  • 스프린트 회고
    팀이 함께 모여 스프린트를 진행하는 동안 어떤 부분이 잘 되었고 어떤 부분이 잘 안 되었는지를 문서화하여 토론
 

애자일 방법론이란?

  • 최소 기능 제품을 빠르게 개발하여 유저들의 피드백을 받고, 해당 히드백을 바탕으로 지속적으로 개선해나가는 개발 방법론

애자일 방법론의 특징

  • 고객과 개발자의 지속적인 소통을 통하여 요구사항의 변화를 이행
  • 개발자 개인의 가치보다는 팀의 목적을 우선시 하며 고객의 의견을 가장 우선시
  • 주기적인 회의를 통한 프로텍트를 점검
  • 진행하면서 프로그램을 시행해보고 고객으로 부터 피드백
  • 비용절감에 힘쓰는 동시에 프로그램 품질 향상을 위한 노력

애자일 방법론의 가치

  • 공정과 도구보다 개인과 상호작용
  • 포괄적인 문서보다 작동하는 소프트웨어
  • 계약 협상보다 고객과의 협력
  • 계획을 따르기보다 변화에 대응하기

장점

  • 잘못된 제품을 개발하는데 사용하는 시간을 최소화
  • 더 자주 유저의 피드백을 얻을 수 있기 때문에 실패할 확률을 낮출 수 있음.
  • 계획 혹은 기능에 대한 수정과 변경에 유연하게 대처할 수 있음.

단점

  • 요구사항이 명확할 경우, 오히려 속도가 늦춰짐.
  • 최종 제품이 요구사항과 달라질 수 있음.
  • 고객에게 제공하는 가치에 집중하기 때문에, 기술적 완성도가 떨어짐.

+ Recent posts