페이지

레이블이 wiki인 게시물을 표시합니다. 모든 게시물 표시
레이블이 wiki인 게시물을 표시합니다. 모든 게시물 표시

2010년 5월 27일 목요일

Wiki adoption story

예전 글과 같은 논의/설득의 과정을 통해서 팀에 위키 도입하는 것에 성공했다. 하지만 내가 원한 상용 위키 도입은 미뤄졌다. 우선 무료 위키로 시작하고 본 궤도에 올라가면 상용을 써 보도록 하자고 결론이 났다.

우선 무료 위키 소프트웨어를 리스트 업해서 우리에게 맞는 위키를 하나 선택해야 했다. 후보는 DokuWiki, Media wiki, MoinMoin 등으로 압축되었다. 이중 WISWIG방식이 가장 쓸만한 MoinMoin으로 선택했다. 이유는 위키를 처음 접하는 사람들이 많았기 때문에 최대한 learning curve가 없어야 한다는 이유에서이다. 만약 그런 고려를 하지 않았다면 Media wiki를 사용했을것이다.

Moin을 설치하고 쓰기 시작! 예상대로 적극적으로 위키를 사용하는 사람들은 기존에 관심이 많았던 극소수에 불과했다. 이때부터 어떻게 사람들을 involve시킬 수 있을까 고민이 들기 시작했고 여러 문서들을 읽게 되었다. 외국에는 Wiki Evangelist라는 job title도 있었다.
 
크게 2가지 방식을 취한다. 첫번째로 유용한 컨텐츠를 추가해 나갔다. 여러가지 가이드 문서들 .doc으로 되어 있던 문서들을 위키로 옮겼다. 거의 나와 안선임님의 독무대. 허나 모든 내용을 우리 둘이서 작성할 수는 없는 일. 두번째로 유용한 use case를 발굴해 나가고 홍보했다.
- Release dashboard,
- Weekly report
- 각종 취합..
등으로..

처음엔 낯설어 하던 사람들이 점점 Wiki에 컨텐츠를 만들기 시작하면서 서서히 일상에 파고든다. 사람들이 일하는 패턴이 변하기 시작한다. I made it! 기존의 행동패턴을 바꾸는 것이 얼마나 힘든 일인가?
 
현재 위키는 위키는 우리 팀에 있어서는 안되는 툴로 인식되었다. 하여 매니지먼트는 상용위키 도입을 승인한다. 그리고 난 위키의 최고봉인 Atlassian의 Confluence 500 Users 라이센스를 구입하고 적용했다.. 역시 상용이라 WISWIG가 강력하다.
 
요즘에 고민하고 있는 것은 Wiki Content들의 정리다. 사람들은 제각기 생각이 다르고 글쓰는 스타일도 다르다.
- toc를 만드는 사람도 있고 안만드는 사람도 있고..
- Heading 2부터 시작하는 사람도 있고 Heading 이 아예 없는 사람도 있고..
해서 일관성과 체계성을 확보하기 위해서 또 많은 노력이 들어가야 한다는 것을 깨닫고 있는 요즘이다.

이제 Wiki Policy등을 만들어서 제각각인 패턴들을 하나로 수렴 해나가야 하는 숙제를 안고 있다.

2008년 11월 5일 수요일

Why Wiki

최근에 회사에서 information share를 하기 위한 툴이 필요하다는 요구가 있어서 Wiki를 셋업하기로 했다. 하지만 mgmt 회의에서 위키가 사용하기 불편하다는 말이 나오고 누군가가 M$ Onenote를 사용해보자는 얘기를 했나보다. 그래서 그런제안을 한 사람과 나는 만나서 어떤것이 더 나은 툴인지 설명을 해야 했다.

지못미 위키!. OneNote따위에게 비교 당하게 해서... 

우리 팀을 설득할 수 있어야 한다.
그렇다면 Wiki를 사용해야 하는 당위성을 어떻게 논리적으로 설명할 수 있을까?

예를 들어보자. 
우리팀은 최근 exchagne server를 새로 설정했고 나는 이에 대한 guide를 작성했다. 나는 여러번 리뷰를 했고 가능한 자세하게 만들어서 팀원들에게 배포를 했다. 문서 포맷은 ppt였고 이메일에 첨부해서 배포했다. 여러번 리뷰를 했다고 하지만 여러 군데 실수가 있었고 자세하지 못한 부분도 있었다. 이를 여러 사람들이 이메일 회신을 통해 피드백을 주었고 어떤 사람은 수정된 ppt를 첨부로 보내 주기까지 했다. 더 좋은 가이드 문서를 위해 난 피드백을 받은 델타를 원본 ppt에 적용해야 한다. 이 부분은 좀 고통스러울 수 있다.
- 수정된 부분이 어디인지 identify를 해야 하고
- 내가 원본에 반영해야 하기때문에
여러 human error들이 나올 수 있다. 이런 과정을 몇번 돌아야 제법 쓸만한 문서가 나오게 된다.
시간이 지나고 메일 박스가 다른 메일들로 가득 찰 즈음에 신입사원이 등장한다. 그럼 난 신입사원에게 줄 이 문서를 찾기 위해 메일 메일 박스를 열심히 뒤져야만 한다. 

그림으로 하면 아래와 같다고 할까 ?
 
만약 같은 일을 위키라는 툴을 사용했다면 전체 과정은 무척이나 간단해질 수 있다.
나는 위키의 특정 페이지에 가이드 초안을 작성하고 이를 공유한다. 잘못된 부분 혹은 빠진 부분은 동료들이 페이지에서 바로 수정해 나간다. 신입사원이 들어오면 url만 안내해주면 된다.. 정말 간단하지 않은가?

위의 예는 하나의 예시일 뿐이고, 여러 정보들이 위키에 모여지게 되면 훨씬 강력한 툴로 생산성에 도움을 줄 수 있다.

OneNote는 그 컨텐츠가 적을때는 위키와 비슷하게 사용할 수 있다. 그러나 그 컨텐츠가 많이 늘어나면 노트의 묶음일뿐 쉽게 정보를 관리하기가 힘들게 된다. namespace(category)라든가 각 페이지에 대한 access control, tracking user activity, history, recent changes, RSS feed등이 다 그런것을 편리하게 해주는 feature들인데 OneNote는 없지않은가. 애초에 태생이 틀린 놈들이다. OneNote는 standalone으로 위키는 collaboration tool로서..