[23/11/13] 기획자가 알아야할 서비스 평가 지표 / '핀다' 개발팀이 스크럼, 코드리뷰 개선한 방법

이카루스·2023년 11월 12일
0

읽을거리

목록 보기
16/29
post-thumbnail

1.기획자가 알아야할 서비스 평가 지표

https://yozm.wishket.com/magazine/detail/2299/?utm_source=stibee&utm_medium=email&utm_campaign=newsletter_yozm&utm_content=contents

서비스를 평가하는 지표는?

서비스를 평가하는 지표는 크게 "제품", "마케팅", "비즈니스"로 나눠집니다.

제품 관련 지표

(1)DAU/WAU/MAU(Day/Week/Monthly Active Users)
:DAU는 지난 하루, WAU는 한 주, MAU는 한 달 동안 제품을 사용한 유저를 측정하는 지표입니다. 통상 서비스 내 트래픽과 영향력을 측정하는 지표로 사용되고 있으며, 현재 우리 서비스를 얼마나 많은 사용자가 이용하고 있는지 측정하기 위해 사용합니다.
(2) 리텐션(Retention)
: 사용자가 서비스를 지속적으로 이용하는 비율을 측정합니다. 서비스 유형에 따라 다른 기준을 적용합니다​​.
(3) NPS(Net Promoter Score)
: 고객 만족도와 충성도를 수치화합니다. 서비스 추천 가능성을 0점(전혀 없음)에서 10점(매우 높음)까지 점수화합니다​​. 이러한 NPS 계산법은 응답한 전체 고객 중 추천 고객 비율에서 비추천 고객비율을 빼면 됩니다.
(4) 전환율(CVR)
: 사용자가 원하는 행동을 수행하는 비율을 나타냅니다. ‘사용자가 목표 행위를 수행한 비율’을 측정하는 목적으로 사용됩니다. 예를 들어, 한 페이지에서 다른 페이지로 넘어가는 것과 같은 행동을 측정합니다​​.(CVR 계산법 = 전환수/클릭수 * 100%)
(5) 고착도
: 일일 활성 사용자(DAU)를 월간 활성 사용자(MAU)로 나눈 값으로, 사용자 충성도와 서비스 사용 빈도를 나타냅니다​​.
(6) 이탈률(Churn Rate)
: 고객이 서비스 사용을 중단하는 비율입니다. 고객 이탈의 원인을 이해하고 전략을 조정하는 데 도움이 됩니다​​.이처럼 이탈률은 서비스를 이용하는 유저가 어떤 목적을 가지고 있고, 어떤 행동을 취하고 싶은지 알아낼 수 있는 핵심 지표로 활용될 수 있습니다.

마케팅 관련 지표

(1) ROAS(Return On Advertising Spend) & ROI(Return On Investment)
: ROAS는 광고 캠페인의 효율성(광고비 대비 매출액을 통해 얼마나 많은 매출을 올렸는지)을, ROI는 투자의 전반적인 수익성(투자수익률로 투자한 비용 대비 이익금을 평가하는 지표)을 측정합니다​​
ROAS = (해당 광고로부터의 매출 / 광고 비용 ) * 100
ROI = 이익(매출 - 마케팅 비용) / 투자 비용
* 100
(2) CAC(Customer Acquisition Cost)
: 새로운 고객을 얻기 위해 들어가는 비용입니다. 마케팅 전략의 효율성을 이해하는 데 중요한 지표입니다​​. CAC = 신규 고객 획득과 관련된 전체 비용/신규 획득한 고객 수
(3) CAC 회수 기간
: CAC를 회수하는 데 필요한 시간을 나타냅니다. 고객 획득 전략의 재정적 건강성과 지속 가능성을 나타냅니다​​.
(4) LTV(Lifetime Value)
: 고객이 서비스나 제품을 사용하는 동안 가져다주는 총 이익을 나타냅니다​​.만약 우리 서비스의 LTV 지표가 높다면, 건강한 비즈니스 모델을 가지고 있다고 생각해 볼 수 있습니다.
LTV = 1/이탈률
*매출

비즈니스 관련 지표

(1) MRR(Monthly Recurring Revenue)
MRR은 월간 반복 매출로, 월간 구독 형태의 서비스를 제공하는 경우 비즈니스의 성장을 측정하는 기본 지표입니다. 주로 비즈니스 상태를 평가하는 지표로 활용되며, 만약 연간 구독 서비스를 제공하고 있다면 MRR을 12로 나누어 성장을 측정하는 경우도 있습니다.
(2) ARR(Annual Recurring Revenue)
ARR은 연간 반복 매출로 월간 구독 매출을 12배로 산출하거나, 전년도 대비 비즈니스 성장을 측정하는 지표입니다. ARR은 MRR과 다르게 전년도 대비 서비스가 성장하고 있는지를 평가하는 것이 중요한데요. 현재 매출이 전년 대비 상승했는지 평가하여, 서비스의 성장 가능성을 보여줄 수 있습니다.

2. '핀다' 개발팀이 스크럼, 코드리뷰 개선한 방법

https://yozm.wishket.com/magazine/detail/2295/?utm_source=stibee&utm_medium=email&utm_campaign=newsletter_yozm&utm_content=contents

1) 개발문화 필수 요소들

(1) 공유하고 신뢰하기

서로의 상황을 공유(이슈)
서로를 이해하며 신뢰 관계 유지
각자의 다양성을 존중하며 자율적으로 일하기
자연스러운 학습 및 Insight 발견 및 발전

(2) 공개하고 참여하기

수평적인 팀 구성원들과 동반자 관계로서 함께 만들기
모든 영역에서 팀 구성원들이 참여 및 의견을 낼 수 있는 분위기 조성(친해지기)
모든 정보를 팀 구성원에게 공개 및 방향성 공유(음지에서 양지로, 부족한 코드도 피드백으로 훌륭한 코드로 재탄생)

(3) 자극받고 성장하기

함께 성장할 수 있도록 주변에 긍정적인 영향으로 성장의 씨앗이 되는 부분을 응원 및 지지
서로 돕고 자극을 받아 팀 구성원 모두가 빠르게, 지속 가능한 성장 만들기

2) 핀다 프로젝트 팀의 변화

흐름

  • Item 선정 및 Design Document 작성
  • Tech Spec 작성(Jira Epic)
    -일정 논의 및 공수 산정(Jira Task, Story Point, Start Date, End Date, Work Log)
  • Daily Scrum(15 min)
  • 작업 진행(WorkLog 추가, Status 변경)
  • Code Review
    -작업 종료(Status 변경)
  • 회고, Backlog 기록(PT 별, 개발 그룹별)

장점

  • 전반적인 스프린트 진행상황 공유가 빠름
  • 회고를 통해 KPT 공유
  • Code Review를 통해 품질 향상
  • Problem 되풀이 가능성 Low

단점

  • Jira/Confluence 등 툴 사용성 High(처음은 귀찮아질 수도 있어요!)

Daily Scrum 변화
: 과거에는 아이스 브레이킹 시간이 있었지만, 현재는 몰입도 향상을 위해 이를 제거하고, Scrum Master가 회의를 진행합니다. 업무 진행 사항은 서면으로 공유하여 15분 규칙을 유지합니다.
Jira/Confluence 활용 강화
: 모든 팀원이 Jira 티켓을 통해 작업 상태와 일정을 투명하게 공유합니다. 이전에는 개발자 외 직군이 Jira를 잘 사용하지 않았지만, 현재는 널리 활용되고 있습니다.
코드 리뷰 및 테스트 강화
: 코드 리뷰를 의무화하고, 승인자가 있어야만 배포할 수 있는 규칙을 적용했습니다. 테스트 코드의 비율도 높이고 있으며, 목표는 70%입니다.
분야별 리뷰 및 회고
: 프론트엔드와 백엔드 팀은 별도로 회고를 진행하고, 다음 스프린트를 준비합니다.
레드퀸 효과 활용
: 기술적 탐색과 공유를 통해 팀 간의 건강한 성장을 유도합니다.
결과: Sprint 진행 상황 공유가 빨라지고, 코드 품질이 향상되었습니다. 또한 KPT(Kanban, Problem, Try)에서 문제의 반복 가능성을 최소화했습니다.

추가

데일리 Scrum

날 마다하는 짧은 회의를 뜻한다.매일 현재 상태를 업데이트하고 조율하는 것 을 의미한다.
다른 애자일 방법론인 XP에서는 스탠드업 미팅이라고 하는 것도 있다. 스탠드업 미팅에서는 회의를 서서하는 것이 필수적이다.

스프린트

계획,개발,리뷰 작업 등 최소 단위의 Cycle이다. 보통 1~4주 단위에서 선택

KPT 회고

Keep, Problem, Try의 약자로 회고 내용을 세 가지 관점으로 분류하여 회고를 진행한다는 것이 중요한 포인트이다. 이처럼 팀을 3개의 관점으로 나누면서, 회고를 진행하여, 꼼꼼하고 효율적인 회고가 이루어질 수 있게 된다. 짧은 시간에 모든 구성원의 생각을 공유하고, 실행가능하고 측정 가능한 액션을 도출해낸다. 액션은 다음 회고까지 실행하는 의견이다.
keep : 현재 만족하고 있는 부분, 계속 이어갔으면 하는 부분
problem : 불편하게 느끼는 부분, 개선이 필요하다고 생각되는 부분
TRY : Problem에 대한 해결책, 다음 회고 때 판별 가능한 것, 당장 실행가능한 것

레퍼런스

  1. https://medium.com/dtevangelist/scrum-dfc6523a3604
  2. https://gmlwjd9405.github.io/2018/06/01/agile-dailyscrum.html
profile
Der Schmerz, der mich nicht töten kann, macht mich nur stärker (나를 죽이지 못하는 고통은 나를 더 강하게 만든다)

0개의 댓글