- 맥킨지가 2012년 분석한 대규모 IT 프로젝트에서 일정은 평균 45% 초과됐습니다. 개발 중 요구사항 변경이 가장 빈번하게 지목된 원인이었습니다.
- 요구사항이 바뀌는 것은 기획 깊이의 문제가 아닙니다. 기획 단계에서 어떤 결정을 내려야 하는지, 어떤 결정은 개발 중에 내려도 되는지를 조직이 합의하지 않아서입니다.
- 기획-개발 경계는 문서 완성도가 아니라 결정 완료 여부로 정의됩니다. 개발 착수 전 체크리스트가 없으면 결정은 계속 뒤로 밀립니다.
요구사항 변경이 일정을 두 배로 만드는 구조
맥킨지 글로벌 인스티튜트가 2012년 발표한 대규모 IT 프로젝트 분석 보고서는 5,400개 이상의 프로젝트를 검토했다. 일정 초과가 평균 45%였고 예산 초과가 평균 7%였다. 일정이 늘어나면서 인건비가 함께 늘었기 때문에 예산 초과가 따라왔다. 일정 지연의 원인으로 가장 빈번하게 언급된 것은 '개발 단계에서 발생한 요구사항 변경'이었다.
이 현상은 기획팀의 역량 문제로 귀결되는 경우가 많다. 실제로는 구조 문제다. 많은 조직에서 기획과 개발의 경계는 문서 양으로 결정된다. 문서가 충분히 두꺼워지면 개발을 시작한다. 그런데 어떤 결정이 기획 단계에서 완료돼야 하는지, 어떤 결정은 개발 과정에서 내려도 되는지 합의가 없다. 결정이 빠진 채로 개발이 시작되고, 개발 도중 그 결정을 내려야 하는 시점이 오면 요구사항 변경이 발생한다.
배리 뵘(Barry Boehm)이 1981년 정리한 소프트웨어 비용 모델에 따르면, 요구사항 변경의 비용은 발견 시점에 따라 크게 달라진다. 기획 단계에서 발견해 수정하는 비용이 1이라면 개발 단계에서는 10배, 테스트 단계에서는 수십 배로 늘어난다. 요구사항 변경을 개발 단계로 미루는 것은 수정 비용을 크게 키우는 것이다.
기획 단계에서 결정하지 않고 넘어가는 세 가지 유형
첫 번째는 예외 처리 결정이다. 주요 사용 흐름은 기획 단계에서 정리되지만, 사용자가 오류를 냈을 때, 데이터가 없을 때, 권한이 없을 때 어떻게 처리할지는 '개발하면서 정하자'고 넘어간다. 이 결정들이 개발 단계에서 한꺼번에 몰리면 작은 결정 하나하나가 기획팀과의 협의를 필요로 하게 된다.
두 번째는 이해관계자 합의 결정이다. 영업팀과 운영팀이 같은 화면을 다르게 사용하는 경우, 누구의 요구를 우선할지 결정하지 않고 개발이 시작된다. 개발 도중 두 팀 중 한 팀에서 요구사항 변경을 요청하면, 이미 만들어진 부분을 수정해야 한다.
세 번째는 성능 기준 결정이다. 동시 사용자 수용 규모와 응답 속도 기준을 정하지 않고 개발에 들어간다. 성능 기준이 없으면 개발자는 임의의 기준으로 설계하고, 출시 전 테스트에서 기준이 정해지면 전체 구조를 바꿔야 하는 상황이 생긴다.
기획-개발 경계를 명확히 하는 방법
가장 단순한 방법은 '개발 착수 체크리스트'를 만드는 것이다. 이 기능의 개발을 시작하기 전에 반드시 결정돼야 하는 항목들을 명시한다. 체크리스트의 모든 항목이 결정됐을 때만 개발을 시작할 수 있다는 원칙을 조직이 지키면, 개발 중 요구사항 변경의 상당수가 줄어든다.
Ahn Partners 판단: 기획-개발 경계 문제를 다루는 조직에서 효과적인 것으로 관찰한 것은 '결정 로그'입니다. 기획 과정에서 내린 결정과 그 결정의 근거를 기록해 두면, 개발 도중 요구사항 변경 요청이 왔을 때 기존 결정과 충돌하는지 즉시 확인할 수 있습니다. 변경 요청이 기존 결정과 충돌하면, 변경의 비용을 인식하고 의사결정권자가 판단하는 구조를 만들 수 있습니다.
한 문장으로 정리하면, 요구사항이 개발 중에 바뀌는 것은 기획이 덜 된 것이 아니라 기획이 끝나는 시점을 조직이 합의하지 않았기 때문이다. 개발 착수 전에 무엇을 결정해야 하는지 목록을 만드는 것이 가장 빠른 첫 번째 해결책이다.
점검 목록
- 가장 최근에 완료한 개발 프로젝트에서 개발 착수 이후 요구사항 변경이 몇 건이었는가
- 개발을 시작하기 전에 반드시 결정돼야 하는 항목이 명문화돼 있는가
- 기획 단계에서 내린 결정과 그 근거가 문서로 남아 개발 도중 참조할 수 있는가