Skip to content
isdnetworks
Go back

확정과 제안의 표시 구분

설계 문서를 보내고 나서 그중 일부가 이미 확정된 것처럼 이야기가 진행됐다. 문서를 다시 열어 보니 성격이 서로 다른 항목이 같은 형태로 나열돼 있었다.

Table of contents

Open Table of contents

성격이 섞여 있던 다섯 줄

다섯 항목 중 둘은 기기 사양과 운영체제 제약 때문에 그렇게밖에 할 수 없는 것이었다. 다른 둘은 내가 낸 제안이었고 나머지 하나는 아직 정하지 않은 것이었다.

전부 같은 형태로 적혀 있으면 읽는 쪽에서는 그 다섯을 다 정해진 것으로 읽는다. 표시가 없으면 성격의 차이가 전달되지 않는다.

확정과 제안과 미정

그래서 항목마다 표시를 붙이고 표시별로 다른 것을 함께 적게 했다. 확정에는 왜 그렇게밖에 못 하는지 근거를 적었더니 같은 논의가 다시 나오지 않았다.

제안에는 대안을 함께 적어서 고를 수 있는 항목이라는 것을 드러냈다. 미정에는 무엇을 확인해야 하는지를 적었다.

미정을 앞에 둔 이유

확인이 필요한 항목만 따로 모아서 문서 맨 앞자리에 뒀다. 전에는 문서 끝에 묻혀서 답이 안 왔다.

읽는 쪽이 무엇을 답해야 하는지를 첫 화면에서 알게 되니 회신이 빨라졌다. 답이 오면 답한 날짜와 답한 사람을 붙여서 확정 항목으로 옮겼다.

짐작을 확정으로 적으면 그 위에 쌓인다

사양서의 수치로 직접 계산한 항목이 있었는데 그것은 추정으로 따로 표시했다. 계산이 맞아도 실제와 다를 수 있기 때문이다.

나중에 실측해 보니 계산으로 나온 값의 절반밖에 안 됐다. 추정으로 표시해 뒀기 때문에 그것을 전제로 다른 결정을 쌓지 않았고 확정으로 적었으면 그 위의 결정들까지 함께 무너졌을 것이다.

판과 뒤집힌 결정

여러 판이 오가면 어느 것이 최신인지 헷갈리므로 판과 날짜를 적고 파일 대신 링크로 공유했다. 파일을 보내면 각자 다른 판을 들고 이야기하게 된다.

나중에 확정이 뒤집힌 항목도 지우지 않고 언제 왜 바뀌었는지를 함께 남겼다. 뒤집힌 이유가 남아 있으면 같은 방향으로 다시 뒤집는 일이 줄어든다.

정리


Share this post on:

Previous Post
스키마 변경은 코드 배포가 아니다
Next Post
같은 종류 작업의 같은 모양