사용자와 업무 범위

전체 학교 업무 대신 하나의 흐름을 고릅니다

동아리 신청 업무를 개선한다고 할 때 가입 신청, 행사 신청, 회비 결제, 출석 관리가 한꺼번에 떠오를 수 있습니다. 모든 일을 한 번에 조사하면 참여자에게 묻는 질문도 넓어지고 어떤 결과를 제출할지 모호해집니다. 범위는 관심이 없는 일을 버리는 선언이 아니라 이번에 판단할 질문의 경계를 정하는 약속입니다. 이 레슨에서는 행사 신청 시작부터 승인 또는 반려 결과 확인까지를 연속된 흐름으로 정리합니다.

아직 실제 사용자의 문제를 선택하지 않았으므로 범위는 조사 가설입니다. ‘이 구간에서 상태 확인 불편이 있는지 알아본다’라고 적으면 검증할 여지가 남습니다. ‘모든 신청자는 승인 화면이 필요하다’라고 쓰면 조사 전에 결론이 굳습니다. 사용자의 행동을 듣고 범위를 바꿀 수 있지만 변경 이유와 제외되는 자료를 기록해야 앞선 근거를 다른 결론의 근거로 오해하지 않습니다.

사용자 역할과 원하는 결과를 연결합니다

사용자는 제품을 구매하는 사람만 뜻하지 않습니다. 신청서를 제출하는 신청자와 신청을 검토하는 행사 운영자는 같은 업무에서 다른 목표를 가집니다. 신청자는 제출 여부와 결과를 알아야 하고 운영자는 신청 정보를 검토하고 결과를 전달해야 합니다. 두 역할의 목표를 각각 쓰면 한 화면의 편리함이 다른 역할의 부담으로 바뀌는 조건도 조사할 수 있습니다. 소속이나 성별보다 업무 행동을 기준으로 구분합니다.

사용자 ID	역할	목표	물어볼 사례
U01	신청자	신청 결과를 확인해 다음 행동을 정합니다.	최근 신청 후 결과를 확인했던 순서
U02	행사 운영자	신청을 검토하고 결과를 전달합니다.	최근 검토를 마친 뒤 결과를 알린 방법

U01과 U02는 사용자 유형의 식별자입니다. 조사 참여자 P01과 P02는 실제 조사에서 가명으로 구분할 개별 참여자 번호입니다. 한 유형에 여러 참여자가 속할 수 있으므로 둘을 섞지 않습니다. 역할 두 종류를 적었다고 사용자 두 명을 인터뷰한 것은 아닙니다. 다음 모듈에서 참여자를 만날 때 유형마다 어떤 사례를 들을지 준비하는 표가 이번의 산출물입니다.

시작과 종료를 관찰할 수 있는 사건으로 씁니다

‘신청부터 승인까지’는 짧지만 승인한 운영자와 승인 사실을 확인한 신청자 중 누구를 종료 기준으로 삼는지 불명확합니다. 시작은 ‘신청자가 행사 공지를 보고 신청을 시작함’, 종료는 ‘신청자가 승인 또는 반려 결과를 확인함’으로 적습니다. 저장 완료, 운영자 검토 완료, 사용자 결과 확인은 서로 다른 사건입니다. 문의가 결과 전달 사이에서 발생한다면 검토 완료에서 조사를 끝내면 핵심 구간이 빠집니다.

흐름은 신청 시작, 제출, 운영자 검토, 결과 전달, 결과 확인으로 나눕니다. 각 단계마다 행동 주체, 그 단계가 끝났음을 보여 주는 것, 다음 단계로 전달되는 정보를 적습니다. 제출 단계에서는 신청자가 제출 버튼을 누르고 접수 사실을 확인합니다. 운영자 검토 단계에서는 운영자가 결과를 결정합니다. 이 표는 구현 명세가 아니라 현재 업무에서 어떤 일이 일어나는지 확인할 조사 틀입니다.

반려 결과를 종료 사건에 포함하는 이유는 승인되지 않아도 사용자가 결과를 알아야 하기 때문입니다. 승인 사례만 조사하면 반려 사유를 못 찾는 불편이 빠질 수 있습니다. 결과가 아직 결정되지 않은 상태도 질문 후보로 남깁니다. 다만 이 레슨에서 대기 기간이나 승인 규칙의 숫자를 임의로 정하지 않습니다. 실제 규칙을 설명할 운영자에게 확인할 사항으로 표시합니다.

포함·제외·의존 조건을 분리합니다

포함 목록은 이번에 직접 살필 단계입니다. 신청 제출, 운영자 검토, 상태 확인을 넣습니다. 제외 목록에는 회비 결제와 행사 출석 관리를 두고 ‘신청 결과 전달 흐름을 먼저 조사하기 위해서’라는 이유를 붙입니다. 제외는 존재를 부정하는 말이 아닙니다. 해당 업무가 현재 조사 판단에 미치는 영향을 발견하면 의존 조건으로 기록하고 범위를 다시 검토할 수 있습니다.

로그인 없이 신청 결과를 볼 수 없다면 로그인은 흐름에 영향을 주는 선행 조건입니다. 이번 조사에서 로그인 체계 전체를 설계할 필요는 없지만 ‘로그인한 신청자의 결과 확인을 우선 조사하며 로그인 실패 문의는 별도 분류한다’처럼 조건을 표시합니다. 제외 항목만 나열하고 이런 조건을 지우면 실제 사용자의 시작점과 조사자의 시작점이 달라질 수 있습니다. 무엇을 다루지 않는지와 무엇이 필요하다는 사실을 함께 읽습니다.

의존 조건이 불확실하면 질문과 확인 대상을 남깁니다. ‘회비를 낸 사람만 승인되는가’는 추측을 규칙으로 저장하지 않고 운영자에게 확인할 질문으로 씁니다. 사실로 확인된 뒤에는 결제 구현을 조사 범위에 넣을지, 결제 여부만 외부 입력 조건으로 다룰지 결정합니다. 범위를 작게 만드는 데만 집중하지 않고 선택한 구간을 설명하는 데 필요한 정보가 빠졌는지 봅니다.

같은 범위를 다른 사람이 읽게 합니다

범위표를 동료에게 주고 ‘신청자가 제출 완료 문구는 봤지만 결과를 못 찾는 상황이 포함되는가’라고 묻습니다. 포함된다고 답하려면 종료가 신청자의 결과 확인으로 되어 있어야 합니다. 이어 ‘행사 당일 출석 QR이 안 찍히는 상황도 조사하는가’라고 묻습니다. 제외 목록의 출석 관리를 근거로 이번에는 별도 과제라고 설명할 수 있으면 경계가 읽히는 상태입니다.

검토자가 다른 답을 했으면 문장이 애매한지 기준이 충돌하는지 살핍니다. 시작과 종료가 너무 넓거나 포함과 제외에 같은 단어가 들어 있으면 먼저 고칩니다. 두 역할 중 한 역할의 목표가 빠져 있다면 사용자 표를 보완합니다. 한쪽을 지워 표를 간단하게 만드는 것은 문제를 해결하지 못합니다. 최소한 신청자와 운영자의 행동을 연속해서 따라갈 수 있어야 합니다.

범위 변경은 이유와 연결해 남깁니다

조사 중 운영자가 “반려 결과는 별도 메신저로 전달한다”고 설명하면 결과 전달 구간의 중요성이 달라질 수 있습니다. 그 설명을 새로운 근거로 기록하고 기존 결정에 무엇을 더하는지 씁니다. ‘결과 전달도 포함’이라는 문장만 덮어쓰면 처음부터 알고 있었던 사실처럼 보입니다. 가상 사례에서 정한 범위와 실제 조사 후 확인한 범위를 구분하면 제안서의 발전 과정을 설명할 수 있습니다.

제출할 범위표에는 두 사용자 유형, 시작과 종료, 단계별 담당, 포함과 제외, 확인 질문을 넣습니다. 사람이 각 단계에서 무엇을 하는지 설명할 수 있으면 다음 레슨의 동의문에서도 조사 목적을 구체적으로 말할 수 있습니다. 실제 인터뷰 질문을 길게 만들기 전에 이 표를 읽고 어떤 최근 경험을 들으면 범위 안의 행동을 확인할 수 있을지 한 문장으로 적습니다.

유형 ID | 업무 역할 | 원하는 결과
U01 | 신청자 | 신청 결과 확인
U02 | 행사 운영자 | 검토와 결과 전달