요구사항 분석은 병목이나 R&R싸움이 아니다.

속도가 중요해도 역할을 포기하지 말자.

*페북에 짧게 썼던 글을 다시 써봤어요.

얼마 전 외부팀의 요구사항이 UI레벨로 올 때, 그대로 개발에 전달 하지말고 꼭 판단해야한다고 말했다. 그 자리에 있던 다른 동료가 어차피 그렇게 해야될 일이라면 일을 2번하는 꼴 아니냐고 물었었다.

충분히 물어볼 수 있는 질문이었다.

속도만을 중요시한다면 이 판단의 시간이 병목이라고 생각할 것이고,  동료들의 판단 역량에 대한 믿음이 부족한 것 아니냐는 의문도 있을 수 있다.

물론 개발자에게 도달하기까지 이슈업 되지 않고 변경이 늦어지는 것이 서비스 발전에 병목이 되서는 안된다. 하지만 요청사항 해결이 서비스 발전에 무조건 옳은 방향이 아닐 때도 있다.

내가 PO든 기획자든 요청사항에 대해 판단하려는 이유는 3가지다.

1. 현업 외부팀은 프로덕트의 모든 부분을 고려하지 못하고 제안했을 수 있으니, 프로덕트 모든 것을 포함한 해결책에 대해서 다시 판단하는 것이 PO의 전문성이다. UI를 변경제안하는 일이 우리 일이 아니고, 정말 중요하고 급한 것을 파악하는 것이 우리 일이니까,

2. 요구사항을 집요하게 파고들면서 사용자로서 현업의 불편함을 인지해야한다. 바이패스하면 모두 편할 것 같지만 PO는 계속 사용자의 입장을 분석할 기회를 잃는 것일 수도 있다.

3. 하나하나 개발이 진행할 문제에 대해서 필요성과 우선순위 검증이 없다면 괴로운 것은 개발이다. 백로그가 무지하게 쌓이면 개발자는 괴롭지 않을까. 개발리소스는 소중하니까,.의미있는 일을 하기 위한 기준 마련을 위해서는 이 과정이 필요하다.

다시 한번 강조하지만, 빠르게 들어오는 모든 요구사항을 다 들어주는게 능사가 아닐 때도 있다. 이야기를 듣다보면 근본적 문제가 있는데 해결할 수 없으니 궁여지책으로 낸 요청사항도 많으니까. 요구사항 너머의 니즈를 찾아야한다고 생각한다.

이런 이야기에 어떻게 다 알고 판단하냐며 불만이 가득해질 수도 있다. 하지만 모두에 대한 존중이 모두에 대한 책임전가가 되지 않는다는 장담할 수 있다면 그렇게 하자. '쟤네가 하자고 해서 하는 거다'라는 논리외에 말할 논리가 없다면 어느날 문제가 나타난다. 뭐하는 사람인지 스스로 의심이 되고 성장한계가 오고 어느날 본인에게 뭐하는 사람이냐는 질문이 온다.

 물론 역량의 한계는 있을 수 있다. 역량은 키워야지.

내 경험과 생각이 항상 옳지는 않겠지만, 비즈니스, 사용자, 개발, 디자인 모두 걸쳐서 지휘의 역할을 한다는 말의 의미에 대해서 계속 고민해야한다. 방향성이 맞으면 빠르게 하고, 모든 일에 중요도를 똑같이 두면 하나도 빠르게 할 수 없다..