요청의 영향과 근거

요청을 받았다고 작업 순서가 정해지지는 않습니다

동아리 운영자는 승인 알림, 신청자는 상태 조회, 회계 담당은 엑셀 내보내기를 요청합니다. 세 기능을 받은 순서로 만들면 먼저 말한 사람의 요구가 앞서고 조사한 문제는 뒤로 밀립니다. 제품 담당은 누가 더 강하게 요청했는지보다 어떤 업무가 어떤 조건에서 막히는지 비교합니다. 이번에는 Q01인 결과 경로 탐색 문제를 기준으로 요청의 영향과 근거 수준을 분리하여 첫 제안을 작성합니다.

연습 자료와 기록 공간

미션 starter를 별도 연습 폴더에 풉니다. Python 3과 Git만 사용하며 외부 서비스에 접속하지 않습니다. spec.json과 이전 JSON은 m05 solution에서 이어받은 원본이고 backlog.json이 새 제출물입니다. 첫 세 레슨은 문서 작성 실습이며 마지막 레슨은 별도 변경 비교 패키지를 사용합니다. JSON은 큰따옴표와 쉼표로 항목을 구분하고 마지막 항목 뒤에는 쉼표를 붙이지 않습니다. 문서 작업의 output은 비워 두고 실행한 명령의 결과만 기록합니다.

영향은 대상과 막힌 일을 함께 씁니다

상태 조회의 영향은 “모든 회원에게 편리함”보다 “결과 경로를 모르는 신청자가 접수 상태를 확인하기 위해 두 경로를 다시 탐색함”으로 적습니다. 영향의 대상, 발생 조건, 막힌 행동을 함께 적으면 다른 요구와 비교할 수 있습니다. 발생 횟수를 조사하지 않았다면 “매일 수십 건”이라고 채우지 않습니다. 신청 기간에만 생기는 문제인지 상시 문제인지도 미확인 질문으로 남겨 조사 범위를 정합니다.

관찰과 기대 효과를 분리합니다

E003은 두 경로를 열고 문의한 관찰이고 E006은 신청 양식에 결과표 안내가 없다는 관찰입니다. 이 자료는 경로 탐색의 불편을 뒷받침하지만 승인 알림이 문의를 얼마나 줄일지는 보여 주지 않습니다. 영향 칸에는 관찰된 불편을 적고 기대 효과 칸에는 아직 검증할 가설을 적습니다. “조회 경로를 제공하면 재탐색이 줄어들 수 있음”은 가설이며 이미 줄었다는 결과 보고와 구별해야 합니다.

반례는 판단을 좁히는 자료입니다

E005에서 다른 신청자는 결과표를 바로 찾았습니다. 반례를 숨기면 전체 신청자가 실패하는 문제로 확대하게 됩니다. 같은 경로라도 처음 온 사람과 익숙한 사람의 조건이 다를 수 있습니다. 반례 ID를 보존하고 이번 첫 범위를 결과 경로를 모르는 신청자로 좁힙니다. 반례가 있다는 이유만으로 불편을 없다고 처리하지 않고 문제가 생기는 조건을 더 구체적으로 설명하는 데 사용합니다.

근거를 요청마다 다르게 해석합니다

I01 상태 조회는 탐색 관찰과 직접 연결됩니다. I02 승인 알림은 조회하러 오지 않는 사람에게 도움이 될 가능성이 있지만 현재 조사에는 승인 후 방문 여부 기록이 없습니다. I03 엑셀 내보내기도 운영자 작업량 자료가 부족합니다. 세 요청에 같은 E003을 붙였다고 신뢰도가 같아지지 않습니다. confidence에 직접 근거인지 문제 배경만 공유하는지 쓰고, 없는 효과 자료를 추가로 수집할 질문을 남깁니다.

노력은 견적과 조건을 함께 제시합니다

이 연습의 개발 2~4일 같은 범위는 모의 추정이며 실제 일정 약속이 아닙니다. 목록 API 계약이 아직 없다는 조건을 effort에 붙이고 계약 검토 뒤 다시 추정하도록 적습니다. 화면 한 장이 간단해 보여도 본인 데이터만 반환하는 계약과 빈 목록·오류 처리가 필요합니다. 신입 담당자가 혼자 확정 일자를 약속하면 숨은 작업이 뒤늦게 나타납니다. 개발 담당에게 포함 작업과 제외 작업을 보여 주고 범위를 확인합니다.

숫자를 써도 불확실성은 남습니다

점수표를 사용한다면 영향 1~3의 의미와 판단 근거를 먼저 적습니다. 영향이 3이라는 사실만으로 조사 대상 전체에게 효과가 있다는 뜻은 아닙니다. 근거가 부족한 효과를 높은 점수로 채운 뒤 합계로 선택하면 추측이 객관적 결과처럼 보입니다. 점수는 대화를 돕는 표시이며 결정 이유를 대신하지 않습니다. 추정치 범위를 바꾸었을 때 순서가 바뀌면 추가 확인이 필요한 민감한 판단이라고 기록합니다.

위험은 평균 점수에 묻지 않습니다

다른 사람의 신청 정보가 보일 수 있는 요청은 대상 수가 작아도 접근 정책 검토가 필요합니다. 엑셀 내보내기의 요청자는 운영자지만 내보낼 필드와 담당 행사 범위는 아직 정해지지 않았습니다. 작은 노력이라는 이유만으로 먼저 제공하지 않습니다. 개인정보·권한 문제는 개발 완료 뒤 확인할 장식이 아니라 제공 조건입니다. m04 정책을 참조하고 현재 근거로 승인할 수 없는 범위를 hold로 남깁니다.

채택과 보류는 둘 다 설명합니다

I01은 Q01 직접 대응을 검증하기 위해 adopt로 제안합니다. I02는 승인 이벤트와 전송 실패 계약이 미결이라 hold, I03은 운영자 작업량과 내보낼 필드가 미확인이라 hold로 제안합니다. hold는 가치가 없다는 판정이 아닙니다. revisit에 언제 어떤 자료를 보고 다시 판단할지 적습니다. “나중에” 대신 “첫 조회 과업 관찰 뒤 승인 후 방문 여부를 확인”처럼 재검토 계기를 쓰면 보류가 방치로 바뀌지 않습니다.

비교표를 의사결정 문장으로 바꿉니다

표 아래에는 “결과 경로 탐색 근거가 있는 상태 조회를 먼저 검증하고, 알림 효과와 운영자 내보내기 작업은 추가 조사 후 재평가합니다”라고 씁니다. 이 문장은 선택한 요청, 이유, 제외한 요청, 다시 볼 조건을 포함합니다. 기능 목록을 전부 적은 표보다 결정의 경계를 읽기 쉽습니다. 모의 자료를 보고 작성한 제안이라는 basis=proposed를 유지하며 실제 이해관계자의 합의가 있었다고 보고하지 않습니다.

틀린 근거 연결을 찾아 고칩니다

동료가 “엑셀은 E003 때문에 필요하다”고 적었다면 E003이 기록한 행동을 다시 읽습니다. 신청자의 경로 탐색은 운영자의 내보내기 반복 작업을 증명하지 않습니다. 같은 문제 배경을 공유한다는 연결은 유지할 수 있지만 직접 효과 근거라고 설명하지 않습니다. 없는 ID를 만드는 대신 운영자에게 어떤 파일을 얼마나 자주 옮기는지 질문할 계획을 남깁니다. 근거의 존재와 해석의 적절성을 따로 검토합니다.

완료 기준은 선택을 설명할 수 있는 상태입니다

제출 전에 동료가 세 요청 중 하나를 바꾸어 추천해 보게 합니다. 왜 그 선택이 더 낫다고 생각하는지 들으면 자신의 기준이 숨겨져 있는지 알 수 있습니다. 중요하다는 형용사만 남아 있으면 대상과 조건을 보완합니다. 가설을 사실처럼 읽을 수 있으면 confidence를 수정합니다. 이번 레슨을 마쳤다는 것은 비교표가 채워졌다는 뜻보다 주어진 근거로 무엇을 선택하고 무엇을 아직 판단할 수 없는지 설명할 수 있다는 뜻입니다.