기준정보 확정일 정하기 - 품목 코드가 오픈 주를 막는 이유

화면이 끝났는데 왜 오픈이 멈추나

멈추는 이유는 결함 목록보다 비어 있는 기준정보다. 코드가 없으면 배치와 연계가 같이 실패한다.

화면 개발이 끝나도 오픈이 멈추는 현장은 결함 건수보다 기준정보 칸을 먼저 본다. 품목 코드와 조직 코드, 거래처 마스터가 비어 있으면 정산 배치는 0건으로 끝나고, 권한 없는 사용자는 메뉴에 들어가지 못하며, 연계 전문은 코드 거절로 돌아온다.

증상이 한 주에 겹치면 원인은 화면이 아니다. 개발 진척 90%는 대개 화면 완료율이라 주간보고만 보면 준비가 된 것처럼 보인다.

리허설 3회차에서 미매핑 1,200건이 나오면 그 숫자는 개발 결함이 아니라 값이 없는 코드다. Risk(위험) 대장에 데이터 늦음이라고만 적고 확정 날짜를 비워 두면, 그 위험은 매주 다음 주로 넘어간다.

넘어간 주는 컷오버 전주에 3만 건을 한 번에 받는 일정으로 돌아온다. 전주에 받은 파일은 컬럼 검증을 돌릴 시간이 없고, 돌리지 않은 파일은 운영에 그대로 올라간다.

올라간 뒤에 고치면 이미 정산 숫자가 흔적 없이 바뀐 뒤다.

확정일은 오픈 몇 주 전에 두나

오픈 4주 전이 현장의 마지노선이다. 그 전에 업무 오너 확인이 없으면 리허설은 표본 시험으로 남는다.

확정일은 오픈 4주 전으로 둔다. 4주가 넉넉해 보여도 적재, 매핑 검증, 리허설 2회를 넣으면 주가 금방 찬다.

WBS에 기준정보라는 한 칸만 있으면, 요구 정의 12주를 한 덩어리로 둔 일정과 같은 일이 난다. 진척은 매주 조금씩 오르다가 마지막 주에 조직 코드가 통째로 바뀐다.

칸은 나눈다. 초안 수신, 매핑표 작성, 업무 오너 확인, 전수 적재, 리허설 대조.

확인이 끝나기 전에 전수 적재를 그리면 그 줄은 이미 재작업이다. 샘플 500건으로 화면을 연 것과 전수 3만 건을 올린 것은 다른 시험이다.

샘플 합격 다음 주에 전수를 붙이지 않으면 미매핑은 오픈 주에 터진다. 여유일이 0인 줄이 개발이 아니라 이 확인 칸인 프로젝트가 많다.

그 칸의 담당 이름이 비어 있으면 일정표는 아직 계획이 아니다. 담당이 휴가인 주를 확정 주로 잡으면 사인은 다음 주로 밀린다.

마스터 사인은 누가 해야 하나

개발 PM이 아니라 업무 오너와 운영 담당이다. 두 사인이 없으면 그 파일은 아직 초안이다.

코드 값을 아는 사람은 화면을 만든 개발자가 아니다. 품목이 매출인지 원가인지, 조직이 폐점인지 통합인지는 업무 오너만 안다.

오픈 뒤에 그 코드를 고칠 사람은 운영 담당이다. 그래서 사인은 두 자리다.

한 자리만 있으면 파일은 초안이다. 초안을 운영 DB에 넣으면 다음 날 배치 숫자가 검수 조서와 어긋난다.

검증(Validation) 시나리오에 마스터 확인이 한 줄도 없으면, 현업은 화면 흐름만 보고 합격이라고 말한다. 합격 다음 날 배치가 실패하면 그 사인은 유지되지 않는다.

사인 칸은 네 개면 된다. 코드 수, 미매핑 잔여, 구코드와 신코드의 대응, 확정 날짜.

이름과 날짜가 비면 확인이 아니다. 대리 사인은 더 위험하다.

팀장 출장 중에 대리가 찍은 확인은 조직 코드가 바뀐 뒤 취소되는 일이 잦다. 취소는 일정을 되감아 주지 않는다.

주 담당이 없는 주는 확정 주로 잡지 않는다.

오픈 전 변경과 오픈 후 변경은 어떻게 가르나

확정일 이전 수정은 이행 범위다. 이후 추가는 변경으로 넘겨 컷오버 범위에 다시 넣지 않는다.

확정일 전에 들어온 수정은 매핑표를 고치고 다시 적재하면 된다. 확정일 뒤에 조직이 하나 늘었다고 컷오버 주에 코드를 고치면, 권한과 배치와 연계가 같이 다시 열린다.

다시 열린 범위는 리허설을 한 번 더 요구한다. 그 한 번이 오픈 창 안에 없으면 오픈일이 밀린다.

변경관리로 넘길 때는 세 줄을 남긴다. 무엇이 바뀌는지, 이번 오픈에 넣지 않는 이유, 운영 개선으로 여는 날짜.

그 기록이 없으면 현업은 요청마다 긴급을 붙이고, 긴급은 전부 이번 오픈이 된다. 상한도 숫자로 둔다.

확정 뒤 코드 변경은 주 20건까지, 그 위는 다음 릴리스다. 상한이 없으면 20건과 200건이 같은 긴급으로 올라온다.

고정계약일수록 이 상한을 미루면 안정화 2주가 코드 수정으로 잠긴다. 잠긴 안정화는 인도가 아니라 연장 개발이다.

연장에 단가를 다시 묻기 전에, 상한을 회의록에 먼저 남긴다.

리허설에서는 무엇을 세야 합격인가

전수 적재 건수, 미매핑 잔여, 확정 이후 변경 건수다. 화면 시나리오 합격만으로는 마스터가 안 닫힌다.

리허설 합격 도장에 화면 시나리오만 있으면 마스터는 열린 채로 오픈한다. 같은 표에 전수 적재 건수, 미매핑 잔여, 확정 이후 변경 건수를 적는다.

미매핑 0을 모든 현장에서 요구할 수는 없다. 그럴 때는 잔여를 업무 오너가 건별로 수용했다는 목록을 남기고, 그 건은 오픈 결함 대장에 넣지 않는다.

목록이 없으면 잔여 40건이 오픈 당일 장애처럼 보인다. 리허설은 한 회로 끝내지 않는다.

1회는 매핑 오류를 찾고, 2회는 수정본을 전수로 다시 올린다. 2회를 빼면 1회의 오류가 운영 데이터에 남는다.

적재 시간도 잰다. 3만 건에 4시간이 걸리면, 컷오버 창이 6시간인 프로젝트는 롤백 여유가 2시간뿐이다.

그 2시간은 화면 결함 하나에도 사라진다. 일정 회의의 첫 숫자는 진척률이 아니라 이 적재 시간과 미매핑 잔여다.

두 숫자가 비어 있으면 그 리허설은 합격이 아니다.