Share           Pin It
나름 테크기업에서 일하다보니 가끔 듣는 얘기가 있다. 외국의 유수 테크기업들은 기획자라는 포지션이 따로 존재하지 않는데, 한국에만 특이하게 기획자라는 직군이 존재한다는 얘기다. 한국에서 기획자들의 역할을 대략 생각해보면 개념을 디벨롭해서 서비스/제품을 디자인하고 프로젝트의 일정을 관리하면서 결과물에 대한 품질 검수(때론 운영)까지 다양한 일을 한다. 그런데, 구글이나 페이스북같은 서비스 회사에서는 개발자들이 (직접 프로토타이핑하면서) 개념을 디벨롭하고, (중간) 매니저들이 일정이나 리소스 관리 정도를 해주고, 자동화된 테스팅 툴이나 특화된 QA 조직에서 품질검수를 해준다. 애플같은 회사에서는 개념 디벨롭이 디자이너들에게 많은 권한이 넘어가있다는 특징도 있다. 이렇게 보면 기획이라는 특화된 직군이 필요가 없고 누구나 기획의 역할을 담당하면서 분업/전문화되있다는 느낌을 받는다.

그럼에도 불구하고, 여러 서비스를 담당하며 다양한 기획자들과 일하다보면 기획자들만이 가지는 특장점을 종종 목격하게 된다. (즉, 이 글의 목적이 기획자가 필요없다는 얘기를 하려는 것이 아니다.) 특히 개발자들과는 다른 다양한 분야/전공에서 오는 (다양성의) 장점을 발견할 때가 많다. CS나 공학을 전공한 사람이 볼 수 없는 다양한 면을 볼 수 있다는 것은 (만인을 위한) 서비스/제품을 개발하는데 분명 도움이 된다.


(세부 업무를 무시하고) 얼핏 생각하면 기획자는 큰 틀에서 서비스나 제품의 밑그림을 그려야하는 사람이라는 느낌을 은연중에 받는다. 그런데 현실적으로 기획자는 큰 그림을 그릴 수가 없다. 기획자 개인의 능력이나 자질을 얘기하는 것이 아니라, 그들의 권한을 얘기하는 것이다. 극단적으로 주니어 기획자가 괜찮은 서비스에 대한 아이디어를 낸다고 쳤을 때, 그 아이디어가 바로 실현될 가능성이 몇 퍼센트나 될까? 2, 3년 내에 비슷한 서비스가 만들어진다면 그나마 괜찮은 편에 속할 것이다. 대부분의 아이디어는 두세단계 위로 올라갈 기회조차 없다. 일명 그냥 까인다. 결국 (큰 조직에서) 서비스에 대한 큰 그림을 그리는 그리고 그려야하는 사람들은 힘있는 경영자나 창업자인 경우가 대부분이다. (그러나 급변하는 사회에서 늙은이들의 생각은 신뢰하지 못하겠다.) 관리자가 관심을 가지는 아이템에 대해서 살을 붙이고 구체적인 채색을 하는 것이 실무 기획자들의 몫으로 내려온다.

현실이 그렇기에, 내가 기획자들에게 바라는 큰 두가지는 [첫째] 가능성이나 현실성을 염두에 두지 말고 다양한 상상을 하는 것과 [둘째] 서비스의 디테일을 챙기는 것이다. 서비스나 기능의 가능성은 개발자가 검토하고 리소스나 일정은 관리자가 걱정/조율하면 된다. 대신 기획자는 자신의 서비스에 대한 다양한 모습을 상상하고 시나리오를 만들어내는 것이 첫째 미션이다. 그리고 실제 개발된 서비스나 제품이 고객들에게 전달되기 전까지 그리고 전달된 이후의 세심한 디테일을 모두 챙기는 것이 둘째 미션이다. 내 생각이 틀렸을 수도 있다. 그러나 지금 나는 그렇게 믿는다.

이것이 나의 1001번째 생각이고, 함께 일하는 분들에게 해주고 싶은 얘기다.

==
페이스북 페이지: https://www.facebook.com/unexperienced


댓글을 달아 주세요

속도와 방향

Gos&Op 2013.05.27 09:43 |
Share           Pin It

간혹 TV강연이나 블로그 등에 좋은 글이라고 소개된 것들을 보면 성공하기 위해서는 속도보다는 방향이 더 중요하다고 말한다. 목표한 바가 확고하다면 믿고 느리더라도 묵묵히 가라는 메시지다. 틀린 말은 아니다. 그러나 속도보다 방향이 중요하다고 말하는 것은 그저 이미 성공했던 사람들의 자기 방어에 불과하다. 요즘과 같은 불확실한 시대에는 방향보다 속도가 더 중요하다. 특수한 경우가 아닌 이상은 올바른 방향을 처음부터 알 수가 없다. 재벌가의 자녀로 태어나거나 어릴 적부터 악기나 운동에 천재적인 재능을 보이지 않는 이상 사람이 성공하는 방향을 절대 알 수가 없다. 어느 게 맞는 방향인지 알 수 없는 상황에서 방향이 중요하다고 말하는 것은 공허한 울림에 불과하다.

방향을 알 수 없기 때문에 속도가 중요하다. 느림의 미학도 존재하고 완급의 묘미도 있지만, 일반적으로 빠를수록 좋다. 처음부터 올바른 방향을 잡았다면 빠르면 빠를수록 빨리 목표지점에 도착할 수 있고, 방향을 잘못 잡았다면 빠르면 빨리 방향이 잘못되었다는 것을 파악하고 방향을 바로 수정할 수가 있다. 그런데 방향이 중요하니 그곳을 향해서 느리더라도 지치지 말고 나아가라라고 말한다면 그 방향이 맞을 때는 괜찮지만, 만약 방향이 조금이라도 잘못 되었다면 온갖 수고를 다 하고 나서 결국 잘못된 곳에 도착할 수 밖에 없다. 그리고 방향이 맞더라도 속도가 느리면 의미가 퇴색되는 경우가 많다. 올림픽 100m 달리기에서 메달을 따지 못한 선수들은 방향이 틀려서가 아니라 속도가 느려서이다. 목표를 완성하기 위해서 방향이 시작이라면 속도는 끝이다. 시작이 반이다라는 말이 의미가 있지만, 끝이 없으면 시작의 반은 헛수고에 불과하다.

서비스나 제품의 개발 방법론도 방향과 속도에 대비해서 생각해볼 수 있다. 기획 중심의 개발은 방향을 중시하는 방법론이고, 실행 중심의 개발은 속도를 중시하는 방법론이다. 이전 글들에서도 밝혔지만, 개인적으론 (일반적으론) 실행 중심의 개발 방법론이 맞는 것같다. 적은 초기 리소스를 들여서 실험하고 검증해보고 더 큰 리소스를 들려 완성하면 된다. 초기 실패가 전체 실패로 이어지지 않는다. 그러나 잘못된 기획은 자칫 많은 리소스만 허비하고 결국 전체 실패로 귀결될 수가 있다. 물론 잡스와 같이 천재적 기획자가 있다면 얘기는 달라진다. 스스로 나는 또는 우리 팀은 천재적인가?를 자문하고, 조금이라도 의심이 든다면 개발, 속도 중심의 접근법을 택할 것을 권한다.

빨리 실패하고 작게 실패하고 많이 실패하는 것이 성공의 밑걸음이 된다. 단, 실패에 익숙해지면 안 된다.

(2013.05.24 작성 / 2013.05.27 공개)

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

완벽에의 집착

Gos&Op 2013.04.16 08:48 |
Share           Pin It

보통 사람이라면 누구나 완벽할 수는 없어도 완벽을 한 번쯤은 꿈꿔본다. 주어진 모든 문제를 단번에 해결하는 그런 만능인이 된다거나 자기가 만든 모든 것들이 완벽하게 작동하는 것을 상상해본다. 시험을 치를 때는 채점하기 전까지는 마치 만점을 받은 것같은 착각이 들 때도 있고, 몇 만 라인의 코드에 버그 하나없이 자연스럽게 실행되는 것을 상상하기도 한다. 완벽을 향한 동경 또는 집착은 누구나 가지고 있다.

서비스를 새롭게 만들 때도 기획자들도 완벽을 꿈꾸는 듯하다. 모든 사용자들의 니즈를 모조리 파악해서 만인의 필요를 충족시켜주는 그런 서비스를 꿈꾼다. 그래서 가능한 모든 기능을 생각하고, 이것만 추가되면 서비스가 완벽해질 거고 사용자들은 즐겁게 사용할 거야 등과 같은 망상에 빠져든다. 한 번 망상에 빠져들면 그것을 생각하면 생각할 수록 더욱 깊이 빠져든다. '이건 분명 대박일 거야. 사람들이 이걸 좋아하지 않을 수가 없어.' 등과 같은 자기 암시에 빠진다. 물론 그런 긍정적인 자세는 필요하다. 그러나 그런 완벽에의 집착이 결국 서비스를 그릇되게 만들고 만다.

세상에는 완벽한 것이 없다. 이론적으로 완벽한 것이 있다면 수학에서 0정도는 생각할 수가 있고, 종교에서는 신만이 완벽하다. 만약 완벽한 것이 존재한다면 우리에겐 기회가 없다. 이미 완벽한 대체제가 존재하는데 왜 우리가 새로운 서비스를 만들어야 하는가?라는 의문이 든다. 구글이 검색 시장을 장악했지만 새로운 검색 서비스들이 등장하고, 페이스북이 인터넷을 거의 차지한 것같지만 또 다른 SNS들이 선을 보인다. 시장을 지배한 그것들이 완벽하지 않기 때문에 그것을 대체 또는 보완할 새로운 것을 생각하게 된다.

서비스를 기획하면서 신규 서비스는 기존의 모든 것들을 커버하고 또 사람들의 새로운 니즈와 욕구를 모두 충족시켜줘야 한다는 그런 망상 아닌 망상에 사로잡혀있는 경우가 많다. 신규 서비스는 이런 이런 기능들이 모두 포함되어있어야 하고, 이런 기능은 차별화 포인트이기 때문에 꼭 필요하다는 식의 요구조건들이 만들어진다. 그렇게 늘어난 요구조건을 모두 충족시키기 위해서 개발기간은 무한정 늘어나고, 또 많은 기능들로 인해서 서비스는 복잡해진다. 당연히 더 많은 라인의 코드는 더 많은 버그를 양산한다. 결국 완벽을 꿈꿨던 서비스는 스스로의 무능으로 잊혀져간다. 리드타임이 길어서 외부트렌드가 변했거나 경쟁 서비스가 이미 나왔을 수도 있고, 수많은 버그들과 복잡성 때문에 사용자들의 외면을 받을 수도 있다.

그렇기 때문에 100을 꿈꾸더라도 처음에는 핵심 기능과 몇몇 차별화 포인트만을 충족시키는 7~80정도를 선보일 필요가 있다. 50보다 밑이면 사람들이 쳐다보지도 않기 때문에 어느 수준의 완성도는 필요하다. 그렇게 런칭했으면 또 사람들의 피드백을 보면서 나머지 2~30을 더 추가하고 개선하면 된다. 그렇게 100을 만들고, 또 다른 100을 덧붙여서 200을 만들어 가야 한다. 그런데 우리는 처음부터 100을 만들겠다는 욕심과 집착으로 100을 만들었지만 실제 나온 것은 2~30 밖에 되지 않는 쓰레기만을 만들어낼 뿐이다. 재활용도 불가능하다.

완벽은 좋은 것이지만 집착은 필패로 이어진다. 사실 기획에서 필요한 것은 완벽에 대한 집착이 아니라 디테일에 대한 추구다. 명품은 완벽해서 명품이 아니다. 디테일이 살아있기 때문에 명품이다. 장인도 완벽을 추구하는 사람이 아니라, 디테일을 놓치지 않는 사람이다. 완벽은 존재하지 않는다. 그러나 디테일은 다른 결과를 만들어낸다.

(2013.04.11 작성 / 2013.04.16 공개)

추가. 동영상 내의 가격과 기간 사이의 토론 내용 참조. (9.50)

페이스북 페이지: https://www.facebook.com/unexperienced

댓글을 달아 주세요

Share           Pin It

요즘 기획 회의에 자주 들어갑니다. 기획자뿐만 아니라 개발자들도 함께 모여서 그동안 내부에서 논의된 내용을 장황하게 설명을 해줍니다. 저는 그냥 옆에서 듣고만 있는데 그냥 불안감이 엄습합니다. 그냥 기획은 참 좋은데 왜 그런 불안감이 올까요?

기획자들은 몽상가입니다. 그들의 이야기를 듣고 있으면 세상은 참 긍정적입니다. 꿈꾸는 모든 것이 바로 눈 앞에 펼쳐질 것만 같습니다. 그래서 불안합니다.

개발자들은 참 현실적입니다. 그저 자신이 할 수 있는 이야기만 나오면 바로 달려듭니다. 기술적으로 가능하다는 것을 또는 바로 해결해줄 수 있다는 것을 기획자에게 말해주고 싶어서 안달입니다. 특히 예쁜 기획자 앞에서는 더 자신만만해집니다. 그래서 불안합니다.

기획자와 개발자가 모여서 얘기를 나누는 것을 듣고 있으면 둘 다 문제의 본질은 놓처버린 것같습니다.

기획자들끼리 모여서 이런 저런 아이디어를 추려서 가져옵니다. 비슷한 부류끼리 오랜 시간을 얘기하다보니 그들이 보는 한 가지 세상에 대한 얘기들만 가득찹니다. 서로가 서로에게 좋다좋다 얘기하다보니 자신이 꺼내는 이야기의 현실성이 있는지 없는지를 잊어버립니다. 그래서 꿈같은 기획서를 만들어옵니다. 꿈이 항상 이뤄지는 것이 아닙니다. 그냥 개꿈이나 깨어질 것들이 더 많습니다.

개발자들은 그거 내가 해줄 수 있는데라고 우쭐댑니다. 꿈같은 기획서에 유능한 개발자의 조합이 참 좋아 보입니다. 어느 순간 개발자의 시야도 기획자의 그것과 같아집니다. 이제 마치 꿈이 이뤄질 것만 같습니다. 더이상 이들의 대화에서 틀렸다거나 나쁘다라는 표현이 등장하지 않습니다. 꿈같은 기획서가 깨어지는 순간입니다.

큰 비전을 공유하는 것은 중요합니다. 그러나 서로가 다른 것을 보는 무리에서 큰 줄기의 비전이 중요합니다. 같은 것을 보고 같은 것을 말하는 무리에게는 굳이 비전이 필요가 없습니다. 어차피 따로 달려가도 같은 곳을 향하기 때문입니다. 빛이 모여서 레이저가 되서 단단한 물체도 뚫어버릴 수도 있습니다. 그러나 무리가 막무가내로 내달리다보면 결국 낭떠러지로 모두 떨어지는 경우도 있습니다.

이런 저런 기획, 개발회의를 들어가보면 이런 동질성에 동화되는 모습을 자주 봅니다. 다름이 전제되지 않은 동질성은 결국 레이저가 아니라 낭떠러지로 향하는 한 무리의 짐승떼일 뿐입니다. 모든 기획서는 마치 성공할 것같습니다. 모든 개발은 칼같을 것같습니다. 그러나 대부분은 실패합니다. 꿈이 꿈인 이유는 그냥 꿈이기 때문입니다. 더 현실적인 기획이 필요합니다. 더 시니컬한 개발이 필요합니다. 부정성을 더하고 싶어서 말하는 것이 아닙니다. 혁신은 100번의 NO에서 탄생합니다. 1000번이 될 수도 있습니다. 그렇게 빛을 정제해야지 레이저가 됩니다.

댓글을 달아 주세요

서비스 개발 방법론

Gos&Op 2013.01.21 09:43 |
Share           Pin It

지난 연말에 신규 서비스를 위한 기획회의에 참석한 직후에 적고 싶었던 글입니다. 어떻게 하면 사용자들을 만족시키는 좋은 서비스를 만들 수 있을까?에 대한 글을 적고 싶었습니다. 너무 당연한 일반론이지만 정리해두면 좋을 것같다는 생각을 했습니다. 당시에는 처음부터 제대로된 컨셉/기획안을 만들어서 빈틈없는 개발을 하거나 빠르게 개발하고 사용자들의 반응에 맞춰서 빠르게 수정보완하는 것에 대한 설명을 적을 예정이었습니다. 그런데 이 한문장이외에 덧붙일 내용도 없었기에 그냥 글을 적지 않기로 했습니다. 그런데 최근 몇 가지 더 생각나서 글을 완성시켜야겠다고 마음먹었습니다. 새로운 방법론이라기보다는 앞서 말한 기획중심의 개발과 개발중심의 기획을 확장/변형한 방법론입니다.

성공하는 서비스를 만들기 위해서 어떻게 해야할까요? 기획 또는 개발을 '설계'라는 용어로 아울러서 말하겠습니다.

기획중심의 설계.
가장 먼저 떠오르는 생각은 시대의 트렌드와 사용자들의 니즈를 잘 파악해서 그 트렌드와 니즈를 파고드는 서비스의 컨셉을 정하고, 그 컨셉에 충실한 완벽한 서비스를 기획한다는 것입니다. 완벽한 기획이라는 것이 그 기획대로만 개발하면 무조건 성공할 수 밖에 없는 것입니다. 현실적으로 불가능한 얘기같지만, 말그대로 기획이 완벽했다면 개발 및 운영에 문제가 발생할 수가 없습니다. 보통의 기획서가 완벽하지 않기 때문에 문제인 것입니다. 실패하는 많은 기획서를 보면 대충 리소스를 산정해서 서비스 개발에 대략 10주 걸리고, 테스트하는데 2주면 되기 때문에 3달 후에는 서비스를 런칭할 수 있다 식으로 계획을 세웁니다. 그런데 실제 개발에 착수하면 예기치 못했던 문제들이 발생하고 리소스는 늘 부족하고 개발기간은 늘 촉박하고 그래서 대강 나온 서비스를 제대로 테스트도 하지 않고 런칭을 합니다. 그러면 런칭 직후부터 문제가 터지기 시작하고 초기의 버그는 사용자들을 떠나게 만듭니다. 요즘처럼 대체제가 많은 시기에는 그런 초기의 서비스 불만은 치명적입니다. 우리가 접하는 많은 서비스들은 기획에서부터 시작한 것들이 많습니다. 예전에는 대체제가 없었기 때문에 사용자들이 기다려줬고, 그래서 현재는 나름 성공/정착한 서비스들이 많습니다. 그러나 최근에는 기획에서 시작한 서비스들이 제대로 성공하는 경우를 못 봤습니다. 완벽하지 못했기 때문입니다. 완벽한 기획안을 못 만들면서도 우리는 늘 관념적으로만 이런거 좋겠지?라고 생각하고 불완전한 기획에서 개발에 들어가고 서비스를 런칭하고 그래서 실패하고 맙니다. 다시 말하지만 기획이 완벽하면 서비스는 성공합니다. 제품의 개발주기가 몇년씩 걸리는 산업에서는 여전히 유효합니다.

개발중심의 설계.
두번째로 떠오른 생각은 적당한 감을 가지고 초기 서비스를 만들어보고 일부 사용자들에게 테스트를 받아보고 보완해서 어느 정도 수준에 오른 서비스를 런칭하는 것입니다. 어느 누군가가 이런 기능/서비스가 필요해라고 말하면 그걸 바로 구현해서 적용해보고 사용자들이 꾸준히 사용하면 기능을 더 개선하고 그렇지 않으면 완전히 없애거나 처음부터 다시 디자인/구현해서 런칭을 하는 것입니다. 구글의 성공 이후에 영원한 베타라는 말이 생겼습니다. 지금 가장 많이 사용하는 Gmail도 초기 몇년동안은 계속 Beta 표시를 달고 서비스가 되었습니다. 일반 사용자들은 그냥 괜찮게 사용하고 있었지만 그래도 계속 베타 마크를 붙이고 서비스했습니다. 알파, 베타 마크가 사용자들에게 문제가 발생할 수 있으니 이해해주세요라는 그런 무언의 압력이기도 하지만, 사용자들의 반응을 보고 꾸준히 개선해나갈께요라는 그런 의지의 표현이기도 했습니다. 기획중심의 설계가 완벽한 기획이 필요했다면, 개발중심의 설계에서는 빠른 구현 및 꾸준한 모니터링이 필요합니다. 극단적으로 몇 시간에서 며칠내로 초기 버전이 구현되지 못하면 또는 초기 반응이 시큰둥하면 바로 접을 수 있어야 합니다. 긍정 또는 부정적인 사용자들의 (명시적/암묵적) 피드백을 얼마나 빨리 많이 수집해서, 그것들을 얼마나 빨리 수정/개선해서 차기 버전으로 만들어내느냐가 성공의 관건입니다. 초기 서비스에 버그가 있었지만 사용자들이 완전히 실망하기도 전에 며칠 또는 몇 시간 내에 문제가 해결되는 것을 보여준다면, 아무리 초기에 치명적인 결함이 있더라도 사용자들은 그 문제가 며칠 내에 해결될거다라는 기대감을 가지게 됩니다. 그래고 나의 피드백이 바로 반영이 되는구나라는 것을 느낀 사용자는 해당 서비스의 열혈 사용자가 될 가능성도 더 높습니다. 적당히 좋은 아이디어/컨셉을 빠르게 구현해서 적용해보면서 가능성이 없으면 초기 비용이 별로 안 들었을 때 바로 접으면 그만이고, 가능성이 있으면 더 많은 리소스를 투입해서 더 나은 서비스로 발전시켜나가면 됩니다.

데이터중심의 설계.
세번째 방법은 기획과 개발의 중간 쯤에 위치하면서 개발중심의 변형입니다. 새로운 서비스를 기획, 구현하기에 앞서서 현존하는 데이터들을 모으고 분석하는 것입니다. 예를들어 검색엔진에서 어느날 갑자기 특정 패턴의 검색어들이 많이 유입된다면 그런 패턴어를 처리해줄 수 있는 검색서비스를 만들어서 제공해주는 것입니다. 다음이나 네이버에서 영화, TV프로그램, 인물 등의 다채로운 정보가 검색에서 스페셜로 노출되는 것도 그런 종류의 검색어들이 상시적으로 많다는 것을 관찰/분석한 이후에 만들어진 것입니다. (간혹 경쟁사에서 서비스를 오픈해서 따라하는 경우도 있지만.. 이런 경우 기획중심의 설계로 들어가는 경우가 많음.) 아니면 트위터에서 오프라인 번개에 대한 니즈가 급증하는 것을 관찰했다면 트위터와 매끄럽게 연계된 번개서비스를 만드는 것입니다. 트위터의 초기에 트위터를 둘러싼 수많은 독립 서비스들이 개발되어 트위터에코를 만들었던 것을 생각하면 됩니다. 데이터중심의 설계는 신규서비스의 설계에 국한한 것이 아니라, 이미 런칭한 서비스의 개선에 더 큰 역할을 합니다. A/B 테스트로 알려졌듯이 새로운 기능이 사용자들에게 좋은 평가를 얻는지 확인하기 위해서 기존 기능과 신규 기능 사이의 버킷테스틀르 통해서 새로운 서비스에서 사용성이 더 좋으면 새로운 기능으로 대체하는 방법을 취합니다. 데이터중심의 설계는 개발중심의 설계와 밀접하게 커플링되어있습니다.

경험중심의 설계.
네번째는 기획중심의 설계의 변형이지만, 근본적인 차이점은 관념과 실제에 있습니다. 기획중심에서는 그냥 주변의 트렌드나 설문조사 등에서 나타난 이야기를 바탕으로 새로운 서비스를 기획하는 것이라면, 경험중심에서는 나 자신이 실제 사용자가 되어서 그 속에서 느꼈던 불편한 점들을 모아서 그것들을 극볼할 서비스를 만드는 것입니다. 때로는 기존 서비스에 만족하지 못해서 대체제/경쟁제를 만드는 것도 가능합니다. 작년 말에 사내외에 다양한 페스티벌을 만들어보고 싶다는 글을 적었었는데, 그 속에는 기본적으로 그런 페스티벌을 기획하고 운영해보면서 스스로 불편함도 느껴보고 또 사용자들의 행동을 가까이에서 관찰해보고 그들의 불편을 해소할 방법을 찾아보고 그걸 서비스화시켜보고 싶다는 것을 염두에 둔 생각이었습니다. 내가 직접 여행을 해보면서 불편한 점이나 좋았던 점 등을 경험해보지 않고, 관념적으로만 이런 게 필요할 것같고 이런 건 ROI가 안 나올 것같고 등과 같은 관념으로만 서비스를 기획하고 만들다보면 결국 리소스는 많이 투입했는데 결과는 좋지 못한 그런 경우가 빈번히 발생합니다. 실생활에서 참가해서 경험해보지 않고서는 어떤 서비스가 진짜 필요한지 이해할 수가 없습니다. 인터넷 기업을 다니는 사람들을 주변에서 관찰해보면 그들이 인터넷과 너무 동떨어져서 생활하는 경우를 자주 봅니다. 생활에서는 인터넷/모바일 서비스를 전혀 이용하지 않으면서 새로운 인터넷/모바일 서비스를 기획/개발하는 경우를 종종 봅니다. 그런 사람들에게서 제대로된 것이 나올 수 있을지 의문입니다.

이상으로 네가지로 나누어서 서비스 개발방법론이라고 거창하게 적었지만, 뭔니뭐니해도 오늘날 가장 중요한 것은 래피드프로토타이핑 rapid-prototyping입니다. 빨리 구현해서 테스트해보는 것이 가장 필요합니다. 기획중심의 설계에서도 기획단계에서부터 이런저런 기능을 테스트해보고 실제 데이터를 보면서 파이널 제품으로 갈 것인지 말 것인지를 결정해야 합니다. 실제 서비스의 프로토타입이나 데이터를 보지도 않고 무조건 위에서 시킨 업무라고해서 끝까지 기획서만 만드느라 많은 시간을 허비해버리고 정작 기획서가 나왔을 때는 이미 트렌드는 끝나가거서 유사제품들이 시장에 넘쳐나는 경우를 종종 봅니다. 특히 이미 성공한 제품/서비스를 가진 기업들일 수록, 후속 서비스에 대한 (대박) 압박 때문에 이런 오류를 자주 보입니다. 그럴수록 초기 단계에서부터 테스트 및 분석을 거치면서 큰 그림을 완성해야 합니다. 확고한 (초기) 컨셉이 정해졌다면, 작게 생각하고 빠르게 만들어서 사용자들의 반응을 관찰/분석해서 좀더 강건한 서비스를 기획/개발하는 것이 정석입니다. 애플에서 매킨토시를 처음 만들 때 케이스만 수십가지/차례 만들었다는 전설적인 이야기, 새로운 애플 제품은 적어도 100가지 디자인 중에 하나가 선택된다는 이야기, 페이스북에서 Q&A기능을 넣었다가 사용자 반응이 미비해서 그냥 빼버린 사례, 그리고 앞서 말했던 구글의 영원한 베타전략 및 A/B테스트에서 교훈을 얻어야 합니다.

대학에서 품질공학 수업을 들으면서 초기 기획/설계 단계에서 오랜 시간을 보내면 최종 제품 개발에서 실패가 적다는 것을 정석으로 가르쳐주고 있습니다. 실물 경제에서는 초기 디자인 단계에서 많은 것들이 검토되면 뒤쪽의 생산 단계에서 문제가 적게 발생한다는 얘기입니다. 몇 년의 준비과정이 필요한 제품의 경우에는 맞는 말이지만 인터넷/모바일 서비스처럼 몇 개월 또는 수주 내에 서비스의 승패를 결정하는 분야에서는 재고되어야할 내용입니다. 그리고 기획/설계 단계에 많은 것들을 점검하고 긴 회의를 거치더라도 앞서 말했듯이 꾸준한 프로토타이핑 및 테스트를 거치지 않으면 완벽한 서비스가 그냥 좋은 서비스에 밀려나고 맙니다. 그리고, 3~6개월만 개발이 지연되어도 트렌드에서 벗어나는 경우도 있지만, 6개월 ~ 1년 이상의 장기적인 마일스톤을 세워두고 꾸준히 개발/개선해야할 서비스나 기반기술들도 있습니다. 양자 모두에서 빠른 프로토타이핑과 테스트는 여전히 필수/유효합니다.

결론적으로 말하자면 현실에서는 다양한 경험에서 서비스 아이디어를 얻고 빨리 구현해서 데이터로 검증을 받아서 새로운 서비스를 만드는 것이 정도가 아닐까 생각합니다. 아이디어만으론 절대 성공할 수 없습니다. 어린 친구들에게 좋은 아이템이 있으면 창업해보라고 부채질을 하지만, 기본적으로 그들이 가진 재능과 패기를 바탕으로 조언하는 것이지 능력이 없는 이들에게는 그런 조언도 해주지 않습니다.

지나치게 일반적인 내용을 너무 길게 적었습니다. 앞서 '정석'이라는 표현도 사용했지만, 실제 성공하는 서비스의 왕도는 없습니다. 각 기업/조직의 문화에 따라서 더 적합한 방식이 따로 있습니다. 일반론에 함몰되지는 말았으면 합니다.

PS. 웃픈 글이 있어서 링크를 겁니다. 게임업계인에게 직접 듣는 게임업계의 슬픈 현실. 대화내용에서 카툰 아래에 나오는 '기획자가 필요없다'는 대목이 최근 IT업계의 현주소입니다.

(2013.01.14 작성 / 2013.01.21 공개)

댓글을 달아 주세요

관념 속의 기획자들

Gos&Op 2012.11.02 17:18 |
Share           Pin It

회사에서 다양한 서비스와 기능들을 새롭게 추가하지만 모든 것이 성공하지는 않는다. 때로는 많은 돈을 투자한 프로젝트도 최종 단계 또는 런칭을 한 이후에 성과가 별로 좋지 않으면 투자한 자금을 순손실로 처리하고 접는 경우도 있다. 반면에 별로 기대를 하지 않고 그냥 만든 서비스는 사람들의 이목을 끌고 완소 아이템/서비스가 되는 경우도 간혹 본다. 왜 어떤 서비스는 성공하고 또 비슷한 다른 서비스는 실패하는 걸까? 하이컨셉 하이터치 시대에 참신한 컨셉/개념의 부재, 친근한 터치의 부재, 또는 부적절한 전략적 타이밍 등을 예전 글에서 말한 적이 있다. 또 다른 글에서는 실패하는 서비스는 필요한 것이 아니라 그냥 필요할 것같은 것을 내놓기 때문에 그렇다라고 말한 적도 있다.

최근 새로운 프로젝트를 시작했다. 그런데 입사한지 채 1년도 되지 않았고 단독으로 새로운 서비스를 전담한 적이 없는 신입 기획자가 프로젝트의 메인 기획자로 배정되었다. 신입이기 때문에 의욕적으로 일을 하는 모습을 보여주고, 또 모르거나 부족한 부분에 대해서는 매번 의견을 구하는 모습이 예쁘다. 그래도 아직 서비스 런칭 경험이 부족해서 그런지 옆에서 보기에 답답하기도 하다. 경험있는 기획자라면 금새 해치웠을 일도 속도가 조금 느리고, 어쩌면 속도가 느린 것이 아니라 기획의 프로세스와 결과물에 대한 구체적인 안을 모르는 것같은 느낌이 들기도 한다. 신입 기획자에게 많은 것을 바라는 그런 욕심을 부리는 것은 아니지만, 옆에서 조금만 도와주고 메꿔주면 그/그녀가 금방 성장할 수 있을텐데라는 안타까움이 크다. 어쩌면 그/그녀가 지금 빠져있는 함정이 이 글에서 말하는 상황에 맞지 않을 수도 있다. 그러나 일반적으로 신입 기획자들이 빠지는, 때로는 노련한 기획자도 빠져버리는 그런 함정에 대한 얘기를 하고 싶다. 그리고, 더 중요한 코멘트는 이 글에서 말하는 기획자는 단순히 서비스를 기획하는 그런 기획자만을 뜻하지 않는다. 더 일반적으로 다양한 이벤트를 설계하는 기획자도 포함되고, 또 개인/가정적으로 자신/가족의 삶을 디자인하는 그런 모든 사람들을 뜻한다.

최근에 사내에서 재미있는 행사들이 있었다. 사실 사내의 공식행사는 아니다. 제주바람에서 기획한 겟인제주 여행 및 공연, 사내의 기타동호회 주관의 미니음악회 및 MT/발표회, 그리고 사내 사진동호회가 주체한 <특별한 하루> 행사, 그리고 조만간 있을 올레걷기행사 (이건 공식인가?) 등에 참여했다. 혼자서 돌아다니며 사진을 찍는 것은 좋아하지만, 음악회에 참여하거나 단체 행사에 참가하는 것은 내 적성에 맞지가 않다. 그래도 반복되는 지루한 삶에서 일탈의 물결을 일으키기 위해서 기꺼이 이런 저런 행사에 참가하고 있다. 물론 귀찮고 사람들의 눈이 편한 것은 아니지만, 이런 행사에 참가해서 주변을 관찰하는 것이 새로운 즐거움을 선사한다.

기타동호회 MT를 다녀온 이후에 MT를 준비했던 기타동 회장이 게시판에 다음의 글을 남겼다.

(나름) 큰 행사를 진행하면서 기록에 대한 계획을 미리 세우지 않았던것이 가장 큰 실수가 아닌가 생각이 듭니다. 행사 악보집을 만들기는 했지만 준비 과정에서부터 후기까지 사진,영상, 문서 등에 대해서 이제서야 생각하니 아쉬움을 금할 길이 없습니다. T.T

이런 행사를 처음 준비하다보니 미쳐 생각지 못했던 많은 것들이 행사가 끝난 이후에 떠오른 모양이다. 그래서 답글로 '그렇게 기획자로 커가는 거임.'이라고 남겼다. 첫번째 행사에서 미흡했던 부분을 기록/기억해놓고 다음 행사를 준비한다면 다음 행사는 분명 이번보다 더 나아질 거라 믿는다. 만약 그렇게 시행착오를 조금 거치면서 새로운 행사를 계속 기획, 준비해간다면 위의 기타동 회장은 조만간 훌륭한 기획자가 될 거로 믿는다. 단순히 행사 기획자가 아닌, 삶/인생의 기획자로... 이렇게 MT나 공연/연주회를 기획, 준비한 그런 경험을 가지고 새로운 서비스를 만든다면 분명 재미있는 서비스도 만들 수 있으리라 믿는다. 그리고 기타동회장이 지나가는 말로 "<특별한 하루>를 준비한 사진동의 회장/총무도 많이 힘들었을 거에요."라고 했다. 행사를 한번 준비해본 사람의 입에서만 나올 수 있는 반응이다. 나처럼 그냥 단순히 행사에 참가/참관을 한 사람의 입장에서는 단순히 그 행사가 즐거웠느냐 아니냐에 대한 반응만 보였을 건데, 한번 큰 행사를 준비한 사람의 입장에서는 다른 행사를 볼 때도 그 행사를 준비한 사람의 심정을 먼저 유추해보게 된 듯하다. 미리 도움을 요청했으면 다양한 측면으로 도와줬을텐데라고 생각했는지도 모른다. 그렇게 그들은 역지사지의 동지애를 키울 수가 있었을 거다.

왜 의욕적으로 시작한 새로운 서비스가 실패하고 마는 걸까?를 고민하면서 최근에 오프라인에서의 일을 회상해봤다. 왜 서비스는 실패하는 걸까? 이전 글에서 밝혔듯이 '그냥 필요할 것같은 것'을 기획하고 만들기 때문에 실패하는 것같다. 그냥 관념적으로 이런 저런 기능이 필요하지 않을까? 이게 있으면 좋겠지?라고 생각하고 서비스/프로세스/UI/UX 등을 기획, 개발한다. 관념에서 나온 결과물은 그저 핑크빛 전망 뿐이다. 현실성이 없고 실제하지 않기 때문에 이게 진짜 유용한지 판단할 수 없다. 판단을 할 수 있더라도 또 관념 속에서 판단한다. 그러니 그냥 좋을거다, 필요할거다, 사람들이 좋아할거다 정도로 판단하고 일을 진행한다. 그러다보니 명확한 기획안도 나오지 않고 일의 진행속도도 느려지고, 또 많은 리소스가 들어간 결과물도 애초의 의도에 벗어난 괴물이 튀어나온다. 그런 괴물은 분명 사람들이 좋아할 요소가 없다. 특히 시장에서 입지를 갖춘 회사에서 나온 제품들 중에 그런 괴물들이 많이 있다. 투자한 리소스, 즉 매몰비용이 높아서 쉽게 포기하지도 못하고, 그렇지만 인기도 없어서 계속 운영하기도 버거운 그런 괴물...

몇 해 전에 스티브 잡스가 애플이 끊임없이 혁신적인 제품을 만들어내고 성공할 수 있었던 이유를 기술 Technology과 인문 Art의 만남이라고 말해서 사람들 사이에 오래 회자되었다. 그래서 이/공대에서도 기술뿐만이 아니라, 정치 경제 사회 문화 예술 등의 다양한 인문학을 가르쳐서 학생들의 교양 수준을 높여야 한다고 말했다. 그런 교양을 갖추고 기술을 터특한 사람만이 창의적인 사람이 되는 것처럼 떠들어댔다. 나도 그 순간에는 그런 것같아다. 그래서 대학에서 교양과목 수업이나 더 많이 듣고 졸업할 껄 그랬다면 후회한 적도 있다. 그런데 지금 생각해보면 잡스가 말했던 인문은 단순히 그런 교양과목이나 문화예술 참관을 뜻하는 것은 아닌 것같다. 위의 사내동호회 회장들과 같이 다양한 행사/이벤트를 기획하고 준비하고 또 실행에 옮기는 그런 활동 및 경험이 잡스가 말한 인문이 아닐까?라는 생각을 하게 된다. 이런 저런 행사을 준비하면서 진짜 이게 필요한가를 깊이 고민을 해보고, 또 실행에 옮기면서 부족했던 점을 복기해보고, 또 다음 행사에서는 그런 부족분을 보완하고... 그렇게 행사 또는 삶을 디자인해보면서 얻는 경험이 새로운 서비스나 제품을 만드는데 그대로 투영된다. 내가 전에 이런 행사를 해보면서 이런 기능이 있었으면 좋겠더라라고 생각을 하고, 그래서 그 기능을 해줄 서비스를 만들어서 다음 행사에 적용해보면서 만들어진 서비스/제품은 '필요할 것같은'이 아니라 '필요한' 것이다. 관념에서 만들어진 것이 아니라, 바로 경험과 삶에서 만들어졌기 때문이다. 음악, 특히 비틀즈에 빠져있었던 잡스에게서 iPod과 iTunes가 나왔다는 점은 기억해둘 필요가 있다.

글머리에서 신입 기획자 얘기를 꺼냈다. 대학을 갓 졸업해서 회사 시스템이나 서비스에 제대로 적응하지 못한 그/그녀가 처음부터 멋진 서비스를 기획할 수는 없다고 본다. 그냥 주어진 업무이니 뭔가 새로운 것을 만들어 보고 싶다는 의욕은 넘칠 거다. 그러니 이런저런 것을 만들면 사람들이 좋아하지 않을까?를 궁리하고, 그렇게 프로젝트에 투입되었다고 본다. 아직 신입이라 대학을 다니면서 또는 생활하면서 느꼈던 필요성을 충족시킬 서비스를 주도적으로 만들 힘도 없을테니.. 자신이 스스로 필요성을 느끼고 주도적으로 일을 이끌어나가지 못하는 환경에서 그/그녀는 머리로만 생각하고 결과물을 만들어내는 유혹에 빠질 가능성이 높다. *** 그래서 서두에 언급한 것이지, 부족함을 지적하기 위해서 언급한 것은 아님을 재참 밝힙니다.*** 유능하고 경험있는 사람들도 그렇긴 매 한가지지만... 나도.

다양한 경험, 다양한 식견... 때로는 일상적인 일이 아닌 다른 행사들에 참가해보는 것도 좋을 것같다. 가능하다면 그런 행사를 직접 기획하고 만들어보면 더 좋을 거다. 삶에서 경험하지 못하고 그냥 관념으로 서비스를 만들다보면 결국 삶과 동떨어진 것이 나오기 마련이다. 프로토타이핑... 스타트업을 하면서 새로운 생각이 떠올랐을 때 몇시간 또는 며칠 내로 시제품을 만들 수가 없으면 시도하지도 말라는 얘기를 들은 적이 있다. 그리고 스타트업에 펀딩할 때도 얼마나 훌륭한 기획/경영자가 있느냐보다는 실제 서비스를 제대로 구현할 수 있는 개발자 수/비율이 몇이냐에 따라서 펀딩한다는 그런 얘기도 있다. 프로젝트의 성공은 서비스의 완성도보다는 어쩌면 현실성/실현가능성이 더 중요한지도 모르겠다. 

불가능한 것은 상상하고, 가능한 것은 손에 잡아야 한다.

댓글을 달아 주세요

Share           Pin It

2주 전에 최근에 런칭한 서비스에 대한 향후 방향성 및 기능보강을 위한 워크샵이 열렸습니다. 제가 직접적으로 참여해서 만든 서비스는 아니지만, 사내에서 이래저래 쑤시고 다녔더니 '그러면 니가 직접 해봐'라는 식의 오더가 내려온 듯합니다. 그래서 20명정도의 서비스 담당자와 마케팅, 개발, UX 담당자들이 모여서 1박2일 동안 열띤 토론을 버렸습니다. 먼저 참가자 별로 해당 서비스에 대한  3분 스피치를 하고, 비슷한 내용의 사람들끼리 3개조로 나눠서 더 구체적인 안을 내도록 했습니다. 그런 후에 취합된 내용을 모두에게 발표를 하고, 또 각 서비스 개념/방향에 대해서 칭찬/비판의 시간을 가졌습니다. UX팀에서 워크샵을 주관을 했습니다.

개별 조모임을 시작할 때, 사내외에서 IT기술트렌드에 말빨이 있으신 유명 블로거님이 'UX팀은 프로세스를 너무 좋아해'라고 말씀하셨습니다. 저도 이 말이 바로 납득이 되었습니다. 이번 워크샵 이전에도 다른 서비스를 기획, 개발할 때 언제부턴가 UX팀에서 처음부터 합류를 했습니다. 그들은 프로젝트가 시작하면서부터 사용자 설문 및 FGI 등을 진행하고, 담당자들이 모인 자리에서 그런 조사결과를 미리 발표를 해주는 경우가 많았고, 또 컨셉을 잡아가면서 어느 정도 체계화된 프로세스/단계를 강조하는 모습을 자주 목격했습니다. 어떤 분야가 오랜 시간의 경험을 축적하다보면 특정 방법론은 효과가 있고 또 다른 방법론은 효과가 미약하다는 등의 지식이 누적되고, 그렇게 누적된 지식은 프로세스 또는 프레임워크라는 정형화된 틀로 만들어집니다. 그렇게 한번 만들어지면, 이후에는 문제/상화과 무관하게 그 틀에 맞춰서 일을 진행하는 것이 일반화되어있습니다. 어쩌면 오늘날 UX 전문가라는 분들은 그런 틀을 얼마나 많이/다양하게 가지고 있고, 적용할 수 있는가에 의해서 결정되나 봅니다.

아무런 프로세스도 없이 주먹구구식으로 프로젝트를 진행하면 많은 문제들이 발생합니다. 계획도 없이 인력부터 충원해놓고는 결국 할 일이 없어서 그런 비싼 인력을 놀게 만드는 경우도 종종 보게 되고, 비슷한 종류의 일을 여러 그룹에 동시에 분배해서 같은 일을 중복으로 처리하는 경우도 발생합니다. 간혹 중요한 체크사항을 빠트리는 경우도 발생하고, 또 충분한 인력 등의 지원을 못해주는 경우도 발생합니다. 그렇기 때문에 이런 저런 상황에 맞는 다양한 툴킷을 마련해두고, 적제적소에 투입하면 일의 효율이 높아지는 것은 당연합니다. 그런데 정형화된 프로세스의 문제는 프로세스가 견고해지면 질수록 그것에 변형을 가하기가 어려워집니다. 감히 대가가 만들어놓은 프로세스가 잘못되었다고 반박하기가 어려울 때도 많고, 때로는 특정 프로세스에 너무 익숙해져서 더 큰 그림을 못보고 지나치는 경우도 발생합니다. 좋은 것이 항상 좋은 것은 아닌데, 우리의 생각이 그렇게 유연해지기가 어렵습니다.

기획이 너무 체계화되면서부터 오히려 재미있는 기획이 사라지는 것같습니다. 아무런 프로세스나 지식이 없는 경우에는 다양한 생각을 막 쏟아내고 그 중에서 재미있어 보이는 것이나 아니면 빨리 구현해볼 수 있는 것을 찾아서 주먹구구식으로 막 개발하던 때가 있었습니다. 대부분의 스타트업들이 이런 식으로 처음에는 일을 진행할 것입니다. 그렇게 자유롭게 생각하고 막 만들어볼 때는 재미있는 것들이 많이 나오는데, 막상 그것을 제품/서비스화를 하기 위해서 깊이 고민하면서부터 서비스가 재미가 없어집니다. ROI를 따지기 시작하고, 사용성을 따지기 시작하면서부터 깊은 늪에 빠지는 것같습니다. 진짜 재미있고 필요한 기능을 추가하기 보다는, 그저 사용자들을 예측해서 필요할 것같은 기능들을 마구집어넣기 시작하면서부터 서비스는 초기 기획의도에서 벗어나기 시작합니다. 그렇게 서비스는 복잡해지고 사용하기 어려워지고 그래서 또 사용자들로부터 외면을 받고, 결국 서비스는 쥐도 새도 모르게 사라집니다.

워크샵이 있고 며칠이 지난 후에 잠자리에 들면서 '기획은 공학이 아니다'라는 생각이 떠올랐습니다. 공학이나 과학에서는 일관된 프로세스가 중요합니다. 화학실험에서 시약을 넣는 양과 순서와 시간은 매우 중요합니다. 수많은 요소 중에서 하나만 다르게 투입되어도 실험의 결과가 완전히 바뀌어버립니다. 그렇듯이/역으로 정해진 순서와 양을 잘 맞춰서 투입하면 결과물을 또 99%이상 정확히 예측도 할 수가 있습니다. 그리고 과학에서 가설검증은 일종의 (귀납적 경험을 거친 후의) 연역적 사고과정입니다. 어떤 현상을 목격하고 그것을 잘 설명해주는 가설을 세웁니다. 그리고 그 가설을 검증하기 위해서 다양한 실험을 계획하고 수행을 합니다. 그래서 예상했던 결과가 맞으면 가설이 맞는 것이고, 그렇지 않으면 가설을 기각하고 새로운 가설을 세우거나 새로운 실험계획을 수립하고, 또 실험을 통해서 가설을 검증하는 과정을 반복합니다.

그런데 (제품/서비스) 기획도 이런 과학/공학의 과정을 거치는 게 맞는 걸까요? 앞서 말했듯이 어느 정도 정형화된 프로세스는 유효합니다. 그렇지만 하나의 프로세스가 모든 서비스의 기획에 적합한 것이 아닙니다. 그런 프로세스가 특정 서비스의 기획에서 효과가 있다하더라도 프로세스를 진행하면서 유연하게 순서를 바꾼다거나 새로운 단계를 추가/제거하는 일을 끊임없이 벌어져야 합니다. 그런데 고착화딘 프로세스 신봉자들은 사람들의 자유로운 사고의 과정을 장려하기 보다는 그저 틀에 맞춘 질문지에 답변을 할 것을 요구하고, 틀에 맞춘 결과물을 요구하는 경우를 자주 봅니다. 공학은 선형이고 연속적이고 매끄러운 프로세스가 특징이지만, 기획 (또는 사람의 행동 및 사고 과정)은 대부분의 경우 비선형이고 불연속적이고 요철이 많은 그런 미분불가능한 프로세스입니다. 웹2.0시대에 등장한 '영원한 베타'라는 개념이 그런 귀납적인 과정을 잘 설명해줍니다.

창의적이고 재미있는 제품/서비스를 만들기 위해서는 먼저 딱딱하고 재미없는 프로세스부터 파괴하는 것이 우선이지 않을까요? 물론 프로세스 무용론을 펼치는 것은 아닙니다. 주니어들을 교육/훈련시키기 위해서는 프로세스 따라하기가 효과적입니다. 그럼에도 불구하고 더 다양하고 유연한 사고를 거쳐서 더 재미있고 창의적인 결과를 얻기 위해서는 그런 정형화된 프로세스를 파괴하는 과정을 거쳐보는 것도 좋지않을까 생각합니다.

이제껏 많은 제품/서비스에서 실패를 했기 때문에 어쩌면 더 정형화된 프로세스를 고집하는 시도를 해보는 것인지도 모릅니다. 이런 과정을 통해서 또 좋은 결과를 얻게 되면 앞으로는 더 고착화된 툴킷이 될테고, 이렇게 해봐도 별 소용이 없다는 것이 검증되면 새로운 프로세스를 도입하거나 아니면 또 과거처럼 주먹구구로 돌아갈지도 모릅니다. 좋은 결과를 얻기 위해서 이런 저런 다양한 시도를 해보는 것은 참으로 좋습니다. 그게 정형화된 과정을 거치든 그렇지 않든... 그러나 '오직 하나'만을 고집하지는 않았으면 합니다.

댓글을 달아 주세요

  1. Favicon of http://funcrush.tistory.com BlogIcon 두렁청해 2012.09.04 11:15 신고 Address Modify/Delete Reply

    프로세스가 존재하는 이유를 잊고, 프로세스를 위한 프로세스가 만연하는 것 같습니다.

  2. Favicon of http://daumux.tistory.com BlogIcon herb2002 2012.09.04 14:08 신고 Address Modify/Delete Reply

    안녕하세요. 부환님
    UX랩 백인섭입니다. 평소에 부환님 블로그에 좋은 아티클이 많아서 종종 들르곤 했었는데
    저희 랩에 대한 이야기가 있어서 간단히 글 남기려 합니다.

    우선 캠프 워크샵에서 경험하셨던 내용은 UX하는 사람들만이 사용하는 방법론, 프로세스가 아니고 전략 수립이나 기획단계에서 사용되는 일반적인 방식입니다.
    여러 분야의 이해 당사자들이 민주적이고 평등한 관계에서 커뮤니케이션할 수 있게 도와주는 일종의 퍼실러테이션입니다.

    이런 퍼실러테이션 스킬이 저희 UX쪽 인력에게는 아주 중요한 능력입니다.
    엔드유저를 만나서 그들의 의견을 오염없이 듣고 그 내면에 존재하는 진의를 파악하고 역시 내부 고객들이 오해하지 않고 이해할 수 있게하는 영역을 크게는 커뮤니케이션, 작게는 퍼실러테이션이라고 합니다.

    이런 일련의 기법들은 연차나 경험에 따라 개인별로 차이가 많이 나고 조직 내부에도 이런 문화나 방법론이 정착되지 않은 상황에서 역시 효율에 대한 기복이 큰 편입니다.
    말씀 주신 것처럼 저희 랩 구성원들이나 회사 자체가 아직 토론이나 토의 문화가 일부 부족한 부분이 있기 때문에 이런 방법론, 프로세스의 활용이 필요해 보입니다.


    그리고 창의적인 서비스를 만들기 위해서는 개인이나 조직 자체가 Creative한 마인드를 항상 가지고 있는게 중요한데 사람이라는게 좌뇌를 주로 쓰다가 갑자기 우뇌를 써서 창의적으로 확 바뀌기 쉽지 않습니다.(이래서 창의적인 사고를 연구하시던 분들이 Black Box와 Glass Box 를 같이 사용할 수 있게 여러 방법론, 프로세스를 제안하시고 있습니다. )
    실제 저희 회사에 아주 창의적이고 혁신적인 분들이 어느 정도 되는 지는 정확히 모르겠습니다만 내 주변에 당장 스티브 잡스나 조나단 아이브 같은 사람이 안보이는 현실로 봐서는 이런 방법론, 프로세스를 잘 활용하는 것이 좀더 효율적이라 생각해봅니다.
    굳이 유행하는 말로 바꾸자면 집단 지성, 집단 창의 정도로 표현하면 어떨까요 ?


    몇 년 전에 어느 커뮤니티에서 브레인스토밍의 무용론이 한참 거론되던 적이 있었습니다.
    '몇 번 해봤더니 결과가 내 혼자서 몇시간 고민해보는 거나 별반차이 없더라, 참여한 6~7명이 그 시간에 거기 모여서 허황된 이야기하는 시간이 정말 아깝더라는'

    먼저 브레인 스토밍은 60년이 넘은 역사를 가지고 있습니다. 하나의 방법론이 60년을 버텨왔다는 것은 다양한 환경에서 그만틈 제 역할을 해오고 있다는 반증이라고 생각합니다.
    그리고 브레인 스토밍은 몇 번의 경험으로는 그 장점을 이해하기 힘든 방법론입니다. 브레인 스토밍은 평등과 발산, 긍정이라는 기본 철학을 가지고 있는데 이를 제대로 존중하지 않고 이름만 브레인스토밍을 하는 경우가 대부분이라서 많은 오해와 무용론을 만들어 내고 있다고 생각합니다.
    어느 정도의 시간을 거쳐서 조직 내부의 구성원들이 브레인스토밍에 대해서 충분히 이해하고 서로를 존중하는 순간에 극대화된 성과를 낼 수 있고 그런 시간은 분명히 온다는 신념을 가지고 있습니다.( 그런 시간이 오기까지의 기회 비용을 충분히 메꿀 수 있는)

    저희 UX랩 아직 부족한게 많아서 여러분들의 도움으로 조금씩 자리 잡아가고 있어서 정말 감사히 생각하고 있습니다.
    자격지심에 저희가 방법론, 프로세스 만을 이야기하는 사람들처럼 보여지는 것 같아 이래저래 글이 길어졌습니다.
    더불어 저희는 방법론, 프로세스 펼쳐내는 것보다는 좋은 제품, 서비스를 만들기 위해서 모인 사람들입니다. 부족하지만 열심히 노력해서 말씀 하신 창의적이고 재밌는 제품.서비스를 만드는데 조금이라도 도움이 되도록 하겠습니다.

    나중에 기회가 되면 직접 뵙고 이런 저런 이야기 나눌 수 있는 시간이 있으면 좋겠네요.

    백인섭 드림.

    • Favicon of http://bahnsville.tistory.com BlogIcon Bahniesta 2012.09.04 15:08 신고 Address Modify/Delete

      해당 워크샵이나 그런 것은 그냥 예를들었을 뿐이고.. 요즘 너무 정형화된 형태로, 나쁘게 표현하면 관료주의로, 일을 진행하려는 경향이 강해지는 것같아서... 그런 것을 우려하는 취지로 글을 적었습니다. 오해는 없으시길 바랍니다. take it easy.