Загружаем каталог…
Загружаем каталог…
CS 실시간 대시보드 요청서가 왔다. 위젯 5종. 전체 미처리 건수 경로별 미답변 문의 유형별 분포 담당자별 처리 부하(%) SLA 경보 데이터를 뒤져보고 2종만 만들었다. 나머지 3종은 "왜 못 만드는지"를 PR 본문에 표로 적어서 냈다. 이 글은 그 표에 대한 이야기다. 먼저 데이터를 본다 요청서를 받으면 바로 화면부터 그리고 싶어진다. 위젯 5개면 카드 5개니까. 그런데 대시보드 위젯은 데이터가 있어야 존재할 수 있다. 그래서 순서를 뒤집었다. 5개 각각에 대해 "이 값을 지금 데이터로 계산할 수 있나"를 먼저 확인했다. 1 전체 미처리 건수 — 이미 있다 화면에 이미 있는 카드가 정확히 그 값이었다. 요청서를 쓴 사람이 다른 이름으로 불렀을 뿐이다. 만들지 않고, 기존 카드가 그 값이라고 답했다. 같은 숫자를 두 번 보여주는 카드를 추가하면, 둘이 어긋나는 날 아무도 어느 쪽이 맞는지 모른다. 2 경로별 미답변 — 만들었다 (단, 예외를 뒀다) 이건 만들었는데, 설계에서 한 가지를 어겼다. 이 값만 화면 필터를 따르지 않는다. 대시보드의 다른 값들은 전부 "지금 보고 있는 범위"를 따른다. 그게 일관성이고, 보통은 그게 맞다. 그런데 이 값의 목적은 "세 경로 중 어디가 밀려 있나" 를 보는 것이다. 탭으로 한 경로를 선택하면 나머지 두 경로가 항상 0이 되고, 그러면 값이 존재할 이유가 사라진다. 일관성을 지키면 기능이 없어지는 경우다. 그래서 예외를 두되, 예외라는 사실을 카드 라벨에 적었다. 경로별 미답변 · 탭·필터 무관 이 한 줄이 없으면 사용자는 "필터를 걸었는데 숫자가 안 변하네? 버그네"라고 생각한다. 의도된 예외와 버그는 화면에서 구별되지 않는다. 구별해주는 건 라벨뿐이다. 단, 권한 범위는 지켰다. 필터는 무시해도 자기가 볼 수 없는 건은 여전히 안 보인다. 편의를 위한 예외가 권한을 뚫으면 그건 예외가 아니라 사고다. 3 문의 유형별 분포 — 만들었는데, 쓰려던 컬럼을 못 썼다 유형별로 세면 되는 간단한 일이었다. 통합 테이블에 category 컬럼이 있었다. 세어봤더니 대상 12,259건이 전부 같은 값 이었다. 색인할 때 기본값으로 OTHER 를 넣고 있었고, 아무도 실제 값으로 채우지 않았다. 컬럼이 있다고 데이터가 있는 게 아니다. 그래서 원본 세 테이블의 유형 컬럼을 합쳐서 셌다. 경로마다 enum 이 달라서, 서버는 원본 값을 그대로 내려주고 화면이 기존 유형 필터와 같은 표 로 이름을 붙이게 했다. 필터에서 고르는 이름과 분포에 뜨는 이름이 달라지면 안 되니까. 상위 5개만 내려준다. 세 경로를 합치면 유형이 22종을 넘어서 카드에 안 들어간다. 못 만든 두 개 여기서부터가 이 글의 본론이다. 4 담당자별 처리 부하 — 구조적으로 불가능 "담당자별로 몇 건씩 들고 있나"를 보려면 문의마다 담당자가 있어야 한다. handler_id 라는 컬럼이 있었다. 이름만 보면 담당자다. 코드를 따라가 보니 이 값이 채워지는 시점은 답변을 등록할 때 였다. 즉 "담당자"가 아니라 "답변한 사람" 이다. 그래서: 미처리 건에는 구조적으로 담당자가 없다 — 아직 아무도 답을 안 했으니까 "담당자별 미처리 건수"로 범위를 낮춰도 항상 0 이다 진짜로 만들려면 문의를 담당자에게 배정하는 절차 가 먼저 있어야 한다. 그건 위젯이 아니라 업무 흐름이다 이건 "데이터가 없다"가 아니라 "그 개념이 제품에 없다" 였다. 5 SLA 경보 — 기준이 0건 "마감 임박 건을 경고로 띄워 달라." 마감 시각 컬럼 sla_due_at 이 있었다. 대상 12,259건 중 sla_due_at 이 채워진 건: 0 시작 시각( sla_started_at )은 전부 있었다. 시작은 자동으로 찍히는데 마감 기준을 정한 사람이 없었던 것이다. 몇 시간 안에 답해야 하는지가 어디에도 정의돼 있지 않으니, 경보를 띄울 선이 없다. 표로 적어 낸 이유 PR 본문에 이렇게 넣었다. 위젯 판단 근거 전체 미처리 건수 이미 있음 기존 카드가 그대로 그 값 담당자별 처리 부하 불가 배정 절차가 없음. handler_id 는 답변자 SLA 경보 불가 대상 12,259건 중 sla_due_at 이 0건 세 가지를 노린 것이다. 첫째, 요청자가 다음 결정을 할 수 있다. "못 만듭니다"로 끝나면 대화가 끝난다. "배정 절차가 없어서 못 만듭니다"라고 하면, 요청자는 *"그럼 배정 절차를 만들까?"* 또는 *"그건 나중에 하고 다른 걸 먼저"* 를 고를 수 있다. 공을 되돌려주는 게 아니라 선택지를 주는 것이다. 둘째, 6개월 뒤 같은 요청이 다시 온다. 그때 이 표가 없으면 또 같은 조사를 한다. 있으면 "그때 이랬는데 지금은 바뀌었나?"만 확인하면 된다. 조사 결과는 코드보다 오래 산다. 셋째, 숫자를 적어야 믿는다. "SLA 데이터가 부실합니다"는 의견이고, "12,259건 중 0건"은 사실이다. 전자는 반박당하고 후자는 다음 행동으로 이어진다. 안 만드는 것도 결정이다 주니어 때 나는 "못 한다"를 말하는 게 능력 부족을 인정하는 거라고 생각했다. 그래서 어떻게든 만들었다. 담당자별 부하 같은 걸 요청받으면, handler_id 로 대충 그룹핑해서 뭔가 그럴듯한 숫자가 나오는 카드 를 만들었을 것이다. 그게 제일 나쁘다. 아무도 그 숫자가 "답변한 사람 기준이라 미처리 건에는 해당 없음"이라는 걸 모른 채, 그 숫자로 사람을 평가하게 된다. 데이터가 없는 위젯을 만들면, 없는 데이터가 있는 것처럼 보인다. 빈 카드보다 나쁘다. 그래서 요즘은 요청서를 받으면 화면보다 데이터를 먼저 본다. 그리고 못 만드는 게 나오면, 못 만든다는 말 대신 무엇이 있어야 만들 수 있는지 를 적는다. 다음 글은 "없던 개념을 만든" 쪽 이야기다. 마케팅 수신 동의가 참/거짓 한 칸 으로만 저장돼 있던 걸, 분쟁에서 증명 가능한 기록으로 바꾸는 데 네 번의 PR 이 걸렸다.
То, что RADAR обнаружил и классифицировал для этой возможности. Это опубликованный источником текст, а не подтверждение, что предложение ещё действует.
만들 수 없는 위젯 3개의 이유를 표로 적어 냈다. CS 실시간 대시보드 요청서가 왔다. 위젯 5종. 전체 미처리 건수 경로별 미답변 문의 유형별 분포 담당자별 처리 부하(%) SLA 경보 데이터를 뒤져보고 2종만 만들었다. 나머지 3종은 "왜 못 만드는지"를 PR 본문에 표로 적어서 냈다. 이 글은 그 표에 대한 이야기다. 먼저 데이터를 본다 요청서를 받으면 바로 화면부터 그리고 싶어진다. 위젯 5개면 카드 5개니까. 그런데 대시보드 위젯은 데이터가 있어야 존재할 수 있다. 그래서 순서를 뒤집었다. 5개 각각에 대해 "이 값을 지금 데이터로 계산할 수 있나"를 먼저 확인했다. 1 전체 미처리 건수 — 이미 있다 화면에 이미 있는 카드가 정확히 그 값이었다. 요청서를 쓴 사람이 다른 이름으로 불렀을…
Открыть источник