gitlab 프로토콜 1.2

1.2 변경 목표

  1. 개발팀이 문맥을 더 넓고, 깊게 이해할 수 있도록
  2. top-down의 신속함과 bottom-up의 디테일이 균형있게 반영되도록
  3. 장기적으로 이로운 아이디어/정책도 축적될 수 있도록

이번 프로토콜 업데이트의 핵심은 전사 이슈 회의입니다. 사실 모든 구성원들이 등록된 모든 이슈를 파악하는 것은 굉장히 시간 소모적인 일입니다. 하지만 각 이슈가 제안된 배경과 맥락을 알고, 어떤 이슈가 왜 진행되기로 결정되었는지 학습할 수 있다면 훨씬 긴 시간동안 진행되는 제품 개발 과정에서 맥락을 모르기 때문에 발생하는 더 큰 비효율을 줄일 수 있다고 판단했습니다.

전사 이슈 회의에서는 평소에 업무 접점이 없어서 교류하지 못했던 동료들의 의견도 들어볼 수 있을 겁니다. 그 과정에서 맥락에 부합한 제안을 자주 하는 동료는 전사적으로 영향력과 평판을 획득하게 됩니다. 그리고 저를 포함한 리더십들은 이렇게 동료들에게 인정받은 구성원들 중, 훌륭한 동료에 부합하는 분들이 경력, 연차와 상관없이 더 많은 권한과 책임을 갖는 리더십으로 임명되도록 최선을 다해 노력할 것입니다. 왜냐하면 결국 건강한 조직문화는 모두가 인정하는 훌륭한 동료가 더 큰 보상을 받는 과정에서 강화된다고 믿기 때문입니다.

한편 팀원이 현장에서 얻게되는 인사이트는 회사가 신속한 pace of innovation을 유지하기 위해 반드시 필요합니다. 따라서 팀원이 참여하여 bottom-up으로 회사가 무엇을 해야 하는지 알려주는 process는 매우 중요하고, 이에 적극 참여하는 구성원들은 더 큰 보상을 받아야 합니다. 이와 동시에 회사의 로드맵 상 중요한 핵심 어젠다는 여전히 top-down으로 신속하고 일관되게 진행될 수 있어야 합니다. 결국 top-down과 bottom-up, 신속함과 다양함 사이에서 balance를 찾기 위해 우리는 끊임없이 고민하고, 주의하고, 진화해야 합니다.

구성원의 역할

팀원의 역할

1. 제안할 아이디어나 해결할 이슈가 있으면 리셉션 gitlab에 등록한다.
  • 목적에 따른 리셉션 gitlab
    • 신규 기능이 개발이 필요한 경우: 신규기능 gitlab에 등록
    • 기존 기능의 수정이 필요한 경우: 기존기능 gitlab에 등록
    • 장기적인 아이디어의 제안: 아이디어 gitlab에 등록
  • 이슈 등록 시 권고사항
    • “문제→솔루션” 또는 “제안→기대효과”를 간단하게 작성한다.
    • 상세기획 or 솔루션을 제안하지 않도록 노력한다.
2. 아이디어 gitlab에 등록된 이슈를 up/down vote한다.
  • gitlab 운영자와 제품리드는 up vote된 아이디어 중 일부를 임의로 선택하여 진행시킬 수 있다.

gitlab 운영자의 역할

기존기능 gitlab 운영자: @youngsoo

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

신규기능 gitlab 운영자: @jaehyun

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

제품 리드의 역할

1. 로드맵을 달성하기 위한 이슈를 gitlab에 등록한다.
  • 로드맵이슈(C) 라벨을 달아 주요 어젠다임을 표시한다.

진행 process

1. 매주 새롭게 생성된 다음 이슈들의 내용과 맥락을 이해하는 시간을 갖는다.
  • 공유할 이슈
    • 신규기능 gitlab – 후보이슈(A), 준비완료이슈(B)
    • 기존기능 gitlab – 해결된 이슈, 담당자가 배정된 이슈
    • 아이디어 gitlab – 등록된 모든 이슈
    • 로드맵이슈(C)
  • 발표자
    • 신규/기존기능 gitlab – gitlab 운영자
    • 아이디어 gitlab 이슈 – 제안자
    • 로드맵이슈(C) – 제품 리드
  • 참석자
    • 전사 참석을 권장하나 필수는 아님
2. VP engineering은 마일스톤 산정회의를 통해 마일스톤을 확정한다.
  • 일정: 새로운 마일스톤 시작 2주 전, 월요일
  • 참석 대상: 제작팀 전체
  • 산정 대상 이슈
    • 신규기능 gitlab – 준비완료이슈(B)
    • 로드맵이슈(C)
  • 단, 제품 리드는 반드시 들어가야 할 소수의 이슈를 선정할 수 있다.