비기술 청중에게 기술 부채를 어떻게 설명하나요?

불평이 아니라 결정으로 만드는 법

• 요구가 아니라 선택지가 있는 트레이드오프로 제시합니다: "현재의 느려지는 속도로 계속 기능을 출시할 수도 있고, 지금 두 스프린트를 투자해 앞으로의 기능 비용을 대략 3분의 1로 줄일 수도 있습니다."
• 가능한 곳은 정량화합니다: 스프린트당 잃는 시간, incident 빈도, 불 끄는 데 쓰는 역량의 비율.
• 일부 부채는 괜찮다는 점을 정직하게 말합니다. 모든 부채를 갚아야 하는 것은 아닙니다; 핵심은 딜리버리를 적극적으로 갉아먹는 부채를 갚는 것입니다.

함정

• 전문 용어 쓰기("리팩터", "결합도", "아키텍처가 잘못됐다"). 코드를 과도하게 다듬고 싶어 하는 것처럼 들리게 합니다.
• 엔지니어가 그 자체를 위해 깨끗한 코드를 원하는 것으로 규정하기; 이는 자기 탐닉처럼 읽힙니다.
• 늑대 소년 외치기 — 모든 것을 부채라 부르면 진짜 긴급한 것이 생겼을 때 신뢰를 잃습니다.

왜 중요한가

tech debt를 비즈니스 용어로 설명할 수 없으면 그것은 결코 자금을 받지 못하고, 팀은 서서히 멈춰가는데 리더십은 왜 속도가 떨어지는지 의아해합니다. 그것을 비용, 속도, 리스크로 규정하는 것이 위기가 되기 전에 고칠 시간을 얻어주는 길입니다.