Role and Responsibility(R&R)
프로덕트 매니저
- 제품에 대한 최종 책임자
- 제품에 대한 미션 제시
- 고객의 이익 제시
- 문서 작성
- 정책 정의서
- 용어 정의
- 기본 운영 정책
비즈니스중심으로 정의하고, UI는 고려하지 않습니다- 예를 들면 다음과 같습니다
- 회원가입 | 약관동의 | 필수
- 회원가입 | 비밀번호 | 특수문자, 영어 대소문자 포함 8자 이상
- 게시판 | 공지사항 | 운영자 | CRUD
- 게시판 | 공지사항 | 회원/비회원 | R
- 정책의 카테고리에 따라 형식을 다르게 해야할 수 있습니다
- 백로그
- 개발 해야할 목록으로
개발자와 소통하기 위한 목적으로 작성 - 제목: 카테고리-ID-제목
- 카테고리: Front|Admin|기타 등
- ID
- 페이지 번호 등으로 사용될 수 있습니다
- 소통, 검색 등을 위해 사용될 수 있습니다
- 내용
- 신규/개선
- 신규인 경우
정책 정의서와TO-BE에 대한 상세 내용이 있어야 합니다 - 개선인 경우
AS-IS,수정된 정책 정의서,TO-BE에 대한 상세 내용이 있어야 합니다
- 신규인 경우
- 관련된 백로그
- 일정
- 완료 여부
- 신규/개선
- 개발자들이 판단하기 쉬운 형태로 내용이 정리되어야 합니다
- 개발팀과의 소통을 통해 구현 가능 여부, 난이도 등을 확인하여 반영합니다
- 개발 해야할 목록으로
- 화면 흐름도
- 페이지 이동, 모달 등 화면 흐름을 표현하기 위한 목적으로 작성
- 플로우차트, 마인드맵, 트리 등으로 시각화하여 작성
- IA(Information Architecture)
- 정보 구조 설계도로
디자이너와 소통하기 위한 목적으로 작성 - 화면간의 상하 관계 정의
- 고객 동선 관리
- 내용
- 계층 구조를 표현하기 위한 넘버링
- 유형: 페이지|모달|팝업|링크 등
- 정보 구조 설계도로
- 와이어프레임, 목업, 프로토타입 등
- 정책 정의서
경고
모든 문서는 수정될 수 있습니다. 수정된 경우 변경 이력을 남기고, 변경 사항을 전체에 알려야 합니다.
UX/UI 디자이너
매니저
- 목표 설정
- 팀 구성 관리
- 팀원 경력 성장 계획 및 코칭
- 사회적 건강 관리
- 팀원 멘탈 케어
- 갈등 중재
테크 리드
- 주요 기술적 결정
- 소프트웨어 아키텍처
소프트웨어 아키텍처의 모든 것은 다 트레이드오프다‘어떻게’보다 ‘왜’가 더 중요하다- 기술의 넓이 확보
- 알고 있는 것과 모른다는 사실을 알고 있는 것의 범위를 넓혀야합니다
- 기술 역량 확보 계획
- 필요한 플랫폼과 인프라 확보
- 위임하기(필요한 경우 가이드 후 위임)
- 위임받은 팀원이 곤란한 경우에는 방치하지 않고 직접 처리
- 부정적 피드백과 시스템적 해결책 공유
- 문제 상황을 팀원의 탓으로 귀결시키는 것을 피해야합니다
- 긍정적 피드백 공유
- 정책 정의서에 대한 피드백
- 백로그 개발 가능 여부, 난이도 등에 대한 피드백
- 백로그 개발
- 코드 리뷰
- 기술 이슈 추적
엔지니어
- 테크 리드의 결정 검증 및 피드백
- 테크리드가 모든 파트에 전문성을 갖기는 어렵기 때문에 담당자로서 검증과 피드백을 해야합니다
- 기술의 깊이 확보
- 알고 있는 것의 범위를 넓혀야합니다
- 백로그 개발
- 코드 리뷰
- 기술 이슈 보고