작업을 어떻게 하겠다고 말해 두고 시작했다. 하다 보니 다른 방법이 나아 보여서 그쪽으로 진행했다.
Table of contents
Open Table of contents
말없이 바꾼 방법
결과는 원하던 대로 나왔다. 그런데 보고했더니 아까 말한 것과 다르다는 답이 왔다. Redmine 티켓에는 처음 말한 방법이 그대로 적혀 있었다.
내 생각에는 결과가 같으니 문제가 없었다. iBatis 매퍼를 고치는 대신 SQL 을 한 번에 바꾼 것이 그 방법이었다. 방법이 나아졌으면 그것을 굳이 말할 필요가 있나 싶었다. 그 자리에서는 넘어갔지만 왜 지적이 나왔는지를 나중에 따져 봤다. SVN 이력을 되짚어 보니 말한 날과 바꾼 날이 이틀 차이였다.
결과가 같아도 예상이 틀어진다
상대는 내가 말한 방법을 전제로 다음을 준비하고 있었다. SVN 커밋이 어느 시점에 올라올지도 그 전제에 들어 있었다. 어느 시점에 중간 결과가 나올지와 무엇을 확인해 주면 되는지가 그 방법에 달려 있다.
방법이 바뀌면 그 예상이 전부 어긋난다. SVN 에 언제 올라오는지도 거기 묶여 있었다. 결과가 같다는 것은 마지막에만 같다는 뜻이고 그 사이는 다르다. 그러니 결과가 같아도 말하지 않은 것은 문제가 된다.
바꾸기 전에 한 줄로 말한다
그래서 방법을 바꿀 때는 바꾸기 전에 한 줄이라도 말하기로 했다. 무엇을 왜 다르게 하는지만 적으면 된다. Redmine 의 티켓 댓글이 그 자리였다.
명백히 나은 경우에도 말한다. MyBatis 로 옮기는 것처럼 누가 봐도 나은 변경도 예외가 아니다. 나은지 아닌지를 내가 판단하는 것 자체가 상대가 모르는 정보를 전제할 수 있기 때문이다. 한 줄 쓰는 데 드는 시간이 나중에 맞추는 시간보다 훨씬 짧다.
계획과 실제를 함께 적는 보고
보고할 때도 결과만 적지 않고 계획과 실제를 나란히 적게 했다. 주간 보고는 Excel 한 장에 두 열로 뒀다. 둘이 같으면 같다고 한 줄만 쓰면 된다. Excel 의 두 열이 같은 값이면 그걸로 끝이다.
다르면 어디가 왜 달라졌는지가 그 자리에 나온다. 이 형식이 있으니 바뀐 것을 빠뜨리기가 어려워졌다. 오래 걸리는 작업은 중간에 알릴 지점도 미리 정해 두었다. Redmine 티켓의 진행률을 그 지점으로 삼았다.
못 하겠으면 그것도 말한다
예상보다 오래 걸릴 때도 알리기로 했다. Redmine 의 예상 공수와 실제 공수를 그때 함께 고쳤다. 조용히 늦어지면 상대는 예정대로 되고 있는 줄 안다.
아예 못 하겠는 경우도 마찬가지인데 그때는 Confluence 에 세 가지를 적는다. 어디까지 됐고 무엇에 막혔고 무엇이 있으면 되는지다. 그리고 이런 합의는 대화로만 하면 잊히니까 Confluence 문서로 적어 두었다.
정리
- 결과가 같아도 방법이 다르면 상대의 예상이 틀어진다
- 중간 결과와 확인 지점과 다음 판단이 방법에 달려 있다
- 바꿀 때 먼저 한 줄로 말한다
- 명백히 나은 경우에도 말한다
- 보고에 계획과 실제를 같이 적는다
- 오래 걸리는 작업은 알릴 지점을 미리 정한다
- 못 하는 경우 어디까지 됐고 무엇에 막혔고 무엇이 필요한지 적는다
- 합의한 것을 적어 두면 나중에 확인할 수 있다