똑똑한 엔지니어들은 아키텍처에 대해 의견이 갈립니다. 그것은 건강합니다. TL의 일은 논쟁에서 이기는 것이 아니라 의견 불일치를 좋은 결정과 헌신하는 팀으로 바꾸는 것입니다. 대부분의 분쟁은 모두가 기준에 동의하면 해소됩니다.
해결을 위한 프로세스
text
1. 먼저 기준에 AGREE하라 — 우리는 무엇을 최적화하는가?
(규모, 단순성, 출시 시간, 팀 친숙도)
2. 각 측이 가장 강한 주장을 펴게 하라 — strawman이 아니라 steelman
3. 데이터를 찾아라 — spike, benchmark, prototype
4. 여전히 팽팽하면 — TL이 결정하고, 이유를 설명한다
5. DISAGREE AND COMMIT — 일단 결정되면 모두가 함께 노 젓는다
구체적인 예시
두 엔지니어가 microservices vs. monolith를 두고 논쟁합니다. 당신은 재구성합니다. "내년에 우리는 무엇을 최적화하는가?" 답인 "작은 팀으로 빠르게 출시"는 monolith를 명백한 선택으로 만듭니다. 논쟁은 사실 명시되지 않은 목표에 관한 것이었습니다.
결정할 때 vs. 미룰 때
되돌릴 수 있는 결정은 빠르게 하나를 골라 움직이십시오. 잘못 결정한 비용이 작습니다. one-way door는 속도를 늦추고 데이터를 모으십시오. 숙고를 되돌림 가능성에 맞추면 bikeshedding과 무모한 결정 둘 다 피합니다.