현장과 사무실의 경계를 문장으로 정하기

빨라져서 생긴 사고

발주가 취소됐습니다.

사무실에서 오전에 올라온 측정값을 보고 자재를 주문했는데, 오후에 그 값이 바뀌었습니다. 현장에서는 아직 작업 중이었고, 오전 값은 중간 확인이었습니다.

아무도 잘못하지 않았습니다. 현장은 성실히 올렸고, 사무실은 빠르게 움직였습니다.

느릴 때는 없던 문제입니다. 저녁에 한 번에 넘어오니 그게 곧 확정이었으니까요. 속도를 올리면서 확정이라는 개념이 사라진 겁니다.

상태를 셋으로 나눴다

빠르게 흐르게 만들었으면 어디까지가 초안이고 어디부터가 확정인지 따로 표시해야 합니다.

한 문장을 버튼 옆에 붙였다

상태 정의를 문서로 길게 쓰지 않았습니다. 대신 확정 버튼 옆에 한 문장을 띄웠습니다.

현장 확정을 누르면, 사무실은 이 값으로 다음 작업을 시작합니다.

이 문장 하나가 긴 설명서보다 잘 먹혔습니다. 누르는 사람이 그 행동의 결과를 그 자리에서 알기 때문입니다.

규칙을 문서에 적으면 아무도 안 읽습니다. 규칙을 행동하는 화면에 적으면 읽습니다. 이후 다른 기능을 만들 때도 계속 쓴 방법입니다.

되돌리는 길을 먼저 냈다

확정 후에도 값이 틀릴 수 있습니다. 확정 해제를 막지 않았습니다.

확정 해제 시
  1. 사유 입력 (필수)
  2. 이 값을 참조한 후속 작업 목록 표시
  3. 해당 담당자에게 알림 발송
  4. 이력에 기록 (누가 · 언제 · 왜)

누가 영향을 받는지 시스템이 알고 있으니, 사람이 기억해서 연락할 필요가 없습니다.

여기서 배운 게 있습니다. 되돌릴 수 없게 잠그면 사람들은 확정을 안 누릅니다. 잘못 누르면 큰일 난다고 느끼면 계속 "작업 중"으로 남겨둡니다. 그러면 상태 구분 자체가 무의미해집니다.

되돌릴 수 있어야 확정이 쓰입니다. 안전장치는 잠그는 쪽이 아니라 되돌리는 길을 내는 쪽이 맞았습니다.

합의가 코드보다 오래 걸렸다

이 단계에서 실제로 만든 코드는 상태 필드 하나와 화면 몇 개입니다. 이틀이면 끝나는 분량입니다.

어려웠던 건 셋으로 나누자고 서로 동의하는 과정이었습니다. 현장은 "확정을 왜 우리가 누르냐"고 했고, 사무실은 "그럼 언제 움직이냐"고 했습니다.

세 번의 회의 끝에 정해진 건 기능이 아니라 문장이었습니다.

두 달 뒤에 확인한 것

상태를 나눈 지 두 달이 지나고 로그를 봤습니다. 규칙이 실제로 쓰이고 있는지 궁금했습니다.

현장 확정 클릭        전체 건의 94%
확정 해제             전체 건의 3.1%
해제 사유 미기재      0건 (필수라 불가)
확정 전 사무실 착수   1건 (담당자 실수, 알림으로 즉시 발견)

해제가 3%나 된다는 게 처음엔 걱정스러웠습니다. 그런데 사유를 읽어보니 대부분 "재측정 결과 반영"이었습니다.

되돌리기가 잘 쓰이고 있다는 뜻이었습니다. 잠갔다면 이 3%는 애초에 확정을 안 눌렀을 겁니다.

남은 숫자

처음 정한 세 목표를 모두 넘겼습니다. 다만 이 단계에서 일을 줄인 건 자동화가 아니라 합의였습니다.

다음 편에서 할 것

값이 제때 들어오니 이상값을 자동으로 알려주고 싶어집니다. 당연한 순서처럼 보였습니다.

그래서 만들었고, 두 달 동안 아무도 그 알림을 보지 않았습니다.