조언과 잔소리의 차이를 알아야 좋은 제품이 나옵니다.
사용자가 원하지 않는 제품은 잔소리와 같습니다.
남에게 무언가를 조언하려 할 때, 제일 중요하게 알아야 하는 점이 있습니다. 그건 바로 상대방이 나의 조언을 원하고 있느냐입니다. 상대방이 나의 조언을 바라고 있지 않음에도 내가 조언을 한다면 그건 상대방에게는 조언이 아닌 잔소리가 된다고 합니다. 필요성이 없는 말을 상대방에게 전달했기 때문입니다. 그래서 타인에게 내가 조언을 하고 싶다면 정말 타인이 원하는 때에 해야 그 말이 조언으로 들리게 됩니다.
듣는 사람이 있어야 조언입니다. 이 부분은 각각이 행하고 있는 제품이나 프로젝트에도 동일하게 해당하는 사항이라고 생각합니다. 저는 제품을 계획하고 만들어가는 사람의 입장에서 제일 중요한 것은 그 제품이 사용하는 사람들에게 필요한 제품인가라고 생각합니다. 제품이 아무리 뛰어난 기술력을 갖고 있어도 그걸 사용하는 사람이 없다면 무용지물인 것처럼 사용자가 필요한 제품인지를 확인해야 의미 있는 상품이 나올 수 있습니다.
과거의 제품에서도 이미 그런 제품들이 있습니다. 아바타라는 영화가 등장하며 3D 콘텐츠의 붐이 일어났을 때, 영화관이 아닌 집에서도 이를 볼 수 있다며 TV 제조사들은 3D TV를 앞세워서 마케팅을 진행했습니다. 편광식이냐 셔터 식이냐의 기술을 내걸며 각자 자신들의 3D 기술이 더 낫다는 것을 들이밀었습니다. 심지어 모바일에서는 3D 안경을 쓰지 않아도 콘텐츠를 3D로 볼 수 있는 무안경 3D 기술을 도입한 제품도 등장하게 되었습니다.
그런데 제품이 각광을 받은 것과는 달리 실제 판매량은 좋지 않았습니다. 이유는 간단했습니다. 사람들은 3D 기술에 호기심을 가졌지만 그에 대한 필요성을 느끼지 못했기 때문이었습니다. 또, 실제로도 3D 콘텐츠는 많지도 않았고 3D 콘텐츠를 찍기 위해서는 특수한 장비들이 필요했습니다. 심지어 3D를 시청하고 나면 눈에 대한 피로도가 발생하게 되어 장시간의 시청은 불가했습니다. 결국 제조사들은 3D라는 단어를 빼버리게 되었습니다.
3D 제품들은 3D 콘텐츠를 편하게 시청할 수 있게 하겠다는 목표로 만들어진 제품이었을 것입니다. 하지만 현실은 공급되는 콘텐츠의 부재와 사용자는 그 행위를 선호하지 않는다는 관점을 무시해서 만들어진 것이 아닐까 합니다.
이런 경우는 우리가 일을 할 때도 종종 직면하게 됩니다. 어떤 문제를 해결하기 위해 제품을 만드는 것이 아니라 어떤 제품을 만들어 보자고 이야기를 하고 그 제품이 해결할 수 있는 문제를 대입하게 됩니다. 이런 경우는 다음과 같이 해석될 수 있다고 봅니다.
A라는 문제가 있을 경우, A에 대해 힘들어하는 B라는 집단이 있습니다. 집단 B는 문제를 해결하게 되면 C라는 효과를 얻게 됩니다. 그래서 A를 해결하는 제품 D가 나오게 되면 집단 B는 이득인 C를 얻기 위해 제품 D를 빠르게 사용하게 됩니다. 충분한 이득을 얻은 B는 만족하게 되고 피드백 등을 통해 D의 개선도 얻어낼 수 있습니다.
반면에 D'라는 제품을 만들고 이 제품이 해결할 수 있는 문제 A'를 찾으려 한다면 그 A'에 힘들어하는 B'가 있는지는 알기 어려울 수 있습니다. 간혹 D'를 사용하게 하며 집단 B'가 익숙해지면 되지 않을까요,라고 하지만 학습에는 시간이 걸리고 집단 B'가 얻을 수 있는 이득 C'가 무엇인지는 알기 어렵습니다. 필요성이 없는 상태로 출발하다 보니 제품 D'는 피드백이 없을 수 있고 제품은 제자리걸음을 하게 될 수 있습니다. 이 순환이 계속되면 결국 D'는 아무도 원하지 않는 제품으로 전락할 수 있습니다.
그래서 어떤 문제를 해결하고 어떤 이득을 주기 위한 제품인지에 대한 정의는 중요하다고 생각합니다. 아무도 원하지 않는 말을 모두에게 도움이 될 것이라며 외쳐본들 이를 원하지 않는 사람들은 귀에도 담기 싫은 잔소리로 판단하고 흘려버리기 때문입니다.
저는 이 관점을 확인하고 진행해야 하는 것은 기획하는 사람만의 일이 아니라고 생각합니다. 프로젝트를 관리하는 사람의 관점에서도 이를 확인하고 점검을 해줘야 합니다. 개발을 진행하는 사람이 자체적인 검증을 진행하지만 자신이 발견하지 못한 관점에서 문제를 확인하기 위해 QA 부서에 테스트를 의뢰하는 것처럼 프로젝트 관리자도 함께 하고 있는 프로젝트나 제품의 기획서에 생각하지 못한 부분이 있는지 여부를 확인해야 합니다. 그래서 그 의도를 확인하고 함께 점검하기 위해 요구사항 정의서나 기능 정의서와 같은 문서를 기반으로 확인하고 점검해야 합니다.
어떤 문제가 있는지, 이 문제를 해결하면 어떤 이득을 줄 수 있는지, 이 문제는 어떤 방식으로 해결할 것인지, 이 방식을 사람들은 어떻게 사용하게 될 것인지 등의 이런 내용들을 함께 점검하며 우리가 하고자 하는 일이 사용자들에게 잔소리로 느껴지지 않게끔 만들어야 합니다.
조언도 좋은 때가 필요합니다. 자신의 잔소리를 나의 말은 시간이 지나면 느끼게 될 좋은 조언이라고 생각하는 분들도 있습니다. 이런 분들께는 말을 하는 사람이 아닌 듣는 사람의 입장으로 관점을 바꿔서 보라고 합니다. 제품도 마찬가지입니다. 이건 좋은 제품이고 이걸 쓰면 이런 문제들을 해결할 수 있어,라고 하지만 실제 사용하게 되는 사람들이 그 문제들을 가지고 있는지는 아무도 모릅니다. 아무런 근거가 없이 주장을 한다면 감이고 추측일 뿐입니다. 과거에 이미 성공한 사례라고 하더라도 그건 그 당시의 사용하는 사람들과 발생했던 하나의 일화일 뿐입니다. 현재의 사람들이 필요한 것이 무엇인지 확인하고 그걸 준비하는 것이 이 제품을 통해 너의 문제를 해결할 수 있다고 제일 조언하기 좋은 때라고 생각합니다.
원하지 않는 조언이 잔소리라고 말하지만 잔소리도 때를 잘못 만난 조언이라고 생각합니다. 제품을 만들어보자라고 하는 사람들의 생각도 동일하다고 봅니다. 모든 제품이나 프로젝트는 모두 어떤 문제를 해결하기 위해 태어났고 흥하지 못한 것들은 자신의 때나 자신의 대상을 만나지 못한 것이라고 생각합니다.
나의 말이 언제 누구에게 도움이 되는지를 알아야 좋은 조언이 되는 것처럼 좋은 제품도 어떤 사람들의 어떤 문제를 해결하기 위한 것인지 등의 명확한 기준을 가져야 좋은 제품이 될 수 있다고 생각합니다. 프로젝트 관리자라면 그 기준을 함께 확인하고 잘 맞춰 가고 있는지를 점검할 수 있어야 합니다. 그래야 우리의 프로젝트가 도움이 될 수 있기 때문이니까요.
