⚖️ 스펙 추가를 보는 두 가지 시선

“범위는 늘어나지 않는다. 이해가 깊어질 뿐이다. 전통적인 소프트웨어 개발 방식에서는 개발 기간을 산정하고 출시일을 정해 개발을 진행하던 중 새로운 것이 드러나면 이를 은밀한 범위 확장(scope creep)이라고 한다. 개인적으로는 개발 범위가 확장된 것이 아니고 이해가 더 깊어진 것이라고 생각한다. … 사람들이 이해하던 내용에서 맹점을 찾아낸 것이다.” - 제프 패튼, , 백미진, 허진영 옮김. 인사이트, 2018. 최근에 진행하던 프로젝트에서 새롭게 발견된 요구사항을 추가할 것인지를 두고 실무 기획자랑 대화할 기회가 있었습니다. 이 판단을 두고 두 가지 생각이 들었어요. ‘스펙을 추가하자고 하면 디자인이든 개발이든 안 좋아할 게 뻔한데.. 나중에 생각할까..’ ‘헐 이걸 몰랐네. 이게 안 되면 사용자는 혼란스러울 텐데.. 넣자고 설득할까..’ 1️⃣ 전자는 스펙 추가를 ‘미흡한 기획’, ‘스프린트 계획의 구멍’으로 보는 시선이었습니다. 팀은 스프린트(가 됐든 다른 어떤 형식이든) 계획에 상당한 공을 들였으니 그걸 건드리고 싶지 않아 합니다. 기획에서도 오류를 인정하기 쉽지 않고요. 그래서 PM은 해당 스펙을 다음 이터레이션을 넘깁니다. 2️⃣ 후자는 스펙 추가를 ‘이해의 확장’으로 보는 시선이었습니다. 모든 계획은 현실에 들어가야 평가가 가능해집니다. 사용자에게 제공하려는 가치를 붙잡고 고민을 더해갈 때, 처음에는 몰랐던 핵심적인 요소가 발견될 수 있습니다. 릴리즈를 했을 때 제품의 viability를 저해할 만한 요소라면 스펙은 추가될 수 있다고 봅니다. 저는 후자의 관점을 취하기로 하고, 그 요구사항을 천천히 평가해 봤습니다. 우리 제품의 비즈니스 목표와 그것을 달성하기 위한 제품의 MVP에 해당하는 것일까 생각해 봤습니다. 그렇다는 확신이 들었고 해당 스펙을 추가하기로 협의를 했습니다. 계획되지 않은 스펙의 추가는 물론 내 실수일 수도 있지만😅 이해의 확장일 수 있다는 걸 알고 나니 조금 더 당당한 느낌으로?