오늘의 목표는 프로젝트 매니지먼트 개론 완강, 피그마 2주차 수강이다.
2일차도 아자스!!
[chater 2]
- 스크럼: 애자일의 원칙을 실천하는 방법 중 하나
- 팀이 협업하고 목표를 달성하기 위한 효율적인 관리 프레임워크
- 짧은 주기(스프린트)로 프로젝트 진행
- 스포츠 팀이 큰 시합을 준비하는 것과 유사, 게임에서 하나의 라운드
- 스크럼에서 사용되는 주요 용어
- 스프린트: 말 그대로 목표를 향해 전력 질주하는 기간. 통상적으로 2주를 잡는다. 스프린트 기간 동안에는 다른 이슈는 우선 순위를 낮추고, Sprint에서 제시된 목표 달성만을 위해 팀원 전체가 기여한다.
- 백로그:
- 제품의 백로그 : 제품(예. 입고 서비스)에 부여되는 큰 과제들, 운영 이슈 등. PO는 주기적으로 backlog의 우선 순위를 조정한다.
- 스프린트 백로그 : 해당 스프린트 내에 진행할 작업 목록. 제품 백로그와 마찬가지로 우선 순위가 높은 순 ~ 낮은 순으로 나열된다.
- 스토리 리뷰 시 사용 언어: 에픽, 스토리, 스토리 포인트 -> 회사마다 정해진 난이도로 측정
- 에픽: 팀 내의 큰 목표. 크게 신규 프로젝트, 기존 기능 개선 및 버그 수정 두가지로 나뉜다.
- 스토리: 에픽 내에는 요구사항이 여러 개 있다. 요구사항 하나를 스토리라고 한다.
- 스토리 포인트: 작업의 난이도, 피보나치 수열을 기준으로 1,2,3,5,8,13 중 고를 수 있다.
- 스프린트 기간이 짧아도 장단점이 존재한다. 즉 조직 전체가 하나의 일률적인 스프린트 기간을 따르기 보다는, 자기조직화 된 팀이 팀의 정황을 고려해서 가장 적합한 기간을 선택할 수 있어야 한다.
스크럼을 진행함으로써 개인별로 하루의 계획을 세울 수 있고, 앞으로의 진행 방향을 공유하며 더 나은 프로덕트를 생산할 수 있을 것 같다.
그러나 마지막 아티클을 읽어보면서 무작정 고객의 피드백을 듣고 백로그에 넣는다고 해서 좋은 것은 아니다.
백로그에 넣었다는 것은 그것을 언젠가는 해결해야하는 법. 즉 치우거나 해결하거나 이다.
모든 백로그가 단순하게 치워버려야 할 짐덩이는 아니므로 이중에는 반드시 짚고 넘어가야 할 중요한 것들도 있을 수 있음.
즉, 백로그 정리가 쉽지는 않겠지만 그것을 고르는 기준 또한 중요할 것임.
좋은 스크럼 시간에는 편안한 환경 조성이 필수.
- JIRA에서 사용되는 용어
- 프로젝트: JIRA에서 프로젝트 단위로 이슈를 관리하는 공간
- 보드:
- 칸반: 생성된 이슈들을 칸반보드 형태로 나타나 있는 것을 볼 수 있다.
- 스크럼 형태로 보드를 생성한다면 Backlog와 Active sprints 둘 중 하나로 나타난다.
- 이슈: 보드 내 생성된 작업들
- 에픽: 여러번의 스프린트를 거쳐 완료되는 정도의 작업량을 가진 업무.
- 스토리: 비지니스 가치를 제공하는 최소 단위의 요구사항(하나의 에픽에 여러개의 스토리가 있을 수 있음.)
- 태스크: 하나의 스토리를 완성하기 위한 구체적인 작업들(하나의 스토리에 여러개의 태스크 가능), 구성요소는 디자인, 기술검토, 개발, 문서화 등
- 버그: 주로 QA 시 요구사항을 충족하지 못하는 경우나 운영 중 발생한 이슈를 리포팅하기 위한 용도로 사용
- 서브 태스크: 하나의 태스크를 여러개의 세부작업으로 나눌 필요가 있는 경우 태스크의 하위 작업의 용도로 사용
- 이 단계는 회사마다 규정이 다를 수 있음.
- 컴포넌트: 에픽 또는 이슈들을 묶어주는 단위로써 해당 이슈의 목표점 또는 특징
애자일 원칙을 가장 잘 실현할 수 있는 것은 스크럼.
이 스크럼을 하기 위해서는 jira를 많이 사용하니 실무에서 어떻게 사용하는지 잘 복습해둘 것.
- 프로덕트 개발 과정
- 기획: 목표수립 → 문제정의 → 해결안도출 → 문서화 → 이해관계자 파악
- 여유 있는 일정 산정할 것
- 잘 작성된 문서는 가치 높은 자산: 아이디어 회의록 → PRD요구사항 문서 → (필요시) 실험 문서 → 테크 스펙 문서 → QA문서 → 회고록
- 결국은 심리적 안정감: 협업을 성공적으로 이끌기 위해선 구성원들이 직군에 상관 없이 편하게 또 치열하게 아이디어를 발산할 수 있는 환경에서 나온다.
- 디자인: 기획안을 바탕으로 디자이너가 UI/UX를 디자인한다.
- 이때 PM은 기획 내용 공유 → 디자인 이슈 해결 → 디자인 일정 관리 → UX리서치 진행
- 디자이너가 프로토타입을 설계하면 사용성 테스트를 진행하여 최종 결정
- 개발: 개발자가 기획,디자인을 바탕으로 프로덕트를 개발
- 이때 PM은 기획 공유 → 개발 이슈 해결 → 개발 일정 관리 진행
- QA: 지금까지 개발한 것을 개발 환경에 배포, 사용해도 문제가 없는지 품질을 테스트
- 이때 PM은 QA 계획 수립 → QA진행 → QA 일정 관리 → 버그 리포트 관리
- 출시(릴리즈): 예정된 날짜와 시간에 모든 사용자가 사용할수 있도록 기능을 오픈
- 이때 PM은 출시 모니터링 → 사용자 반응 분석 진행
- 기획: 목표수립 → 문제정의 → 해결안도출 → 문서화 → 이해관계자 파악
잘 작성된 문서가 중요시 되고 있다. 모든 것의 시작은 기획부터!
[chater 3]
- 이번 챕터에서는 내가 PM이 되고 싶은 이유에 대해서 다시 한번 생각해보게 되었다. 내가 기대하는 모습과 실제 모습이 다를 수 있으며 그것의 간극을 줄이기 위해 많은 노력이 필요할 것 같다는 생각이 들었다.
- 실제로 PM은 서비스를 기획 하기도 하지만 그만큼 서비스를 종료하기도 한다. 서비스 종료에서도 많은 배울 점들이 있고 하나의 과정이기에 막 속상하고 그럴 필요는 없다고 한다. 다음 서비스에서 더 성장한 모습을 보이는 것이 중요.
- 또한 내가 사용자가 아닌 제품을 담당했을 때 그 대상에 대한 경험, 관심이 없어서 사용자의 니즈를 상상하기 어려울 수 있다. 이때는 무조건 직접 사용자가 되어 많이 써보거나 UX리서치(사용자 인터뷰, 설문조사 등)가 필수다. 직접 현장에 나가서 사용자를 직접 만나며 더욱 적극성을 발휘해야 제품을 성공시킬 수 있다. 또한 고객과 가장 자주 만나는 회사 내부 전문가에게 배우거나 온라인 SNS 분석을 실시할 것.
어느 서비스든 사용자 분석이 제일 중요하다는 점. 잊지말기. 직접 되어보는 용기 가지기.
- PM은 조직 구조나 규모에 따라 하는 일의 범위가 다르다. 즉 팀에서 기대하는 역할과 어긋나면 실망으로 이어질 수 있다. 이때는 내가 담당한 제품, 팀에서 내가 어떤 역할 범위를 가져갈지를 스스로 잘 정의할 수 있어야 한다.
- 시장 상황이 바뀌면서 최상위 목표가 수시로 바뀌고, 직무별로 우선시하는 우선순위의 기준이 다를 수 있다. 이때는 제품의 방향상을 기반으로 우선순위 기준에 대해서 팀 내 합의한 후 애자일 방식으로 움직여야한다. 또한 심리적으로 계속 바뀌는게 당연하다는 마인드 세팅은 필수.
PM하면서 문제와 어려움이 발생한다면 제일 먼저 마인드 세팅이 필수. 또한 스스로 정의를 내리고 합의 도출 해볼 것.
- 커뮤니케이션의 기본
- 부트캠프 내 팀활동에서 주도적으로 리딩해볼 것 → 팀 활동은 팀원들이 비슷한 출발선에서 시작하며, 실패해도 부담이 적다. 그러나 회사는 내가 연차가 적다면 제일 경험이 부족하며 실패 시 매출 손시, 유저 이탈 가능 등 부담이 커진다. 즉 팀 활동에서의 시행착오가 실제 회사에 들어갔을 때 실수를 줄여줄 수 있고, 체계적인 협업 하는데 도움이 될 수 있기에 스스로 주도적으로 리딩해보는 경험을 많이 쌓을 것.
- 커뮤니케이션에서 오류가 생긴다면, 그 이유는 각자 알고 있는 정보가 다르거나, 각자 원하는 목표가 다른 것이다. → 이럴 때 이제 크로스체크는 당연시, 또한 상대방의 니즈를 파악할 것.
- 커뮤니케이션 원칙
- 상대방의 니즈 파악: 상대방이 어떻게 생각할지, 무엇을 원하는지 알아볼 것 → 상대방이 듣고 싶은 방식으로 이야기 할 것 → 상대방의 언어로 말할 것(이해하기 쉽게)
- 빌드업: 결정을 통보하는 것이 아니라 사전에 정보를 공유하고 논리를 쌓아가며 자연스럽게 동의하게 만들 것.
- 상대방이 이해하고 납득할 수 있는 논리적 근거를 함께 제공 → 갑작스러운 통보가 아니라, 사전에 과정을 공유할 것 → 사람들이 '내가 참여했다'고 느낄 때 더 적극적으로 협업한다는 특성 이용할 것.
- 상대방에게도 미리 마음의 준비 과정이 필요하다는 점 기억할 것.
- 크로스체크: 내가 전달한 정보가 그대로 받아들여졌는지 확인하는 과정
- 구두로 합의한 직후 (저는 이렇게 이해했는데 맞을까요?) 식으로 체크
- 업무 지식/요청 후 (지금 이해한 대로 설명해줄 수 있을까요?) 식으로 체크
- 중요한 결정/정보 공유 후 (다시 한번 정리해서 문서로 공유할게요!) 식으로 체크
적절한 시점에 적절한 사람에게 진행 상황 공유할 것.
(상대방이 듣고 싶은 or 필요로 하는 정보 위주로)
요청 시 요청의 맥락을 설명해야하며, 갑자기 말고 사전에 미리 공유해둘 것.
요청을 받았을 때에도 요청 자체보다 근본적인 문제나 목표를 파악할 것.
→ 거절 시 현재 내 상황을 설명하고 가능한 대안이나 차선책을 함께 제시하여 상대방과의 관계를 유지시켜야함.
거절도 잘 할 수 있어야함. 내 할일을 파악하고 우선순위를 고려하여 요청을 받아들이거나 거절할 수 있어야함.
상대방 설득 시, 상대방의 입장을 충분히 이해한 후 '이득을 본다'는 느낌을 줄 것.
설득도 한번에 하는 것이 아니라 단계적으로 공감대를 형성하며 실시할 것.
프로젝트 매니지먼트 완강 !!!
피그마
[chapter 2]
- 프레임과 그룹
- 프레임: 피그마에서 코드 블록을 만드는 기능이자, 실제 화면으로 인식하는 개체, 코드 블록을 만드는 기능이고, 실제 코드로 바꿀 수 있는 개체
- 그룹: 여러 개체를 하나로 묶어주는 기능, 편집이나 조정이 필요할 때, 또는 편의를 위해 여러 개체를 하나로 담는 기능
- 레이어 관계
- 부모-자식 관계: 감싸고 있는 것과 감싸진 것의 관계
- 정렬: 테이너 안의 개체들을 정렬하고 배치하는 방법
- 단일 개체만 정렬하는 경우 부모 컨테이너를 기준으로 위치가 정해진다.
- 여러 개체를 정렬하는 경우, 기준점에 가장 가까이에 있는 개체를 기준으로 정렬된다.
개체 복제: windows → ctrl + d
- 균등분배(...): 정리하기(선택된 개체들을 가로 세로를 딱 맞춰서 정렬), 수직 간격(세로 간격을 균일하게), 수평 간격(가로 간격을 균일하게)
- 오토레이아웃: 레이어를 쌓고, 프레임을 배치하고 정렬하는 피그마의 핵심 기능, 레이아웃에 유연함을 만들어줌.
- 코드 블록의 구조 -
- 패딩(Padding): 코드 블록 안에 있는 개체와 함께 실제 블록의 사이즈가 되는 내부 여백
- 보더(Border): 코드 블록 내부 공간 바로 바깥의 가장자리. 실제 코드 블록의 테두리
- 마진(Margin): 코드 블록 바깥의 여백이자 다른 코드 블록과의 간격
- 이 코드 블록은 피그마에선 프레임으로 만들 수 있다.
- 다른 말로 컨테이너라고 부른다.
- 모든 코드 블록은 내부에 들어있는 개체와, 개체를 둘러싼 패딩(내부 여백)으로 만들어진다.
- 오토레이아웃은 개체를 패딩으로 감싸 컨테이너를 만들 때 사용한다.
- 오토레이아웃의 활용: 오토레이아웃은 컨테이너를 간격에 맞게 규칙적으로 정렬해주는 기능도 수행, 이 컨테이너들을 여러 개 쌓을 때, 얼마만큼의 간격으로 몇 개를 쌓을 건지를 오토레이아웃으로 편하게 만들어 낼 수 있다.
- 오토레이아웃의 정렬 방향: 오토레이아웃 안에 있는 프레임을 어떤 방향으로 쌓을 지를 정함. (세로: 수직 방향으로 쌓기 // 가로: 수평 방향으로 쌓기 // 감싸기: 수평 방향으로 쌓다가, 일정 위치부터는 다음 줄에 쌓기)
- 정렬 위치: 오토레이아웃의 사이즈가 변할 때, 안에 있는 프레임들이 어디를 기준으로 정렬되는 지 정함.
- 오토레이아웃 해제: 오토레이아웃 속성을 제거. 오토레이아웃이 아닌 일반 프레임으로 변경.
- 고급 옵션: 오토레이아웃의 고급 속성을 설정.
- 간격: 오토레이아웃 안에 프레임이 여러개 있을 때, 이 프레임 사이의 간격.
- 좌우 패딩: 오토레이아웃의 좌우 여백값.
- 상하 패딩: 오토레이아웃의 상하 여백값.
- 패딩 개별 조정하기: 상하좌우 패딩을 각각 따로 설정.
- 프레임 밖으로 넘친 부분을 보이지 않게 가릴 수 있음.
- 프레임 크기를 내부 콘텐츠에 딱 맞게 맞춤.
- 프레임과 컨스트레인트
- 컨스트레인트: 제약, 제한이라는 뜻, 오토레이아웃 안에 있는 개체들이 움직이는 방식을 제한한다는 뜻
- 부모 컨테이너와 자식 컨테이너를 만들고 자식 컨테이너를 눌렀을 때 파란색 점선 이 나타나는데 이것이 컨스트레인트이다. 즉 자식 컨테이너가 부모에 고정되어 움직이는 일종의 핀 위치이다. → 기본으로 왼쪽과 위쪽으로 나오는데 이것은 자식 컨테이너는 부모 컨테이너의 사이즈가 변할 때 왼쪽과 위쪽이 고정된채 따라간다는 의미이다.
1. 컨스트레인트 조건을 바로 선택 가능: 하이라이트되는 부분을 누르면 그 부분에 맞는 컨스트레인트 조건이 바로 적용됨.
2. 가로 방향의 컨스트레인트 조건을 선택 가능:
| Left | 부모의 왼쪽 가장자리를 기준으로 고정 |
| Right | 부모의 오른쪽 가장자리를 기준으로 고정 |
| Left and right | 부모의 왼쪽 가장자리와 오른쪽 가장자리 모두 기준으로 고정 |
| Center | 부모 길이의 중간을 기준으로 고정 |
| Scale | 부모 길이에 비례해서 |
3. 세로 방향의 컨스트레인트 조건을 선택 가능:
| Top | 부모의 위쪽 가장자리를 기준으로 고정 |
| Bottom | 부모의 아래쪽 가장자리를 기준으로 고정 |
| Top and bottom | 부모의 위쪽 가장자리와 아래쪽 가장자리 모두 기준으로 고정 |
| Center | 부모 높이의 중간을 기준으로 고정 |
| Scale | 부모 높이에 비례해서 |
- 프레임 리사이징: 프레임은 기본적으로 가로와 세로 길이가 고정
Fixed 고정값 공통 Hug 자식 컨테이너의 크기에 맞춰 조정 부모만 쓸 수 있음 Fill 부모 컨테이너의 크기에 맞춰 조정 자식만 쓸 수 있음 - 리사이징 관계 정리
- 자식이 고정값(fixed)이라면, 부모는 그걸 감싼다.(hug).
- 자식이 부모에 맞게 쭉 늘어나야 한다면(fill), 부모는 고정값으로 멈춰야 한다.(fixed).
- 반대로, 부모가 자식을 감싸기로 한다면(hug), 자식 사이즈는 고정되어야 한다.(fixed).
- 부모와 자식 둘 다 고정일 수도 있다.
- 리사이징과 움직임
- 보이는 디자인 결과물에는 차이가 없을 수 있지만, 부모와 자식의 리사이징 관계에 따라 실제로 변하는 부분들이 달라짐.
- 오토레이아웃 컨테이너를 여러개 쌓기 시작하면 리사이징을 꼼꼼하게 신경써야 동적으로 변하는 레이아웃을 설계 가능.
자식 컨테이너의 리사이징 값이 fixed인지 꼭 확인하고 진행할 것.
자식 컨테이너의 리사이징 값이 바뀌면 부모 컨테이너의 리사이징 값도 자동으로 바뀜.
→ 자식 컨테이너는 부모 컨테이너 안의 영역을 꽉 채우는 값(fill)으로 되어 있기 때문에, 부모 컨테이너의 길이에 따라 유동적으로 변한다.
- 포지션: 요소의 위치를 고정하거나 스크롤에 따른 위치를 조정할 때, 개발에서 포지션이라는 속성을 조정해서 만든다.
- Static(스태틱): 일반적인 요소들이 가지고 있는 포지션, 기본값이자 스크롤을 하면 같이 따라 같이 움직인다.
- Fixed(픽스드;고정된): 화면 전체를 기준으로 스크롤하더라도 항상 고정된 위치(화면 전체를 기준)
- Absolute(앱솔루트): Fixed와 유사하지만, 고정되는 기준이 컨테이너 안이다(부모 컨테이너 기준)
- Sticky(스티키): 스크롤에 따라서 기본값과 Fixed를 전환하는 포지션, 특정 위치부터는 상단에 고정되는 것
- 프로토타입 패널에서 설정 가능.
이렇게 오늘의 목표까지 모두 수강 완료하였다!
또 오늘 튜터팀이랑 면담 하였는데 시간이 좀 짧긴 했지만 그래도 내가 궁금한것들, 고민이었던 것들 털어놓을 수 있는 시간이 있었어서 의미 있었다. 앞으로 종종 찾아가서 궁금한거 싹...물어봐야지 (ㅎㅎ)
'내일배움캠프 본캠프' 카테고리의 다른 글
| [PM부트캠프6기] 0316 Today I learned (0) | 2026.03.16 |
|---|---|
| [PM부트캠프6기] 0313 Today I learned (0) | 2026.03.13 |
| [PM부트캠프6기] 0312 Today I learned (0) | 2026.03.12 |
| [PM부트캠프6기] 0311 Today I learned (0) | 2026.03.11 |
| [PM부트캠프6기] 0309 Today I learned (0) | 2026.03.09 |