완전히 새로운 팀의 업무 프로세스를 어떻게 구축하나요?

Question

Accepted Answer

**가볍고 명시적으로** 시작한 다음, 팀이 실제 고충 지점으로부터 프로세스를 진화시키게 둡니다. 가장 큰 실수는 첫날에 이전 직장의 무거운 프레임워크를 들여오는 것입니다. 새 팀에는 몇 가지 타협 불가한 기본, 공유된 합의, 그리고 조정을 위한 빠른 피드백 루프가 필요합니다.

## 최소 실행 가능 프로세스

- **Definition of Done**과 **Definition of Ready** — "완료"와 "시작할 준비"가 모두에게 같은 의미가 되도록.
- 작업에 대한 단일 **진실의 원천**(하나의 보드), 그리고 작업이 다섯 개의 옆문으로 들어오지 않도록 명확한 유입 경로.
- **브랜칭 및 코드 리뷰** 표준, 그리고 기본 CI 파이프라인. 품질 게이트는 나중에 덧붙이는 게 아니라 첫날부터 존재합니다.
- 가벼운 **의례(ceremony)**: 짧은 데일리 싱크, 계획 수립 주기, 그리고 무엇보다 **회고(retrospective)** — 나머지 모든 것을 개선하는 엔진.

## 어떻게 펼치는가

1. **먼저 경청하기.** 각 사람과 이야기하고; 무언가를 강요하기 전에 그들의 맥락, 강점, 좌절을 파악합니다.
2. **워킹 어그리먼트를 함께 작성하기.** 겹치는 근무 시간, 의사결정 방식, on-call 기대치, 소통 규범. 주인의식은 공동 저작에서 나옵니다.
3. **작은 것을 빠르게 처음부터 끝까지 출시하기.** 실제 작업으로 한 번 돌려보고 빈틈을 찾는 것만큼 프로세스를 다지는 것은 없습니다.
4. **회고를 돌리고 조정하기.** 프로세스 자체를 백로그가 있는 제품으로 다룹니다.

## 트레이드오프와 함정

- **너무 많은 프로세스**는 모멘텀을 죽이고 불신의 신호를 보냅니다; **너무 적으면** 혼돈과 재작업을 만듭니다. 가벼운 쪽으로 기울고 진짜 문제가 요구할 때만 추가하세요.
- **도구와 프로세스를 혼동하지 마세요** — Jira는 방법론이 아닙니다.
- **칙령에 의한 프로세스**를 경계하세요. 팀이 형성에 도움을 주지 않았다면, 그들은 그것을 우회합니다.
- **심리적 안전감**을 일찍 수립하세요; 아무도 정직하게 말하지 않는 회고는 연극입니다.

## 간단한 템플릿

- 우리는 [주기]로 일한다. 완료란 [DoD]를 뜻한다. 우리는 모든 PR을 [X시간] 내에 리뷰한다. 우리는 [DACI/담당자]로 결정한다. 우리는 [간격]마다 회고한다.

## 왜 중요한가

팀의 프로세스는 나머지 모든 것이 그 위에서 돌아가는 운영체제입니다. 잘 구축하면 좋은 엔지니어가 복리로 쌓이고; 나쁘게 구축하면 매 스프린트를 마찰, 모호함, 재작업과 싸우며 보냅니다. 이를 의도적으로 — 가볍고, 명시적이고, 공동 소유로 — 하는 것은 시니어 리더십의 가장 명확한 신호 중 하나입니다.