외부 연계 담당

외부 연계 담당은 개발자가 맡나?

담당은 전문을 신청하고 기관 점검 창을 잡는 역할이다. 화면 개발자와 창 주인을 한 칸에 넣으면 창은 비고 화면만 늘어난다.

연계 화면을 그리는 사람과 기관에 점검 슬롯을 넣는 사람은 직무가 다르다. 개발자는 전문 항목과 코드값을 맞춘다.

창 주인은 상대 기관 담당 전화, 신청서, 회선, 점검 가능 요일을 잡는다. 두 일을 한 중급 개발자 칸에 넣으면, 그 사람은 화면을 고르는 주에는 신청서를 못 넣고, 신청 주에는 화면을 못 고친다.

WBS에 연계를 개발 하위 줄로만 두면 이 분리가 안 보인다. 착수 2주 차에 연계 담당 이름, 대체 1명, 상대 기관 창구를 세 칸으로 연다.

이름이 비면 그 줄은 이미 위험이다. 위험 목록에 올리기 전에 이름부터 채운다.

전문이 바뀌면 창은 누가 다시 잡나?

전문 항목이 한 번 바뀌면 기관 점검 창은 처음부터 다시 잡아야 한다. 변경 주체와 재신청 기한을 같은 주에 적는다.

정산 코드 한 자리가 바뀌어도 상대 기관은 회귀 점검을 다시 잡는다. 내부에서는 작은 변경이다.

기관 쪽에서는 다음 달 슬롯이다. 슬롯이 월 1회인 기관에 재신청을 한 주 미루면 오픈이 한 달 밀린다.

변경관리 대장에 연계 영향을 체크하지 않으면, CCB는 화면 공수만 보고 승인한다. 승인 다음 날 창이 날아간다.

전문 변경의 기본 질문을 하나 박는다. 이 변경이 외부 전문 버전을 올리는가.

올리면 창 주인이 재신청일을 같은 회의에서 말한다. 말 대신 액션 아이템 한 줄이면 된다.

한 줄이 없으면 개발은 끝났는데 연계는 다음 달이다.

리허설 없이 본점검에 들어가면 무엇이 깨지나?

본점검은 한 번인 경우가 많다. 리허설에서 전문 오류를 안 빼면 본점검 실패가 일정 실패다.

기관 본점검은 참관자와 점검표가 있다. 그 자리에서 항목 누락이 나오면 창은 다음으로 넘어간다.

리허설은 내부 시뮬레이터나 사전 구간에서 전문을 한 바퀴 넣는 일이다. 리허설 일정을 WBS에 본점검 2주 앞으로 칸을 만들지 않으면, 본점검 전날 밤 데이터가 첫 시험이 된다.

전날 밤 시험은 실패 확률이 높다. 실패해도 내부에서는 고칠 시간이 있다.

기관 창에는 시간이 없다. 리허설 산출물은 성공 여부가 아니라 실패 목록이다.

목록이 0건이어야 본점검을 신청한다. 목록을 안고 본점검에 들어가면, 상대 기관 신뢰까지 한 번에 깎인다.

본점검이 실패하면 우회 경로는 어디에 적나?

실패 시 수동 업로드, 파일 교환, 일정 이관 중 무엇을 쓸지 계약 전에 고른다. 현장에서 고르면 이미 한 주가 간다.

실패를 가정하지 않은 연계는 일정 단일 점이다. 단일 점은 Risk(위험) 대장에 영향 고, 발생 중으로 올라가야 한다.

대응이 재신청이면 그건 대응이 아니라 대기다. 대기가 아닌 경로는 세 가지 중 하나를 미리 고른다.

수기 대사 후 오픈, 파일 교환으로 2주 운영, 해당 기능을 1차 오픈에서 제외. 세 경로의 결정권자와 현업 안내 문장을 착수 때 적어 둔다.

본점검 당일 오후에 고르면 현업 공지가 안 나가고, 안 나간 공지는 콜센터 문의가 된다. 문의가 쏟아지는 오픈은 연계 실패가 서비스 실패로 읽힌다.

연계 창은 계약 어디에 남기나?

상대 기관 협조, 점검 횟수, 실패 시 일정 책임을 특수조건에 한 줄씩 둔다. 내부 일정표만 있으면 창은 상대 마음이다.

수행 계약에 상대 기관이 서명하지 않는다. 그래서 창을 내부 마일스톤처럼 찍으면 찍은 쪽이 다 책임진다.

발주 특수조건에 기관 협조 요청 주체, 점검 신청 기한, 상대 지연 시 오픈일 조정 원칙을 적는다. 세 줄이 없으면 기관이 한 달을 미뤄도 수행사 지체상금 대화가 된다.

대화가 되는 이유는 창의 주인이 계약에 없어서다. 컨소시엄이면 연계 사를 역할 칸에 명시한다.

주관이 창까지 떠안으면 개발 공수는 남고 창 공수는 숨는다. 숨은 공수는 안정화 달 야근이다.

야근으로 창을 만드는 사업은 오픈은 해도 인도가 아니다.