technical risk를 어떻게 식별하고 완화합니까?

Question

Accepted Answer

**technical risk**는 딜리버리를 탈선시키거나 production에서 깨질 수 있는 모든 것입니다. 미지수, 취약한 의존성, 확장 한계, single point of failure입니다. TL의 일은 **위험을 일찍 드러내고 의도적으로 줄이는 것**입니다. 위험은 그 위에 무언가를 쌓기 전에 다루는 것이 가장 저렴하기 때문입니다.

## 위험을 관리하는 방법

```text
1. IDENTIFY — 무엇이 잘못될 수 있나?(미지수, dependency, 규모, 보안, 사람)
2. ASSESS — 가능성 x 영향. high-high 사분면에 집중하라.
3. 가장 큰 미지수를 FIRST로 공략하라 — spike, prototype, load-test
4. MITIGATE — 가능성이나 blast radius를 줄여라(redundancy, flag, fallback)
5. MONITOR — 알려진 위험을 추적하라; 현실화될 때의 계획을 가져라
```

## 늦게가 아니라 일찍 de-risk하라

가장 위험한 것은 *미지수*입니다, 추정할 수 없는 것들. spike나 prototype으로 먼저 다뤄, 프로젝트가 아직 바꾸기 저렴할 때 진실을 알아내십시오. 쉽고 알려진 부분을 먼저 만드는 것은 생산적으로 느껴지지만 지뢰를 끝까지 남겨둡니다.

## 구체적인 예시

프로젝트가 규모에서 써본 적 없는 third-party API에 의존합니다. 그것이 작동한다고 가정하고 전체 시스템을 설계하지 말고, 1주차에 그것에 대해 prototype하십시오. 당신의 부하를 감당하지 못한다면, 모든 것을 그 주위에 만든 뒤가 아니라 지금 알게 됩니다.

## 함정

편안하고 알려진 작업을 먼저 하고 무서운 미지수를 마지막으로 남기는 것. 그것은 틀렸을 때의 비용을 극대화합니다, 정확히 거꾸로입니다.

## 왜 중요한가

늦게까지 무시된 위험은 위기가 됩니다. 비싸고, 일정을 망치며, 사기를 꺾습니다.

위험을 일찍 사냥하는 TL은 지금의 작은 알려진 비용으로 나중의 큰 알려지지 않은 비용을 피하는 거래를 합니다.

그 선견지명이 senior lead가 제값을 하게 만드는 큰 부분입니다.