[책] '개발 함정을 탈출 하라'를 읽고

(ref: http://www.yes24.com/Product/Goods/98548554 (opens new window))

처음 개발 함정이라는 제목을 보고 오버 엔지니어링 하는 개발자 이야기인 줄 알았다. 여기서 개발은 IT, 테크 업계에서 말하는 development 혹은 engineering 이 아니다. 원제를 보면 Escaping the build trap.

Build. 즉, 무엇을 만드는 것 의 함정을 말하고 있다. 그럼 무엇을 만드는 것을 말하고 있는 것일까? 바로 프러덕트(Product)이다.

부제 역시 이 책을 잘 설명하고 있다. "진정한 가치를 창출하는 프러덕트 매니지먼트의 길". 진정한 가치 창출을 하는 프러덕트를 어떻게 만들 수 있는지. 그리고 그 과정에서 우리를 방해하고 있는 것들이 무엇인지를 말해주는 책이다.

내용에 앞서 계속 반복되고 있는 "프러덕트"를 먼저 이해해야 한다.

사실 실무에서는 프러덕트, 제품, 서비스, 프로젝트 등 단어가 혼용돼서 많이 사용되고 있는 것 같다. 책에서는 해당 개념들을 다음과 같이 정의하고 있다.

• 프러덕트 : 가치를 유저에게 전달하는 매개체. 하드웨어, 소프트웨어, 엑셀, 이유식, 틴더 등
• 서비스 : 인간이 주요 역할로 가치를 전달하는 것. 세무 대행 서비스, 로고 디자인 등
• 프로젝트 : 특정 목표를 위해 개별적으로 지정하는 범위. 주로 마감일 등의 달성해야 할 산출물이 정해져 있음.

그렇다면, 책 제목인 개발 함정이란 무엇일까. 첫 장부터 시원스럽게 답을 알려준다.

성과물이 아닌 산출물을 성공 기준으로 잡으며, 기능의 실제 가치를 확인하지 않고 기능을 개발하는 상태가 개발 함정에 빠져있는 상태라고 이야기하고 있다.

여기서 중요한 것은 프러덕트의 "가치"다. 가치를 유저에게 전달하지 못한다면 제대로 된 프러덕트를 만들 수 없고 우리는 그저 가치 없는 일을 하며 함정에 빠져버린다는 것이다.

왜 이러한 개발 함정에 빠지는 것일까?

당연한 말이지만, 회사는 항상 성장만 할 수는 없다. 회사가 성장세가 둔화되면 가장 빨리 해보고 싶은 것은 기능 추가다. 혹시 우리가 필요한 기능이 없어서 유저들이 오지 않는 건 아닐까? 이렇게 급급한 마음에 기능을 추가하다 보면 진짜 필요한 문제를 찾지 못하고 그저 프러덕트가 의미 없이 비대해질 뿐이다.

그렇다면 개발 함정에 빠졌는지 어떻게 알 수 있을까?

스스로에게 질문해보자. 출시한 제품의 성공 여부를 어떻게 평가할 것인가? 약속했던 마감일을 잘 준수했는가? 버그가 없는가? 아니다. 중요한 것은 우리가 찾았던 문제를 잘 해결했는가이다.

• 산출물보다 성과물이 중요하다.

그렇다면 성과는 어떻게 정의할 것인가. 기능을 통해 소비자의 문제를 해결하도록 하는 것. 이것을 잘 측정해야, 직원의 성과 역시 제대로 평가할 수 있다.

프러덕트의 가치 정의/평가 -> 성과 평과 -> 성과를 내기 위한 개발

이렇게 회사의 성공을 좌지우지할 프러덕트 개발을 어떻게 하면 잘 운영할 수 있는지 크게 4개의 파트로 정리하고 있다.

프러덕트 매니저의 직무, 전략, 과정, 그리고 조직.

더 자세한 이야기는 책에 실제 비지니스 예시, 그리고 가상의 회사 컨설팅을 통해 자세히 설명하고 있다. 프러덕트 매니저를 꿈꾼다면 한 번 꼭 읽어보길 바란다.

지금까지 내가 일해 왔던 환경을 뒤돌아 보았을 때, 대부분 큰 프러덕트의 로드맵을 잡고 고민하고 실험하는 것은 기획자에게 모든 책임을 몰아주었던 것 같다. 하지만 최근에는 개발자 역시 프러덕트에 대한 책임을 요구받고 있는 것 같다. 개발자였던 동료들이 더 높은 직책으로 가며, 이제는 그저 기술 리더가 아닌 프러덕트를 총괄하며, 기술 측면뿐만 아니라 비지니스, 프러덕트 성장 등 더 시야를 넓혀가는 모습을 많이 볼 수 있게 되었다. 사실 어디 출신, 전공은 상관 없다. 제대로 된 프러덕트를 만들고 그것을 세상에 보여주고 싶다면 누구나 프러덕트 매니저가 될 수 있다고 생각한다.

책에서 언급하고 있는 몇 가지 태도들. 구현에 앞서 "왜"라는 질문 하기, 그저 전달되는 요구사항을 만들기 급급하지 않기 등은 프러덕트 매니저에게 떠밀기만 할 태도는 아닌 것 같다. 프러덕트를 만드는 모두가 가져야할 태도 라고 생각된다. 내가 버튼 하나를 만들더라도, 그것이 왜 필요한지. 유저가 정말 그것을 사용할지 고민해보는 것을 내 직무가 무엇이든 위치가 어떠한 사람이든 기본적으로 가져야 하는 책임이라 생각한다.

"권력을 근거로 조직을 이끄는 것은 저숙련 노동자들을 밀착 감독해 생산량을 극대화하던 산업시대 방법론의 유물이다. 소프트웨어 시대를 사는 우리는 그런 식으로 일하지 않는다."

노동집약산업에서 일하는 전문 인력이라면 누구든 이렇게 일해야 할 것이다. 회사 역시 직원에게 그만큼의 자율성을 주고 참을성 있게 기다릴줄 알아야 성공하는 회사가 될 것이다.