‘쉬어가기.. 혁신을 이끌어내는 방법 [1]‘ 에서는 개발자들에게 쉬어갈 수 있는 시간을 제공함으로써 창의와 혁신을 이끌어는내는 이야기를 해보았다. 이번에는 ‘직접보기’라는 주제로 비슷한 이야기를 해보려 한다.

‘직접보기’ 가 필요한 이유는 아래의 그림을 보고 생각해보자. 이 그림이 말하고자 하는 원목적은 완전히 동일하진 않지만, 실물을 보지 않고 커뮤니케이션 했을 때의 문제를 효과적으로 말해주고 있다.

정리하면 고객이 원하는 것을 각 사람/조직마다 다르게 이해하고 있으며 심지어 고객 스스로도 자신이 무엇을 필요로 하는지 알지 못한다 것이다.

시장 조사를 토대로 고객의 needs 를 모두 만족시킨 제품의 출시 후 반응이 그리 좋지 않은 수많은 사례들을 잘 설명할 수 있는 논리이기도 하다.

혁신적인 제품을 잘 만들어내기로 유명한 애플(Apple)사의 경우, 신제품을 만들 때 시장 조사를 아얘 하지 않는 것으로도 유명하다(You Can’t Innovate Like Apple [2]). 시장에 존재하지 않는 제품에 대해 물어봐야 가치 있는 대답을 구하기 어렵기 때문이다. 대신 스스로 계속해서 실제품 수준의 프로토타입을 수없이 만들어보면서 직접 만져보고 써보며 자신들이 정말 이 제품을 원하는가를 판단한다. 그 결과 애플의 제품들은 종종 시장에서 당연히 필요하다고 생각하는 기능이 빠지기도 하고 이미 더 나은 제품들이 수두룩한데~ 라고 평가절하되곤 한다.

이미 만들어진 제품에 대해서는 다르다. 직접 사용해본 사용자들의 피드백은 소중하다. 애플 리테일 스토어가 중요한 역할을 수행하는데, 리테일 스토어의 직원들은 고객이 와서 들려준 이야기들을 놓치지 않고 본사로 보고하게 되어 있다. 그래서 스티브 잡스는 아이디어 도둑(유명 마케터 이해선 대표의 메시지 [3])이라는 말이 나오기까지 했다.

고객의 소리를 듣는 방식에 있어 두 경우가 다르다고 이야기했지만, 사실 그 원리는 동일하다. 바로 제품을 직접 만져보고 사용해본 사람들의 소리를 듣는다는 것이다.

이는 사실 애자일, 전통 할 것 없이 거의 모든 소프트웨어 개발 방법론에 중요하게 다루는 주제이고, 결론 또한 항시 동일하다. 짧은 반복 주기로 매 주기마다 동작 가능한 제품을 내놓고, 이를 고객에게 보여주고 피드백을 받는다. ‘당신이 말한 것을 우리는 이렇게 이해했는데, 이것이 정말 당신이 원했던 것이오?’ 를 확인하는 가장 중요한 절차인 것이다. 진정 공존을 원한다면 이 과정에서 쓸데없는 과장과 화려한 프리젠테이션은 없어져야 한다. 그리고 프로젝트 진행에 관련된 주요 인력들이 다 참석하는 것이 좋다. 고객, 프로젝트 리더, 영업 담당자, 주요 개발자들 등이 포함된다. 이들이 자주 모여 현실을 냉정하게 보고 허물없는 이야기를 하다보면 다음과 같은 반응들을 심심치 않게 목격할 수 있을 것이다.

1. 내가 말했던 건 이게 아니었어요. 이러저런 모습을 상상했었는데요. 다음 릴리즈땐 이렇게 고쳐봐주세요.
2. 내가 의도했던게 이게 맞긴 한데.. 직접 써보니 좀 이상하군요. 다른 아이디어가 있을까요?
3. 이 부분은 제 생각과 다르긴 하지만.. 솔직히 지금이 더 좋아 보이는군요. 이대로 갑시다.

직접 보기는 서로의 생각을 확인하고 공유할 수 있는 가장 좋은 방법이며, 다음 방향을 결정짓기 위한 논의를 시작하기 위한 믿음직한 베이스가 되어준다.

또한 개발자들에게는 자신들의 창의력과 열정을 어필할 수 있는 절호의 기회가 되기도 한다. 직접 구현하면서 가장 먼저 써보게 되는 개발자들은 가장 빠르게 피드백을 줄 수 있는 훌륭한 고객인 셈이다. 이해한 요구사항대로 구현했을 시 불편한 부분이 있거나 더 나은 안이 떠오르면 릴리즈 전에 그 아이디어를 정리해두자. 가능하다면 직접 구현해서 보여주는 것이 가장 좋다. 직접 사용해본 고객과 말이나 문서 정도로만 본 고객은 확연히 다른 반응을 보인다.

이런식으로 개발자들의 능력을 인정받고 발언권을 강화해두는 것이 조직 전체의 커뮤니케이션과 생산성 향상, 제품 혁신에 긍정적인 영향을 줄 것이다. 개발자들은 기본적으로 창의적인 인력들이며, 이에 더해 현실적이다. Sci-fi 영화에나 나올 법한 허무 맹랑한 꿈을 꾸지도 않고, 일부러 과장하려는 경향도 적다. 먼 과거와 달리 골방의 괴짜들이 모여 있는 집단도 아니다. 윗사람들보다 신세대이며 소비의 주체라는 장점도 있다.

결론?

조직은 제품을 직접 보고 함께 이야기하는 문화를 정착시킴으로써 많은 것을 얻을 수 있다. 단, 어설프게 릴리즈 압박용으로만 오용하지 않도록 주의하자. 상향식 변화는 실패할 것이며, 하향식 변화는 성공한 것 처럼 보일 것이다. ^^ [4]

[updated]

사례를 몇 가지 추가해보기로 하였다.

• Developing Torchlight [5] – Runic Games 사에서 Torchlight 라는 게임을 제작하는 방식을 이야기한다. 그들은 짧은 주기로 항시 play 가능한 게임을 만들어 개발자, QA 팀, 심지어 그드의 가족, 친구들까지 초대해서 게임을 즐기게 했다고 한다. 시장에서의 성공 여부는 아직 판가름하기 이르지만 기대를 가지고 지켜보고 있다.
• 와우 성공 요인은? [6] – 초창기 와우 개발을 이끌었던 블리자드의 수석 PD 인 셰인 다비리 를 인터뷰한 내용이다. 초창기 가장 어려웠던 점 중 하나는 블라지드로써는 낯선 장르였던 MMORPG 의 비전을 경영진에 설득하는 것이었다고 한다. 직접 만들어 알파 버전을 보여주니, 절대 성공할 수 없다고 말하던 사람마저 하루 아침에 자신의 편이 되었다 한다.
• Eclipse [7] 와 Jazz/RTC [8] – 오픈소스 개발 환경 프로젝트 중 역사상 가장 성공적인 프로젝트 중 하나인 Eclipse 와 그 개발 과정에서 얻은 노하우까지 툴에 녹이고 있는 Jazz/RTC 프로젝트도 좋은 예가 될 수 있다. 이들은 1년 주기의 정식 릴리스 사이에 6주 정도의 간격으로 다수의 안정적인 Milestone 버전을 내놓는다. 그리고 이전 릴리스 대비 어떤 기능이 개선되었는지 알기 쉽게 보여주는 New & Noteworthy 를 함께 알려주어서 사용자들이 정식 릴리스를 기다리지 않고도 새로운 기능들을 빠르게 접해볼 수 있다. Milestone 버전은 충분히 안정적이기 때문에 critical 한 프로젝트가 아니면 큰 부담 없이 새 milestone 을 테스트해본다. 이런 방식으로 사용자 커뮤니트의 빠른 피드백을 유도해 지속적으로 다음 릴리스에 반영해나간다.
• Mobile SecondLife [9] – 내가 참여해 진행하다 중단된 프로젝트다. 과제 초창기부터 개발진에서는 도저히 성공 가능성이 없다고, 이걸 누가 쓰겠냐며 과제의 의미를 찾지 못하고 있었다. 링크의 데모는 연구 성격의 개념적 시연이어서 상당히 제한적인 환경에서만 동작 가능했다. 이를 바로 상품화하려 하니 현실적인 제약들 때문에 흥미로운 개념들의 거의 모두를 다 들어낼 수 밖에 없었다. 남은 것만으로는 정말 시도할 가치가 없는 과제였다. 하지만 그 목소리가 경영진에까지 전파되지는 못했다. 수개월간의 고생 끝에 만들어진 베타 버전을 임원에게 시연한 바로 다음날 과제는 바로 중단되었다.

1. 쉬어가기.. 혁신을 이끌어내는 방법 (wegra.org)
2. You Can’t Innovate Like Apple (Pragmatic Marketing)
3. 유명 마케터 이해선 대표의 메시지 (제레미의 TV 2.0 이야기기)
4. Bad Team Culture – 변화의 시작.. 상향식? 하향식? (wegra.org)
5. Agile Approach in Game Development (wegra.org)
6. 와우 성공 요인은? 전 수석 PD 셰인 다비리 인터뷰 (Inven Communications)
7. Eclipse (Eclipse Foundation)
8. Jazz/RTC (IBM Rational)
9. Mobile SecondLife (Samsung)