코드를 아는 사람에서 무엇이 맞는지 아는 사람으로

자동화가 한 단계를 삼키면 그 단계에 있던 사람은 위나 옆으로 옮겨 갑니다. 사라지는 경우보다 옮겨 가는 경우가 많았습니다.

옮겨 가는 방향

지금 자동화되는 단계는 '만들기'입니다. 그러면 남는 자리는 그 앞과 뒤입니다.

앞 — 무엇을 만들지 정하는 자리. 이건 기술 문제가 아니라 업무 문제입니다. 그 업무를 아는 사람이 아니면 정할 수 없습니다. 뒤 — 맞는지 판정하는 자리. 이것도 기술보다 도메인입니다. 무엇이 맞는 답인지는 그 일을 해 본 사람만 압니다.

그래서 생기는 역전

한동안 IT 프로젝트에서 현업 담당자는 주변부에 있었습니다. 요구사항을 말해 주고, 나중에 검수 회의에 불려 오는 자리였습니다. 만드는 일이 어려웠기 때문에 만드는 사람이 중심이었습니다.

만드는 일이 쉬워지면 이 배치가 흔들립니다. 무엇이 맞는지 아는 사람이 중심으로 옵니다.

다만 조건이 붙습니다

'무엇이 맞는지 안다'는 것과 '그것을 남이 확인할 수 있게 적는다'는 것은 다른 능력입니다. 머릿속에 있는 기준은 계약이 되지 못합니다. 판단 기준을 글로 적고, 남이 같은 기준으로 같은 판정을 내릴 수 있게 만드는 것 — 이건 따로 배워야 하는 기술로 보입니다.

지금 이 능력을 부르는 이름이 아직 정착되지 않았습니다. 검증 담당, 평가 설계, QA 리드 등으로 제각각 불립니다.

여러분 조직에서는 '무엇이 맞는지 정하는 일'을 누가 맡고 있습니까? 그리고 그 판단이 문서로 남아 있습니까?