중도 사양 확장의 종류와 납기 영향

개발 착수 후에는 기획 내용을 재검토하게 됩니다. 화면이 순차 개발되는 과정에서 기존 결정의 적합성을 다시 검토하는 경우가 발생합니다. 착수 시 확정한 사항이라도 실제 결과물을 확인하면 변경하고 싶은 부분이 발견됩니다.

그러나 변경 요청 시 비용 증가와 일정 지연을 우려하게 됩니다. 변경 가능 여부를 문의하는 것 자체를 부담으로 판단하기도 합니다. 이미 개발한 결과물을 번복한다고 판단하기 때문입니다.

결론적으로 개발 도중에 기획을 변경하는 것은 정상입니다. 다만 변경의 성격에 따라 결과가 크게 상이합니다.

정상적인 과정인 기획 변경

기획은 구상 단계의 결과이고, 개발은 이를 실제로 구현하는 과정입니다. 구상과 실제 결과물 사이에는 차이가 발생합니다.

화면 최초 확인 시 개선 방향을 발견하는 것은
기획의 오류가 아니라 기획이 구체화되고 있다는 의미입니다.

따라서 원활하게 운영되는 프로젝트는 변경 발생을 사전에 반영하여 설계합니다. 일괄 개발 후 최종 확인하는 방식이 아니라 중간 결과물을 확인하며 방향을 조정하는 구조를 적용합니다. 다만 문제가 되는 변경은 별도로 있습니다.

범위 확장형 변경의 위험

문제는 두 유형의 경계가 불명확한 경우가 많다는 점입니다. 선택 항목 1개 추가 요청은 단순 수정으로 판단되지만, 실제로는 검색 방식 전체를 변경해야 하는 경우도 있습니다. 발주처에는 소규모 요청이지만 개발사에는 대규모 작업이 됩니다.

이를 구분하지 않고 요청이 누적되면 일정은 지연되고 비용은 증가하며, 일정 지연의 원인을 확인하는 상황이 발생합니다.

변경 요청 전 확인 사항

변경을 요청하기 전에 다음 세 가지를 확인하십시오.

중간 확인 일정의 필요성

변경 부담의 실제 원인은 변경 자체가 아니라 현재 진척도를 모르는 상태에서 변경해야 한다는 점입니다.

개발 착수 후 1개월에서 2개월간 진행 보고 없이 결과물을 받으면 그 시점에 변경 요청이 일괄 발생합니다. 변경량이 증가하므로 비용이 증가하고 일정이 지연됩니다.

1개월 후 10건을 변경하는 방식보다
2주마다 2건에서 3건씩 조정하는 방식이 비용과 부담이 적습니다.

따라서 중간 확인 주기를 확정하는 것이 중요합니다. 1주 또는 2주 단위로 주기를 확정하여 현재까지 개발된 화면을 직접 확인하는 일정을 운영합니다. 이 구조가 있으면 변경 사항이 발생해도 소규모 단위로 조정할 수 있습니다.

흐름소프트가 정기 화면 확인 일정을 반드시 운영하는 이유입니다. 중간 단계마다 화면을 함께 확인하며 현재 상태를 유지할지와 변경할 대상을 확인합니다. 이 방식에서는 기획 변경이 일괄 번복이 아니라 단계별 방향 조정이 됩니다. 확인 시점에 범위 포함 여부도 바로 안내하므로 이후 예상하지 못한 비용 발생이 감소합니다.

요약

개발 도중의 기획 변경은 정상입니다. 실제 결과물을 확인하며 개선 방향을 발견하는 것은 일반적인 과정입니다. 다만 기존 범위 안의 수정과 범위 확장형 변경은 성격이 상이하며, 이를 구분하지 않으면 비용과 일정이 점진적으로 증가합니다.

변경 사항이 발생하면 범위 포함 여부를 우선 확인하고, 현 단계 필요성을 검토하고, 서면으로 기록하십시오. 이 판단을 소규모 단위로 반복할 수 있도록 중간 확인 주기를 확정하면, 기획 변경이 일정 차질이 아니라 결과물 개선 과정이 됩니다.

변경 절차를 계약서에 적는 방법은 변경 요청 처리 절차에, 범위에 포함되는지 구분하는 방법은 납품 범위 정하기에 정리했습니다.