개발자가 쓴 임시 문장으로 오픈해도 되나

서버 연결 확인까지만 된다. 금액과 기한이 있는 문장은 업무 오너 승인본이 있어야 발송한다.

화면 문구와 문자 문구를 한 번에 검수하나

나누는 편이 낫다. 화면은 흐름이고 발송은 수신 행동이다. 한 시험에서 닫으면 둘 중 하나가 빠진다.

외부 심사가 반려되면 오픈을 미뤄야 하나

그 채널을 오픈 범위에 남길지만 결정한다. 재심사 여유일이 없으면 채널을 빼고 변경으로 남긴다.

오탈자 수정은 변경 요청인가

금액, 기한, 수신 대상이 그대로면 오탈자로 볼 수 있다. 그 셋 중 하나가 바뀌면 변경으로 다시 승인한다.

알림 문안 확정하기 - 문자와 메일 문구가 오픈 주에 멈추는 지점

오픈 주에 문자가 안 나가면 어디부터 보나. 서버가 죽은 경우보다, 문구 승인이 비어 있는 경우가 더 잦다. 결재 도착, 비밀번호 초기화, 장애 안내, 검수 요청. 이 문장들은 화면 카피가 아니라 발송 계약이다. 수신자가 보는 문장에 금액과 기한이 들어가면, 그 문장은 현업과 법무가 닫아야 한다. 개발자가 임시 문장으로 넣어 둔 채 리허설에 들어가면, 반려는 발송 직전에 나온다. 반려가 한 번 나면 그 주의 발송 리허설은 비고, 오픈은 문구 없이 나가거나 일정이 밀린다. 알림 문안을 누가 언제 확정하는지, 어떤 칸이 비면 발송이 멈추는지를 발주 시점 순서로 적는다.

칸	비어 있으면	닫는 사람
채널과 발송 시점	리허설 시각을 못 잡음	업무 오너
변수와 예시 값	금액이 빈 문자가 나감	업무 오너
글자 수와 잘림	문장이 중간에서 끊김	개발과 업무 오너
법무 확인	과장 문장이 운영에 남음	법무
외부 심사 상태	반려 주에 발송 연습이 빔	발송 담당

알림 문안을 닫기 전에 보는 칸

문구는 왜 화면 카피와 따로 보나

화면 문장은 업무 흐름을 안내하고, 발송 문장은 수신자의 행동과 금액을 묶는다. 승인 주체가 다르다.

화면의 안내 문구와 문자, 메일, 알림톡 문안을 한 파일에 두면 둘 다 늦게 닫힌다. 화면 문구는 버튼을 누르면 다음으로 가는 안내인 경우가 많다.

발송 문장은 수신자가 금액을 내고, 기한 안에 서류를 내고, 비밀번호를 바꾸는 행동과 붙는다. 행동이 붙으면 오탈자 하나가 민원이 된다.

착수 때 채널을 나누지 않으면 개발자는 임시 문장으로 채우고, 현업은 오픈 주에 처음 읽는다. 처음 읽는 주는 고칠 주가 아니다.

PM은 문구 목록을 화면 목록과 분리해 둔다. 분리된 목록에는 채널, 발송 시점, 변수, 수신 대상이 있다.

변수가 비어 있으면 그 문장은 아직 시험할 수 없다. 시험할 수 없는 문장을 리허설 당일에 채우면 발송 시각만 밀린다.

누가 사인해야 발송이 열리나

금액과 기한이 있는 문장은 업무 오너와 법무가 닫는다. 개발자 임시 문장만으로는 발송 채널이 안 열린다.

사인 칸은 개발 완료가 아니다. 업무 오너는 그 시점에 그 문장이 나가는 것이 맞는지 본다.

법무는 과장, 누락, 수신 동의 범위를 본다. 두 사인이 없으면 외부 채널 심사에 올리지 않는다.

외부 심사가 있는 채널은 반려 한 번에 그 주 리허설이 빈다. 금요일 오후에 반려가 나오면 월요일 발송 연습은 문구가 없다.

문구가 없는 연습은 서버 연결만 확인하고 끝난다. 연결 확인과 문장 확인은 다른 시험이다.

검증(Validation) 시나리오에 발송 문장 번호를 적는다. 시나리오 3번이 결재 도착이라면, 수신된 문장의 금액과 기한이 화면과 같은지도 같이 적는다.

화면과 문자가 다른 금액이면 합격이 아니다. 그 불일치는 결함 대장의 문구 항목으로 남긴다.

화면 결함 칸에 같이 적으면 문구 담당이 사라진다. 담당이 사라진 문장은 다음 주 회의에서 임시 문장으로 돌아온다.

변수와 길이는 언제 고정하나

변수 이름, 글자 수, 잘림 규칙을 문구 확정일에 같이 닫는다. 길이가 나중에 바뀌면 심사를 다시 한다.

문장 초안이 통과해도 변수가 바뀌면 다시 거절되는 채널이 있다. 고객명 자리에 부서명을 넣거나, 금액에 부가세를 빼면 이미 승인된 문장과 다른 문장이 된다.

확정일에는 변수 목록을 같이 닫는다. 변수명, 예시 값, 최대 길이, 빈 값일 때 대체 문장.

문자 90자를 넘는 문장은 잘리거나 잘림 안내가 필요하다. 잘림 규칙을 오픈 주에 정하면 리허설은 그 주가 아니라 다음 주가 된다.

메일 제목과 본문도 따로 둔다. 제목만 바꾸고 본문을 옛 금액으로 두면 수신자는 제목을 믿고 본문에서 멈춘다.

발주 산출물에 문구 시트를 한 장 넣는다. 시트 없이 메신저로 문장을 주고받으면 어떤 버전이 승인본인지 아무도 모른다.

승인본의 파일명과 날짜를 주간보고에 한 줄로 남긴다.

반려되면 일정은 어디로 밀리나

반려된 문장은 그 주 발송 리허설에서 뺀다. 서버 시험과 문장 시험을 같은 날로 묶어 두지 않는다.

반려를 당일 수정으로 처리하려는 제안이 먼저 나온다. 수정은 개발이 아니라 다시 승인과 다시 심사다.

그 시간을 WBS에 안 넣으면 오픈일만 고정된 채 발송이 빈다. 발송이 빈 오픈은 사용자는 들어왔는데 안내가 없는 상태다.

안내가 없으면 콜센터가 그 공백을 채운다. 콜 수를 줄이려고 만든 알림이 반대로 콜을 만든다.

일정은 이렇게 가른다. 문장 확정, 외부 심사, 반려 시 재심사, 발송 리허설.

재심사 칸의 여유일이 0이면 그 채널은 오픈 범위에서 빼는 결정을 같은 주에 한다. 변경관리에 빼는 이유를 남기지 않으면, 다음 주 회의에서 다시 오픈 범위로 들어온다.

들어온 문장은 또 심사를 기다린다. 기다리는 동안 개발자는 임시 문장으로 우회 발송을 만들고, 우회 발송은 운영에 남는다.

오픈 뒤 문구 변경은 어디에 두나

오픈 후 문장 수정은 장애 조치가 아니다. 변수와 금액이 바뀌면 변경 요청으로 다시 승인한다.

오픈 다음 날 현업이 문장을 더 친절하게 고쳐 달라는 요청이 온다. 친절의 범위가 오탈자면 당일 수정이 될 수 있다.

금액, 기한, 수신 대상이 바뀌면 당일 수정이 아니다. 그 변경은 다시 업무 오너와 법무를 거친다.

외부 심사가 있는 채널이면 재심사 일정도 붙는다. 이 구분을 운영 매뉴얼에 안 적으면 모든 문구 요청이 장애 채널로 들어온다.

장애 채널은 30분 응답을 약속한 곳이다. 문장 재승인을 30분에 끝낼 수는 없다.

끝내지 못한 약속이 주간 장애 숫자에 쌓인다. 오픈 점검표의 발송 항목은 세 칸이면 된다.

승인본 날짜, 리허설에서 수신한 샘플, 오픈 후 변경을 받을 창구. 샘플이 없으면 그 채널은 오픈 준비 완료가 아니다.

준비 완료를 서버 가동으로만 적지 않는다. 샘플을 받은 시각이 승인본 날짜보다 이르면, 그 리허설은 옛 문장을 받은 것이다.

옛 문장 리허설은 합격으로 넘기지 않는다.