필요가 있다고 생각되어, 메모해 둡니다.
맞을수도 있고, 틀릴수도 있는 거니까, 인용할 필요도 없고, 따질 필요도 없겠습니다-
1. 관리 S/W 를 통해 문서를 공유해야 되는 이유
불과 몇년 전까지만 해도, 개발 문서와 자료를 사내에서 공유 storage 의 특정 folder 를 통해서 공유했습니다.
1) 좋은점.
- 접근이 편하다.
- file copy, move, rename 모두 편하다.
- file 열람이나 사용시에 소요되는 시간 낭비가 거의 없다. ( network 속도에 문제가 없을때 )
2) 나쁜점.
- 편하고 쉬운만큼, 비슷한 file 들이 난무하게 되면서, 시간이 흐를수록 관리가 어려워진다.
- 작성자나 변경자 이름을 일일이 기입하지 않으면, 누가 어떤 일을 했는지 알 수 없다.
- 복수의 사용자가 하나의 file 을 변경하면서, 어느샌가 사라지는 내용이 생긴다.
- 언제 어떤 수정이 있었는지, 일일이 기입하지 않으면 알 수 없다.
- 미숙한 사람이 굉장한 수정을 가해서 원본이 필요하게 될 경우, 심하면 난리가 날 수 있다.
- 개발 이외의 사용자가 자료를 찾는 것이 사실상 불가능하다.
결과적으로, 각 file 들은 담당자 한 명만이 변경한다는 정책이 없다면 곤란해 집니다.
이런 정책은 게임 개발을 정/부 체제의 사무적 형태로 이끕니다.
이건 개인적인 생각일수도 있지만, 모든 개발자는 기획안을 낼 수 있고, 개발에 직접 참여할 수 있어야 한다고 봅니다.
그래서, 몇년전부터 상용 solution 을 사용해서, 사내 팀별 게시판을 구성했습니다.
각 게시판에는 공지,일정,토론,자료실,위키,설문 등의 기능이 포함됩니다.
이 게시판을 통해서 가능한한 모든 자료를 공유하고 있습니다.
개발에 필요한 것, 참고가 되는 것, 모두 다 공유를 합니다.
1) 좋은점.
- 문서 갱신 작업에 혼선이 없다.
- 누가 어떤 자료를 작성 또는 수정을 했는지 알 수 있어서, 업무 역량이 시각화 될 수 있다.
- 잘못된 갱신을 하더라도, 원하는 날짜의 것으로 되돌릴 수 있다.
- 모든 자료를 작업 PC에 보관하지 않더라도, 가볍게 자료 열람이나 갱신이 가능하다.
- 전체적인 관리가 용이하다.
2) 나쁜점.
- 자료 열람 또는 갱신시에 시작과 종료에 약간의 시간이 소요된다.
- 동시에 여러 사람이 자료 갱신을 할 수 없으므로, 누군가 대기해야 된다.
- 사외에서는 작업이 불가능하다.
- binary인 office file 들은 변경 내역을 확인할 수 없다.
이렇게 하기 전에는 VSS 나 SVN 등을 사용해 보기도 했으나, 비용과 사용법의 문제가 컸습니다.
google wave 등, 이러한 용도의 solution 이 끝없이 등장하고 있는 이유가 바로 이러한 project 투명화와 공유를 위해서겠죠.
개선의 여지가 매우 많지만, 최소한 자료의 공유는 접근성과 관리의 용이성 등의 면에서 봤을때, 관리 S/W 를 통해서 하는 것이 옳다는 것을 확인했습니다.
2. 공적인 의견 교환은 메일이나 메신저를 이용해야 되는 이유
인원이 적을때나 많을때나, 직접 얼굴을 보고 말로 하는 것이 서로를 공경하는 태도이며 진행을 원활하게 만든다고 생각했습니다.
상대와 같은 높이의 시선을 일부러 맞추고, 원하는 내용을 또박 또박 말로 표현하며, 필요하다면 여러가지 자료를 사용했습니다.
1) 좋은점.
- 화자의 화법에 따라서 매우 원활한 전달이 가능할수 있다.
- 대화를 하다 보면, 그 자리에서 더 좋은 방법을 찾을 수 있다. ( 하지만, 이 말은 전달 사항이 부정확하며, 허점을 지니고 있다는 뜻이다 )
- 사람과 일의 관계가 아니라, 사람과 사람이 일을 해 나간다는 공통의 분위기를 형성할 수 있다.
2) 나쁜점.
- 전달시에 공유되었던 내용과 결과물 사이에 격차가 발생하기 쉽다. 서로가 사용한 단어와 표현이 100% 구체적이지 않기 때문이며, 확인하려면 근거 자료가 부족해서 엇갈리기 때문이다.
- 당장 어떤 작업에 집중하고 있는 사람을 방해할 수 있다. 이것을 피하려면 미팅 시간을 잡아야 하는데, 모든 일을 이렇게 할 수도 없다.
- 누가 어떤 말을 했는지 어디에도 남아있지 않으므로, 나중에 토론을 벌이다 보면 대체 누가 낸 의견인지 알 수 없게 된다.
물론, 모든 일을 구두상으로만 한 것은 아닙니다.
말로 전하고 어딘가에 메모를 하지만, 이 메모가 공유되지 않는 일이 많아서 문제가 되는 것이죠.
누가 어떤 의견을 냈고, 어떤 지시를 했고, 어떤 답변이 나왔고, 어떤 문제를 겪었으며, 어떤 해결책을 제시했는지를 구체적으로 저장할 필요가 있습니다.
인사 고과의 근거 자료가 된다는 점도 있겠지만, 일 진행을 공유한다는 점에 있어서 매우 도움이 됩니다.
그래서, Yammer 라는 메신저형태의 S/W 를 사용하게 됐습니다.
누가 어떤 이야기를 했는지 저장되며, 시간이 지난 뒤에도 확인할 수 있으므로, 자리를 비웠더라도 그 사이에 무슨 일이 있었는지 알 수 있습니다.
실시간 전체 공지도 효과적이고, 전달을 못받았다는 핑계가 나올 빈 틈도 없습니다.
그리고, 위에서 언급되었던 자료 공유법과 연계하여, 어떠한 개발 자료가 추가되면 Yammer 또는 mail 을 통해 전체 선임급 또는 책임급 이상에게 알립니다.
이때, 추가 또는 갱신된 자료의 link 를 첨부하여, 자료의 위치를 계속 인지시킵니다.
운영,홍보,전략 등 관련 부서에서 project 진행 상황을 공유받을 수 있으므로, 필요한 조치를 미리 생각할 수 있게 됩니다.
누가 어떤 요청을 했는지, 이 요청에 대한 응답에 어느 정도의 시간이 소요됐는지, 불응했는지 확실하게 기록을 남기게 됩니다.
서로간의 이해 차이가 있었다 하더라도, 근거가 남아 있으므로 객관적인 위치에서 수정을 할 기회가 생깁니다.
이 경우에는 나쁜점을 찾을 수 없었기 때문에, 좋은점과 나쁜점을 구분하지 알겠습니다.
물론, 모든 의견 교환을 유선상으로 한다는 것은 아닙니다.
기본적인 공유가 된 상태에서는, 토론을 하더라도 좀 더 효과적인 진행이 가능할 것입니다.
모든 자료는 사전에 공유되며, 미팅시에는 불필요한 설명 과정 없이 토론에만 집중할 수 있도록 하는 것이 좋다고 생각합니다.
사실, 잘 하는 사람들이 모여서 잘 하면, 이러 저러한 체계는 불필요할 수 있습니다.
하지만, 보통 사람들이 모여서 일을 하려다 보면, 어떠한 집단에서든지 공유의 문제가 발생합니다.
그러니까, 이런 문제를 해결하려고 여러가지 진행론이 등장하고, solution도 끊임없이 제작되는 거죠.
우리는 보통 사람이기 때문에, 효과적인 공유를 위해서는 방법을 개선해 나가야 한다고 생각되어 메모해 둡니다.