이글루스 캔미팅 다녀왔습니다.

지난 27(금)~28(토)일 이글루스팀은 캔미팅을 다녀왔습니다.

“캔미팅은 조직구성원들이 수시로 일상의 업무와 차단된 장소에서 정해진 혁신과제에 대하여 격의없이 자유롭게 논의”하는 것인데 사실 업무조직의 구성원들이 격의없이 이야기 하기란 쉽지 않은 일입니다. 격의없다는 것은 직위를 떼고 이야기하자는 것은 아닐겁니다. 왜냐하면 캔미팅은 경영과제에 대한 주제를 토론하고 이 과정에서 의사결정권자가 참석하여 결정을 내리도록 노력을 해야 하는 목적이 있기 때문입니다.

어떤 식으로 주제에 대한 토론을 할 것인지 준비하지 않고 가면

  1. 그저 놀고 먹고만 오게 되거나
  2. 어설프게 시간만 잡아먹는 회의를 하게 되거나
  3. 의사결정권자가 진행하는 (지루한) 회의

를 하기 쉽습니다.

이글루스팀 캔미팅은 팀 구성원간 더 원활한 커뮤니케이션을 할 수 있도록 “우리팀 더 친해지기”로 정하였습니다. 팀원들 대부분이 오랫동안 함께 회사생활을 해서 친한 상태이긴 합니다만 역시 사람사는 곳이다보니 일부 구성원 사이에는 상대적으로 좁은 대화통로를 갖고 있는 경우가 있습니다. 업무는 시스템에 의해 이루어지는게 맞습니다만 시스템을 운용하는 것도 사람일뿐더러 시스템상으로 부족한 부분을 채울 수 있는 것은 역시 충분한 커뮤니케이션이라고 생각했기 때문입니다. 이를 위해서 아래 세 가지 항목에 대해서 미리 팀원들에게 메일로 답변을 받았습니다.

  1. 내가 회사생활 하면서 최고의 순간은 이 순간이었다.
  2. 반면 가장 속상했던 순간은 이 때였다.
  3. 사람들이 절대 모를 나만의 비밀(매력 또는 재능)은 바로 이 것!

각 항목의 답변을 통해 구성원들이 회사생활에서 어떤 점에 기쁨을 느끼는지, 또 어떤 점에서 가장 실망했는지를 알게 됨으로써 개개인이 추구하는 회사생활 (넓게는 삶)의 가치를 엿볼 수 있도록 하였습니다. 메일로 받은 답변을 파워포인트로 한명당 한장씩 예쁘게 꾸며서 A3용지에 칼라레이저로 뽑은 다음 색상지에 하나씩 붙이고 고리를 묶어서 한장 씩 넘길 수 있도록 미리 만들어서 갔습니다. 프로그램을 진행하는 자리에서 한명씩 나와 자신의 이야기를 하도록 했구요. 순서대로 나와서 발표하기 직전에 한가지 프로그램을 더 끼워넣었습니다.

발표자는 이른바 “친해지고 싶어요” 모자를 구성원 중 2명에게 씌워줄 수 있습니다. 제과점에서 파는 생일축하용 종이 고깔모자구요. 발표하기전에 더 친해지고 싶은 사람 두명을 골라 그 모자를 씌워줍니다. 이 행동은 긍정적인 인식과 부정적인 인식을 모두 갖고 있습니다. 이걸 할까 말까 걱정을 한 것도 바로 이 부정적인 영향 때문인데요. 우선 긍적적인 것은 정말 모자가 갖고 있는 그대로의 메세지인 “당신과 더 친해지고 싶어요, 즉 당신은 친해지고 싶은 사람이에요, 그럴만한 가치가 있어요” 라는 의사를 표시하는 것입니다. 사실 그렇구요.

반면 부정적인 메세지를 주고 있는 것이 있는데 이것은 어느 정도 긍정적인 메세지가 가질 수 밖에 없는 태생적인 메세지이기도 합니다. 즉, “지금 나는 너와 (상대적으로) 친하지 않다.”는 메세지를 모자를 씌워주는 사람에게 전달한다는 점입니다.

이 문제는 처음에는 사회자가 취지에 대한 설명을 긍정적인 면을 부각함으로써 해결하려고 하였는데, 실제로 프로그램을 진행하면서 팀원들은 발표자 양쪽에서 서로 어깨동무를 하면서 사진 찍기를 제안하고 실행함으로써 부정적인 인식을 긍정적으로 바꾸고 서로가 서로에게 유쾌한 기념행사로 바꾸는 해결책을 스스로 마련하였습니다.

예산이 허락한다면 모자를 씌워준 사람과 모자를 쓴 사람에게 커피쿠폰이나 상대방의 이름이 써진 인형을 선물하는 등의 보완책 등으로 더 큰 효과를 만들 수 있을 것입니다.

제가 담당했던 순서는 이거였구요. 다른 프로그램에 대한 사진은 폴로군의 이글루에서 찾을 수 있습니다. 아래 사진은 저녁먹으러 가기 전에 하고 있는 타뷸라의 늑대 게임입니다. 흐흐흐.

타뷸라의 늑대

백업시스템 마련.

백업의 중요성은 두말하면 잔소리겠지만 이게 또 ‘에이 설마~’하는 마음 때문에 제대로 실행에 옮기기가 쉽지 않습니다. 엊그제 한번 사고치고 나니까 진짜로 백업을 해야겠다는 생각이 들더군요. (물론 백업을 해도 백업하드 파티션을 날리는데는 당해낼 수 없겠습니다만 -_-;;)

새로택에서 나온 FHD-254UK (2.5인치 80G / 삼성 5400rpm/8M HDD 포함)에 프리웨어인 syncback 3.2.14를 이용해서 백업을 하도록 했습니다. 백업 규칙(원본/사본 디렉토리, 같은 이름 파일을 지울지 덮어 씌울지 등..)과 시간을 지정해 두면 알아서 백업을 시키므로 점심시간에 내문서, 프로젝트파일 디렉토리, 메신저 로그, 메일함 등을 백업하도록 해 두었습니다.

QA(Quality Assurance) 목록 작성 중…

빠르면 다음 주에 오픈할 기능 때문에 QA(Quality Assurance) 목록을 작성하고 있습니다. 이달 초에 오픈한 새글쓰기개편에서도 기능 오픈 전에도 QA를 거쳤는데 사실 QA에 대한 경험이 없다보니 서비스 오픈 후에 사용자들이 리포팅한 버그들이 수두룩합니다. QA가 잘 되었다면 사용자들이 겪을 불편을 꽤 많이 해소할 수 있었을텐데요.

QA를 해보니 이런걸 느끼겠더군요.

QA목록을 작성하는 사람은 QA를 하는 사람들이 명확히 자신이 해야하는 테스트의 내용을 알 수 있도록 QA항목을 작성해야합니다. 자기 혼자 작성하고 자기 혼자 테스트 하는거라면 상관없지만 다른 사람은 자신이 작성한 리스트를 가지고 테스트를 해야 하기 때문에 의미가 명확하지 않으면 테스트를 할 수 없거나 잘못된 테스트를 수행할 수 있습니다. 예를 들자면 이런 항목이죠.

“계속 버튼을 눌렀을 때 기존 목록은 잘 나오는가?”

“계속”이라는 버튼을 누르는 것인지, 아니면 어느 버튼을 한번 누른 채로 있는 것인지, 아니면 한번 누르고 또 누르고 또 누르고 또 누르는 것인지 모호합니다. 기존 목록이 뭔지도 모르겠구요. 어떻게 나와야 “잘~”나오는 것인지도 알 수 없지요. 원래는 나와야 하는 목록의 가장 최근 항목 한개는 굵은 글씨로 표시되어야 하는 것이 맞는데 그냥 보통 글씨 모양으로 목록이 나와도 테스트를 하는 사람은 “아~ 잘 나오는구나. OK!” 라고 해당 QA항목이 성공적으로 동작했다고 보고한다는 것입니다.

버그가 생기는 이유중의 하나는 커뮤니케이션을 하지 않았거나 잘못된 커뮤니케이션을 했기 때문이라고 하더군요. (Why does software have bugs? ) 그런데 그 버그를 잡기위해 하는 QA에서조차 스스로 그 버그를 재현하고 있을 수 있다고 하니 이놈의 “커뮤니케이션 문제”는 언제나 생기는, 가장 중요한 문제인 듯 합니다.

어제 밤에 QA리스트 만드는걸로 머리 싸매다가 Tong팀의 QA 리스트의 샘플을 구해서 봤습니다. (sepia 과장님 고맙습니다.^^) 저는 통을 쓰지 않는데도 QA리스트의 항목을 보고나니까 마치 QA테스트를 할 수 있을것 같은 자신감이 들더군요. 짧은 항목은 10글자 내외짜리도 있고 긴 항목도 두 줄을 넘기지 않지만 명확하게 테스트를 해야 할 항목이 명시되어 있었습니다. “[대상A]가 [상황A 또는 동작A]일 때 [대상B]가 [동작B]를 하는가?”처럼 오해의 소지가 없이 명확한 테스트를 할 수 있도록 항목이 잘 짜여져 있었습니다. 각 항목이 포함된 기능분류도 잘 되어 있었구요. 해당 항목의 테스트를 진행할 사람이 명시되어 있었고, 처리여부(○,△,Ⅹ)와 코멘트를 입력할 수 있도록 되어 있더군요. 이글루스가 했던 방법과는 조금 차이가 있던게 저희는 하나의 QA 리스트를 가지고 테스트 참여하는 사람은 전체 항목을 다 테스트를 했었습니다. 한명은 IE6, 한명은 IE7, 한명은 Firefox 이렇게 브라우저별로 나누어 전체 항목을 테스트 했는데 이런 차이는 서비스별로 최적화의 영역이 아닐까 싶네요.

QA를 시작하고 서비스를 오픈하는데까지는 QA목록을 만드는 것보다 100배는 골치아픈 일이 생기고 복잡,미묘한 기류를 헤처 나가야 합니다. 그렇지만 당장의 서비스오픈날짜에 쫒겨 그 힘든 과정을 회피하거나 포기한다면 서비스 사용자들이 그 불편함과 고통을 겪게 되고 서비스 제공자는 결국 댓가를 치뤄야겠지요.

동작은 하는가, 하려고 하는 모든 기능이 제대로 되는가, 혹시 잘못 동작할 우려는 없는가에 대한 테스트는 각각 50점짜리,80점짜리, 100점짜리 서비스가 되느냐 마느냐의 차이같습니다.

QA에 대해 참고할만한 사이트나 책이 있으면 소개도 부탁드릴게요.