가치는 우리가 원하는 것이다. 우리가 원하는 것은 가치일까?

A가 우리에게 목적지에 도착하는 자동차를 만들어달라고 요청하면 자동차를 만들어 줄 것이 아니라, 자동차를 왜 만들어야 하는지에 대한 파악이 중요하다.

대개 우리도 스스로가 무엇을 원하는지 모르는 경우가 많다. 나 역시도 오늘 떡갈비가 땡겨서 먹었지만, 진정으로 원하는 건 떡갈비가 아니라, 양념이 버무려진 고기의 감칠맛을 느끼고 지방과 단백질을 흡수하고 싶었는지 모른다.

A가 자동차를 만들어 달라는 이유가 무엇일까? 예로 들었을 때, 요청한 누군가는 사실 빠르게 목적지에 도착할 수 있는 걸 원하는 것일지 모른다. 그렇다면 우리가 고민하는 것은‘자동차를 어떻게 만들지?’ 가 아니라 ‘어떻게 빨리 목적지에 도착하게 하지?’ 가 될 것이다. 둘은 아주 분명한 차이가 있다.

빠르게 가치를 충족시킬 수 있는 방법은, 먼저 나무판자에 바퀴 네 개를 붙여 만든 스케이트를 제공하는 것이다. 그 후엔 페달을 연결해 자전거를 만들어 제공하고, 그 후엔 엔진을 붙여 오토바이를 만들어 제공한다. 이후엔 자동차가 될 수 있겠지.

어쨌거나 우리는 목적지에 빠르게 도착하길 원하는 사람에게 신속하게, 그리고 꾸준하게 진화하는 서비스를 제공할 수 있다. 처음부터 완벽하게 제공할 필요는 없다. 정확한 가치를 찾아내고, 그 가치를 빠르게 효과적으로 전달하는 것이 중요하다. 그것이 가치를 이끌 수 있으며, 관리할 수 있는 길이다.

많은 것이 바뀌었다. 나의 환경은 책상이 아니라 넓은 토론장으로 바뀌었고, 나의 입은 타협이 아니라 추궁으로 바뀌었고, 나의 일은 가치를 찍어내는 것이 아닌 가치를 만들어 내는 일로 바뀌었다.

책을 읽기 전에는 가치라는 단어를 떠올릴 수가 없었다. 그저 유저가 하면 좋은 것, 크루가 하면 좋은 것 이었다.

가치. 한 단어가 나의 마음속에 있던 찝찝함을 해결하고, 사고에 변화를 준다. 변화한 사고로 뻗어나가기 시작해 많은 유저, 크루에게 영향을 줄 것이라 믿는다.

유저가 원하는 것은 무엇인가? 크루가 원하는 것은 무엇인가? 도대체 우리가 원하는 것은 무엇인가?

기록

가치

• 가치는 명확해야 합니다. 그래야만 가치를 이끌 수 있고 관리할 수 있습니다.

• 실패하는 이유는 여러 가지가 있겠지만 대부분 사용자가 진정으로 원하는 것이 무엇인지 모르는 상태에서 프로젝트를 이끌기 때문입니다.

• 길을 잘 이해하는 것이 행복한 프로젝트를 위한 길입니다.

• 길을 잃어버렸을 때는 가치를 떠올려 보세요.

• 가치는 우리가 원하는 것입니다.

• 가치를 만드는 일은 꾸준하고, 지속가능하며, 끊임없어야 합니다.

피처

• 작동하는 소프트웨어를 보여주세요.

• 모든 사람은 각각 다른 피처를 원합니다.

• 더 일찍 배포하고 싶던 피처는 무엇인가요? 그 이유는 무엇인가요? 다르게 구현했어야 한 피처는 어떤 것이 있나요? 만들 필요가 없던 피처도 있었나요?

• 배포하려는 피처에 시간과 비용을 들일 필요 없을 때가 올 것입니다.

• 피처 단위 개발로 진행할 때는 현재 어떤 일을 진행하고 있는지 알 수 있습니다.

• 이것이 없으면 살 수 없을 정도로 중요한 피처 말이죠. 이런 피처를 먼저 추려내고 기록하세요.

• 주기마다 하나의 완성된 제품을 만들도록 목표를 세우세요. 이렇게하면 언제든 제품을 배포할 준비가 갖춰집니다.

• 실제로 작동하는 피처를 볼 수 있어야만 합니다.

• 간결하지만 작동하는 버전을 먼저 개발

• 개발 주기마다 피처를 개선하는 작업을 반복하세요.

• 피처를 단위로 계획하고 피처에 의해 성장하고 피처를 단위로 관리해야 합니다.

설계

• 작은 조각들은 큰 조각을 더 완벽하고 더 쓸모 있게 만듭니다.

• 가끔은 잘못된 방향으로 가고 있음을 깨닫는 것이 가장 중요한 정보가 됩니다.

• 항상 사용자 스토리를 기준으로 개발하세요.

• 정확한 추정을 해야 한다는 생각 때문에 보수적으로 추정하기 쉽습니다.

• 10 가지 일을 형편없이 진행하는 것보다는 8가지 일을 잘 진행하는 것이 낫습니다.

• 기반을 구성할 때 너무나도 많은 것을 고려하게 되므로 그만큼 많은 시간을 잡아먹습니다.

• 배포일을 앞두고 결함 수정으로 일정이 얼마나 지연될지 알 수 없기 때문이죠.

• 항상 최고의 설계를 유지해야 합니다.

• 그 피처를 지원하도록 설계를 개선해야 합니다.

조직

• 제품 책임자가 이해할 수 있는 피처를 만들 수 있는 작은 개발팀을 여럿으로 구성하는 것입니다.

• 동감한다면 조직 전체를 조금씩 바꿔 나가세요.

• 피처를 중요한 순서대로 나열한 후, 그것을 기반으로 팀을 구성하는 것은 어떨까요?

• 전문가는 단지 전문가이기 때문에 높은 연봉을 받는 것이 아닙니다. 그들이 다른 사람을 전문가로 이끌어 줄 수 있어 그런 것입니다.

• 오늘은 어제의 업무량만큼 일할 수 있습니다.

• 업무량을 개인 별로 추정하는 것은 결코 권하지 않습니다. 개인이 아닌 팀 전체를 이해하고 팀이 할 수 있는 양을 추정해야 합니다.

• 압박하는 행동은 치명적입니다. 절대 하지 마세요.

• 작업 속도를 관찰하세요.

• 팀 전체에는 어떤 기술이 필요할까요?

• 경영진부터 가장 아래쪽에 있는 제품 책임자, 그리고 개발자 모두가 알아야만 합니다.

테스트

• 끊임없이 종합적으로 테스트해야 합니다.

• 테스트는 비즈니스와 개발자 관점으로 나눠 진행합니다.

• 인수테스트 주도 개발

• 개발자에게 테스트를 먼저 작성하게 한 뒤, 그 테스트를 통과하게끔 제품을 개발하는 것입니다.