컨소시엄 역할 분담 정리 - 주관 참여사 WBS 기성 품질 종료 책임

인터페이스 칸은 왜 주관 WBS만으로 안 될까?

참여사 산출물이 맞닿는 지점이 인터페이스입니다. 칸이 비면 양쪽이 상대가 할 일로 미룹니다.

주관 WBS에 연계 개발이라고만 있으면, 주관은 참여사 API를 기다리고 참여사는 주관 스펙을 기다립니다. 인터페이스 표에 제공 쪽, 수신 쪽, 스펙 확정일, 시험일을 적습니다.

확정일이 지난 칸은 Risk(위험)로 올리고, 올리지 않으면 기성 주간에 갑자기 공백이 됩니다. 그 공백은 일정 숫자가 아니라 책임 공백이고, 책임 공백은 회의에서 서로 상대 회사 이름을 부르는 데만 쓰입니다.

기성은 역할과 어떻게 맞춰야 할까?

기성 비율과 산출물 인도가 같은 표에 있어야 합니다. 주관만 기성을 받으면 참여사 산출물이 늦어져도 현금 흐름은 안 멈춥니다.

계약 기성이 주관 통으로만 흘러가면, 참여사 지연이 주관의 현금에는 바로 안 보입니다. 역할별 산출물과 기성 트리거를 연결합니다.

인터페이스 시험 합격, 모듈 검수, 문서 인도를 기성 칸에 걸고, 미달 시 유보 조건도 한 줄로 둡니다. PM이 주간에서 기성만 보고 인터페이스 칸을 안 보면, 돈은 나갔는데 경계는 비어 있는 상태가 됩니다.

품질 기준은 회사마다 달라도 될까?

공통 품질 문을 하나 두고 회사별 세부만 허용합니다. 문이 다르면 통합 주에 기준 싸움이 납니다.

참여사마다 커버리지, 코드 리뷰, 시험 양식이 다릅니다. 통합 직전에 맞추면 이미 늦습니다.

착수 때 공통 품질 문, 예를 들어 치명 결함 0, 시나리오 합격, 보안 점검 합격, 을 합의하고 회사별 도구는 그 아래 둡니다. 공통 문이 없으면 주관 품질이 참여사 산출물을 거부할 근거가 약하고, 근거가 약하면 일정만 소모됩니다.

의사소통 경로는 몇 줄로 정리할까?

발주, 주관, 참여사 삼각에 창구 이름을 둡니다. 전원 메일은 결정이 없고, 창구 없는 직행은 책임이 없습니다.

참여사가 발주에 직접 물어보고 주관이 모르는 결정이 반복되면, 범위가 세 갈래로 자랍니다. 의사소통 규칙에 공식 창구, 참조, 에스컬레이션을 적습니다.

변경은 주관 창구를 통과하게 하고, 기술 실무 협의는 참여사 간 가능하되 결과를 주관 이슈에 남깁니다. 규칙이 있으면 속도가 줄지 않고 기록이 남습니다.

종료 책임은 누가 끝까지 가져갈까?

하자, 안정화, 운영 인계의 주관을 이름과 기간으로 적습니다. 컨소시엄이 해체된 뒤 빈 전화는 발주 비용입니다.

준공 후 주관만 남고 참여사가 빠지면, 참여사 모듈 장애의 주인이 사라집니다. 종료 책임 표에 모듈별 잔류 기간, 연락 창구, 이관 산출물을 적습니다.

잔류가 끝난 뒤의 창구도 계약 특수조건에 옮깁니다. 옮기지 않으면 발주 운영이 여러 회사에 동시에 전화하고, 그 시간이 곧 장애 복구 시간에 더해집니다.

종료 표를 준공 주가 아니라 착수 주에 초안으로 두면, 기성 협상 때 빠지기 어렵습니다.