범위 관리 이야기
범위의 확장은 목숨 걸고 방어하자.
범위의 확장 즉, 추가 요구사항은 프로젝트를 진행하면서 다반사로 발생하는 일이다. 우리나라 IT 프로젝트의 환경에서 범위 확장을 방어하기는 결코 쉬운 일이 아니다. 나 또한, 범위의 확장으로 인해 고생했던 기억이 너무 많다. 고객은 당연하다는 듯이 추가적인 요구사항을 얘기하기 마련이고, 범위가 확장되면 당연히 원가가 상승하고 일정은 지연될 수밖에 없다. PMBOK에서는 범위 관리에 대해 "해야 할 일을 하되, 해야 할 일만 한다."라고 되어있다. 말은 쉽지만, 그게 어디 쉬운가.
그렇다면, 범위 관리를 잘하려면 어떻게 해야 할까?
첫 번째, PM은 사업 초반에 "사업의 내용과 고객의 비즈니스"에 대해 완전히 파악해야 한다.
사업 초반이라는 것은 적어도 1개월 이내의 기간을 말한다. 사실 1개월도 늦을 수 있다. 고객은 이미 그 비즈니스를 수행하고 있으므로, 그 비즈니스에 대한 전문가라고 봐야 하기 때문이다. 따라서, 되도록 프로젝트를 수행할 PM이 제안 작업에까지 참여하여 고객의 비즈니스에 대해 미리 파악하는 것이 좋을 것이다.
사업의 내용이 너무 방대하고, 고객사의 비즈니스 복잡도가 심하여 제대로 파악이 어려운 경우, 범위 관리에 실패할 가능성이 다분히 존재한다. 그렇기 때문에 더더욱 해당 분야의 경험이 풍부한 PM일수록 유리하며, 대체로 금융/국방/의료 등과 같이 업무의 특수성과 복잡성이 클수록 전문화되는 경향을 보이는 것 같다.(ㅇㅇ분야 전문 PM이라는 이름으로...) General 한 관리업무로 생각되기 쉬운 PM도 전문성이 더해진다면 유리한 것은 당연하다.
사업내용과 고객 비즈니스가 어느 정도 파악이 된 이후에야 고객의 갑작스러운 요구사항이 계약된 사업의 범위에 포함되어있는 것인지, 완전히 벗어나는 것인지, 아니면 어느 정도 걸쳐있는 내용인지 걸러낼 수 있을 것이고, 그 이후에야 대응방안을 결정할 수 있다.
프로젝트가 너무 크거나, 난이도가 높은 경우에는 해당 분야의 경험이 풍부한 인력을 PL로 투입시켜, 해당 인력에게 의존할 수도 있을 것이다. 하지만, 고객 요구에 즉시 대응하지 못하는 PM은 그만큼 리스크를 안고 가는 것이라고 생각한다. 그러므로, 최대한 빨리 모든 범위를 파악할 필요가 있다.
두 번째, 자사 제품의 장단점과 한계를 명확히 알고 있는 상태에서 착수시점의 버전에서 더 이상의 제품 개선은 없다는 것을 전제로 방어해야 한다.
자사 제품이 원래의 사업범위에 포함된 요구사항 중 일부를 충족하지 못하는 경우도 있을 수 있다. 또한, 그 기능이 제품의 공통기능이어서, 프로젝트팀에서 커스터마이징이 불가능한 경우도 있을 것이다. 그럴 경우, 내부적으로는 이슈화시켜 연구소나 제품개발팀에 기능 개발을 요청해야겠지만, 그것마저도 여의치 않을 수 있다. 해당 기능이 일반적으로 사용될만한 기능이 아니라면 제품 개발을 하는 입장에서는 굳이 제품에 포함시키고 싶지 않을 것이기 때문이다. 또한, 제품 차원에서 해당 기능이 개발이 되어서 적용된다 하더라도 내가 진행하는 프로젝트가 해당 기능의 첫 번째 마루타일 필요는 없지 않은가.
그런 경우, 일단은 해당 요건을 요구사항에 포함시킨 고객의 진의를 파악해 보아야 한다. 실제로 확인해보면 의외로 고객이 별생각 없이 넣어놓은 요구사항일 경우가 많다. 고객의 의도를 파악하였고, 정말로 필요한 기능이어서 요구사항에 포함된 것이라면 현재 제품의 기능으로 구현 가능한 형태를 대안으로 제시하고, 요구사항 정의서에 명시하여 고객의 승인을 받아내도록 노력하자. 모든 추가 요구사항을 그와 같이 정리하기는 어려울 수도 있겠지만, 그렇다고 정리하지 않고 구현상의 이슈가 있는 항목을 놔두면 절대로 안될 말이다. 구현 형태를 명확히 정리되지 않은 요구사항은 검수 단계에서 항상 문제가 된다.
너무나도 핵심적이고 필수적인 요구사항이고, 대안으로 제시한 방안에 대해서도 고객이 만족하지 못하여 끝끝내 잘라내지 못한 경우에는 프로젝트 기간중에 개발이 되면 다행이겠지만, 그렇지 못한 경우에는 대체로 조건부 검수로 하여 프로젝트 종료 이후에 개발해주기로 한다거나, 제품 차기 버전에 포함하기로 협의하고 마무리 할 수 밖에 없을 것이다. 그런 경우라도 실제로 처음 적용 시에는 언제든 버그 발생의 위험이 있으며 사업 종료 이후에도 계속해서 끌려다닐 수 있는(끝나도 끝난 것이 아닌 상태인...) 단초가 되는 것이다. 따라서, 회사에서 능력 있는 PM으로 자리매김하기 위해서라도 고객의 요구사항을 현재의 제품 기능으로 방어하기 위해 최선을 다해야 한다.
세 번째, 즉시 답변할 것과 파악한 후 대응할 것을 구분하자.
고객과 미팅 중에라도 언제든 추가 요구사항은 튀어나올 수 있다. 모든 답변을 즉시 할 수 있는 준비가 되어있더라도, 정말 확실하거나, 너무나도 기본적인 사항 외에는 일단은 파악 후에 대응하는 것이 좋다. 일단은 수첩에 잘 적어두었다가 하루 정도의 시간을 갖고 대응논리 등을 만들어서 정리하여 완곡한 표현으로 회의록(또는 이슈검토보고서 등)을 적어서 고객에게 제출하자. 해당 문서는 출력하여 고객의 사인을 받으면 가장 좋겠지만, 메일로 보내 놓는 것만으로도 일단은 기록이 남는 것이고, 추후에 다시 고객이 요구할 경우 대응할 수 있는 근거가 되기 때문이다.
반대로, 기술적으로 가능할 것 같다는 말을 고객은 추가요구사항을 수용한 것으로 받아들일 수 있다. 그냥 툭 던지든 가볍게 물어본 내용이라도 섣불리 된다고 얘기했다가, 나중에 고객이 된다고 하지 않았느냐 라고 얘기할 수 있으니, 되도록 즉답은 피하는 것을 습관으로 들여야 한다.
