오랜만에 공감가는 읽을거리 하나 공유 합니다.
오전에 출근해서 메일링으로 온 것인데, 프로젝트를 리딩하는 입장에서 도음이 될 만한 내용이네요.

프로덕트 리더가 반드시 피해야 할 5가지 실수

특히 2번 내용에 적잖이 공감을 하는데...

2. 품질보다 양을 우선시한다.

빠른 성장을 추구하다 보면 제품 로드맵에 수많은 기능들을 가득 채우고 싶은 유혹에 빠지기 쉽습니다. 하지만 한 번에 모든 것을 처리하려고 하면 집중력이 흐려지고 팀에 부담을 줄 수 있습니다.

정확하고 단호하게 우선순위를 정하여 이러한 실수를 피하세요. 그리고 제품의 핵심 가치 제안에 집중하여 각 기능이 중요한 목표에 부합하는지 확인하세요. 변화하는 시장 상황과 사용자 피드백에 적응하기 위해 로드맵을 지속해서 검토하고 조정하는 것도 잊어서는 안 됩니다.

개인적으로 같은 맥락에서 조금 덧 붙이고 싶은 내용이 있다.

개발 스펙을 잡을 때,
무엇을 개발할 것인가? 를 정의하는 것 못지않게 중요한 것이 무엇을 개발하지 않을 것인가? 를 정의하는 것도 아주 중요하다.

소프트웨어 개발 현장에서 자주 목격되는 현상이다.
비즈니스의 전략과 그 전략을 실현하기 위한 본질만을 기능으로 정의(스펙인)하는 것을 넘어, 자기 자신이 이 기능에 대해 깊고 다양하게 생각할 수 있음을 피력하는 수단으로 스펙을 정의하는 실수말이다.

사실 이런 것들 중 대부분은 치장하기 기능으로 스펙아웃의 대상이 되어야 하거나 지금 당장은 필요치 않은 부가기능(핵심 기능을 런칭한 후 개발해도 되는 기능)들이 대부분이다. 즉 오버스펙이거나 좋은 기능이지만 지금 당장은 필요하지 않은 기능!

특히 스타트업은 시간과 자원이 한정되어 있다.
본질적인 기능을 시장에 빠르게 런칭하고 데이터와 고객의 반응을 보면서 점진적으로 개선해 나가는 것이 중요하다고 생각한다.

국제적인 프로젝트 관리 협회인 PMI는 프로젝트의 3대 제약사항을 '일정/원가/범위'로 정의했다.
앞서 언급한 치장하기 기능들은 이 3가지 요소 모두에 영향을 미친다.
더불어 프로덕트의 품질에도 영향을 미친다. 더 많은 기능은 필연적으롸 더 많은 검증이 필요하고 더 많은 버그 가능성을 내포한다.

이것은 린스타트업, 린소프트웨어개발방법론의 철학에도 깔려 있는 원칙이다.
린 방법론의 핵심은 생산에 있어 낭비요소를 제거(or 최소화)하는 것이다.

소프트웨어 개발과정에서 불필요한 기능, 오버 스펙된 기능, 나중에 필요한 기능 등은 모두 (현재 시점에서는) 낭비요소이다.
핵심 기능만을 오류 없이 고품질로 런칭하여 프로덕트의 성장성과 기회를 빠르게 증명하는 것이 무엇보다 중요하다고 생각한다.

린 방법론에 대해서는 아래의 글이 핵심을 잘 정리해 놓은 듯 하니, 참고하면 좋겠다.
https://brunch.co.kr/@kbhpmp/22