신입 PM이 너무 강해짐 -(7)
기획서 다시 써오세요!
기획서 다시 써오세요!
PM으로서 가장 힘든 상황 중 하나는 아마도 개발팀으로부터 “기획서 다시 써오세요!“라는 피드백을 받는 순간일 것입니다. 경험 많은 PM도 어려워하는 이 상황을 신입 PM들이 겪게 될 때, 제가 종종 그들에게 해드리는 이야기를 오늘은 글로 적어보려고 합니다.
저는 현재 PM으로 일하고 있지만, 저의 모든 과거 커리어가 PM은 아니었어요.
펌웨어 개발자로 시작해서 소프트웨어 개발자로, 그리고 UX 디자이너 업무도 하고, 기술 영업, 마케팅, 전략기획 등 다양한 업무를 하다 보니, 그때는 이해하기 어려웠던 상대방의 입장을 이제는 좀 더 자연스럽게 잘 이해하게 된 것 같아요.
“당신이 뭘 알아?“라고 생각하실 수 있지만, 그래도 각 영역에서 적어도 팀장 타이틀까지는 일해본 경험이 있다보니, 각각의 업에 대한 전문성은 그 일을 계속 해오신 분들에 결코 비할 수 없지만, 여러 상대방의 입장에서 고민해보는 시각은 조금 생긴 것 같아요.
제가 처음 개발자로 일을 시작하게 된 2002년도의 개발문화를 이야기하자면
(그래요 저 PC통신 세대입니다 ㅎㅎ)
지금은 익숙하게 들리는 애자일, 유저스토리, 스크럼에 대한 이야기보다는 프로젝트 관리와 납기에 대한 이야기가 더 많았고, 웹 기반 서비스보다는 윈도우 기반 설치형 프로그램이 대세였던 시대였습니다.
그 당시에는 MVP(Minimum Viable Product)를 출시하고 계속해서 고객의 반응을 보면서 제품을 발전시켜 나가는 개념보다는, 잘 짜여진 소위 말하는 완벽한 제품 기획서를 바탕으로 개발해야 하는 모든 기능들에 대한 공수 산정을 하고, 철저한 일정 관리를 기반으로 한 제품 릴리즈 개념이 주를 이루었습니다.
이게 잘못되었다는 것은 절대로 아닙니다. 모든 개념은 적절히 상황에 맞게 사용될 필요가 있습니다. 하지만 시대적으로 많은 방향성을 따르기만 했어야 했던 상황에서 그들은 보다 완벽한 기획서를 추구하고, 이를 바탕으로 보다 정교한 빈틈없는 개발 공수를 산정해 나가는 것이 곧 전문성의 판단이 되어버렸습니다.
그 시절의 개발자들은 치밀한 계획과 완벽한 실행을 통해 높은 품질의 소프트웨어를 제공하는 것을 목표로 했습니다. 모든 기능이 사전에 정의되고, 그 정의된 기능들이 예측 가능한 시간 안에 정확하게 구현되는 것이 중요했습니다. 이러한 환경에서는 개발자들이 코드 한 줄 한 줄을 신중하게 작성하고, 작은 오류 하나도 허용되지 않는 분위기 속에서 일했습니다.
지금과는 달리, 그때는 변화의 속도가 상대적으로 느렸습니다. 고객의 피드백을 실시간으로 반영하기보다는, 일단 완성된 제품을 시장에 내놓고 난 후에야 피드백을 받을 수 있었습니다. 이는 개발자들에게 더 큰 압박감을 주었고, 초기부터 완벽한 제품을 만들어야 한다는 부담을 안겨주었습니다.
그렇다보니 초기 기획의 완성도가 그 어느때보다 중요한 시대 였어요.
하지만 시간이 지나면서 소프트웨어 개발 방법론도 크게 변했습니다. 애자일, 유저스토리, 스크럼과 같은 현대적인 방법론들이 등장하면서, 빠르게 변화하는 시장의 요구에 대응하고, 고객의 피드백을 신속하게 반영할 수 있는 유연한 개발 방식이 주목받기 시작했습니다. 이제는 완벽함보다는 빠른 출시와 지속적인 개선이 더 중요한 가치로 여겨지고 있습니다.
문제는 과도기
여기서 문제는 과거의 그들이 현재의 의사결정권자이거나 그들의 업무를 보고 배운 세대들이 현재의 팀장 또는 부서장 레벨일 가능성이 높다는 점입니다. 이들은 완벽한 기획서와 철저한 일정 관리를 중시하는 문화에서 성장했습니다. 그러나 세상은 빠르게 변화하고 있습니다. 현 세대의 개발자와 PM들은 고객의 피드백을 빠르게 반영하는데 적합한 방식을 받아들이고 일하고 있습니다. 이들은 빠르게 변화하는 시장의 요구에 대응하고, 사용자 중심의 프로덕트를 개발하는 데 중점을 두고 있습니다. 하지만 이 과정에서 이와 반대되는 방식을 고수하는 이들과의 갈등이 발생하기도 합니다.
MVP에 대한 이야기를 하는 순간, “어차피 다시 다 바뀔 텐데 좀 더 전체적인 기획을 다 잡고 하지 않고 왜 대충 개발하라고 하나요?“라는 피드백을 받을 수도 있습니다.
이러한 피드백은 매우 이해할 만한 반응입니다. 전통적인 개발 방식에 익숙한 사람들에게는 완벽한 기획서를 기반으로 모든 기능을 철저하게 계획하고 개발하는 것이 성공의 열쇠로 여겨졌기 때문입니다. 과거에는 한 번의 릴리즈에 모든 기능이 포함되어야 했고, 이는 철저한 사전 계획과 긴 개발 주기를 요구했습니다.
그러나 현대 소프트웨어 개발에서는 시장의 요구와 사용자의 기대가 빠르게 변하고 있습니다. 완벽한 기획서를 작성하고 모든 기능을 포함시키는 것은 시간과 자원을 많이 소모할 뿐만 아니라, 출시 시점에 이미 시장의 요구에 뒤처질 위험이 큽니다. 여기서 MVP(Minimum Viable Product) 개념이 등장합니다.
MVP는 가장 기본적이고 중요한 기능만을 포함한 최소한의 제품을 먼저 출시하여, 실제 사용자로부터 피드백을 받는 것을 목표로 합니다. 이를 통해 제품의 방향성을 조기에 확인하고, 불필요한 기능 개발을 피하며, 더 나은 사용자 경험을 제공할 수 있습니다. MVP는 “대충 개발”하라는 의미가 아니라, “신속하게 시장에 반응하라”는 전략적 접근입니다. (MVP가 아닌 MLP - Minimum Lovable Product 컨셉도 있습니다. 이에 대해서는 다음에 알아보도록해요)
물론 MVP 접근 방식이 익숙하지 않은 분들에게는 불완전한 제품을 출시하는 것이 불안할 수 있습니다. 그러나 이 방식은 사용자 피드백을 통해 제품을 개선해 나가는 과정에서 오히려 더 큰 가치를 창출할 수 있습니다. 초기 사용자의 피드백을 통해 실제로 필요한 기능을 빠르게 파악하고, 이를 반영하여 제품을 개선해 나가는 것이야말로 진정한 사용자 중심의 개발 방식입니다.
결국, MVP는 완벽한 기획서와 철저한 일정 관리를 중시하는 전통적인 개발 방식과는 다른 접근법입니다. 그러나 이 방법은 현대의 빠르게 변화하는 시장 환경에서 제품의 성공 가능성을 높이는 데 매우 유용한 전략입니다. 중요한 것은 MVP를 통해 얻는 사용자 피드백을 적극적으로 반영하여, 점진적으로 제품을 개선해 나가는 것입니다.
이러한 과정이 반복되면서, 최종적으로 사용자에게 최상의 가치를 제공하는 완성도 높은 제품을 만들어낼 수 있습니다. 따라서, “어차피 다시 다 바뀔 텐데”라는 우려를 이해하면서도, MVP 접근 방식의 장점을 잘 설명하고, 이를 통해 얻을 수 있는 실질적인 이점을 강조하는 것이 중요합니다. 이는 신속한 시장 대응과 사용자 중심의 제품 개발을 가능하게 하여, 궁극적으로 더 큰 성공을 가져다줄 것입니다.
다행히 우리는 변화하고 있어요
세대가 바뀌고 있습니다. 이제는 “기능을 완벽히 구현”한다는 관점에서 “개발로 고객의 문제를 해결”한다는 관점을 가진 개발자들이 많아지고 있으며, 그런 분들이 점점 더 의사결정권자가 되고 있습니다.
기술의 발전과 시장의 빠른 변화에 따라, 이제는 개발자들이 단순히 기능을 구현하는 데 그치지 않고, 고객의 문제를 해결하는 데 중점을 두고 있습니다. 이는 사용자 중심의 개발 철학이 자리 잡으면서 더욱 중요해졌습니다. 고객의 요구를 신속하게 반영하고, 실질적인 문제를 해결하는 제품을 만드는 것이 성공의 열쇠로 여겨지고 있습니다.
현대의 개발자들은 고객의 피드백을 중시하며, 이를 기반으로 제품을 지속적으로 개선해 나갑니다. 이들은 더 이상 모든 기능을 처음부터 완벽하게 구현하는 것을 목표로 하지 않습니다. 대신, 가장 중요한 기능을 먼저 구현하고, 고객의 반응을 통해 필요한 기능을 추가하거나 개선하는 방식으로 접근합니다. 이러한 접근 방식은 빠르게 변화하는 시장 환경에서 매우 효과적입니다.
이러한 변화를 주도하는 개발자들이 의사결정권자가 됨으로써, 우리는 더욱 유연하고 혁신적인 개발 환경을 만들어가고 있습니다. 이들은 고객의 목소리를 듣고, 그들의 문제를 해결하는 데 집중함으로써, 더 나은 제품과 더 큰 가치를 창출하고 있습니다. 이러한 변화는 우리 모두에게 더 큰 기회를 제공하며, 앞으로도 계속해서 발전해 나갈 것입니다.
하지만 완성도 높은 기획 문서는 필요해요
큰 단위의 모든 기획문서를 한 번에 다 작성하지 않는다고 해서, 빠르게 전달해야 한다고 해서 기획 문서의 완성도가 떨어져도 괜찮다는 의미는 아닙니다. 우리는 개발자들이 개발에 온전히 집중할 수 있도록 지원해야 하며, 그러기 위해서는 완성도 높은 기획 문서가 빠른 템포로 개발팀에 공유되어야 합니다.
기획 문서는 단순히 아이디어를 나열하는 것이 아니라, 개발자들이 실제로 필요한 정보를 명확하게 제공하는 도구입니다. 기획 문서에 개발에 필요한 요건들이 빠진 채, 문제 정의와 가설만 담겨 있고 이를 기반으로 디자인만 잡혀서 전달되는 경우를 종종 보게 됩니다. 이러한 문서들은 개발자들이 실제로 무엇을 구현해야 하는지 혼란을 초래하고, 결과적으로 프로젝트의 진행에 지장을 초래할 수 있습니다.
기획 문서를 잘 작성하기 위한 가장 좋은 방법은 내가 정리한 문서를 보고 개발자가 되어 한번 만들어보는 상상을 해보는 것입니다. 이렇게 하면 문서의 완성도를 높이고, 개발자들이 실제로 필요한 정보를 명확하게 제공할 수 있습니다.
이와 관련된 재미있는 예로, 아래 영상을 참고해 보세요. 이 영상은 아이가 적어온 샌드위치 만드는 법을 보고 아빠가 그대로 따라 만드는 모습을 담고 있습니다. 이 과정을 통해 기획 문서의 중요성과 명확한 지침의 필요성을 이해할 수 있습니다.
이 영상에서 아빠는 아이가 작성한 지침을 그대로 따르려고 하지만, 명확하지 않은 지시나 빠진 정보 때문에 예상치 못한 어려움을 겪습니다. 이는 우리가 작성하는 기획 문서가 개발자들에게 얼마나 중요한지, 그리고 얼마나 명확하고 구체적으로 작성되어야 하는지를 잘 보여줍니다.
따라서, 기획 문서를 작성할 때는 개발자의 입장에서 생각해 보고, 그 문서를 바탕으로 실제로 개발을 해보는 상상을 해보세요. 이를 통해 문서의 불완전한 부분을 발견하고, 더 나은 지침을 제공할 수 있습니다. 이 과정이 반복되면, 개발팀과의 소통이 원활해지고, 프로젝트의 성공 가능성도 높아질 것입니다.
물론 모든 기능을 영상 속의 내용처럼 세밀하게 작성하는 것은 현실적으로 어려울 수 있습니다. 그러나 위의 영상과 같은 마음을 가지고 기능 명세서를 작성한다면, 좀 더 유연한 소통이 개발자들과 가능할 것 같아요.
