‘웹 개발 방법론 및 협업의 길’ 패널토의에서 못 다한 이야기

웹어플리케이션 2007 이 6월 21일 삼성동 코엑스에서 있습니다.
저는 오후 세션 중 ’16:10—16:50 Panel 웹 개발 방법론 및 협업의 길’ 에 우연한 기회로 패널로 참가 했습니다.
패널토의가 열린 장소는 꽤 넓었습니다. 약 500명 정도가 있었다고 합니다. 앞에 앉아 있을 때에는 불빛 때문에 앞줄에 있는 사람 밖에 보이지 않았고, 비디오 카메라가 있었는지 앞쪽에서 모니터링 할 수 있는 화면이 있었습니다. 앞에서 그 모니터를 보니깐 재미 있던데요.
SIGCHI 2006 의 패널토의에서 flickr.com 창업자가 패널토의에 나왔는데, 이 사람은 패널 토의 중간 중간에 패널들과 플로어를 사진을 찍더라구요. 문득 앞에 나오니깐 그 생각이 나서 저도 한번 해볼까 했는데, 차마 못하겠더라구요.

(패널토의 사진 출처)
 
40분은 1명의 좌장과 3명의 서로 다른 배경과 회사의 사람들이 ‘협업’ 에 대해서 논의를 하기는 짧은 시간이었습니다. 역시나 예상했던 데로 재미있게 논쟁을 하기에는 짧았지만, 다른 직무에서의 접근과 다른 회사문화를 조금이나마 들을 수 있었던 것 같습니다.
저는 패널토의를 기회로 웹 서비스 개발에 대한 협업에 대해서 생각해 보았 습니다. 시간이 짧아서 다 얘기를 하지는 못해서 못한 내용까지 블로그에 정리를 하려고 합니다.

(패널 토의 사진 출처)
 
 
 
협업의 주체와 대상
패널토의에서의 웹 서비스 개발은 SI, MIS, 솔루션 개발 보다는 인터넷 비즈니스 영역으로 규정을 지었습니다. SI 나 솔루션 개발에 비해서 인터넷 비즈니스는 비즈니스 모델이나 시장 출시 등이 다른 것 같아서 구별을 했습니다. 그래서 협업의 주체나 대상은 제품 관리자, 비즈니스 기회자, UI 기획자, 디자~이너, 마케터, 프로그래머로 보았습니다. 여기에 최고 경영자나 부서장도 포함 될 수도 있을 것 같습니다.

협업은 전문화가 요구하는 시대적 요청이다
전통적인 소프트웨어 개발은 프로그래머가 비즈니스 기획을 하고, 요구사항을 수집하고, 태스크 분석을 해서 인터렉션을 설계하고, 아이콘이나 배경화면등의 디자~인을 하고, 구현을 하고, 테스트를 하고, 확산을 하고 , 마케팅을 하고 영업을 하고, 이런 컨퍼런스와 같은 트레이드 마케팅을 했습니다. 그러나 이제는 모든 것이 전문화 되어 가고 있습니다. 인터넷 비즈니스에서는 기존 소프트웨어 엔지니어링 외에 기획, 인터렉션 설계, 디자~인, 마케팅이 추가적으로 세분화되어 왔습니다. 요즘은 거꾸로 소프트웨어 엔지니어링도 기술 에반지리스라고 하면서 마케팅개념을 도입하기도 하는 것 같습니다. 전문화가 되면서 혼자서 할 수 있는 것은 점점 줄어 들고 자연스럽게 협업이 중요해진 것 같습니다.
협업은 소프트웨어의 CMM처럼 프로세스의 성숙도와 기업 문화에 따라서 크게 좌우될 것 같습니다. 기업의 프로세스 정도나 조직문화나 팀웍에 대한 이야기는 다른 데서도 많이 볼 수 있을 것 같습니다. 저는 일반적인 조직관리 이야기 보다는 제품 전략 측면에서 생각 해 보았습니다.
 
 
한 개의 답은 없다.
그림은 노만이 <보이지 않는 컴퓨터>에서 ‘Brian Hall Clark of clarkcooper design’ 를 인용한 것입니다.

디자~이너는 다른 어떤 의자에 비해 독특하고 기교 있는 의자를 원합니다. 건강과 안전을 우선하는 사람들은 손,발,머리,머리등을 부상으로부터 보호하기를 원합니다. 엔지니어는 엄격하고 튼튼하고 실용적인 설계를 합니다. 마케팅 부서는 포커스그룹을 연구하고 나서 조정장치, 엑세서리, 컵 받침 등의 요소를 추가해달라고 합니다. 제품 생산자들은 간단한 도구들을 가지고 자르고 연결 할 수 있는 단순한 자료들을 원합니다. 소비자들은 단순하면서도 편하고 앞뒤로 흔들며 앉을 수 있는 의자를 원합니다. 이렇게 디자~이너, 엔지니어, 제조업체, 마케팅, 사용자가 서로 다른 니즈를 갖고 있습니다.
아마도 제품을 기획하거나 설계, 개발하면서 이렇게 서로 생각하는 제품의 모습이 다를 것입니다. 이 의자들은 모두 다 다릅니다. 그러나 틀린 것은 아닙니다. 각자의 역할에서는 맞기 때문입니다. 그런다고 한가지 답이 모두의 답이 되지는 않습니다.
 
제품관리자는 시장 상황과 기술, 사용자의 니즈에 따라 균형있게 결정해야 한다.
결국 제품 개발을 할 때에 균형이 필요하게 됩니다. 그리고 이 균형은 시장 상황, 기술, 사용자의 니즈에 따라서 이루어져야 한다고 생각합니다.
구매계층 모델 을 보더라도 한 가지 속성이 시장을 계속 지배하는 것이 아니라 기능, 신뢰, 편리성,가격 등 그 속성이 변하는 것을 알 수 있습니다.
수용자를 중심으로 보는 기술수용주기모델 에서도 마찬가지 입니다. 시장 초기에는 기술이 기반이 된 기능이 필요하고, 그 다음에는 사용성이 중요하게 됩니다. 비즈니스 상황에 따라서 마케팅이 필요할 때와 기술이 필요할 때, 사용자 경험이 필요 할 때가 있습니다.
저는 구체적인 내용은 조금 다르지만 노만이 주장한 사용자 중심의 제품은 비즈니스 상황에서 기술, 마케팅, 사용자 경험에 동의 합니다. 제품이 의자라면 이 세가지는 다리입니다. 그리고 의자는 비즈니스 상황 위에 있습니다. 제품이라는 의자는 어느 한 다리만 없어도 서 있을 수 없습니다. 기술, 마케팅, 사용자 경험 이 세가지 모두 중요합니다. 다만 아까 이야기 한데로 비즈니스 상황에 따라서 집중해야 할 요소가 다릅니다. 비즈니스 상황에 따라서 마케팅이 중요할 수도 있고, 기술이 중요할 수도 있고, 인터렉션이, 디자~인이 중요할 수도 있습니다. 이 서로 다른 요소에 대해서 균형을 결정하는 것은 제품 관리자 입니다. 제품 관리자는 그 제품의 비즈니스를 책임지므로 비즈니스 성공을 위해서 균형을 잡아야 합니다.
 
제품 관리자는 오케스트라 지휘자 처럼 균형을 맞추는 역할을 하고, 제품 개발과정에서 악기를 다루는 연주자들은 다음의 두 가지를 가져야 할 생각이라고 생각합니다.
 
 
 
각 역할은 최종 목적인 비즈니스와 사용자에 집중
저는 사용자에게 유용하고 사용하기 쉽고, 사용하고 싶은 제품을 만들고 그래서 사용자가 가치를 느끼고 좋아하는 제품을 만드는 것이 사용자 중심의 제품 개발이라고 생각합니다. 그러나 기업에서는 이것만으로는 안되고 동시에 비즈니스가 되어야 합니다. 사용자 중심 제품 개발은 무조건 이익 추가가 아니라 사용자에게 가치가 있는 것이 비즈니스가 되는 것을 말합니다.
기업은 고객중심, 고객 감동이라고 대외 커뮤니케이션을 하지만 이윤추구가 그 기본입니다. 비즈니스를 하기 위해서 제품을 만들고 제품을 알리고 팝니다. 다시 제품을 만들고 판매를 하기 위해서 회사는 각 역할을 나눠놓았습니다. 수직적 구조이던지 수평적 구조이던지 간에 최종 목적은 비즈니스 입니다. 즉 시장 점유율과 수익이 일반적인 목적입니다.
물론 사용자 중심이 제품 지향에서는 무조건 수익만을 생각하는 것은 아닙니다. 그러나 이 이야기를 하는 것은 각 역할은 자기의 역할만을 생각할 때에 협업이 되지 않기 때문입니다.
예를 들어, 이 숫자를 단기간에 무조건 맞추어야 한다는 경영자와 제품 관리자, “사회적 네트웍크가 대세이니 이러한 개념으로 제품을 만들어야 한다” 고 하는 인터넷 기획자. “최신의 기술을 사용해야 한다” 고 하거나 이런 기능이 필요하다고 하는 프로그래머, 디자~이너만 아는 디자~인을 하는 디자~이너. 이런 제품 품질로는 마케팅을 할 수 없다고 하는 마케터, 사용자가 이런 것이 불편하고 이런 것을 필요로 한다고 하는 유저 리서처, 이러면 사용자가 불편한 것이라고만 하는 인터렉션 설계자, 소비자는 이런 것은 쓰지 않을 것이라고 하는 시장 조사자들이 있습니다.
제품관리자는 이러한 점들을 조율해야 합니다. 각 역할자는 자기의 역할 뿐만 아니라 자기의 역할이 존재하는 최종 목적을 생각해야 할 것입니다. 비전을 공유하고 공감하는 것이 시작일 것입니다.
최종 목적인 비지니스가 되기 이해서는 사용자가 제품을 사용해야 합니다. 그리고 각 역할들은 제품을 사용할 수 있도록 만들고 알리는 작업을 해야 합니다. 제품 관리자, 기획자, 인터렉션 설계자, 디자~이너, 프로그래머, 마케터, 리서치는 각 역할도 중요하지만 궁극적으로 목표하는 것은 제품이 사용되게 하고, 그래서 비지니스가 되어야 함을 잊어서는 안될 것입니다.
제품 개발은 전략적인 측면에서 오케스트라와 같은 균형과 조화를 이루어야 하고, 동시에 째즈와 같은 성격도 다 같이 있어야 합니다.
 
 
 
각 역할은 자기 역할에서 전문가이면서 다른 역할을 이해하는 지식과 열린 마음을 통한 팀웍

한 분에 대해나 전문가 이면서 다른 분야에 대한 기초적인 이해를 하고 있고, 열린 마음을 가지고 있고, 공동의 목표가 있을 때 팀웍이 이루어진다고 생각합니다.
T자형 인간이나 십자형 인간등은 한분야 뿐만 아니라 다른 분야에 대해서 전문가적인 지식을 갖춰서 다른 사람과 협업을 할 수 있다는 것을 전제로 하고 있는 것 같습니다.
동시에 이해할 수 있는 열린 마인드를 가지고 있어야 합니다. 그래야 서로 다른 전문가들이 협업을 할 수 있습니다.
제가 S그룹을 나오기 전에 S그룹 HCI연구회 모임을 다시 열자고 제안을 해서 종합기술원에서 모임을 한 적이 있었습니다. 그때에 어떤 분이 오셔서 저 한테 물었습니다. “새로 프로젝트를 하는데, 인간공학, 디자~인, 전산학 등의 박사들로 팀을 만들었는데 잘 안됩니다. 어떻게 해야 하나요?” 라고 말입니다.
저는 “아마도 자기 분야만 고집하고 다른 분야와의 협업이 없었을 것입니다” 라고 답했습니다.
그 당시에는 T자형, 십자형 인간형이란 말은 몰랐고, 이중 전문가, 삼중 전문가가 제가 하고 있는 목표였습니다. 자기 분야에는 정통하지만 다른 분야와 어떻게 어우러질지 모른다면 어떻게 협업을 하겠습니까. 그러니 전문가들이라고 데려다 놓고 전문가 평가를 하면 다 다른 전문 분야의 다른 이야기만 합니다.
 
 
시간이 없어서 청중에서 질문을 받지 못하고, 좌장이 사전에 올라온 질문 중에서 2개를 선정했습니다.
 
질문1. 현재 기업의 생산성에 있어서 가장 중요한 것은 구성원간의 협업이라 생각합니다
그 중에서 가장 중요한 것은 상호간의 커뮤니케이션이라고 생각합니다. 각 업체에서 이런 커뮤니케이션을 어떻게 수행하는지 궁금합니다. 그리고 사용하는 툴이 있다면 어떤 것이 있는지요? –천사마음
우리회사의 경우에 벅질라는 시스템을 사용합니다. 원래 버그를 팔로업 하기 위해서 만든 시스템이지만, 제품 별로 벅질라가 있어서 해당 제품과 관련된 각 역할간의 협업 시스템으로 사용하고 있습니다.
그외에 다른 점은 리서치가 참여해서 제품 개발을 할 경우에는 모든 역할간의 논의의 시작을 사용자의 데이타로 시작 한다는 것입니다. 기획자, 디자~이너, 프로그래머, 마케터가 모든 리서치에 참여합니다. 필드 리서치를 하면 현장을 같이 다니고, 사용성 테스트나 포커스그룹 인터뷰를 하면 실험실의 관찰룸에서 같이 관찰을 하고 논의를 합니다. 설문 조사나 갱서베이, 데이타 마이팅 데이타도 경영진 뿐만 아니라 모든 역할과 공유하고 있습니다.
각 역할들은 자기가 만드는 제품의 최종 사용자의 피드백을 받고 이를 통해서 여러 아이디어를 내고 있습니다.
 
 
질문2. 웹 기획시 기능을 실제로 구현 가능한데도, 개발자의 반대에 부딪힐 경우 어떻게 극복하는 지 궁금합니다. 예를 들어 개발자가 기획한 기능이 제대로 구현되지 않는다라든가, 이 기능을 넣을 경우 개발 시간 때문에 프로젝트가 지연될 가능성이 있다거나 하는 문제.. 하지만 기획자는 이 기능을 꼭 넣었으면 하는 상황같은 경우죠. 어떤 해결 방법이 있나요? –김장우
기획자건 개발자건 상관없이 저는 이렇게 애기 합니다. “그거 니 생각아냐?”
이 대목에서 사람들이 웃었다고 하더군요. 구현의 요구사항이 검토된 사용자 니즈가 아니라 개발자나 기획자가 생각하는 니즈에서 나오는 경우가 이런 문제를 발생시킬 수 있습니다.
그동안 소프트웨어를 프로그래머 혼자서 북치고 장구치고 하던 시절에서 프로그래머 스스로 가장 사용자를 잘 안다고 생각했습니다. 자기가 태스크를 분석 하기 때문에 가장 사용자를 잘 안다고 생각했었습니다. 그건 자기 생각인데 말이죠.
그런데 인터넷 비지니스에서 웹 기획자 같은 직무가 전문화 되었는데도 전혀 바뀌지 않은 것 같습니다. 다 자기가 생각한 것을 만들려고 합니다. 그것도 여러사람 피곤하게 하고, 회사 돈을 펑펑 쓰면서 말이죠. 시대는 변했고, 소비자 중심, 사용자 중심의 경영이나 제품 개발을 맨날 들으면서도 실제로는 그렇게 하고 있지 않습니다.
결정 기준은 기획자나 개발자가 아니라 사용자와 시장이고, 이는 사용자 연구를 통해서 도출되고 합의 되어야 할 것 입니다. 바로 이러하 이슈에서 시장 조사나나 사용자연구자는 검사나 판사의 역할을 합니다. 이 애기를 들던 옆 패널 분은 리서치가 있으면 좋겠다고 하더군요.
 
 
 
이상은 그냥 일반적인 조직관리나 협업의 관점 보다는 제품을 개발하는 과정에서 생각해 보았습니다.
웹 개발에서 협업은 비지니스 상황별로 제품 관리자가 균형을 이루게 하고, 각 개인은 최종 목적인 비즈니스비 집중하고, 전문성을 바탕으로 다른 분야를 이해할 수 있는 지식와 열린 마음을 바탕으로한 팀웍이 필요하다고 생각합니다.
 
이 외에 서로 협업을 잘 하기 위해서는 어떤 방법이 있을까요?