좋은 제품을 만들려면 좋은 제품팀이 필요하다. 나쁜 제품팀이 가지고 있는 문제점에 대해 이야기하고, 좋은 제품팀이 되려면 어떻게 해야하는지 설명한다.
아마 이 모델에서 놓치는 가장 큰 기회는 엔지니어들이 너무 늦게 참여한다는 것이다. 엔지니어들이 단지 코드를 짜는 일만 한다면 그들이 가진 가치의 절반만 활용하는 것이나 마찬가지다. 제품개발에서 작은 비밀이 있다면 엔지니어가 보통 혁신을 하는데 가장 훌륭한 원천이라는 것이다. 그러나 이 모델에서 그들은 회의에도 초대받지 못한다. - 22p
엔지니어들이 너무 늦게 참여하면, 이미 결정된 사항에 대해서 반박하기가 쉽지 않다. 이미 결정된 것으로부터 생각하기 때문에 창의력도 해친다. 더 좋은 방법을 제시하는 것도 어렵다 왜냐하면 이전에 결정된 것을 뒤집기 어려운데, 지금까지 결정된 것들이 시간낭비인 것처럼 들리기 때문이다. 그리고 위험은 늦게 발견될수록 고치는데 비용이 커진다. 엔지니어가 늦게 참여하여 문제를 늦게 발견하면 그 고치는 비용도 같이 커지게 된다. 따라서 엔지니어들이 제품개발 시작부터 참여해야 한다.
전통적인 폭포수 방식이 여전히 가지고 있는 가장 큰 문제는 위험이 가장 마지막에 발견된다는 것이다. 고객에 대한 검증이 너무 늦게 일어난다는 의미다. - 23p
고객 자신도 자신이 무엇을 원하는지 잘 알지 못한다. 다 만들었는데 쓸모가 없다면 낭비만 있을뿐이다.
우리가 원하는 것은 용병팀이 아니라 미션팀이다. 용병팀은 지시한 것만 만든다. 미션팀은 진심으로 비전을 믿고 그들의 고객 문제 해결을 위해 최선을 다한다. 제품 전담팀은 마치 사내 스타트업처럼 행동하고 느낀다. - 41p
용병팀은 주어진 일만 하고, 나서서 일하지 않는다. 미션팀은 자율성과 책임을 가지고 문제 해결을 한다.
프로젝트 중심의 전통적인 모델은 프로세스에 따라 할당된 업무를 수행하고 나면 끝이다. 반면에 전담팀 모델은 출시가 되었다고 문제가 다 해결된 것이 아니다. 사용자와 비즈니스 입장에서 원하는 결과가 나올 때까지 끈을 놓지 않는다. - 49p
할당된 업무만 끝나고 떠나는 것이 아니라, 가치 전달에 대한 사용자의 피드백을 통해 다시 다음 액션을 계획해야 한다. 이렇게 하려면 제품 설계 초기부터 가설을 세워서 사용자에게 어떤 가치를 전달하고, 그것을 어떻게 측정할지 계획해야 한다.
고객에 대한 깊은 이해 없이는 그저 추측에만 의존하게 된다. - 55p
고객의 행동을 추측하는 것은 의미 없는 탁상공론일 뿐이다. 고객이 이렇게 하면 더 편하지 않을까요? 이렇게 하면 더 좋지 않을까요? 같은 질문들은 의미가 없다. 진짜 고객의 목소리에 기울여야 한다. 물론 가설을 세우는 것은 좋다. 고객이 이럴 것이라는 가설을 세운 후, 그 가설을 어떻게 검증할지 결정하고 실행하여, 가설이 맞았다면 왜 맞았는지, 틀렸다면 왜 틀렸는지 고민하고 그렇다면 어떻게 해야 할지 다음 액션을 결정해야 한다.
자바스크립트로 직접 만들면서 배우는 - 자료구조와 알고리즘 강의 바로 가기
실습으로 마스터하는 OAuth 2.0: 기본부터 보안 위험까지 - OAuth 2.0 강의 바로 가기
기계인간 이종립, 소프트웨어 개발의 지혜 - Git 강의 바로 가기
코드숨에서 매주 스터디를 진행하고 있습니다. 메일을 등록하시면 새로운 스터디가 시작될 때 알려드릴게요!
