Skip to main content

Role and Responsibility(R&R)


프로덕트 매니저

  • 제품에 대한 최종 책임자
  • 제품에 대한 미션 제시
  • 고객의 이익 제시
  • 문서 작성
    • 정책 정의서
      • 용어 정의
      • 기본 운영 정책
        • 비즈니스 중심으로 정의하고, UI는 고려하지 않습니다
        • 예를 들면 다음과 같습니다
          • 회원가입 | 약관동의 | 필수
          • 회원가입 | 비밀번호 | 특수문자, 영어 대소문자 포함 8자 이상
          • 게시판 | 공지사항 | 운영자 | CRUD
          • 게시판 | 공지사항 | 회원/비회원 | R
      • 정책의 카테고리에 따라 형식을 다르게 해야할 수 있습니다
    • 백로그
      • 개발 해야할 목록으로 개발자와 소통하기 위한 목적으로 작성
      • 제목: 카테고리-ID-제목
        • 카테고리: Front|Admin|기타 등
        • ID
          • 페이지 번호 등으로 사용될 수 있습니다
          • 소통, 검색 등을 위해 사용될 수 있습니다
      • 내용
        • 신규/개선
          • 신규인 경우 정책 정의서TO-BE에 대한 상세 내용이 있어야 합니다
          • 개선인 경우 AS-IS, 수정된 정책 정의서, TO-BE에 대한 상세 내용이 있어야 합니다
        • 관련된 백로그
        • 일정
        • 완료 여부
      • 개발자들이 판단하기 쉬운 형태로 내용이 정리되어야 합니다
      • 개발팀과의 소통을 통해 구현 가능 여부, 난이도 등을 확인하여 반영합니다
    • 화면 흐름도
      • 페이지 이동, 모달 등 화면 흐름을 표현하기 위한 목적으로 작성
      • 플로우차트, 마인드맵, 트리 등으로 시각화하여 작성
    • IA(Information Architecture)
      • 정보 구조 설계도로 디자이너와 소통하기 위한 목적으로 작성
      • 화면간의 상하 관계 정의
      • 고객 동선 관리
      • 내용
        • 계층 구조를 표현하기 위한 넘버링
        • 유형: 페이지|모달|팝업|링크 등
    • 와이어프레임, 목업, 프로토타입 등
warning

모든 문서는 수정될 수 있습니다. 수정된 경우 변경 이력을 남기고, 변경 사항을 전체에 알려야 합니다.

UX/UI 디자이너

매니저

  • 목표 설정
  • 팀 구성 관리
  • 팀원 경력 성장 계획 및 코칭
  • 사회적 건강 관리
    • 팀원 멘탈 케어
    • 갈등 중재

테크 리드

  • 주요 기술적 결정
  • 소프트웨어 아키텍처
    • 소프트웨어 아키텍처의 모든 것은 다 트레이드오프다
    • ‘어떻게’보다 ‘왜’가 더 중요하다
    • 기술의 넓이 확보
      • 알고 있는 것과 모른다는 사실을 알고 있는 것의 범위를 넓혀야합니다
  • 기술 역량 확보 계획
  • 필요한 플랫폼과 인프라 확보
  • 위임하기(필요한 경우 가이드 후 위임)
    • 위임받은 팀원이 곤란한 경우에는 방치하지 않고 직접 처리
  • 부정적 피드백과 시스템적 해결책 공유
    • 문제 상황을 팀원의 탓으로 귀결시키는 것을 피해야합니다
  • 긍정적 피드백 공유
  • 정책 정의서에 대한 피드백
  • 백로그 개발 가능 여부, 난이도 등에 대한 피드백
  • 백로그 개발
  • 코드 리뷰
  • 기술 이슈 추적

엔지니어

  • 테크 리드의 결정 검증 및 피드백
    • 테크리드가 모든 파트에 전문성을 갖기는 어렵기 때문에 담당자로서 검증과 피드백을 해야합니다
  • 기술의 깊이 확보
    • 알고 있는 것의 범위를 넓혀야합니다
  • 백로그 개발
  • 코드 리뷰
  • 기술 이슈 보고