gitlab 프로토콜 1.1

1.1 변경 목표

  1. 어떤 리셉션 gitlab에 이슈를 올리는 게 맞는지 더 쉽게 판단되도록
  2. 더 좋은 해결책이 신속하고, 오해없이 도출될 수 있도록

gitlab 1.0 프로토콜을 약 2달 간 사용하면서 아래와 같은 몇가지 문제가 발견되었습니다.

어떤 리셉션 gitlab에 올리는 게 맞지? 운영 문제이지만 기획이 필요한데…버그인데 근본적으로 아예 새롭게 만들어야 할 것 같아..

1.0에서는 신규 이슈의 등록을 기획, 운영, QA의 직무에 따라 각각 나눠서 등록하도록 했었습니다. 그런데 꽤 많은 이슈들이 올바르게 해결되려면 기획, 운영, QA가 함께 협업해야 했습니다. 이러한 이유로 구성원마다 이걸 어떤 리셉션 gitlab에 올려야 할 지 헷갈려서 많은 communication cost가 발생했습니다.

이 문제를 해결하기 위해 (1) “새로운 기능의 개발”이 필요한 지만 판단하여 2개의 리셉션 gitlab에 올리고, (2) 다음 마일스톤의 결정에도 신규 기능의 추가와 기존 기능의 수정이 균형있게 반영될 수 있도록 프로토콜을 변경하고자 합니다.

좋은 제안이긴 한데 기존 기능과 충돌/중복되진 않나?..이게 제일 좋은 해결책이 맞을까?

모든 팀원들이 각각 얻는 경험에서 각각 합리적인 아이디어를 제안한다 하더라도 기존의 기능, 정책, 더 나아가 서비스의 문맥과 충돌되는 경우가 꽤 있었습니다. 그리고 이 문제는 모든 구성원들이 모든 기능, 정책, 문맥을 항상 최신으로 알지 않는 한 반복되는 문제이기도 합니다.

그래서 우리는 서비스 일관성을 지키고, 서비스의 현재 문맥에 맞는 해결책이 제안될 수 있도록 “기획자”의 직무를 추가하기로 했습니다. 기획자는 서비스의 기능, 정책, 문맥을 잘 알고 있으면서, 팀원들과 함께 더 근본적인 문제가 무엇인지 고민하고, 그 결과 가장 올바른 해결책을 함께 찾아가는 토론 파트너입니다.

내가 원하는 걸 설명하려면 한참이네..근데 나온것도 내가 원한 게 아니야..

협업하는 과정에서 늘 나오는 문제입니다. 생각을 전달하는 것도 시간이 오래 걸리고 어려운 일이지만 많은 사람들이 작업에 참여하는 과정에서 원래 생각과 다른 결과물이 나오기 쉽습니다. 그래서 제안한 사람과 기획자가 화이트보드 앞에서 만나 서로의 생각을 직접 교환할 수 있도록 하는 것이 궁극적으로 더 효율적일 수 있다고 판단하여 이를 프로세스에 반영했습니다.

gitlab 프로토콜 1.1

0. 이슈를 목적에 맞는 리셉션 gitlab에 등록한다.
  • 제안할 아이디어, 해결할 문제를 리셉션 gitlab에 등록한다.
    • 신규 기능이 개발이 필요한 경우: 제품기획 gitlab에 등록
    • 기존 기능의 수정이 필요한 경우: 운영품질 gitlab에 등록
  • “문제→솔루션” 또는 “제안→기대효과”를 간단하게 작성한다.
    • 상세기획 or 솔루션을 제안하지 않도록 노력한다.

<운영품질 gitlab>

1. (운영품질 gitlab) 운영자는 운영과 품질 이슈를 분류하고, 각각 담당자를 배정한다.
  • 운영과 품질 이슈는 다음 기준으로 분류된다.
    • 운영 이슈: 마일스톤 릴리즈가 필요하지 않은 업무 지원
    • 품질 이슈: 마일스톤 릴리즈가 필요한 업무 지원
  • 운영 이슈는 긴급성과 중요성을 고려하여 각각 진행된다.
    • 중요+긴급할 경우: 담당자에게 직접 알리고 asap 진행
    • 중요+긴급하지 않을 경우: 담당자를 어싸인한 뒤, 담당자의 스케쥴에 맞게 진행

<제품기획 gitlab>

1. 운영자는 제안자와 토론하여 다음 항목을 고려하여 이슈를 상세화한다.
  • 더욱 근본적인 문제가 있는지? 그에 따라 다른 솔루션은 없는지?
  • 다른 기능, 정책, 제품과 충돌되는 부분은 없는지?
  • 중요성과 긴급성을 고려할 때, 우선순위가 어느 정도인지?
  • 요구사항을 줄여 더 적은 자원으로 기대효과를 검증해볼 수 있는지?
2. 운영자는 토론 결과를 gitlab에 남기고, 후보이슈(A)를 선택한다.
  • 후보이슈(A)가 아닐 경우, 즉시 closing 한다.
3. 후보이슈(A) 중 다음 조건을 모두 만족하면 준비완료이슈(B)가 된다.
  • 운영자의 판단 하에 기능명세+상세시안 작업이 진행되었다.
  • 제안자가 기능명세와 상세시안을 보고, 원래 제안에 부합함을 확인하였다.

<마일스톤 선정회의>

1. 새로운 마일스톤에 들어갈 이슈를 결정하기 위해 마일스톤 선정회의가 열린다.
  • 일정: 새로운 마일스톤 시작 2주 전, 월요일
  • 참석 대상: 전체 참여가 권장되나, 강제되진 않음
2. 후보이슈(A)를 제안한 팀원은 왜 이번에 해당 이슈가 포함되어야 하는지 주장할 수 있다.
3. 제품총괄(CPO)은 의견 청취 후, 마일스톤에 들어갈 이슈를 최종적으로 결정한다.
  • 제품기획gitlab – 후보이슈(A)
  • 제품기획gitlab – 준비완료이슈(B)
  • 운영품질gitlab – 개발이 필요한 이슈