gitlab 프로토콜 1.0

1.0 변경 목표

  1. 이슈들의 우선 순위를 모든 구성원들이 쉽게 파악하고, 동의될 수 있도록
  2. 쉽게 해결되는 작은 이슈들은 바로 해결될 수 있도록

지난 2-3년동안 n개의 제품, m명의 구성원이 서로 원활히 협업하는 데 gitlab이 큰 역할을 했습니다. 이 과정에서 축적된 협업 경험을 바탕으로 gitlab 프로토콜을 변경해 왔습니다. 이번 변경은 아래와 같은 사례를 해결하기 위해 정의한 목표입니다.

내 아이디어를 제안해도 “어차피” 반영이 안될거야 → 제안해서 뭐해..

제일 큰 문제였습니다. 주도적으로 의견을 내던 구성원들조차 본인이 제안한 아이디어가 매번 반영이 안되면 점차 실망하게 됩니다. 어떤 사람들은 본인이 존중받지 못한다 느끼고, 어떤 사람들은 프로세스에 막혀 조직이 경직되었다고 생각하고, 어떤 사람들은 결국 알수 없는 기준(=리더들의 취향)으로 결정되는 것 아니냐고 실망하기도 합니다.

이슈의 우선순위를 결정하는 사람도 답답합니다. n개의 제품에 대기된 m개의 이슈를 모두 잘 알고 있는 입장에서 특정 이슈는 훌륭하지만, 사업/제품 맥락에서 볼 때 덜 긴급하고, 덜 중요하기 때문에 실행하지 않는 합리적 결정을 한 것 뿐입니다. 타당하나 우선순위가 낮음을 일일이 설명하기 어렵습니다. 게다가 이미 긴급+중요한 이슈는 이미 1~2개의 milestone만큼 대기 중입니다. 계속 거절하다 보면 거절하는 것도 부담이라 우선순위에 맞지 않으나 실행해주는 경우도 생깁니다.

이 문제를 해결하기 위해 (1) 기존 이슈들을 모두 알지 못해도, (2) 시시각각 변하는 사업/제품 맥락에 따른 우선순위 판단의 근거를 알고 있지 않아도, 내가 제안한 이슈가 어떤 우선순위를 갖는지 또는 진행되지 않는다면 왜 그런지 쉽게 알 수 있는 방법이 필요하다고 생각했습니다.

이거 작은 건데 잠깐 이것부터 해줘 → 개발자 맥락 끊김 & 프로토콜 외 back-channel 활용 문제 → 제품팀의 업무 퍼포먼스 하락

내부에서 고질적인 문제로 꾸준히 나오는 문제입니다. 현행은 어떤 종류의 이슈든 gitlab에 등록하면 2~3주 간격의 milestone을 지나 반영되게 됩니다. 제안자 입장에서는 5~10분이면 해결될 것 같은 이슈를 2~3주 기다렸다 해야하는 것이 굉장히 프로세스-경직되어 보입니다. 한편 제품팀 입장에서는 이러한 이슈를 즉시 대응하다보면 개발자들이 몰입하지 못해 제품팀의 업무 퍼포먼스가 크게 저하되는 문제가 있습니다. 구성원에 따라 신속한 문제 해결을 하기 위해 back-channel을 활용해 해결하기도 하는데, 이러면 back-channel을 활용하지 않는 구성원의 이슈는 해결이 점점 늦어져서 프로토콜의 의미가 무색해 집니다.

이 문제를 해결하기 위해 이슈의 우선순위(긴급함x중요함+사업적 맥락)을 고려해 milestone 단위로 운용하는 기존의 방법과는 별도로, 긴급한&쉬운 이슈를 처리하는 side-track이 필요하다고 생각했습니다.

gitlab 프로토콜 1.0

1. 제안할 이슈가 있으면, 리셉션 gitlab에 등록한다.

  • 기존 제품별 gitlab과 별도로 리셉션 gitlab 3종(기획/운영/QA)을 생성한다.
  • 구성원은 목적에 맞는 리셉션 gitlab에 이슈를 등록한다.
  • 이슈 등록 시, 문제정의와 요구사항을 3~4줄의 bullet point로 간결하게 작성한다.
    • 단, 상세기획 or 솔루션을 제안하지 않도록 노력한다.
    • 필요할 경우, pm이 문제정의/요구사항을 인터뷰하여 함께 디벨롭한다.

2-1. (track 1) 즉시 해결될 수 있는 리셉션 이슈는 담당자가 asap로 처리한다.

  • 운영/QA gitlab에 등록된 이슈 중, 별도 기획이 필요 없을 경우
    • 운영 gitlab: devOps 담당자가 즉시 수정, 가능할 때 반영한다.
    • QA gitlab: QA 담당자가 즉시 제품 gitlab으로 등록, 가능할 때 반영한다.
  • 별도 기획이 필요한 경우, 2-2를 따른다.

2-2. (track 2) pm은 리셉션 gitlab의 우선순위를 설정한다.

  • 우선순위는 3단계로 설정한다.
    • 1순위 이슈: 기획/디자인을 디벨롭이 완료되는 대로, 우선 실행될 이슈
    • 3순위 이슈: 타당하나, 우선순위가 낮아 장기간 대기가 예상되는 이슈
  • 너무 장기간 대기가 예상되거나, 타당하지 않을 경우 closed 처리한다.

3. 기획/디자인이 가능할 때, 리셉션 gitlab의 1순위 이슈를 디벨롭한다.

  • 기획/디자인이 mock-up을 제작하여, 제안자와 함께 리뷰한다.
  • 상호 리뷰가 완료되면, 상세 ux/ui 작업 결과물을 만든다.

4. pm은 리셉션 gitlab 이슈을 컨펌한 뒤, 제품 gitlab으로 옮긴다.

  • pm은 다른 제품, 정책, 맥락과의 일관성 및 작업 완성도를 고려하여 컨펌한다.
  • pm은 컨펌된 이슈를 제품 gitlab으로 이동시킨다.

5. pm은 제품 gitlab의 이슈를 우선순위에 따라 milestone에 담아 실행 시킨다.

  • pm은 제품 gitlab 이슈들에 대해 별도의 우선순위를 설정한다.
  • 제품 gitlab의 운용 방식은 기존 프로토콜을 따른다.

기대 효과

기존의 제품별 gitlab에도 1,2,3순위가 있었지만 기존 3순위에는 사실상 보류인 것부터 정말 3순위인 것까지 다 포함되어 있었습니다. 3순위가 워낙 많으니 3순위 중 어떤 것이 먼저 실행되는지도 알기 어려웠습니다. 같은 3순위인데도 처리 결과가 달랐습니다. 여기에서 많은 문제가 발생했습니다.

내 제안이 진행 될 지, 안된다면 왜 안 되는지 알기 쉬워집니다.

이제 아이디어 단계의 이슈는 모두 리셉션 gitlab에 모여 있습니다. 리셉션 gitlab에서 1순위가 되어 기획/디자인 작업이 완료되기 전에는 실행되지 않습니다. 2순위이면 1순위가 다 처리되기 전까지는 대기 상태입니다. 3순위이면 실질적으로 단기간에 진행되기 어렵습니다.

리셉션 gitlab 1순위이면서 디벨롭까지 완료되면, 이제 제품 gitlab으로 넘어가는 명시적인 단계가 있습니다. 일단 제품 gitlab으로 넘어가면 단기간에 실행되는 것이 확실합니다. 간단히 정리하면 이렇게 단계별로 명확히 구별됩니다.

  • 아이디어 제안 = 리셉션 깃랩 등록
  • 목업 → iteration → 상세 ux/ui output = 리셉션 깃랩 1순위
  • 진행 확정 = 제품 gitlab으로 이동
  • 일정 확정 = 제품 gitlab의 milestone으로 지정

우선순위의 기준을 산식으로 만드는 것은 어렵지만, 리셉션 gitlab 1순위인 이슈들을 보면 귀납적으로 회사가 현재 어떤 것을 중요시 하는지 예상할 수 있습니다. pm도 이슈가 거절/보류되는 이유를 말하지 않아도 알릴 수 있어 심리적 부담이 적어집니다.

긴급한/간단한 이슈도 이제 gitlab에 등록하는 것이 좋습니다.

리셉션 gitlab(운영/QA)에 등록된 이슈 중 긴급/간단한 이슈는 담당자가 현재 몰입하고 있는 업무 블록을 마무리하면 그 이후 곧바로 처리해 줄 것입니다. 상대방의 업무 몰입을 방해하지 않는 것을 전제로 하면, gitlab에 등록하는 것보다 더 빠르게 처리할 수는 없습니다.

어떤 이슈를 먼저 기획/디자인 해야 하는지 알기 쉬워집니다.

현재는 milestone에 들어가 있는 이슈를 제외하면 어떤 이슈를 먼저 기획/디자인 해야 하는지  알기 어렵습니다. 이제 리셉션 gitlab의 1순위라는 명확한 기획/디자인 타깃이 생깁니다. 2,3 순위까지 작업을 하는 대신 1순위 제안자와 밀도 높은 소통을 하고, 좀 더 완성도 있는 결과물을 내는 데 집중할 수 있습니다.