회의록에 합의라고 적혀 있으면 기준선인가

아닙니다. 확인 주체 서명, 첨부, 버전, 날짜가 한 줄에 있어야 기준선입니다.

기준선 전에 화면을 더 넣으면 변경인가

날짜 전 추가는 범위 추가입니다. 공수와 일정을 다시 맞춘 뒤 같은 날짜로 닫습니다.

확인 주체를 두 명으로 두면 안 되나

둘 다 서명 권한이 있으면 됩니다. 한 명은 이름이고 한 명은 팀이면 결국 한 명입니다.

버전을 주마다 올리면 기준선이 자주 바뀌나

기준선 파일은 날짜에 묶인 한 세트입니다. 주마다 올리는 파일은 후보이고, 변경 건으로 통과한 것만 세트에 들어갑니다.

기준선 날짜 | 구두 합의를 변경으로 못 부르는 이유

날짜가 없는 합의는 기준선이 아니라 희망입니다. 회의에서 고개를 끄덕인 화면을 변경으로 부르려면 확인 주체, 첨부, 버전, 날짜가 한 줄에 있어야 하죠. 현장에서 구두로 범위를 맞추신 뒤 나중에 변경으로 못 부르는 분들이 많습니다. 서면 날짜가 없어서죠. 하지만 회의록만 쌓아 두면 첨부와 버전이 비어 이전 추가와 이후 변경이 갈리지 않습니다. 이번 포스팅에서는 확인 주체, 첨부 목록, 버전, 기준선 이전 추가, 이후 변경 처리까지 기준선 날짜를 어떻게 박을지 자세히 다뤄보도록 하죠. 구두 합의를 변경으로 못 부르는 상황을 고민 중이시라면 날짜와 첨부부터 칸을 채우는 데 도움이 될 것입니다.

칸	남겨야 하는 것	비면 생기는 일
날짜	확정일 하루	모든 추가가 원래 범위처럼 보임
확인 주체	서명 권한 있는 이름과 대리	기억 싸움, 팀 이름만 남은 공백
첨부	요구 ID, 파일명, 회의록 쪽수	다른 그림을 기준으로 개발
버전	파일 버전과 대장 번호	최종 파일이 여러 개로 갈림
이후 변경	CCB 건과 재검증 여부	범위 누수가 주간 반영으로 남음

기준선 한 줄에 남는 칸과 비면 생기는 일

확인 주체는 누구로 남겨야 기준선이 서나?

회의 참석자 전원이 아니라 서명 권한이 있는 한 명을 확인 주체로 둡니다. 팀 이름만 있는 칸은 다음 주에 이미 공백이죠. 부재 시 대리 이름까지 같은 칸에 적습니다.

주간회의에서 열 명이 고개를 끄덕여도, 그 고개가 기준선이 되지는 않습니다. 나중에 변경으로 부르려면 그때 무엇이 합의됐는지를 한 사람이 서명으로 남겨야 하죠.

확인 주체는 현업 팀장이거나 발주 측 요구 담당처럼 범위를 닫을 권한이 있는 이름입니다. 운영팀, 현업이라고만 적힌 칸은 두 주 뒤에 그 자리에 누가 있었는지를 아무도 기억하지 못하죠.

검증(Validation) 자리에서 시나리오를 통과시켜도, 그 시나리오가 어느 날짜 버전에 묶였는지가 없으면 통과는 통과일 뿐 기준이 아닙니다. 착수 4주 차까지 확인 주체 칸을 비우면, 중반 이후 변경 회의는 기억 싸움이 됩니다.

이름을 적고, 부재 시 대리 한 줄까지 같은 칸에 두세요.

첨부 목록이 비면 왜 합의가 아닌가?

합의 한 줄에는 화면 캡처, 요구 ID, 회의록 쪽수가 붙습니다. 첨부가 없으면 그 줄은 희망 사항이죠. 드라이브 링크만 남긴 칸은 다음 달에 증적이 사라집니다.

회의록에 정산 화면 포함으로 합의라고 적혀 있어도, 그 화면이 어느 와이어인지가 없으면 수행사는 다른 그림을 그립니다. 첨부 칸에는 요구 ID, 화면 파일명, 회의록 날짜와 쪽수, 엑셀이면 탭 이름까지 두세요.

파일이 세 개면 세 줄을 쓰고, 드라이브 링크만 덩그러니 두면 다음 달에 폴더가 바뀌어 증적이 사라집니다. WBS에 요구 확정 산출물을 올려 두었더라도, 그 산출물 안에 첨부가 비면 확정은 제목만 확정이죠.

첨부 개수를 주간보고 한 칸에 숫자로 남기면, 빈 합의가 몇 건인지가 보입니다. 빈 건수가 늘면 기준선 날짜를 잡아도 내용이 없습니다.

버전을 안 적으면 어떤 화면이 기준인가?

같은 화면 이름에 파일이 세 개면 기준은 없습니다. 버전과 날짜를 파일명과 대장에 같이 적으세요. 최종이라는 말만 바뀐 파일은 후보지 기준이 아닙니다.

요구정의서 v0.9, 화면정의서 최종, 최종_진짜가 한 폴더에 있으면 수행 개발자는 가장 최근 수정일을 찍습니다. 최근 수정일이 기준선은 아니죠.

기준선 날짜에 묶인 파일명과 버전 번호를 대장 한 줄에 고정합니다. 그 줄과 다른 파일이 돌면 그것은 이미 후보지일 뿐 기준이 아니죠.

버전을 주 단위로 올리지 않고 최종이라는 말만 바꾸면, 두 달 뒤 검수 조서의 화면과 개발 분기가 어긋납니다. 어긋난 분기는 변경이 아니라 혼선이죠.

혼선은 공수를 잡아먹지만 변경 대장에는 한 줄도 안 남습니다.

기준선 이전 추가는 변경이 아닌가?

기준선 날짜 전에 붙는 항목은 범위 추가입니다. 날짜 이후에 붙는 항목만 변경으로 태우세요. 한 엑셀에 섞어 쓰면 수행은 원래 범위로, 발주는 변경으로 읽습니다.

기준선 날짜를 비워 두면 모든 추가가 원래 범위처럼 보입니다. 날짜를 박은 뒤에는 그 전후가 갈리죠.

날짜 전에 현업이 화면 두 본을 더 달라고 하면 그것은 기준선에 넣는 추가이고, 공수와 일정을 다시 맞춘 뒤 같은 날짜로 닫습니다. 날짜 후에 같은 두 본이 오면 변경관리 안건이죠.

이전 추가와 이후 변경을 한 엑셀에 섞어 쓰면, 수행사는 원래 범위라고 읽고 발주사는 변경이라고 읽습니다. 같은 두 본을 두고 청구와 거절이 갈리는 이유가 여기 있어요.

기준선 확정 회의에 이전 추가 목록을 마지막 안건으로 올리고, 닫힌 뒤에 들어온 줄만 변경 대장으로 옮기세요.

기준선 이후 변경은 어디에 태우나?

날짜가 찍힌 뒤의 추가는 CCB 한 건입니다. 영향, 공수, 재검증 여부를 같은 주에 적지 않으면 수용이 아니죠. 네 칸 중 하나가 비면 그 건은 보류입니다.

기준선 날짜 이후 요청을 주간회의에서 그냥 반영하면, 그 반영은 변경이 아니라 범위 누수입니다. 변경 한 건에는 요청자, 영향 화면, 공수, 일정, 검증(Validation) 재수행 여부를 같이 적으세요.

네 칸 중 하나가 비면 그 건은 보류입니다. 보류를 개발 분기에 먼저 넣으면 기준선 파일이 다시 흔들리죠.

흔들린 파일은 첨부 목록의 버전과 달라지고, 검수 때 어느 화면이 맞는지를 또 묻게 됩니다. 날짜를 박는 이유는 거절을 잘하라는 게 아니죠.

이후 변경을 변경으로 부르기 위한 출발선입니다.