수많은 요구사항을 매우 빡빡한 일정에 맞춰야 한다면

접근법을 달리하면 해결책이 보인다

제품 책임자라면 10명 중 10명 모두가 겪었을 상황.

이건 수많은 요구사항을 매우 빡빡한 일정에 맞춰 넣어야 하는 도전에 대한 글이다.

그래 도전적인 자세는 좋다. 그래서 당신이 소위 '고객이 필요한 모든 기능 A to Z'를 받겠다고 해도 말릴 생각은 없다. 하지만 당신이 제품 책임자로 있는 한 당신의 팀은 영원히 고통받는다에 내 전재산을(대출이 99%지만) 걸겠다.

드래곤 볼 속 '시간과 정신의 방'에서 개발하는 것이 아니라면, 시간은 우리의 편이 아님을 알 수 있다. 시간은 흐른다. 그리고 애자 일한 환경 속에 놓인 우리의 Market-Fit은 지금도 조준이 빗나가고 있다.

시간은 항상 촉박하다. 그런데 출근해서 우리를 기다리고 있는 것은 고객의 목소리를 빗댄 수많은 요구사항이다.  그래 시간은 언제나 문제였다. 하지만 시간을 붙잡거나 컨트롤할 수 없다.

그럼 접근법을 달리해야 한다. 요구사항을 집요하게 파고들어서 시간에 맞출 수 있는 크기로 잘라내야 한다.

 
Case #1
당신은 쏟아지는 요구사항에 의구심을 갖고 있는가? 영업팀 팀장님이 가져온 VOS 엑셀 시트의 수많은 목소리는 고객의 목소리임에는 틀림없을 것이다. 하지만 시간이 생명인 우리에게는 우선순위가 더 중요하다. 질문해야 한다. 그 시트에 1순위는 정말 1순위가 맞나? 그 불만을 해결하는 것이 우리 팀에 가장 중요한 손가락 하나가 될 수 있을까?

Case#2

오랜만에 대표가 말한다. '이건 정말 중요한 신사업입니다. 믿을 만한 PO가 당신뿐입니다. 지금 하고 계신 계획보다 선행해서 진행해야 합니다. 3Q까지 데모 가능한 시제품을 만들 수 있겠죠?'

리더의 권위로 Top-Down으로 내려오는 지시로 움직이는 회사가 아니라면, 이 순간 질문해야 한다.

그 신사업이 정말 지금 진행 중인 일보다 중요한지?  제품 책임자는 바로 나 자신이다. 너무 쉽게 비즈니스 차원의 긴급 건을 수용하게 되면 그 뒤는 치열한 전쟁뿐이다. 오히려 그 중요한 신사업이 본사업을 발목 잡는 함정(Big-Hole)이 될 수 있다.

Case#3

이번 시즌 요구사항을 담은 제품 기획문서가 나왔다. 기획자는 상세한 세부사항까지 놓치지 않은 자신의 능력에 감탄하고 있다. 하지만 소프트웨어를 만드는 사람들은 그 완벽한 문서를 모두 다르게 이해한다. 이건 문서를 만든 사람의 문제가 아니다. 다르게 이해한 개발자들의 문제도 아니다.
진짜 문제는 그 기획문서를 만드는데 너무 많은 시간과 돈을 썼다는 것이다. 그렇기에 사람들은 의심을 가질 여력이 없었다. 그대로 만들기에도 시간은 부족하니까. 나는 이것을 '나쁜 요구사항 기획문서'라고 불러본다. 이런 문서는 왜 만들어야 하는지에 대한 알맹이가 빠져있는 경우가 많기 때문이다. Why에 대한 답은 문제를 가진 사람과 해결해야 하는 사람 사이의 협업에서 나오기 때문이다.

그래서 기획자 한 사람이 며칠을 고생했더라도 함께 모여서 요구사항과 우선순위를 정의하지 않는다면 쓸 잘 데기 없는 문서를 만드느라 팀 전체가 홀딩된 것과 다름없다.

시간을 늘리거나 줄이지 말자. 그건 우리 통제 밖의 영역이다.
투입인력을 늘리는 것 역시 Plan B 정도일 뿐이다. (아무리 인원이 늘어도 할 일은 더 커질 뿐...)

결국 요구사항을 분석하고 질문하고 Why? 에 기반해서 우선순위를 함께 논의해야 한다.

그렇기에 거창한 문서는 필요 없다.

요구사항 백로그 리스트 하나와 어떤 소프트웨어를 만들지 함께 이야기할 동료들이면 충분하다.

그리고 모두가 동의할 수 있는 요구사항을 승인하면 그뿐이다.

이걸 지키지 못하면 결국 문제가 터진다.

- 거창한 요구사항 분석 문서를 만드느라 몇 주를 쓴다.

- 팀 동료들은 입은 굳게 닫은 채 제각각 흩어져 자신에게 일감이 떨어지기만을 수동적으로 기다린다.

- 마지막 최악의 상황은 아무도 Why를 모른 채로 개발하고 있는 상황이다.

승인되지 않은 작업들을 수행하는 것이다. 이건 회사 입장에서도 막대한 손해다.

 
또 한 번 쓰인 코드는 원복 비용이 곱절, 아니 곱 곱절은 될 것이다.
(누더기 코드를 마주 하고 싶지 않다면, 절대 코드부터 작성하지 말자)