[0228_본캠프 8일차]

✔️ 3주차 내용 복습 및 정리

 

1. 제품팀이란?

 

제품을 만들기 위해 각자 다른 전문적인 능력을 갖춘 사람들이 모인 팀

디자이너는 스타트업에서 목적조직과 기능조직이 교차하는 매트릭스 조직으로 팀을 구성하기도 한다.

 

📌 제품팀을 구성하는 방법

• 제품팀을 구성하는 최소 조건 = 보통 1명의 제품관리자 (PO나 PM), 1명의 디자이너, 2명의 엔지니어
• 그 외에도 회사에 따라 제품팀에 데이터 애널리스트, 마케터, BO(Business Operator) 등이 포함될 수 있다.

 

 

 

2. 제품팀의 종류

<목적조직, 기능조직 그리고 매트릭스 조직>

왼쪽부터 목적조직, 기능조직, 매트릭스 조직

목적조직은 특정한 목적을 달성하기 위해 여러 직무의 사람들이 모인 팀
ex. 핀테크 회사라면 도메인별로 대출팀, 카드팀, 예/적금팀으로 나눌 수 있다


• 일반적으로 제품팀 = 목적조직
• 목적조직은 주로 스쿼드나 사일로라고 부른다
• 목적조직은 제품의 목표를 달성하기 위해 다양한 직무의 사람이 모여있는 팀이기 때문에 속도가 빠르고 효율적이라는 장점

 

기능조직은 유사한 직무끼리 구성된 팀
ex. 기획팀, 디자인팀, 개발팀 등이 여기에 속한다

• 일반적으로 많은 스타트업이 이 방식으로 일한다.
• 팀의 규모는 회사마다 다를 수 있지만 아마존 창업자 제프 베조스는 최대 16명을 넘지 않는 것을 추천

 

매트릭스 조직은 구성원이 기능조직과 목적조직이 교차된 형태로 소속된 구성
ex. 프로덕트 디자이너는 기능조직인 디자인팀에 속하면서 동시에 목적조직인 스쿼드에 속할 수 있다.

• 일반적으로 많은 스타트업이 이 방식으로 일한다.
• 팀의 규모는 회사마다 다를 수 있지만 아마존 창업자 제프 베조스는 최대 16명을 넘지 않는 것을 추천

 

 

 

3. 제품팀이 일하는 방식

a. 린스타트업

 

린스타트업은 빠르게 제품을 테스트하고 그 결과를 다시 제품에 반영하는 운영 방식

• 린스타트업은 불확실성이 높은 스타트업에서 제품을 효과적으로 개발하기 위해 고안된 전략
• 핵심 = 낭비를 줄이는 것, 적은 리소스로 제품을 만들어서 빠르게 시장에 검증해 가면서 기능을 고도화해 나가는 방법
• 린스타트업에서는 ‘만들기 → 측정 → 학습’을 반복하면서 피드백을 받고 사용자 중심으로 제품을 만드는 것을 중요하게 생각

 

 

b. 애자일

 

애자일은 제품을 만드는 방법론 중 하나 일정한 주기로 빠르게 제품을 배포해 사용자의 피드백을 받고 요구사항을 수정해 나가는 과정 반복

• 애자일(Agile)은 사전적으로 날렵한, 민첩한이라는 뜻
• 애자일한 제품팀은 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해 나가는 과정을 반복

 

 

 

<반대 의미인 폭포수(Waterfall) 방식과 비교하기>

폭포수 vs 애자일

 

폭포수 방식 (규모가 큰 대기업)

• 폭포가 떨어지는 것처럼 수직적으로 각 단계를 하나씩 단계를 진행
• 각 단계가 완벽하게 완성되었을 때만 다음 단계로 넘어가고 이전 단계로는 돌아가지 않음
• 요구사항 설계부터 디자인, 개발이 순서대로, 그리고 독립적으로 진행 • 단계별로 업무 분담이 명확하고 진행 상황 파악이 쉽다 • 하지만, 속도가 느리고 변화하는 상황에 유연하게 대처하기 어려움

 

애자일 방식 (스타트업)

• 1~4주의 스프린트 단위로 제품을 개발, 테스트하고 피드백을 받아 개선해 나가는 과정을 반복하는 것
• 수평적으로 일하면서 불필요한 의사결정을 줄이고 즉각적인 계획과 실행으로 피드백을 빠르게 반영
• 빠르게 변화하는 환경에 맞추어 기민하고 유연하게 대응할 수 있다는 것이 장점

 

 

 

4. 디자인 QA

 

QA : Quality Assurance의 약자로, 제품이 출시되기 전에 기능을 테스트하는 것

• 제품이 처음 기획한 대로 잘 구현이 되었는지, 회사에서 생각하는 품질 기준이 충족되었는지를 확인하는 과정
• 규모에 따라 별도로 QA 팀이 있기도 하고 제품팀에서 QA를 수행하기도 함
• QA 팀이 있더라도 기능을 만든 담당자라면 대부분 직접 QA를 한다

 

<QA 문서>

• 체크리스트(CL) : 예/아니요, 혹은 Pass/Fail로 답변할 수 있는 확인 성격의 항목을 나열한 목록
• 테스트 시나리오(TS) : 기획한 기능이 모두 제대로 동작하는지 확인하기 위해 작성하는 문서
• 테스트 케이스(TC) : 특정 조건에서 요구 사항을 충족하는지 확인하기 위해 여러 가지 케이스를 작성한 문서

 

 

 

디자인 QA : 디자인이 정확하게 개발되었는지 확인하는 절차 

<이슈 공유하기> #업무티켓

• 어디가 잘못되었는지 엔지니어가 정확하게 알 수 있도록 작성하는 것이 좋다
• 잘못 개발된 화면과, 원래의 디자인 화면을 기획 의도와 함께 전달하기
• 조직에 따라 다르지만 지라나 트렐로 같은 프로젝트 관리 툴을 사용한다면 관리하기 좋게 발견한 이슈를 업무 티켓 형태로 전달
하는 것을 추천!

 

 

 

<이슈의 중요도 정의하기>

 

LOWEST → LOW  → MEDIUM → HIGH→ HIGHEST
(왼쪽부터 점점 올라가는 중요도)