PMDEXIT 프로젝트 용어사전

요구 원천 로그 남기기 - 인터뷰 메모와 확정 명세를 같은 문장으로 두지 않기

“메모는 아직 명세가 아니다”

문제요구사항 식별인터뷰 메모요구 명세

인터뷰 메모 40줄을 요구 명세 본문에 그대로 올리면, 검수 때 어떤 문장이 합의였는지 구분될까요? 현업의 희망과 규정의 의무, 민원으로 들어온 예외가 같은 문단에 들어가 있으면 전부 범위처럼 보입니다. 식별은 원천을 넓게 모으는 단계이고, 명세는 그중에서 이번에 만들 문장만 남기는 단계죠. 원천 칸이 없으면 회의에서 나온 말이 다음 날 기준선에 들어가고, 빠질 때는 변경 절차 없이 조용히 사라져요. 원천 종류와 확정 여부를 요구 ID 옆에 두는 방법을 적습니다. 워크숍 메모를 다음날 명세로 올리고 있다면, 로그 열 하나가 검수 때의 다툼을 줄이는 데 도움이 됩니다.

원천바로 명세에 넣나옆에 남길 칸
인터뷰희망일 수 있어 확정 전엔 보류발언자, 날짜, 확정 여부
규정의무 후보면 후보로만조항 번호, 적용 화면
민원예외 후보최근 기간의 건수, 오픈 포함 여부
기존 화면현행일 뿐 범위는 아님유지 또는 폐기
운영 데이터통계 근거건수와 기준 기간
요구 원천별로 명세에 올리기 전에 남길 칸

메모를 명세로 바로 올리면 검수에서 무엇이 남을까?

희망과 합의가 같은 문장으로 남으면, 검수는 문장마다 범위 다툼이 됩니다.

워크숍이 끝나면 회의록 40줄이 다음 날 요구 목록으로 붙는 현장이 있습니다. 그 목록으로 화면을 만들면 진척은 올라가요.

검수 조서를 열었을 때 차이가 드러납니다. 현업은 그때 그렇게 말했을 뿐이라고 하고, 수행은 목록에 있으니 범위라고 합니다.

회의록만 보면 둘 다 맞는 말처럼 들려요. 요구사항 식별은 원천을 모으는 일이라, 모은 문장 전부가 이번에 만들 범위는 아닙니다.

범위는 확정 열이 예인 문장만입니다. 확정 열이 없는 목록은 메모의 다른 이름이에요.

메모를 설계 입력으로 쓰면 설계가 희망의 평균을 구현하고, 그 평균은 아무도 사인하지 않은 화면이 됩니다. 사인 칸이 빈 화면은 시험 마지막 주에 보류 사유로 돌아옵니다.

원천은 어떤 종류로 나누면 될까?

인터뷰, 규정, 민원, 기존 화면, 운영 데이터로 나누면 확정 주체도 같이 갈립니다.

한 열에 요구라고만 적으면 다섯 종류의 말이 같은 무게가 됩니다. 인터뷰는 발언자와 날짜가 필요하고, 규정은 조항 번호가 필요하며, 민원은 최근 3개월 건수가 필요해요.

기존 화면은 유지할지 없앨지의 결정이 필요하고, 운영 데이터는 기준 기간이 필요합니다. 이 다섯을 요구 ID 옆 원천 칸에 적으면 빠진 근거가 바로 보입니다.

조항 번호가 없는 규정 요구는 아직 원천이 확인되지 않은 상태예요. 건수가 없는 민원 요구는 예외인지 본경로인지 알 수 없어요.

확인 전 문장에는 설계 착수일을 넣지 않습니다. 넣었다가 빼는 일이 재작업 공수가 되기 때문입니다.

재작업은 진척률을 깎지 않고 잔여 일수만 늘리는 쪽으로 나타나요.

희망과 의무는 왜 다른 열에 적어야 할까?

의무는 빠지면 근거가 깨지고, 희망은 빠지면 우선순위의 문제입니다. 열을 나누면 일정이 의무 쪽으로 기웁니다.

있으면 좋겠다는 화면과, 규정에 계산식이 적힌 화면을 같은 순위로 두면 일정이 의무가 아닌 쪽으로 기울 수 있어요. 의무 열에는 근거 번호를 적고, 희망 열에는 말한 사람과 대체 수단을 적어요.

대체 수단이 있으면 희망은 이번 오픈에서 빠져도 업무가 멈추지 않습니다. 근거 번호가 있는 의무는 오픈 범위에서 빼기 전에 변경관리 안건으로 올립니다.

열을 나누지 않으면 의무가 희망 사이에 묻히고, 묻힌 의무는 검수 주 준법이나 보안 지적에서 다시 나와요. 그때 고치는 일정은 오픈 범위의 임계경로가 돼요.

지적이 나온 뒤에 근거 번호를 찾는 데는, 식별 주에 한 칸 적는 것보다 긴 시간이 걸립니다.

확정 전 문장을 설계에 넣으면 어떻게 될까?

확정 전 설계는 진척으로 보이다가, 확정 날에 재작업 일수로 돌아옵니다.

설계자를 기다리게 두지 말자는 이유로, 미확정 문장에도 화면 ID를 붙이는 경우가 있습니다. 화면 ID가 붙으면 일정표는 그 줄을 진행 중으로 표시해요.

2주 뒤에 현업이 그 문장을 거절하면 진행률은 내려가지 않고 재작업 일수만 추가됩니다. 추가된 일수는 원래 일정에 없습니다.

검증(Validation)에서 고객이 사인하는 대상은 확정 문장과 그에 대응하는 시나리오예요. 미확정 문장으로 만든 화면은 사인 칸이 비고, 빈 칸은 검수 보류 사유가 돼요.

설계 착수 조건은 원천이 적혀 있고 확정 열이 예인 줄로 두는 편이 맞습니다. 먼저 그려 보는 줄은 폐기 가능한 검토용이라고 별도 표시합니다.

표시가 없으면 검토용 화면도 3장, 4장씩 범위로 남아요.

변경으로 올릴 때 어느 칸을 볼까?

확정 열을 뒤집는 수정만 변경입니다. 메모 문장을 다듬는 일은 식별을 한 번 더 하는 일입니다.

표현을 고치는 일과 확정 범위를 늘리는 일이 같은 변경요청으로 들어오면 심의 건수가 불어나요. 원천 로그가 있으면 둘은 갈려요.

발언 메모를 더 분명한 문장으로 고치고 확정 열은 그대로면 변경요청 번호가 필요 없습니다. 확정 열이 아니오에서 예로 바뀌거나 의무 근거가 새로 붙으면 그때 변경입니다.

이 구분이 없으면 문구 수정마다 회의가 열리고, 진짜 범위 증가가 그 사이에 묻혀요. 묻힌 증가는 시험이 끝난 뒤에야 화면 차이로 보여요.

로그의 확정 열과 근거 칸이 바뀌었는지만 변경 목록의 첫 열로 쓰면, 심의 건수는 표현 수정만큼 줄어듭니다. 줄어든 시간으로 공수와 일정 영향 칸을 채울 수 있습니다.

자주 묻는 것

회의록 전체를 요구 ID로 만들면 안 되나
만들 수 있습니다. 다만 확정 열이 예인 ID만 설계와 검수에 연결합니다. 나머지는 원천 로그로 남겨요.
현업이 회의에서 말한 것은 전부 합의인가
발언은 원천입니다. 합의는 확정 열과 근거 칸이 채워지고 확인 주체가 남긴 문장입니다.
규정 조항을 아직 못 찾으면 어떻게 적나
조항 미확인으로 적고 설계 착수일에서 뺍니다. 빈칸인 채로 화면 ID를 부여하면 재작업 일수가 됩니다.
문구만 고칠 때도 변경회의가 필요한가
확정 여부와 근거가 그대로면 식별 목록에서 고칩니다. 확정 열이 바뀌거나 의무 근거가 새로 붙으면 변경으로 올립니다.

관련 용어

출처

다른 가이드