sosa0sa.com

부서 후배 녀석이 담주에 출장을 간다.

내가 8월 초에 갔던 것과 유사한 출장인데 목적은 4월 출장이랑 비슷하다(4월 출장은 현지 보험/지원용, 8월은 문제점 원인/분석/해결)

4월에 출장갔을 때 그전 출장자에게 전화했을 때 들었던 “그냥 가면 알아요”라는 황당한 대답을 들었을 때 느꼈던 막막함을 조금이라도 없애려고 그때 적어 놓은 글이랑 이런 저런 이야기들 - 가서 조심해야 할 것들, 호텔 포인트 적립, 항공 마일리지 적립, 쇼핑은 어디서 해야 하는지 등 -을 주저리주저리 이야기해줬다. (4월 출장은 혼자서는 처음 나가는 해외출장이라)

노하우 공유 측면에서도 이런 건 여러 사람들이 공유해야 할텐데 그게 쉽지 않다. 하다 못해 맛있는 맛집이라도 먼저 갔다 온 사람이 알려줘야 할텐데(하긴 이건 가면 현지 파견 인력이 잘 알긴 하지만)

미래를 준비하는 조직의 CEO나 리더는 어떤 고민을 해야할까…여러가지가 있지만, 미래학자인 저자는 두가지 질문에 주목하라고 조언합니다. 1.”앞으로도 이 조직이 학습을 계속할 수 있을 것인가?” 2.”개별 직원 머릿속에 있는 지식이 얼마나 공유되고 있는가?” 기업이나 조직이 미래에도 생존하고 번영하려면 ‘학습’과 ‘공유’가 필요합니다. 하지만 많은 CEO들이 매일 벌어지는 ‘전투’에 허덕이며 ‘전쟁’을 준비하지 못하고 있습니다. 하루 하루의 바쁜 업무들을 핑계로, 직원들의 학습과 그들의 지식공유를 통한 시너지 창출을 뒤로 미루고 있습니다. 이래서는 미래가 없습니다.

출처: 예병일의 경제노트 2008.02.04

사내 고급 정보를 말단 직원까지 유통시켜라!

위에 있는 사람들일수록 고급 정보에 더 잘 노출이 되기 때문에 자기가 똑똑하다고 생각하는 경우가 많이 있죠. 결정을 내릴 때도 더 균형잡힌 결정을 내리기도 하구요. 그건 똑똑해서라기 보다 직위에 기인한 정보 접근성이 달라졌기 때문입니다. (그래서 저는 똑똑한 사람이 위에 올라간다는 말보다는 위치가 사람을 만든다는 말을 더 믿습니다)

평소의 내 지론(?)과 100% 동감인 글이다.

정말로 기밀정보가 아니라면(사실 우리가 접하는 상사들이라고 해봐야 인사와 관련된 것이 아니라면 굳이 기밀이라고 할 만 정보는 없다고 생각한다. 본사가 분리되어 있는 회사의 경우 TV에 나오는 사건에 관계된 내용이 아니라면) 정보는 가능하면 공유가 되어야 한다. 말단 신입사원까지.

정보에 대한 필터링은 개개인이 해야 할 일이지, 윗 사람이 굳이 나서서 할 필요는 없다고 생각한다. 대부분 정보를 공유하지 않는 사람들의 변명은 이렇다.

‘아직 결정되지 않는 내용이라 혼란만 줄 것같다. 최종 결정되면 알려주려고 한다’ ‘그 사람과는 별 관계없는 내용이라서’

필요하다면 위와 같은 제약사항을 언급해주면서 정보를 공유해 주면 된다. 미결정 사항이니 감안해라. 너랑은 크게 관계없어 보이긴 하지만 참고해라. 등등.

일을 하다 보면 일에 대한 욕심때문인지 자신이 접한 정보를 남과 쉽게 공유하지 않는 친구들도 많다. 그런 모습을 보면 걱정이 앞설때가 많다. 아쉽게도 회사에서는 문제를 풀라고 요구만 받았지, 어떻게 풀어야 하는지, 남과 어떻게 공유해야 하는지, 남과 어떻게 함께 일하는 것이 좋은 방법인지에 대해서는 교육받은 적이 없으니 말이다.

이제는 문제를 ‘해결하자’에서 ‘잘 해결하자’로, ‘이 과제를 성공적으로 완료하자’에서 ‘우리의 과제를 함께 성공적으로 완료하자’로 바뀌어야 할 때가 아닐까?

Action Item

• 내가 받은 정보는 가능한 공유하자.
• 모든 사람이 자신의 작업 내용을 공유할 수 있는 공간을 만들자.
• 다른 사람들에게도 자신의 정보를 공유하도록 독려하자.

Wiki를 업무에 도입할 때 가장 큰 장애는 바로 “무관심”이다. 위키라는 것이 어찌 보면 별것이 아니고 쓰다 보면 기존에 엑셀이나 워드, 그리고 메일을 통해 정보를 주고받던 방법을 훨씬 쉽고 편리하게 대체할 수 있으나 위키를 소개받은 극히 일부(10의 하나 정도)가

“오호~~ 이걸 사용하면 이런 이런 일들을 쉽게 할 수 있겠구나”

이런 반응을 보이고 대부분의 개발자들이 보이는 반응은

“이건 또 뭐야?” “뭘 또 배우라는 거야?” “무슨 문법이 이렇게 달라” “WYSWYG editing이 뭐 이래”

이다. 그 나마도 이렇게 반응을 보이는 사람이 10의 하나 둘 정도이고 나머지는 그저 심드렁하게 노코멘트로 일관한다.

zdnet에서 “협업 노하우”라는 제목으로 시리즈물이 올라오고 있다. 그 중 하나가 “위키를 이용한 협업 노하우“이다.

내용을 차근차근 읽어보니 다른 사람들에게 위키를 소개할 때 유용한 내용이 담겨 있어 정리해 본다.(다른 사람들에게는 링크의 전문을 긁어서 메일로 보내주고 - 근데 읽어보기는 할까?)

수정본을 여러 번 주고받다 보면 어느 것이 최종본인지 알기 어려울 것이다. 맨 마지막에 도착한 이메일이 최종본인지, 제목에 “최종본”이라고 쓰여 있는 것이 최종본인지 도무지 확신하기 어려울 것이다. 효과적인 문서 관리의 요구사항

• 언제 어디서나 문서를 작성할 수 있으면 좋겠다
• 문서를 구성원들과 함께 편집하거나 공유할 수 있으면 좋겠다
• 많은 문서를 체계적으로 관리할 수 있으면 좋겠다.

위키의 장점은

• 언제 어디서나 가능하다(편집)
• 한 문서 여러 사람이 함께 편집할 수 있다
• 최근 편집된 문서를 알 수 있다
• 문서 편집 기록을 남길 수 있다
• 문서를 검색할 수 있다

위키에 따라 최근 변경 글 정보를 이메일로 전송해 주거나 RSS로 제공하기 때문에 위키에 접속하지 않더라도 언제 누구에 의해 어떤 문서가 변경되고 있는 지 알 수 있다. 한 사람이 문서를 작성한 후에는 동일 문서를 손 쉽게 여러 사람이 보완/수정할 수 있다. 구성원들은 각자 PC 안에 프로젝트 관련 문서를 쌓아둘 필요 없이 문서가 필요한 경우 위키에 접속하여 열람하면 된다. 문서 작성자 또한 구성워들에게 별도로 공지를 하지 않고, 위키에 최신 문서를 갱신하기만 하면 되므로 업무의 부담이 한결 줄어든다.

“The practice of an Agile developer”를 보면 Architect가 설계만 하면 안된다고 했다. 전적으로 동감하는 말이다. 회사에서 일을 하다면 “현실”을 알지 못하고 이론만 아는 설계팀과 충돌할 때가 많다.

책에서 보면, 다른 회사의 feature를 보면 그리고 혼자서 생각을 하면 A라는 기능은 이 제품에 꼭 필요한 기능이다. 그래서 말한다. “A라는 기능이 없는 제품은 본 적이 없다고”

그럴 때 S/W 개발자는 말한다. “와서 만들어 놓고 가라” 어찌보면 개발자 입장에서 “못한다”라고 말하는 것은 무척 자존심 상하는 일이다. 왜냐하면 S/W 개발자가 못한다고 하는 것은 다른 이유가 아니라 실력/능력이 부족해서 못한다고 생각하는 사람이 대부분이기 때문이다.

하지만 S/W 개발자에게 자원들이 무한정 주어진 것이 아니다. CPU power 그리고 메모리등. 한정된 자원을 주고 게다가 한정된 개발 시간을 주면서 모든 일을 하라고 하니 어떤 일을 할 수 있는 것도 있고, 또 어떤 일을 할 수 없게 되는 것이다.

그리고 Agile에서는 S/W에서 요구사항의 변경은 피할 수 없는 것이므로 어쩔 수 없는 그 상황에도 잘 대처할 수 있도록 하라고 한다. 하나의 water fall 구조가 아니라 잦은 iteration을 이용하라는. 아쉽지만 현실이 그렇지 못할때가 많다. 여러 사람이 함께 개발을 하다 보면 블럭간의 인터페이스를 함께 바꿔야 하는데 이때는 아쉬지만 기술적인 이슈보다는 정치적인 이슈가 개입될때가 많다 -_- (Agile 책을 보면 큰 프로젝트일 수록 water fall이 실패한다고 했는데 정말로 Agile 방법론을 사용할 수가 있는 걸까 늘 궁금하다. 이해 당사자가 무척 많을 텐데)

그래서 대개 설계인력은 S/W나 H/W 개발 경력이 최소한 얼마정도는 있는 사람으로 구성하기 나름이다(물론 늘 그런 것은 아니다. 박사인력인 경우 대부분 S/W 개발보다는 바로 설계 업무를 배정하는 경우가 대부분이다. 누군가 말한 것처럼 박사과정이 하나의 토픽에 대해 전문성을 갖는 것보다 문제를 풀어가는 방법을 배우는 과정을 배운 것이 더 의미가 있다고 하는 것처럼 대부분 실무적인 S/W 개발 경험이 없더라도 잘 하는 경우가 많다(혹은 석/박사과정에서 산학 협력등의 경험을 한 경우도 많고)

다만 그렇지 못한 고급인력(박사로 한정하는 것은 아니다)들이 다른 사람을 힘들게 하는 것이다. 머리는 똑똑하고 나름대로 정보 습득 능력은 높기때문에 보고 들은 것은 많은 데 그것을 자기가 가진(자기가 속한 회사가 만드는) 제품군에 무조건적으로 적용하려다 보니 실무자인 개발자와 충돌하는 경우가 많다.

갑자기 이런 글을 적는 이유는 아침에(토요일이니 새벽이군) 블로그 뉴스를 보다 보니 이런 내용이 있어서이다.

그는 알만한 이들만 아는 회사인 ‘마이크로소프트’라는 회사에 근무하고 있고, 하는 일은 마이크로소프트 개발자 사업부 총괄책임자(전무)다. 소프트웨어를 만들 때 사용하는 개발 툴인 비주얼 스튜디오(Visual Studio) 제품과 닷넷(.Net) 프레임워크 기술 개발을 책임지고 있다. 그가 이끄는 팀은 총 620명. 그는 개발자 사업부 총괄 책임자지만 여전히 매일 서너시간은 코딩을 한다. 그가 하는 코딩은 이미 제품화 된 것보다는 대부분 새로운 아이디어를 시도하는 프로토타입으로 그치는 경우가 많지만 끊임없이 새로운 시도를 추구하고 있다.

와우. 정말 말로만 듣던 코딩하는(프로토타입이라는데 당연히 그래야 하는 것 아닌가? 620명을 총괄하는 살마이 문제점 해결하겠다고 코드 리뷰하는 것도 우스운 일이니-우리 회사엔 그런 사람이 있다고 하는데) Architect(심지어는 project manager) 아닌가. 난 주변에서 코딩한다는 architect를 본적도, 있다는 소문을 들은 적도 없다. 대부분의 사람들이 모두 엑셀이나 파워포인트만 다루고 있다.

너무나도 다른 사람, 회사 분위기가 놀라울 따름이다.

그 외에도 기억하고 싶은 글은

그는 국내 개발자들과의 대화에서 ‘초기 평개발자로서 새로운 시도가 쉽지 않았지 않았느냐’는 질문에 “마이크로소프트에서는 ‘Code wins’라는 말이 있습니다. 개발자라면 직급이 아니라 코드를 통해 해결책을 내놓는 것으로 인정받는다는 것입니다“라고 밝혔다. 그는 또 “ASP.NET도 처음에 나 혼자 프로토타입을 개발하고 나서 그 이후 3-4명의 작은 팀이 생겼습니다. 서버를 통해 코드를 관리하는 것이 효율적이라는 것을 스스로 믿고 강하게 주변 사람들을 설득하는 것이 중요했습니다”라고 조언을 아끼지 않았다. “목표한 바는 결과로 반드시 만들어 내는 것도 중요합니다. 개발자들은 코드로 보상을 받는 것이라고 생각합니다. ‘개발 작업’을 하는 것이 아닌 ‘좋은 제품’을 만들어 내는 것이 중요합니다”라고 관리자로서의 개발자 역할도 강조했다. 스콧 구슬리는 “블로깅은 4년여 전에 시작했는데, 약 2년 전부터 심층적 기술문서들을 올리면서 많은 개발자들이 조회하고 참고하는 정보소스가 됐습니다. 한 달에 보통 10-15회 문서를 올립니다. 이 과정을 통해 우리 기술팀이 개발한 기능들을 더 잘 이해하게 되기도 합니다”라고 밝혔다 스콧 구슬리 전무는 “항상 고객을 염두에 두는 개발자가 되십시오”라는 말로 이번 방한을 마무리 했다

그의 블로그 주소는 http://weblogs.asp.net/Scottgu 이다

꼬랑지) 당연한 이야기지만 설계인력이 늘 현실을 무시하고 과하게 요구하고, 늘 S/W 개발자가 맞는 말만 하는 것은 아니다. 또 많은 경우에는 S/W 개발자의 능력 부족이나 게으름, 혹은 잘못된 태도때문에 타당한 요구사항을 수용하지 못하겠다고 거부한다. 결국 답은 서로가 서로를 좀 더 이해(알기도 하고, 배려/인정도 하고) 서로 지식을 공유하고 많은 대화를 가져야 한다. 누구나 아는 답이 아닐까? 누구나가 다 하는 것이 아니기때문에 문제지만.

작년 말부터 회사에 wiki 를 사용하기 시작했다.

처음에는 mediawiki 를 사용하다 기능이 많아서 인지 몰라도 불필요하게 복잡한 듯 보여 다른 wiki를 찾다가 dokuwiki 를 만났다. 예전에 일롭자 님이 쓰던 위키로만 알고 있었는데 의외로 훌륭했다. 게다가 언제 자료인지 모르겠지만 위키중에 가장 평이 좋은 것이 dokuwiki라는.

mediawiki는 wikipedia 가 사용하는 덕에 사용자층이 무척 넓다. 덕분에 다양한 부가 기능이 장점이다. 하지만 편집 기능이 내겐 불편했고, DB를 사용한다는 점이 오히려 부담스럽다.

dokuwiki는 별도의 DB를 사용하지 않고 파일시스템을 사용한다. 덕분에 백업이 무척 용이하고 migration도 편리한 편이다.(물론 내가 MySql를 잘 다룰 줄 안다면 mediawiki도 괜찮겠지만)

암튼 설치도 쉽고 사용도 쉬운 dokuwiki를 내가 관리하고 있는 개발 서버(라고 해봐야 펜4에 리눅스 설치한 것이 전부)에 설치하고 혼자서 열심히 사용하고 있었다. 위키가 위키다워야 하는데 혼자서만 쓰니 아쉽기는 했지만 주변에 위키를 쓸만한(?) 사람이 보이질 않아 애써 권장하지 않았다.

그러다 productivity에 대해 고민하게 되고 특히나 release it, the practice of agile development등의 책을 보면서 개발 팀에 wiki가 아주 적합한 툴임을 다시 생각하고 주변사람들에게 조금씩 소개하기 시작했다.

10명쯤에게 소개했더니 2-3명이 관심을 갖기 시작했다. 하지만 실제로 사용하는 사람은 1명.

그러다 내가 맡은 일때문에 정보 공유를 해야 할 때 자료를 위키에 정리한 후에 메일에 URL을 알려줬다. 물론 그래도 별 반응은 없었다. 그러다 오늘 파트장이 저녁먹으로 가기전에

“위키 그거 괜찮던데~”

라고 한 마디 하셨다. ㅎㅎ

마치 신입사원이 자신의 성과를 인정받은 것처럼 속으로 좋아라 했다. 내가 하는 일을 인정받았다는  게 중요한 게 아니라 파트장이 위키라는 툴을 이용한 자료 정리의 장점을 인지하고 인정했다는 점이 중요했다.

지금도 여전히 혼자서만 자료를 올리고 있는 위키지만 조금씩 나아질 것이라고 믿는다. 그렇게 함으로써 서로가 가진 정보를조금씩 공유해야지만 현재 우리 부서에 팽배해있는 부서이기주의(내가 하는 일만 관심있어 하기)를 조금이라고 완화시키고 각자가 머리속에만 가지고 있는 노하우를 모을 수 있을 것이다.

That’s the POWER of wiki.

Collaboration is a structured, recursive process where two or more people work together toward a common goal—typically an intellectual endeavor^{[1] [2]} that is creative in nature^[3]—by sharing knowledge, learning and building consensus. Collaboration does not require leadership and can even bring better results through decentralization and egalitarianism.^[4] In particular, teams that work collaboratively can obtain greater resources, recognition and reward when facing competition for finite resources.^[5]

http://en.wikipedia.org/wiki/Collaboration

Though good collaboration doesn’t guarantee a project’s success, poor collaboration almost always guarantees a project’s failure.

Ship it! A practical guide to successful software projects