PM이 알아야 할 Linear 제품 실행 원칙
이전 편인 PM이 알아야 할 Linear 제품 개발 원칙이 프로젝트 관리에 관한 원론적인 이야기들이었다면, 이번 편은 실행에 관한 내용들입니다. PM들이 실제로 적용해 볼 수 있는 방법들을 제시하고 있습니다. 여기서 중요한 것은 제품 개발 원칙에서 제시한 내용들과 실행 원칙에서 나오는 내용들을 연결 지어 보는 것입니다. 그렇게 함으로써 단순히 Linear가 제시하는 방법을 따라 하는 것이 아니라 왜 이렇게 실행해야 하는지를 이해하고 각자 다른 업무 환경에 맞게 적용할 수 있습니다. 아래 내용은 제품 개발 실행(Practices)에 대한 번역입니다.
Linear Method Practices
월별, 분기별 또는 연간으로 로드맵 설정하기
높은 목표를 세우는 것은 의미 있는 임팩트를 만들어내는 유일한 방법입니다. 회사의 큰 방향을 정의할 때는 이에 초점을 맞춰야 합니다. 여기에 더해 예상하지 못한 프로젝트들을 위해 로드맵에 일부 여유 있는 공간들을 확보해 두고 필요에 따라 로드맵을 변경할 수 있도록 할 필요가 있습니다.
프로젝트 내 데일리 업무들을 더 큰 목표와 연결하기
모든 프로젝트와 업무들은 목표와 직접적으로 연관되어야 합니다. 연간/분기별 로드맵 미팅을 할 때에는 프로젝트별 목표와 목표 달성 날짜들을 검토하고, 개발 일정을 계획할 때 각각의 목표들을 가져와 프로젝트에 연결시켜야 합니다.
N-주 사이클로 작업하기
사이클은 건강한 일상을 만들고 팀이 다음에 해야 할 일에 집중할 수 있도록 합니다. 소프트웨어 개발에서 가장 일반적인 기간은 2주 사이클입니다. 다른 우선순위를 놓치지 않을 만큼 짧지만, 중요한 기능을 구축할 수 있을 만큼 깁니다. 사이클은 구성원들이 합리적으로 느낄 수 있어야 합니다. 사이클에 과부하가 걸리지 않도록 조율해야 하며, 완료하지 못한 업무들은 자동적으로 다음 사이클로 넘어가도록 해야 합니다.
관리 가능한 수준의 백로그 유지하기
기능 개발에 대한 모든 요청이나 피드백을 저장할 필요는 없습니다. 중요한 기능이라면 항상 반복해서 드러날 것이고, 낮은 우선순위의 기능이라면 시간이 지나도 개발되지 않을 것이기 때문입니다. 더 집중해야 하는 기능들에 초점이 맞춰진 백로그로 관리해 두면, 개발 일정을 계획하고 실행하는 것이 더 쉽고 빨라질 수 있으며, 실제로 업무들이 완료될 수 있도록 합니다.
기능 개발과 QA를 함께하기
모든 소프트웨어 개발에는 버그가 있습니다. 그러므로 개발 일정에 버그나 다른 수정할 사항들을 포함시켜야 합니다. 신규 기능 개발과 QA가 함께 진행될수록 좋은 제품이 될 확률이 훨씬 크므로 이 밸런스를 맞추는 것에 신경 써야 합니다.
프로젝트 및 이슈를 책임질 담당자 지정하기
각 프로젝트에는 배포를 책임지고 프로젝트 브리핑을 작성할 책임자가 있어야 합니다. 이슈도 마찬가지입니다. 다른 사람들과 함께 협업하지만, 프로젝트 책임자는 한 사람이어야 합니다.
프로젝트 스펙 문서 작성하기
간결함을 목표로 작성되어야 합니다. 짧은 문서는 다른 사람들이 읽을 가능성이 더 높습니다. 프로젝트 스펙 문서의 목적은 프로젝트가 "왜", "무엇을", "어떻게" 진행될 것인지에 대한 내용을 팀원들에게 간략하게 전달하는 것에 있습니다. 이상적으로는 이러한 짧은 문서를 통해 팀은 개발 범위를 결정하고, 우선순위를 명확하게 인지하고, 팀이 잘못된 방향으로 가는 것을 피할 수 있습니다.
사용자를 이해하기
제품이 더 인기 있을수록 더 많은 피드백을 받게 됩니다. 버그가 아니라면, 넘쳐나는 이메일들은 제품에 대한 좋은 신호입니다. 모든 피드백을 구현해야 한다고 생각하지 않아도 됩니다. 단지, 피드백을 바탕으로 새로운 기능을 개발할 때 사용할 소스들로 받아들이면 됩니다. 제품에 대한 사용자들의 트렌드를 읽으려고 노력하는 것이 보다 중요합니다. 사용자를 더 깊이 이해하고, 특정 기능을 필요로 하는 이유를 알아내는 기회로 활용해야 합니다. 단순히 기능을 개발하는 것이 아니라 사용자들의 문제를 해결하는 것이 본질입니다.
개발 범위를 최대한 작게 설정하기
개발 범위가 큰 업무를 수행할 때는 제대로 진행되고 있는지 파악하기 어렵습니다. 이는 하고 있는 일에 대한 동기부여를 떨어뜨릴 수 있습니다. 가능한 경우 범위를 더 작은 부분으로 나누고, 각 부분에 대해 업무를 만들어 보세요. 업무가 완료되는 모습을 확인하는 것은 모두의 동기부여를 상승시키고, 이상적으로는 매주 여러 개의 구체적인 업무들을 완료할 수 있습니다.
Changelog 작성하기
Changelog를 작성하는 팀이 회고할 수 있도록 하고, 성취한 것들을 자축할 수 있도록 합니다. 지속적으로 Changelog를 작성하면, 사용자들에게도 새로운 기능에 대해 소개할 수 있고, 이를 위해 우리가 노력하는 부분을 알려주는 방법이 되기도 합니다. 또한, 각각의 팀들이 개발하는 서로 다른 기능들이 우리 회사가 만들어 가는 가치와 어떻게 연결되어 있는지를 가장 쉽게 확인하는 방법이기도 합니다.
Conclusion
Linear 제품 개발 원칙과 실행 원칙을 연결하면 프로젝트 관리의 핵심이 되는 요소를 이해하고, 적용할 수 있습니다. 예를 들어, Linear팀은 개발 원칙(Principles)에서 언급한 회사의 모멘텀을 만드는 방법을 Changelog를 작성함으로써 달성할 수 있다고 합니다. (이 내용은 Linear CEO인 Karri Saarinen의 다른 글에서 확인할 수 있습니다.)
Changelog를 주기적으로 작성함으로써 회사와 제품 개발 팀이 그들의 개발 속도를 확인할 수 있고, 제품 개발 속도가 느려지는 주기를 체크하여, 해당 기간 동안 부족한 부분이 무엇이었는지를 회고할 수 있기 때문입니다.
또한, 비효율적인 업무를 거부하는 원칙을 지키기 위해서는 백로그 관리를 최소로 하는 것을 통해 달성할 수 있습니다. 정말 중요한 기능이라면 계속해서 백로그에 등장할 것이고, 중요하지 않은 기능들은 결국 개발되지 않을 것이기 때문입니다.
이처럼 우리는 Linear Method 내용 중 원칙과 실행 편에서 연결되는 지점들을 파악함으로써, 제품 개발에 핵심이 되는 요소들을 업무 환경에 맞게 적용하여 우리만의 무기로 발전시킬 수 있을 것입니다.
MOBA에 대해 더 자세히 알아보기
- The Professional To-do Calendar, MOBA 둘러보기
- MOBA를 가장 빠르게 만나는 방법, Join Waitlist