스타트업 업무 용어 정리 1탄 - 업무 문화 편 (feat. 애자일, Jira, OKR..)

이직 후 오랜만에 블로깅입니다. 오늘은 스타트업 업무 용어에 대해 정리해보려 합니다. 

 

외국계 > 국내 스타트업으로의 이직썰은 팀블로그에서 풀었는데, 관심있다면 이것도 함께..  :)

🔗 2021.07.26 - [Vacation] - [서평] 외국계기업->스타트업 이직러에게 추천하는 "프로덕트 오너 (김성한 PO)"

 

 

저처럼 이제 막 IT 스타트업 / 제품 조직에 들어선 분들을 위해, 업무 문화를 이해하는 데 도움이 되는 용어를 정리해봤어요.
무엇보다도 실제 현재 재직 중인 회사에서 자주 들리는/쓰는 용어 위주로, 딱 5개를 뽑아 봤습니다.

각 설명에 대한 메인 출처는 아래의 [프로덕트 오너 by 김성한 ] 책과 제 작고 소중한 경험..입니다 :) 

 

프로덕트 오너 - YES24

 

---

 

1. WBR (Weekly Business Review, 주간 실적 분석)

 매주 진행하는 프로덕트 or 사업 지표 관련 보고 미팅!

• WBR 회의에서는 제품/사업 관련 주요 데이터를 보고하여, 집중해야할 부분을 파악하고 해결책을 논의한다. 
• 이에, WBR 회의 전에는 미리 WBR 문서를 만들어야 한다.
• WBR 문서에는 각 미팅에서 보고자 하는 지표가 일목요연하게 정리되어 있어야 한다.
  • ex) "프로덕트" 부서 ➡️ 주요 요점 (Key Call-Outs), 프로덕트 목표 (Product Goals),주요 지표 (Key Metrics) 
  • ex) "사업/영업" 부서 ➡️ 사업명, 고객사, 계약 일정, 수주금액, 사업 진행 현황, 이슈 사항 등

• 여기서 지표에 활용되는 데이터는 액셔너블(Actionable) 해야한다. 
  • 당장 액션을 취할 수 없는 문제라면, 보고 자체가 시간 낭비이므로 주의해야 한다. 

이와 스펠링만 비슷하게 생긴(?) "WBS (작업 명세 구조도, Work Breakdown Structure)"도 실무에서 정말 많이 쓰이는 용어이다. 프로젝트의 구성 요소를 항목 별로 잘게 쪼개어 일정과 담당자를 지정하고 진행 상황을 한 눈에 파악할 수 있도록 보여주는 문서이다. 실제로 프로덕트의 배포 일정도 이 문서를 통해 관리하고 있다. 

WBS의 예시 (출처: https://philosophiren.com/m/291)

 

2. OKR (Object & Key Results, 목표와 핵심 결과)

조직의 목표를 설정하고, 결과를 검증하는 방법론 

• 회사 > 각 부서> 개인 순으로 각각 OKR을 작성하면, 회사 전체의 목표와 직원 개개인의 목표를 맞추기에 효과적이다.
  • Objective: 매 분기마다 회사>부서>개인의 목표를 약 3개 정도 설정한다. (💡목표는 구체적인 액션이어야 한다!)
  • Key Results: 목표를 달성했는 지 확인하기 위한 핵심 결과를 수치화 한다. (💡수치로 검증할 수 있어야 한다!)
• 예를 들어, 조직의 OKR을 다음과 같이 설정할 수 있다. 
  • OB1: 000 서비스를 연내 성공적으로 출시한다.
    • KR1: 9월말까지 사내 CBT 오픈
    • KR2: 10월말까지 WOW 시나리오 3개 발굴하여 프로젝트화
    • KR1: 12월까지 고객사 10개 이상 유치

 

3. 신규 기능 출시를 위한 기획 문서 양식

제품 조직에서 "문서"를 다루는 일은 너무나도 중요하지만, 사실 아무도 방법론에 대해 제대로 알려주지 않는다. 물론 나는 아직 직접 기획 문서를 작성해 본 적은 없지만, 이 양식을 미리 알아두면 추후 도움이 될 것 같아서 정리해본다. 

• 보통 투-페이저(2-Pager)에서 쓰리-페이저(3-Pager) 내로 다음의 내용을 담아 작성한다. 
  • 목적(Objective): 2~3문장 내로 이 문서의 목적이 무엇이며, 어떤 내용을 다룰 것인 지 명확히 밝힌다.
  • 배경(Background): 반 장 내로 왜 이 신규 기능이 필요한 지에 대해, 진행상황-풀고자 하는 문제-앞으로의 방향성을 이해할 수 있도록 설명한다.
  • 고객을 위해 어떤 일을 하는가?: 각 고객이 왜 해당 기능을 '고용'할 지 짧고 명확하게 3~5개 항목을 나열한다.
  • 원칙(Guiding Principles): 기능 개발~출시의 모든 과정에서 의사결정의 잣대로 삼을 원칙을 중요도 순으로 나열한다. 
  • 목표(Goals): 새로운 기능을 선보일 경우, 어떤 목표를 달성할 지 수치화하여 2~3개 제시한다. 
  • 주요 지표(Key Metrics): 위의 목표(Goals)에 사용되는 지표를 포함하여, 기능이 고객을 위해 제대로 된 목적을 수행하고 있는 지 나타낼 수 있는 지표를 3~4가지 정도 선정한다. 
    • ex) DAU(일간 활성 유저수), MAU(월간 활성 유저수), CS(고객센터) 인입수 등
  • 개발 계획(Roadmap):  단계별 or 시기별 개발 계획을 나열한다.
    • 1단계(Phase 1) > 2단계(Phase2) >. 3단계(Phase3) 별로 어떤 기능이 개발되어야 하는 지 나열한다.
    • 단기(~1달) > 중장기 (~3달) > 장기 (~6개월) 시기 별로 무엇을 해야 하는 지 설명한다.
    • 💡 이 때, 개발팀의 검토를 받아 ETA(개발 완료 예정시간, Estimated Time of Arrival)과 상태도 표기한다.
      • 상태: Green(문제X) / Yellow (ETA까지 끝내기에 이슈가 있는 상태) / Red (ETA 내 완료 불가)
  • FAQ: 유관 부서에서 궁금해할만 한 것들을 미리 예측해서 답변을 적어 놓는다. 

 

4. Jira

개발자용 SW를 개발하는 호주의 아틀라시안(Atlassian) 사가 만든 프로젝트 관리 툴 (feat. 애자일 전문가, Trello, wiki..)

• 대부분 회사의 제품조직은 Jira를 이용하여 개발 진행 상황을 공유 및 관리하고 개발자<>기획자<>디자이너 간 협업하고 있다. 
• 기획자/PO가 이슈 티켓을 생성하여, 담당하는 개발자에게 할당하는 방식으로 업무를 진행한다.   

  

  Jira 이슈의 종류

   
• 이슈는 보통 에픽 > 스토리 > 태스크 순으로 세분화된다. 
  • 에픽(Epic): 주로 신규 프로덕트나 중요한 신규 기능을 개발할 때 큰 목표를 잡아주는 역할
    • 에픽 티켓 아래에 스토리 티켓을 다수 생성해서 관리하는 형태이다.
    • 모든 스토리 티켓과 태스크 티켓이 완료되었을 때, 에픽은 개발 완료 상태가 된다.
    • 에픽 티켓에 미리 작성한 기획 문서의 핵심 내용(목적, 개발 타당성, 목표, 주요 수치 등)을 기입해 놓지만, 비개발 유관 부서와의 커뮤니케이션을 위해 별도 문서(위 "3. 문서 양식"파트 참고)를 작성해 놓기도 한다. 
  • 스토리(Story): 에픽을 달성하기 위해 큼지막하게 분류하는 큰 기능
    • 개발자가 자신이 무엇을 구현해야 하는 지 명확히 이해할 수 있도록, 구체적인 개발 요구사항을 명시해야 한다.
    • 글로만 작성하기에는 한계가 있기 때문에, 별도 UX 흐름 문서나 디자인 시안 등을 링크/첨부파일로 추가한다.
    • ex) "사용자가 지도 상에서 현재 이동 중인 배달원의 위치를 확인할 수 있어야 한다." or "지도상에 실시간 배달원 위치 표시" 등
  • 태스크(Task): 하나의 스토리가 완료되기 위해 개발되어야 하는 것들을 더 잘게 나눈 형태
    
    • PO가 에픽과 스토리를 생성하고 나면, 이후 개발자가 기술적인 요구사항을 나눠서 태스크를 생성한다. 
    • 스토리에 연결된 모든 태스크 티켓이 완료되어야 하나의 스토리가 완료된다. 

"PO가 개발자에게 존중받는 가장 확실한 방식은 요구사항을 명확하게 전달하는 것임을 명심하라."

 

5. 애자일 개발 방법론 - 스크럼 & 스프린트 & 백로그

대부분의 스타트업에서는 애자일 방법론을 따르고 있다. 철저한 사전 계획을 바탕으로 완성된 산출물을 위해 개발을 진행하는 전통적인 폭포수 (Waterfull model) 방법론에서 벗어나, 신속한 반복 작업을 통해 중요한 요구사항부터 빠르게 개발하고 계속해서 새로운 요구사항을 수용하는 방법론이다.  

• 스크럼 (Scrum): 자체 결정권을 가진 소규모 조직이 업무 사이클을 유지할 수 있도록 주기적으로 짧게 가지는 회의 ( 💡애자일 방법론)
  
  • 개발자들이 매일 정해진 시간에 모여 어제 한 일 & 오늘 할 일 & 일을 수행함에 있어 장애요소에 대해 공유한다.
  • 개발이 늘어지거나 개발 후반부에 갑자기 큰 문제가 터지는 것을 방지하기 위함이지만, 매일 진행하는 만큼 이 회의 자체가 일이 되지 않도록 전체 15분~20분 정도로 짧고 간단하게 진행한다. 
• 백로그 (Backlog): 조직이 목표를 달성하기 위해 실행해야하는 태스크를 목록화 한 것.
  • PO는 매일 고객/유관 부서로부터 수많은 요구사항을 전달받는다. 이 요구사항에 대해서는 일단 태스크를 생성하여 보관해두는 데, 이것이 바로 백로그이다. 즉, 일종의 to-do-list이고, 이 백로그를 우선순위에 따라 각 스프린트에 할당하여 개발팀이 처리할 수 있도록 한다. (⬅️ 보통 개발팀 내 스크럼 마스터를 지정하여, 코칭과 스크럼 운영 역할을 맡긴다.)
• 스프린트 (Sprint): 1~4주 단위의 개발 사이클 (보통 2주) 
  • 스프린트 시작 전, 스프린트 계획 회의에서, PO, 스크럼 마스터, 개발팀이 함께 백로그 중 우선순위가 높은 아이템을 검토하고, 스프린트 목표를 설정한 후 개발에 착수한다.

 

---

오늘은 여기까지! 🎶

다음에는 단순히 업무 문화를 넘어서, 실제 업무 상황에서 자주 사용하는 앱/웹 기획관련 기술 용어를 다뤄보려 합니다.
아마 이런 것들이 되지 않을까요? (스포 쫘악) ➡️ 마크 다운, Webhook, 딥링크, 모달, IdP, LDAP, MDM, DRM ...