brunch

라이킷 11 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 연필심 Jul 31. 2022

3화. 우선순위 정리 그거 어떻게 하는 건데

나의 사이드 프로젝트 일대기

흔히들 PM은 우선순위 정리를 잘해야 한다고 이야기한다.

그래서 우선순위 정리 방법은 인터넷에 조금만 찾아보면 수많은 방법론이 나온다.

우선순위 정리에 서툴렀던 나 또한, 인터넷에 우선순위 정리 방법을 검색해 여러 자료를 찾아보았다.

긴급도와 중요도로 4사분면을 그려 여러 항목을 배치해보고...

P1(중요도 상), P2(중요도 중)로 항목마다의 우선순위를 표시하며...

나름대로의 기능 우선순위를 선정하니 왠지 있어 보이는 거다.

그래서 혼자 뿌듯해하며 팀원들에게 공유했다.

근데 이상하게도 볼수록 우선순위의 의미가 별로 와닿지 않았다.

분명 나름의 이유로 우선순위 P1로 적은 항목인데도 이게 진짜 P1인가 싶고, 어떤 P1 항목과 P2 항목은 그 중요도의 차이가 별로 나지 않는 것 같았다. 팀원들에게도 정리한 우선순위를 공유했지만 각자의 이해도 다른 것 같았고, 슬프게도 내가 정리해둔 우선순위를 잘 참고하지 않는 것 같았다.

이런 현상이 일어난 데는 각 우선순위 단계에 대한 기준을 명확히 해놓지 않은 내 불찰도 있다.

하지만 왠지 나는 긴급도x중요도로 나눠진 4사분면 방법론만으로 채워지지 않는 구멍 또한, 분명 존재한다는 생각이 들었다. 그래서 우선순위 정리에 대한 개념을 좀 더 세분화해보자고 생각했다.

우선순위 정리, 도대체 그거 어떻게 하는 건데

내가 생각한 우선순위의 핵심은 ‘우리가 이 기능을 얼마나 개발하고 싶은지', 혹은 ‘우리가 이 기능을 개발해야만 하는 이유’에 대한 명확한 답이 있느냐, 라는 것이다. 이 답에 공감하는 팀원이 많을수록 우선순위가 높아진다.

Q1. 우리는 이 기능을 얼마나 개발하고 싶은가?

이왕 기능을 만들 거 라면, '우리가 그 기능을 얼마나 하고 싶은지'를 한판 정리해보자. 사이드 프로젝트를 참여하는 사람이라면 서비스를 통해 '자아실현' 하는 게 목적인 사람들도 있기 때문에 열정을 파악하는 것 또한 중요하다. 하고 싶은 이유에 따라 해당 기능에 들일 수 있는 몰입도와 정성은 남달라 질 것이다.

또한 만들고 싶은 이유를 정리하다 보면 생각 외로 하고 싶지 않았던 기능이었다거나, 다시 보니 더 하고 싶은 기능일 수도 있다. 이 질문은 우선순위의 이유를 보다 명확하게 만들어준다.

그렇지만, 사실 하고 싶은 이유가 많다고 해서 우선순위가 높아지지는 않는다. 어떤 기능을 개발하고 싶은 이유는 특정 개인의 기호일 수도 있기 때문이다. 그렇다면 우선순위 선정에 '진짜' 중요한 질문은 무엇일까?

Q2. 우리가 이 기능을 해야만 하는 이유는 무엇인가?

우선순위 선정에 진짜 중요한 질문은 '해야만 하는 이유'를 묻는 것이라고 생각한다. 이걸 ‘만들어야만 하는’ 이유가 많을수록 우선순위가 높아진다.

해야만 한다는 건, 반대로 이걸 하지 않으면 안 된다는 뜻이 된다. "왜 이걸 하지 않으면 안 되지?"를 파고파고 가다 보면 해당 기능을 만들어야 하는 이유를 찾을 수 있다. 만들어야만 하는 이유를 생각하는 과정에서 특정 기능 개발에 대한 논리적 근거가 세워지는 셈이다. 결국 해야만 하는 이유를 하나씩 찾다 보면 이 기능의 중요도와 긴급도를 파악할 수 있으며, 그래서 우선순위 정리에 도움이 되는 질문이다.

단, 해야만 하는 이유를 꼽을 때 개인의 선호와 착각하면 안 된다. PM이 A라는 기능을 '만들어야만 하는 이유'를 찾아 우선순위를 선정했더라도, 개발자는 그 기능을 '만들지 말아야 할 이유'를 찾았을 수도 있기 때문이다. 서비스의 로드맵, 유저의 니즈, 팀원들의 목표 등 모두와 합의된 객관적인 이유여야 한다.