33P by xguru 1일전 | favorite | 댓글 6개
  • 많은 회사들이 복잡한 프로세스나 장황한 요구 사항에 얽매여 개발 속도가 느려지지만, 실제로 중요한 것은 빠르게 ‘올바른 제품’을 만드는 것임
  • 제품 개발 과정에서 불필요한 요소들을 제거하면 제품 개발 속도가 매우 빨라짐. 올바른 제품을 만드는 것 자체는 본질적으로 빠른 과정임
  • 제품 팀의 속도를 늦추는 것은 프로세스, 의사 결정자와 실행자 간의 거리, 과도한 명세서 등의 불필요한 요소들임

[Product Velocity를 위한 원칙]

1. ‘덜 하기’가 필요함

  • 일반적으로 속도와 품질 사이에는 트레이드오프가 존재함
  • 대부분의 회사는 요구사항과 기한을 정하고 품질은 결과물로 취급하지만, 우리는 반대로 품질 기준을 정하고 60일 안에 무엇을 출시할 수 있는지 고민함
  • 중요한 것은 모든 요구 사항을 다 충족하려 하기보다는, 중요한 것만 빠르게 완성하는 것임
  • 요구사항을 제거하고 필요한 일만 하면 속도와 품질을 모두 높일 수 있음
  • Elon Musk도 비슷한 접근 방식을 제안하며, “먼저 요구 사항을 덜 멍청하게 만들어라”고 말함

2. ‘바보 모드’가 종종 효과적임

  • ‘midwit meme’을 예로 들면, 똑똑한 사람과 바보는 간단한 해결책에 동의하는 반면, 평균적인 사람은 불필요하게 복잡한 문제를 만듦.
  • 우리는 종종 ‘바보 모드’로 문제를 접근하며, 복잡하게 생각하는 대신 단순한 해결책을 찾으려고 노력함.
  • 실수를 했을 때는 대개 생각이 너무 많았던 것임, 간단한 방법이 더 자주 효과적임
  • "내가 바보라면 어떻게 할까?"라고 자문하면 실행 가능한 해결책에 도달하곤 함

3. 모든 문제가 중요한 것은 아님

  • 소수의 문제들만 매우 중요함. 보안과 같은 중요한 문제는 반드시 해결해야 하지만, 모든 문제를 다 해결할 필요는 없음.
  • 예를 들어, 모바일 UI가 좋지 않지만 고객이 모바일 사용을 거의 하지 않기 때문에 이를 개선하지 않고 있음.
  • 이처럼 고객이 크게 신경 쓰지 않는 문제는 무시할 수 있음.

4. 그냥 만들어라

  • 우리는 제품 개발을 위한 프로세스가 없음. 피그마 목업, PRD, 디자인 시스템, 애자일, OKR, 확실한 제품 로드맵, A/B 테스팅, 그로스 해킹 등을 하지 않음
  • 고객이 엔지니어이기에 우리 엔지니어가 제품, 디자인 등을 모두 처리할 수 있다고 기대함
  • 빠르게 제품을 만들어보고 고객의 반응을 살피는 방식을 선호함

5. 재작성은 필요할 때 함

  • 회사들은 종종 기술 부채를 가능한 오래 미룰수록 더 빨리 움직일 수 있다고 생각하지만, 우리는 필요할 때 대규모 재작성을 하는 것을 불편해하지 않음
  • 때로는 올바른 것을 만들기 위한 가장 빠른 길이 잘못된 것을 만들고, 그것이 잘못되었다는 것을 깨닫고, 올바른 것으로 대체하는 것임
  • 기술 부채를 제거하는 것이 유용해 보인다면 그렇게 할 것임

6. 가능하면 외주를 활용함

  • 가능하다면 사내에서 만드는 대신 외부 벤더의 솔루션을 구매함. 예를 들어 Fern이라는 업체를 통해 SDK를 생성함
  • 물론 공급업체를 이용하는 것은 상당한 초기 비용이 들고 자유도를 제한하지만, 일반적으로 옳은 선택임
  • 우리는 엔지니어링 리소스가 매우 제한적이고 비싼데, 엔지니어 일주일치 시간이 약 5천 달러의 비용이 듦. 기회비용을 고려하면 그 가치는 훨씬 더 높음
  • 실제로 만들 가치가 있는 것은 상대적으로 적음

7. 채용하지 않음

  • 인력을 늘리면 팀의 산출량이 늘어날 것이라 기대하지 않음. 채용은 느리고 어려우며, 온보딩과 인력 관리는 시간을 소모함
  • 특히 많은 지원 없이 기여할 수 있는 유능한 사람을 데려오기가 어려움
  • 따라서 대규모 엔지니어링 팀을 구축할 자원이 있음에도 불구하고, 소규모로 유지하기 위해 최선을 다함. 이는 삶을 훨씬 더 쉽게 만듦

마무리 생각

  • 우리가 이전에 깨닫지 못했던 정도로, 제품 개발은 그렇게 오래 걸리지 않아야 한다는 것을 깨달았음
  • 고객에게 필요한 것을 알고, 강력한 팀을 보유하고 있으며, 주의를 산만하게 하는 불필요한 요소를 배제하면 높은 속도로 제품을 개발할 수 있음

외주에 대한 관리 비용이나 거기에 투입되어야 하는 리소스가 만만치 않을텐데... 그래도 전반적으로는 훌륭한 조언입니다.

항상 외주를 이용하라고 하지만. 외주를 사용할때는 어떻게 해야한다는 거의 못본듯하네요.
명확한 서비스 그림없이 간단한 밑그림만을 넘기게되면 생각보다 더 심한 것들을 받는다는 것을 인지하지 못하는....

"먼저 요구 사항을 덜 멍청하게 만들어라"

???: 빠르지만 애자일하지 않게 만들어주세요

제품이 명확할 때 가능하다고 생각합니다
해야할 게 분명할 때 그 이상의 설계는 불필요하다 요런 느낌

외주 업체가 어느 날 없어지면... 전화 안 받으면 ㅠㅠ