PM => 다양한 부서와 협업
- 서버 개발자
- 프론트 개발자
- 앱 개발자
- QA엔지니어
- UX/UI 디자이너
- UX리서처
- UX라이터
- 마케터
- 데이터 분석가
- 세일즈
- CX매니저
- 서비스 운영자
- 법무팀, 개인정보보호팀
- 통번역가
ex) 서비스 운영자 -> 대기업의 경우, 따로 부서가 있지만 / 스타트업의 경우, PM이 겸직
+ 통번역가, 서비스 운영자 -> 요즘 트렌드는 AI를 이용하여 자동화시키는 추세
------------------------------------------------------------------------------------------------------------------------
본격적으로 어떻게 프로덕트가 만들어지는지에 대해서
" 애자일 이론편 " 에 관한 내용
1. 프로젝트 방법론이란?
- IT 회사에서 대부분의 업무는 프로젝트 업무와 운영성 업무로 나뉩니다.
- PM은 프로젝트 단위 업무와 운영 업무 모두 수행합니다.
업무 분류 예시
| 프로젝트 업무 | ✔️신규 기능 개발, 서비스 개선, 목표 달성 캠페인 등. |
| 운영 업무 | ✔️운영 및 유지보수, 데이터 분석, 마케팅, CX 관리 등 |
- 프로젝트는 기간, 예산, 목표 등이 정해져있고, 그 기간 동안 몰입해서 진행하기 때문에 성공 확률을 높이기 위해 다양한 방법론이 나와있습니다.
Q. 프로젝트 방법론을 알면 뭐가 좋나요?
- PM이 프로젝트 방법론을 알면 프로젝트를 성공 확률이 높아집니다.
- 공부 잘하는 친구들의 방법론을 공부하듯, 프로젝트를 성공적으로 완료시키기 위한 프로젝트 방법론도 다양합니다.
- 대표적인 프로젝트 방법론은 2가지 : 워터폴 & 애자일 방식
워터폴 & 애자일 방식 -> 서로 반대되는 방식 / 반대적인 관계에 있기 때문에 맨날 2개가 짝꿍처럼 따라붙는것
- 워터폴(Waterfall) : 폭포수처럼 각 단계가 끝난 후에 다음 단계로 진행하는 방식
- 애자일(Agile) : 짧은 주기로 작업을 반복하며 고객 중심의 반복적이고 점진적인 개발 방식
최소 기능 제품 (Minimum Viable Product,MVP)
- 최소 기능 제품 (Minimum Viable Product,MVP)은 “제품 개발 초기 단계에서 가장 기본적인 기능만 포함한 제품을 신속히 제작하여 시장에 출시하는 것”이에요
- PM은 MVP를 통해 제품 개발의 초점을 유지하고, 리소스를 효율적으로 사용하며, 시장과 고객의 요구에 빠르게 대응할 수 있어야해요
워너폴 방식 = 다음단계, 다음단계 거쳐서 맨마지막에 짠! 하고 산출물이 나오는것
애자일 방식 = 처음에는 작은 산출물, 계속해서 조금 더 발전된 산출물로 점진적으로 거듭하는것
즉, 애자일에서는 처음부터 목표를 달성을 함 / 처음부터 움직일 수 있는 최소한의 기능들이 작동을 하고있음
MVP를 만드는 이유 : 시장과 고객의 요구에 빠르게 대응하기 위해서!!!
워터폴 -> 자동차가 만들어지기까지의 과정에서 우리는 이미 수많은 리소스를 투입을 했는데,
고객반응이 안좋으면, 그만큼 긴 시간과 비용을 또 한 번 투자를 해야되는거잖아?
반면에 애자일은 빠르게 고객의 반응을 보고, 빠르게 반영할 수 있기 때문에 MVP 를 중요하게 여기는거다
< MVP >
" 빠르게 도전하고 빠르게 실패하고 빠르게 배우자 "
애자일하게 일할때는, MVP의 범위와 우선순위를 정하는 게 굉장히 중요하다!
1-pager
=> 전반적인 큰 그림을 그리는 역할을 하면서, 상세한 와이어 프레임은 그리지 않는것
일정 산정의 차이점
워터폴 -> 무조건 다음 단계가 끝나야 되니깐, 일정 데드라인이 딱 정해져있는데
애자일 -> 굉장히 가변적이기 때문에 데드라인이 유동적으로 변할 수 있다 -> 언제가 데드라인이야? 이런게 혼란스러울 수 있음
애자일 도입 -> 항상 상황을 cross check
기획이 다 끝난 상태에서 디자인 하는게 아니라, 어느정도 기획과 디자인이 중첩되면서 같이 논의를 하게되는 업무방식
디자인이 다 끝난 상태에서 개발이 시작되는게 아니라, 어느정도 디자인의 초안이 나왔을때
그걸보고 개발에서 의견을 주면서 서로 조율할 수 있음
따라서 애자일로 업무하면 -> 서로 다양한 직군들이랑 훨씬 소통할 일들이 많아짐
팀과의 의사소통에 굉장히 집중해야된다!!!!
(MVP 설정 시 다같이 논의하면서 설정해야된다)
만약, 정부에서 온라인 투표 시스템을 만들라고 시켰어
이건 명확하게 요구사항이 정해져있고, 계획이 명확하게 나와있고, 데드라인도 명확하게 나와있어
그래서 중간에 의뢰자의 요구사항이 변하거나 달라질 확률이 적어
예측 가능성이 있고, 안정성이 있어
-> 이럴때는 워터폴 방식이 유리하다
하지만 "고객"의 선택을 받아야하는 기업의 입장에서는
고객의 입장과 피드백을 실시간으로 고려해야되고, 고객 중심적이고 유연하게 만들어야될테니
이러한 요즘의 IT환경에서는 애자일 방식을 선택하는게 유리하다
애자일 방식 -> 굉장히 바뀌는게 많고, 가변적이기 때문에
뭐가 바뀌었지? 라는것을 계속해서 tracking 해줘야되기 때문에 관리하는게 복잡하고
애자일한 방식은 변동성이 높기 때문에 종합적이고 장기적인 계획을 세우기에는 어려울 수 있음
---------------------------------------------------------------------------------------------------------------
그렇다면 현업에서는 어떤식으로 애자일하게 일을 하는가?
Q. 스크럼이 뭔가요?
- 애자일의 원칙을 실천하는 방법 중 하나
- 팀이 협업하고 목표를 달성하기 위한 효율적인 관리 프레임워크
- 짧은 주기(스프린트)로 프로젝트 진행
- 스포츠 팀이 큰 시합을 준비하는 것과 유사 (럭비용어 / 럭비 스포츠 시작하기 전에 서로의 어깨를 맞대는 모습에서부터 유래된 표현이라고함)
- 스크럼은 스프린트 단위로 쪼개어서 진행됩니다.
- 스프린트는 스크럼의 반복적인 개발 주기에요. 일반적으로 1~4주 동안 진행해요.
- 게임에서 하나의 라운드라고 생각하면 쉬워요
100가지 중에서 10가지 선택
뽑힌 10가지 => 스프린트 백로그
나머지 90가지 => 프로덕트 백로그
여기에서 백로그는 to do list 라고 생각하면 편함
프로덕트 로드맵, 백로그를 만들고 우선순위를 관리함 (what과 why를 결정) -> 주로 PM이 수행
스크럼 마스터 -> 스크럼이 원활하게 진행되도록 이끄는 사람 -> 리더가 하기도 하고, 한명씩 돌아가며 번갈아가면서 맡기도함
(스크럼 마스터를 누가 맡는지는 회사마다/팀마다 다름)
(진행자가 따로 존재하지 않고, 참여자들이 동등하게 팀이 정한 방식으로 자발적으로 이야기하는 경우도 있음)
퍼실리테이션(Facilitation)은 집단 구성원들이 공동 목표를 달성할 수 있도록 소통, 협업, 의사결정 과정을 촉진하고 조력하는 활동
퍼실리테이션 역할을 진행할 진행자가 따로 없는 케이스도 있구나~~
팀 구성원들이 돌아가면서 주도를 하기도 하는구나~~
개발자들이 리드역할을 할 수도 있고, 스크럼 마스터가 진행을 도와줄 수도 있다
개발팀 (PM,개발,디자인) -> 다같이 How를 결정함 (어떻게 구현할것인지?) -> 여기에서 말하는 개발자는 코딩하는 사람 뿐만 아니라, 제품을 실제로 "구현"을 하는 모든사람을 일컫어 개발자라고 말하고있음
애자일이란
고객의 요구사항은 빈번하게 변경됩니다. 이에 민첩하게 대응하도록 프로젝트를 일정 단위로 쪼개어, 매 단위마다 결과물을 도출하는 프로세스입니다. 서비스의 요구사항 변경이 잦은 IT 업계에서 자주 쓰입니다. 이 때 주의할 사항은, 애자일은 단순히 빠르게 결과물을 도출하는 것이 아니라는 점입니다. “좋은 제품을 낭비 없이 빠르게 만들기” 위해 제품의 핵심 기능만 구현하며 우선순위가 낮은 기능들은 고려 대상에서 배제하거나 별도의 일정에서 개발합니다.
KEY POINT -> MVP의 범위를 제대로 설정해야된다!!!!!
스크럼이란
프로젝트를 애자일하게 운영하기 위한 방법론 중 하나입니다. 참고로, 애자일 개발 프로세스는 다양한 방법론 전체를 일컬으며, 스크럼(Scrum) 외에도 칸반 프로세스(Kanban), 익스트림 프로그래밍(XP) 등이 있습니다.
스크럼팀 멤버구성 -> 보통 7명
적정인원수가 정해져있다고함 / 피자 1판 (7조각 정도) 나눠먹을 수 있는 멤버수
스프린트(=Sprint)
말 그대로 목표를 향해 ‘전력 질주’하는 기간입니다. 통상적으로 2주를 잡습니다.
백로그(=backlog)
- 제품의 백로그 : 제품(예. 입고 서비스)에 부여되는 큰 과제들, 운영 이슈등입니다. PO는 주기적으로 backlog의 우선 순위를 조정합니다.
- 스프린트 백로그 : 해당 스프린트 내에 진행할 작업 목록입니다. 제품 백로그와 마찬가지로 우선 순위가 높은 순 ~ 낮은 순으로 나열됩니다.
Sprint Planning - 30분
스토리 리뷰 때 backlog에 추가된 티켓을 우선순위에 맞게 Sprint에 추가합니다. 한 스프린트 동안 완료할 스토리 포인트 목표치를 세우는 것이 중요한데요.
팀원 각자의 휴가 일정과 이전 스프린트의 스토리 포인트 완료 수치를 근거로 본 스프린트의 목표를 설정합니다.
-> 숫자를 정해놓음 (그 숫자가 목표치를 수치화한것)
예를 들어 팀원 한명이 하루 휴가 일정이 있는 경우, 목표를 낮게 설정합니다. 또한 이전 스프린트에서 목표한 스토리포인트 수치가 45였는데, 일정이 남아서 50을 해결했을 경우, 이번 스프린트에서는 47 정도로 팀의 목표를 높게 잡을 수도 있습니다.
Kurly에서 작성한 글 참고하기
“어떻게 하면 데일리 스크럼을 최악의 이벤트로 만들 수 있을까요?”
- 특정 이슈에 대해 데일리 스크럼 자리에서 토론을 하다가 길어지고, 결국에는 결론을 내지 못하고 “나중에 따로 이야기 해요.”가 된다.
- 상급자에게 숙제 검사 맡는 느낌이 들도록 진행한다.
- 이야기를 늘 길게 하는 사람이 많거나 일상적인 업무 보고가 반복된다.
- 일방적으로 업무를 전파한다.
- 잘못된 일에 대한 책임 소재를 파악한다.
- 데일리 스크럼을 왜 해야 하는지 모르는 상태에서 하는 경우
- 너무 무겁고 경직된 분위기
- 연속되는 업무적 부담이 있는 경우
- 참여자들이 공감할만한 목표가 없고, 일의 우선순위가 모호하다.
굉장히 빠르게 스크럼을 끝내기 위해서
"플랭크"를 하면서 스크럼을 하는 경우도 있음;;;;; 미팅 20분 넘어가면 사람 죽겠네
보고하는게 아니라, 우리는 함께 작전을 짜는거다!!! 라는 마인드로 스크럼에 참여할것
고객 VOC = 고객 VOC(Voice of Customer)는 고객의 소리라는 뜻
ASIS = 현재상태
TOBE = 개선된 미래 상태
꼭 달성해야 하는 지표(=목표 지표)
해당 과제로 인해 떨어지면 안 되는 지표(=가드레일 지표)
반드시 달성해야 하는 것은 아니지만 살펴보면 좋은 지표(=모니터링 지표)
목표지표, 모니터링 지표 뿐만 아니라 "가드레일 지표" 에서도 유의미한 성과를 거둬야함
- 스크럼이 매우 대표적이지만, 칸반(Kanban) 방식도 있습니다
- 스프린트와 같은 주기 없이 칸반 보드에 ’To Do', 'In Progress', 'Done'으로 작업 단계별로 관리해서 시각화합니다
- 지속적인 흐름 관리가 중요하거나, 자주 우선순위가 변경되거나, 유지/운영 보수 관련 업무에서는 칸반을 사용하기도 합니다
-> TO DO / IN PROGRESS / IN QA / DONE 으로 나눠서
- JIRA란?
- 주로 애자일 개발 프로세스(스크럼, 칸반 등)를 지원하는 프로젝트 관리 툴
- 작업 추적, 우선순위 관리, 팀 협업을 돕는 다양한 기능을 제공
프로젝트(Project)
프로젝트는 말그대로 JIRA에서 프로젝트 단위로 이슈를 관리하는 공간입니다. 각 프로젝트마다 독립된 설정값을 따르며 이슈카드의 ID도 다른 형태로 생성됩니다. 스포카에서는 제품단위로 나뉘기도 하고 제품개발이 아닌 업무별로 나누어서 관리하기도 합니다.
보드(Board)
프로젝트내에 여러개의 보드를 운영할 수 있습니다. JIRA에서는 스크럼과 칸반 2개의 보드 스타일을 제공합니다.
칸반
칸반형태로 보드를 생성한다면 아래 그림과 같이 메뉴에 Kanban board가 나타나게 되며 칸반형태로 이슈를 관리할 수 있도록 합니다. 칸반보드를 보면 생성된 이슈들을 칸반보드 형태로 나타나 있는 것을 볼 수 있습니다.
스크럼
스크럼 형태로 보드를 생성한다면 아래 그림과 같이 메뉴에 Backlog와 Active sprints가 나타나게 됩니다.
Backlog
백로그는 보드 내 현재 생성되어 있는 모든 이슈카드 목록을 보여줍니다. 현재 진행중인 스프린트와 앞으로 진행할 스프린트 그리고 백로그들을 보여주기 때문에 다음 스프린트 계획 시 활용하면 좋습니다.
Active sprints
Active sprints는 말그대로 현재 진행중인 스프린트내 이슈들만 볼 수 있는 화면입니다. 백로그와 달리 칸반형태로 표시하기 때문에 각 이슈의 진행상황을 파악하기에 용이합니다.
이슈(Issue)
보드 내 생성된 작업들을 이슈라고 합니다. 이슈는 여러가지 타입이 있으며 도도카트에서는 크게 Epic, Story, Task, Bug, Sub-Task를 기본적으로 사용합니다.
에픽(Epic)
에픽이란 여러번의 스프린트를 거쳐 완료되는 정도의 작업량을 가진 업무를 말합니다. 에픽의 범위는 회사마다 이슈관리 도구마다 다르게 정의할 수 있지만 도도카트팀에서는 스토리들을 묶은 상위 개념의 기능을 의미합니다. 에픽에서는 기능에 대한 정의만하지 상세한 기술은 스토리를 통해 설명합니다.
스토리(Story)
스토리는 비지니스 가치를 제공하는 최소 단위의 요구사항을 말합니다. 보통 사용자 입장에서 필요한 내용을 일상적인 언어로 기술합니다. 하나의 에픽에 여러개의 스토리가 있을 수 있습니다.
태스크(Task)
태스크는 하나의 스토리를 완성하기 위한 구체적인 작업들을 나타냅니다. 하나의 스토리에 여러개의 태스크가 있을 수 있습니다. 태스트 구성요소는 아래와 같습니다.
- 디자인
- 기술검토
- 개발
- 문서화
버그(Bug)
버그는 주로 QA 시 요구사항을 충족하지 못하는 경우나 운영 중 발생한 이슈를 리포팅하기 위한 용도로 사용됩니다.
서브 태스크(Sub-task)
서브 태스크는 하나의 태스크를 여러개의 세부작업으로 나눌 필요가 있는 경우 태스크의 하위 작업의 용도로 사용합니다.
컴포넌트(Component)
컴포넌트는 에픽 또는 이슈들을 묶어주는 단위로써 해당 이슈의 목표점 또는 특징을 나타냅니다.
스토리 링크 설정
생성된 태스크와 관련한 스토리를 링크합니다. (에픽이 없거나 관련된 스토리가 없는 태스크의 경우 링크하지 않습니다.)
Jira에서는 스토리와 Task가 동일한 작업레벨을 가집니다. (서브 태스크가 있긴 하지만 서브 태스크를 이용하여 작업관리를 하는 경우 작업 Estimate에 대한 리포팅이 제대로 되지 않는 등 불편한 점들이 많아 태스크로 작업 관리를 하는 것을 추천합니다.)
그래서 태스크가 특정 스토리와 관련이 있다는 것을 알 수 있도록 하기 위해서 링크를 걸어줍니다. 링크를 걸어주는 작업이 다소 번거로울 수 있지만 이슈 추적에 매우 도움이 되니 링크를 걸어주는 것을 추천합니다.
Estimate 설정
Original estimate를 설정하여 예상되는 작업 일정을 기입합니다.
-> 시작일과 종료일을 입력하면 타임라인 형태로도 볼 수 있음
