코로케이션 전환 설계 문서를 보내고 나서 그중 일부가 이미 확정된 것처럼 이야기가 진행됐다. 문서를 다시 열어 보니 성격이 서로 다른 항목이 같은 형태로 나열돼 있었다.
Table of contents
Open Table of contents
증상 — 성격이 섞여 있던 다섯 줄
다섯 항목 중 둘은 상면의 전력 한도와 회선 대역폭 때문에 그렇게밖에 할 수 없는 것이었다. 다른 둘은 KVM 가상화와 Docker 전환이라는 내가 낸 제안이었고 나머지 하나는 이전 일정이라 아직 정하지 않은 것이었다.
전부 같은 형태로 적혀 있으면 읽는 쪽에서는 그 다섯을 다 정해진 것으로 읽는다. 표시가 없으면 성격의 차이가 전달되지 않는다.
조치 — 확정과 제안과 미정
두 가지 방법이 있었다. 문서를 확정·제안·미정 세 절로 나누는 것과, 항목마다 [확정]·[제안]·[미정] 표시를 붙이는 것이다. 뒤쪽을 골랐다. 이유는 같은 주제의 항목이 절로 흩어지면 맥락이 끊겨서다. 대신 항목이 옮겨 갈 때마다 표시를 고쳐야 하는 것을 감수했다. 표시별로 다른 것을 함께 적게 했는데 [확정] 에는 왜 그렇게밖에 못 하는지 근거를 적었더니 같은 논의가 다시 나오지 않았다.
[제안] 에는 대안을 함께 적어서 고를 수 있는 항목이라는 것을 드러냈다. [미정] 에는 무엇을 확인해야 하는지를 적었다.
판단 기준 — 미정을 앞에 둔 이유
[미정] 항목만 따로 모아서 문서 맨 앞자리에 뒀다. 전에는 문서 끝에 묻혀서 답이 안 왔다.
읽는 쪽이 무엇을 답해야 하는지를 첫 화면에서 알게 되니 회신이 빨라졌다. 답이 오면 답한 날짜와 답한 사람을 붙여서 [확정] 으로 옮겼다.
주의 — 짐작을 확정으로 적으면 그 위에 쌓인다
서버 카탈로그의 정격 전력으로 직접 계산한 상면 전력 항목이 있었는데 그것은 [추정] 으로 따로 표시했다. 계산이 맞아도 실제와 다를 수 있기 때문이다.
나중에 PDU 로 실측해 보니 계산으로 나온 값의 절반밖에 안 됐다. [추정] 으로 표시해 뒀기 때문에 그것을 전제로 랙 수를 정하지 않았고 확정으로 적었으면 그 위의 결정들까지 함께 무너졌을 것이다.
판과 뒤집힌 결정
여러 판이 오가면 어느 것이 최신인지 헷갈리므로 v1.3 처럼 판과 날짜를 적고 docx 파일 대신 Confluence 링크로 공유했다. 파일을 보내면 각자 다른 판을 들고 이야기하게 된다.
나중에 확정이 뒤집힌 항목도 지우지 않고 언제 왜 바뀌었는지를 함께 남겼다. 뒤집힌 이유가 남아 있으면 같은 방향으로 다시 뒤집는 일이 줄어든다.
정리
- 확정과 제안을 안 나누면 제안이 확정으로 굳는다
- 같은 형태로 적혀 있으면 성격의 차이가 전달되지 않는다
[확정]·[제안]·[미정]표시로 나눈다- 확정에는 근거를 제안에는 대안을 미정에는 확인 항목을 적는다
- 미정을 문서 맨 앞에 둬야 답이 온다
- 답이 오면 날짜와 답한 사람을 함께 적어 확정으로 옮긴다
- 짐작은
[추정]으로 표시해야 그 위에 결정이 안 쌓인다 - 뒤집힌 확정도 이유와 함께 남긴다