유지·수정·추가 조사 판단

결과를 다음 판단의 입력으로 바꿉니다

프로젝트 마지막 보고에서 “좋아졌으므로 계속합니다”라고만 쓰면 담당자는 무엇을 유지하고 어떤 조건에서 다시 검토할지 알 수 없습니다. 제품 담당의 판단은 결과, 불확실성, 행동, 판단을 바꿀 조건을 함께 제시하는 일입니다. 행사 신청 사례에는 문구·경로 초안, 가상 재확인, 별도 가상 이벤트, 미해결 지원 문의가 있습니다. 한 자료의 긍정적인 결과로 나머지 질문을 닫지 않습니다. 다음 행동을 결정할 때는 그 행동에 필요한 근거가 무엇인지 먼저 정합니다.

유지·수정·추가 조사를 구분합니다

유지는 현재 확인한 범위의 표현이나 확인 방법을 그대로 쓰는 선택입니다. 수정은 관찰한 막힘에 대응해 문구·경로·절차를 바꾸는 선택입니다. 추가 조사는 원하는 결론을 지지할 자료를 더 모으는 일이 아니라 아직 구별되지 않은 조건을 확인하는 선택입니다. 세 선택은 프로젝트 전체에 하나만 적용하는 표지가 아닙니다. FAQ01의 좁은 가상 확인 조건은 보존하고 빈 상태 N01은 조사하며 실제 확대 적용은 보류할 수 있습니다. summary.recommendation은 제공 근거 전체의 수준에 맞춰 additional-research로 씁니다.

계산한 차이와 원인 주장을 나눕니다

metrics.json의 이벤트 전 성공률은 2/4인 50.0%, 후 성공률은 3/4인 75.0%입니다. 둘의 차이는 25.0퍼센트포인트입니다. 상대 증가율과 다른 값이므로 “25% 증가”처럼 단위 없이 쓰지 않습니다. 이 숫자는 같은 계산 규칙으로 가상 자료를 요약한 결과입니다. R01·R02를 함께 바꿨고 반복 노출·기기·행사 난이도를 통제하지 못했으므로 어느 수정이 차이를 만들었는지 확정하지 않습니다. comparison.causalClaim=false는 바로 그 미입증 상태를 드러냅니다.

분모를 바꾸어 좋아 보이게 만들지 않습니다

완료율 분모는 유효 시도 전체이며 실패·도움·미확인을 포함합니다. 후 기간에 도움받은 시도가 있다고 분모에서 빼면 계약이 바뀝니다. 성공 시간의 평균은 성공한 시도만 대상으로 계산되어 전체 사용자 대기 시간이 줄었다는 주장을 뒷받침하지 않습니다. 보고서에는 완료율과 성공 시간의 대상이 다르다는 점을 씁니다. 빈 자료가 생겼을 때 성공률을 0이나 100으로 대입하지 않고 미정의 상태로 다룹니다. 지표를 해석할 때 숫자 앞에 대상·단위·기간·제외 조건을 확인합니다.

행동과 숫자가 어긋나면 질문을 만듭니다

후 성공률이 더 높아도 관찰에서는 빈 내역과 권한 안내가 확인되지 않았습니다. 평균 성공 시간이 짧아졌어도 도움이 필요했던 시도는 따로 남아 있습니다. 이런 차이는 어느 자료를 버릴지 고르는 문제가 아니라 무엇을 아직 관찰하지 않았는지 찾을 단서입니다. O06은 새 가상 참여자 한 명의 정상 경로 이해이며 모든 상태 이해를 보여 주지 않습니다. 다음 조사 과업에는 UI-empty와 오류 경로를 따로 넣습니다. 숫자와 관찰의 범위가 다를 때 둘을 같은 성공 척도로 합치지 않습니다.

불확실성은 확인 가능한 질문으로 바꿉니다

“표본이 적습니다”만 적으면 다음 사람이 무엇을 해야 할지 모릅니다. L01은 실제 동의 관찰의 출처·표본을 기록하는 행동으로, L02는 이전 노출 여부를 확인하고 새 참여자를 모집하는 행동으로 바꿉니다. L03은 기기·과업·도움 조건을 기록하고 단독 수정 판단이 필요할 때 변경을 분리하는 행동으로 바꿉니다. 조사 계획은 모르는 조건과 확인 수단을 짝짓습니다. 새 자료가 모든 문제를 한 번에 해결할 것처럼 쓰지 말고 무엇을 구별할 수 있게 되는지 적습니다.

판단을 바꿀 조건은 결론보다 먼저 검토합니다

nextActions의 changeCondition은 어떤 관찰이 나오면 현재 선택을 다시 검토할지를 말합니다. “문제가 있으면 수정”은 누구나 다른 뜻으로 읽습니다. N01에서는 빈 내역에서 계정 안내를 잘못 해석해 반복 시도하는 행동이 확인되면 안내 수정 후보를 검토합니다. N02에서는 권한 누출이나 중복 저장 의심이 나오면 확대 적용을 보류하고 조사합니다. 이는 가상의 경고 조건이지 이미 발생한 결함 기록이 아닙니다. 새 조건을 기존 자료의 사실인 것처럼 표시하지 않습니다.

정책 미결과 검증 미완료를 나눕니다

D01은 승인 인원 기준으로 정원 집계를 바꾸자는 제안이며 업무 정책 결정이 필요합니다. N02는 구현 뒤 키보드·권한·네트워크 회귀를 확인해야 하는 과제입니다. 둘을 “테스트가 남음”으로 묶으면 결정권자를 놓칩니다. 정책은 행사 업무 담당이 동시 승인·취소 시 정원 반환 조건을 합의하고 개발 담당은 이를 구현 검증 항목으로 바꿉니다. 제안서에서 D01은 proposed를 유지합니다. 화면에 참가 미확정 문구를 넣었다는 사실이 정원 집계 정책의 승인을 뜻하지 않습니다.

보류 작업을 다시 여는 이유를 씁니다

I02 승인 알림과 I03 내보내기는 hold 상태입니다. 단순히 시간이 남았다는 이유로 채택하지 않습니다. I02는 I01 이후에도 승인 후 방문하지 않는 조건의 불편이 새 근거로 확인되는지 조사합니다. I03은 운영자의 수작업 영향과 필요한 필드·권한을 확인합니다. 의존성은 기능 순서뿐 아니라 개인정보 접근과 검증 준비도 포함합니다. 담당·검토 시점·재논의 근거를 넣으면 보류가 잊힌 작업이 아니라 근거를 기다리는 선택이 됩니다. 추정 개발 기간을 확정 일정으로 바꾸지 않습니다.

지원 미해결은 지금 필요한 조치를 포함합니다

SUP03 저장 여부는 아직 모릅니다. 다음 행동은 성공률 그래프를 더 만드는 것이 아니라 중복 제출 전에 본인 내역과 허용 요청 기록으로 결과를 확인하는 것입니다. 내역 조회도 실패하면 저장 미확인 상태와 최소 증거로 개발 담당에게 이관합니다. SUP02는 본인 경로 안내 뒤 결과를 확인합니다. 두 문의를 unresolved라는 한 단어로 끝내지 않고 담당과 확인할 결과를 붙입니다. 목적을 달성했다는 새 근거가 있어야 닫을 수 있지만 이번 제공 fixture에서는 pending 상태를 유지합니다.

언제까지 무엇을 하면 끝나는지 제안합니다

nextActions의 when에는 검토 시점과 일정 합의 여부를 씁니다. 실제 팀이 합의하지 않았다면 “다음 행사 전 검토 제안, 담당 합의 대기”라고 적습니다. done은 자료 수가 아니라 완료 판단의 근거입니다. 예를 들어 N02는 구현된 정상·빈 상태·오류별 회귀 결과와 버전이 연결되는 것이 완료 조건입니다. owner가 “모두”이면 누구에게 질문할지 알기 어렵습니다. 역할을 구체화하고 정책 결정·구현·검증·지원 확인의 책임을 나눕니다. 임의 날짜를 서비스의 해결 약속처럼 안내하지 않습니다.

다음 판단의 검토 기준

nextActions는 SUP02·SUP03·D01·I02·I03·N01·N02의 일곱 항목입니다. 항목마다 현재 상태, 근거, 담당, 행동, 시점, 변경 조건, 완료 기준을 채웁니다. FAIL nextActions는 ID·순서·상태·필드 중 무엇이 빠졌는지 README와 비교할 신호입니다. FAIL comparison은 원본 metrics의 숫자와 자료형을 먼저 대조합니다. 통과 뒤에는 각 행동이 실제 불확실성을 줄이는지 사람이 읽습니다. 작은 가상 차이로 운영 확대를 확정하거나 신규 조사를 수행 완료로 쓰지 않았는지 점검하면 다음 담당에게 정직한 판단 출발점을 넘길 수 있습니다.