요구 우선순위 MoSCoW 읽기 - Should를 계약 범위로 오해하는 지점

Should를 하면 좋은 기능으로 적어도 계약에 남나?

제안서나 과업 내용에 문장이 들어가면, Should 라벨은 범위를 지켜 주지 않습니다. 포함 여부가 별도 칸이어야 합니다.

워크숍에서 Should는 있으면 좋다는 말로 통합니다. 그 문장을 제안서 기능 표에 그대로 붙이면, 평가위원은 구현 대상으로 읽죠.

낙찰 뒤에 수행사가 여유분이라고 말하면, 발주사는 제안서 쪽수를 펼칩니다. 우선순위 라벨은 순서이고, 계약 범위는 포함과 제외입니다.

둘은 다른 열입니다. 요구사항 식별 회의록에 Should라고 적힌 줄도, 기준선으로 올릴 때 포함 여부를 Y 또는 N으로 다시 받아야 합니다.

Y도 N도 없으면 그 줄은 아직 요구가 아닙니다. 아직인 줄을 개발 스프린트에 넣으면, 검수에서 그 줄은 Must로 돌아옵니다.

라벨이 약해서가 아니라, 뺀다는 서명이 없어서입니다. 포함 칸을 잠근 회의의 참석자 명단을 기준선 첫 페이지에 붙이면, 나중에 누가 Y를 말했는지가 메일함 검색에 기대지 않죠.

Must와 이번 오픈 범위는 같은 말인가?

같지 않습니다. Must는 워크숍의 급한 순서이고, 이번 오픈 범위는 일정과 검수 시나리오에 들어간 줄입니다.

Must가 80개인데 오픈까지 6주라면, 80개를 전부 이번 범위라고 부르는 순간 일정이 먼저 깨집니다. 급한 것과 이번에 할 수 있는 것은 다른 질문이죠.

Must 안에서도 검수 시나리오에 넣은 줄만 이번 오픈으로 확정합니다. 나머지 Must는 아직 급한 후보로 두고, WBS의 어느 작업에 붙는지 적습니다.

작업에 안 붙는 Must는 구호입니다. 구호를 범위로 세면 진척률의 분모만 커집니다.

분모가 커진 진척은 낮아 보이고, 낮아 보인 진척은 인력을 더 넣자는 말로 이어집니다. 인력 전에 할 일은 Must 목록에서 이번 시나리오 ID가 있는 줄만 남기는 것입니다.

시나리오 ID가 없는 Must는 다음 확인 회의의 첫 안건입니다. 미정 행은 개발 보드에 올리지 말고, 확인 회의 안건 목록에만 두세요.

Could를 워크숍에서 지우면 나중에 왜 돌아오나?

지운 줄이 제외 목록에 없으면, 현업은 잊힌 요구로 기억합니다. 제외는 삭제보다 서명된 목록이 안전합니다.

Could와 Won't를 회의 중에 행 삭제하면 자리가 깔끔해 보입니다. 석 달 뒤 검수에서 그 문장이 다시 나오는 이유는, 삭제에는 동의한 사람 이름이 없기 때문이죠.

안 하기로 한 줄은 제외 목록으로 옮기고, 옮긴 날짜와 확인자를 남기세요. Won't this time이라는 영어 라벨만 있으면, 한국어 조서에서는 이번에 안 함인지 영원히 안 함인지가 갈라집니다.

이번 오픈 제외인지, 사업 전체 제외인지를 한국어로 적습니다. 이번 오픈 제외는 다음 개선 후보가 될 수 있습니다.

사업 전체 제외는 다음 RFP에도 안 넣는 줄입니다. 변경관리는 이 목록에 새 줄을 추가할 때 열고, 이미 제외된 줄을 몰래 되돌릴 때도 엽니다.

제외 목록이 없으면 변경위원회는 매번 처음부터 범위를 다시 읽습니다.

우선순위 표를 기준선 문서와 어떻게 연결하나?

기준선에는 라벨 대신 포함, 제외, 미정만 남깁니다. 라벨은 워크숍 원본에 두고 버전만 참조합니다.

기준선 문서가 MoSCoW 색칠 표 자체이면, 색을 바꾸는 일이 곧 범위 변경이 됩니다. 색 변경은 하루에도 몇 번 나옵니다.

그걸 전부 변경 절차에 태우면 절차가 멈추죠. 기준선은 문장과 포함 여부, 시나리오 ID, 확인 날짜면 충분합니다.

MoSCoW 원본은 첨부 버전으로 가리킵니다. 원본의 Should가 기준선에서 N이면, 검수에서 보는 것은 N입니다.

원본만 보고 Y라고 우기면 첨부 버전 번호를 대조합니다. 버전 번호가 없으면 어떤 워크숍이 이겼는지 알 수 없습니다.

착수 때 기준선 확정일을 하나 두고, 그 날짜의 포함 열을 잠그세요. 잠근 뒤의 라벨 변경은 변경 번호가 있어야 포함 열을 고칩니다.

번호 없이 색만 바꾸면 개발은 새 색을 범위로 착각합니다. 잠금 날짜를 문서 머리말에 적지 않으면, 어느 버전이 잠긴 것인지가 첨부 파일명만으로 남지 않죠.

평가 때 우선순위 표만 보면 무엇이 빠지나?

포함 여부와 제외 서명이 없는 제안은, 기능 수가 많아 보여도 검수 분모가 비어 있습니다.

기술 평가가 기능 행 개수만 세면, 제안사는 Should와 Could까지 표에 넣습니다. 행이 많은 제안이 높은 점수를 받죠.

높은 점수의 표가 계약에 편철되면, 그 행은 전부 이번 범위처럼 보입니다. 평가 칸에 포함과 제외의 샘플을 요구하면 행 수 경쟁이 줄어듭니다.

이번 오픈 시나리오 10개, 제외 5개, 각 제외의 확인 방식. 이 칸이 비어 있는 제안은 착수 4주가 워크숍 재방송이 됩니다.

재방송 동안 개발은 대기하고, 대기는 맨먼스만 소진합니다. 발주서가 이미 나갔다면, 착수 첫 회의에서라도 포함 열을 다시 받으세요.

다시 받는 회의의 산출물은 새 기능 목록이 아니라, 제안서 행마다 붙인 Y, N, 미정입니다. 미정이 20%를 넘으면 그 사업의 범위는 아직 착수 전입니다.

평가 점수표에 제외 예시가 없으면 기능 행 개수 경쟁이 착수 뒤에도 다시 시작되죠.