[코드스테이츠 PMB 11기] 프로덕트 개발 방법론 (워터폴, 애자일)
프로덕트 개발 방법론에는 워터폴(Waterfall)과 애자일(Agile) 방법이 있다. 이 각각의 방법론들에 대해 알아보고, 이 중 애자일 방법으로 문제를 해결하는 방법에 대해서 자세히 알아보려 한다.
요구사항 수집과 분석 ▶ 설계 ▶ 테스팅 ▶ 프로젝트 최종 결과물 ▶ 유지 보수
워터폴은 제품을 기업 내에서 스스로 정하고, 고객 테스트 없이 팀 내 혹은 기업 내 이해관계자들끼리 결정만으로 제품 개발 후 시장에 내놓는 전략이다. 워터폴 개발의 특징은 처음부터 고객 문제를 해결하는 솔루션을 정의하고, 위에서부터 아래로 내려가면서 개발하는 탑-다운 방식으로 개발하는 것이 특징이다.
계획 ▶ 설계 ▶ 개발 ▶ 테스팅 ▶ 배포 ▶ 피드백
애자일은 아주 작은 핵심 요소만으로 제품 혹인 샘플을 만들어서 소비자 반응을 확인하고 점점 살을 붙여 나가는 방식이다. 각 주기는 제품이나 서비스 개발을 지속적으로 향상하는데 초점이 맞춰져 있으며, 반복적이며 사람 중심적인 개발 방식을 취한다.
애자일의 3가지 도구로는 스크럼, 유저 스토리, 칸반이 있다.
다음과 같은 상황을 가정하고 다음 버전 업데이트에 반영할 개선안에 대한 사용자 스토리, 백로그를 작성해보려 한다.
지금은 2020년 9월, 우리는 KAKAO의 PM입니다.
2021년 1분기 내 카카오톡 '멀티 프로필'이라는 신규 프로덕트를 출시하는 것을 목표로 하고 있습니다. 카카오톡 멀티 프로필 프로덕트는 이미 충분한 논의를 통해 요구사항이 정의되어 있으며, 2021년의 가장 큰 프로덕트 릴리즈이므로 워터폴(Waterfall) 개발 프로세스로 개발하기로 결정했습니다.
카카오톡 멀티 프로필 프로덕트를 릴리즈 한 후 다음과 같은 문제점이 발견되었다고 하자.
멀티 프로필이 생겨서 직장동료, 모임용, sns용
등을 따로 만들 수 있게 되어서 너무 좋다!
그런데 내 이름은 하나인데 프로필이 여러 개여서 헷갈려!
이게 모임용이었던가? 직장동료용이었던가?
내가 설정해놓긴 했지만 무슨 용도였는지 자꾸 까먹네...
내 이미지와 같이 멀티 프로필을 설정해놓으면, 어떤 프로필을 어떤 용도로 설정해 둔 것인지 직접 눌러서 확인해야 한다. 이러한 문제점을 해결하기 위한 개선안으로 멀티 프로필에 별명을 설정하는 기능을 추가한다고 가정하고 유저 스토리와 백로그를 작성해보려 한다.
유저 스토리는 팀에서 해결해야 하는 고객의 문제를 제품 팀이 아닌 '고객'의 입장에서 서술한 내용을 뜻하고, 형식은 다음과 같다.
유저 스토리 형식을 이렇게 적는 것은 다음과 같은 장점을 가지고 있다.
1. 나도 모르는 사이에 고객의 입장에서 생각하게 된다.
2. 원래 하려던 방식 말고 더 좋은 방식으로 일하게 된다.
3. 복잡한 기획안을 쓸 필요가 없어진다.
위의 문제점을 가지고 유저 스토리를 만들면 다음과 같다.
백로그는 개발해야 할 기능 또는 제품에서 요구하는 기능과 우선순위를 말한다. 흔히 백로그를 할 일 목록이나 미처 처리하지 못한 것들을 모아두는 것이라고 생각하는 경우가 많은데, 엄밀히 말하자면 이러한 할 일 목록 리스트는 백로그라고 보기 어렵다. 백로그에는 누가 어떤 문제를 겪고 있는지, 그래서 우리가 문제를 어떻게 해결할 수 있을지, 그 문제를 해결함으로써 얻게 되거나 기대하는 결과는 무엇인지를 명시해야 한다.
+) 2022.05.04 추가
이해관계자 관리는 프로젝트 관리에 아주 중요한 요소 중 하나이다. PM은 중요한 개인과 팀 구성원에게 정보를 제공해 과업을 추진해야 프로젝트가 원활해진다. 그러나 영향을 받는 사람과 프로젝트에 영향을 주는 사람들에게 정보를 제공하지 않을 경우, 프로젝트에 문제가 발생할 수 있다. 이해관계자 관리 전략을 수립해 이것들을 제대로 공유한 후 이행하면 개인과 팀, 프로젝트, 기업의 성과를 크게 개선할 수 있다.
먼저 내가 설정했던 유저스토리를 확인해보고, 각 이해관계자가 누구인지 알아보려 한다.
고객의 진짜 니즈를 파악하는 것이 스크럼에서 가장 중요하다고도 할 수 있다. 여기서 고객의 니즈를 알아내는 한 가지 팁이 있다면, 가능한 투명하게 공개하며 고객을 프로덕트 개발/개선에 참여시키는 것이다. 이를 통해 PM은 고객의 진짜 목표 및 문제를 알고 우선순위를 잘 정하는 데 도움이 될 정보를 모을 수 있다.
하나의 기획에 대해서 PM과 개발자, 디자이너는 한 팀이라고 할 수있다. 단순히 기획만 한다고 끝이 아니라 그것을 실제로 만드는 것도 중요하다. 각 팀원들은 다음에는 무엇을 개발할지, 이미 개발했던 것이 스프린트의 목적을 이루었는지 잘 파악해야 한다. 그리고 PM은 팀에게 무엇이 필요하고, 어떻게 하면 팀을 적절히 도울 수 있는지 파악하고 있어야 한다.
새로 생긴 기능에 대해서 공지를 하고, 그것의 사용방법을 유저에게 잘 알리는 역할은 마케팅이 담당한다고 할 수 있다. 따라서 새로 추가된 기능에 대해서 잘 이해하고, 이것을 어떻게 유저들이 쉽게 이해하고, 사용할 수 있게 준비하는 것이 필요할 것 같다.
제품 그룹의 고위 경영진(C-레벨 임원 등)은 PM을 제품 성공에 대한 최종적인 책임과 의무가 있는 사람으로 인정하고 바라본다. 때문에 PM은 개발 상태를 가시화하고 바람직한 방향(예를 들어, ROI 및 시장 점유율)으로 최적화하기 위한 고위 경영진의 (아마도 암묵적인) 지시 사항을 실현시킬 책임이 있기 마련이죠. 이를 위해 PO는 스크럼 마스터의 힘을 합쳐 조직 설계를 개선하고, 프로덕트를 개발할 수 있도록 고위 경영진을 이끌어야 합니다.
프로젝트를 계획하고 결과물을 파악하는 데 많은 시간을 할애했음에도 불구하고 새로운 결과물, 업데이트된 일정 또는 조정된 예산에 대해 너무 많은 이해관계자가 의견을 제시하면 프로젝트가 순식간에 방향을 벗어날 수 있다. 이해관계자와 경계를 설정하는 가장 좋은 방법은 변경 관리 프로세스를 적용하는 것이다. 프로젝트 범위에 대한 변경 사항을 제안, 검토, 수락하는 프로세스를 생성하면 범위 변동에 대한 걱정 없이 프로젝트를 동적이고 최신 상태로 유지할 수 있다.
불가피하게 다른 부서의 이해관계자를 잊어버리거나 이해관계자를 생각했지만, 이해관계자 목록에 추가하거나 영향력-관심 수준을 계산하는 것을 잊어버린 경우가 생길 수 있다. 이러한 사태를 피하기 위한 가장 좋은 방법은 이해관계자 식별 프로세스에 프로젝트 팀을 참여시키는 것이다. 팀에서 브레인스토밍 세션을 통해 모든 이해관계자를 식별하고 분류하여 아무도 목록에서 누락되지 않도록 하고, 매니저나 프로젝트 후원자로부터 목록을 확인받아 포함해야 할 이해관계자가 누락되지 않았는지 확인하는 것이 중요하다.
이해관계자를 분석하고, 이해관계자 등록부에 각 이해관계자와 역할에 대해 문서화를 한 후, 이해관계와 영향을 토대로 이해관계자에 대한 우선순위를 부여해야 한다.
참고자료