요구는 반드시 바뀝니다

석 달 뒤에 다른 요구가 옵니다

계약서에 범위를 적고 서명합니다. 그러면 그 범위가 지켜질 것이라고 다들 생각합니다. 그런데 석 달쯤 지나면 현업에서 다른 요구가 옵니다.

처음에 몰랐던 것을 그때 알게 됐기 때문입니다. 실제로 화면을 써 보기 전에는 무엇이 불편한지 알 수 없습니다. 요구가 바뀌는 것은 누가 잘못해서가 아니라 일의 성질입니다.

문제는 그다음입니다. 받아 주면 일정이 밀리고, 거절하면 관계가 나빠집니다. 둘 다 손해인 자리에서 매번 싸웁니다. 그리고 이 싸움은 계약서에 근거가 없어서 목소리 큰 쪽이 이깁니다.

저는 ERP를 자체 개발할 때 변경 요청 창구와 월 한도를 계약에 넣었습니다. 변경은 한 곳으로만 받고, 한 달에 처리할 양을 미리 정했습니다.

이것이 거절로 읽히지 않은 이유가 있습니다. 순서를 정하는 권한을 요청한 쪽에 줬기 때문입니다. 급한 것을 먼저 넣으려면 다른 것을 빼야 하는데, 그 선택을 현업이 합니다. 우리가 판단하지 않으니 감정이 생기지 않습니다.

한도를 정할 때는 숫자를 크게 잡지 않습니다. 한 달에 다섯 건이면 다섯 건입니다. 여유를 두면 여유만큼 요청이 늘어납니다. 사람은 주어진 양을 채웁니다.

창구를 한 곳으로 모으면 얻는 것이 하나 더 있습니다. 누가 무엇을 언제 요청했는지가 처음으로 세어집니다. 그전에는 복도에서 부탁받은 것과 메일로 온 것이 섞여 아무도 총량을 몰랐습니다.

한도를 넘긴 요청은 버리지 않고 목록에 남깁니다. 다음 달 후보가 됩니다. 이 목록을 요청한 쪽도 봅니다. 그러면 급하지 않은 것은 스스로 뺍니다.

버리면 다시 올라오고 남기면 정리됩니다. 보이는 목록 하나가 거절 열 번을 대신합니다.

다만 자동으로 다음 달에 올라가게 두지 않습니다. 매달 다시 고르게 합니다. 지난달에 급했던 것이 이번 달에도 급하다는 보장이 없습니다.

목록에 요청자 이름은 적지 않습니다. 누가 요청했는지 보이면 그때부터 사람 문제가 됩니다. 무엇이 필요한지만 적습니다.

일 년 동안 변경 요청이 예순두 건 왔습니다. 그중 마흔한 건을 처리했고 스물한 건이 목록에 남았습니다. 남은 것 중 열여섯 건은 시간이 지나면서 스스로 빠졌습니다.

필요가 없어졌거나 다른 방법을 찾은 것입니다. 남은 다섯 건은 다음 계약에 넣었습니다. 그 다섯 건은 정말 필요한 것이었고, 일 년을 기다린 만큼 요구도 분명해져 있었습니다.

한도를 지키려면 처리한 건수를 매달 공개해야 합니다. 숫자가 안 보이면 한도는 말뿐입니다. 공개하면 한도가 규칙이 되고, 공개하지 않으면 담당자의 재량이 됩니다.

이 방식은 규모가 작으면 과합니다. 두세 달짜리 일에는 창구 하나면 충분합니다. 한도까지 만들면 관리 비용이 일보다 커집니다. 자세한 절차 설계는 중단 조건과 결정 기록을 같이 보십시오.

요구가 바뀔 때 무엇을 먼저 보는지는 요구는 기능으로 오지만 문제는 업무에 있습니다에서 이어집니다.