SI 프로젝트 범위 산정을 기능 목록으로만 시작하면 거의 반드시 흔들립니다. 진짜 범위는 화면 수가 아니라 현재 업무 흐름을 어디까지 바꿀 것인지에서 결정됩니다.
"관리자 페이지, 대시보드, AI 상담, 견적 자동화"처럼 기능명을 나열하는 것은 쉽다. 하지만 그 기능이 어떤 사람의 어떤 반복 업무를 줄이는지 정하지 않으면 견적도 계약도 불안해진다.
기능 목록이 부족한 이유
기능 목록은 겉으로 명확해 보인다. 로그인, 회원관리, 게시판, 대시보드, 알림. 하지만 실제 구현에 들어가면 질문이 쏟아진다.
누가 로그인하는가. 어떤 권한이 필요한가. 대시보드의 숫자는 어디서 오는가. 알림은 이메일인가, 텔레그램인가. 게시판은 공개인가 내부용인가. 검수 기준은 무엇인가.
이 질문에 답하지 않으면 기능 하나가 여러 개의 과업으로 갈라진다.
범위 산정의 출발점
범위 산정은 현재 업무 흐름을 적는 것부터 시작해야 한다. 고객이 어디서 들어오고, 누가 확인하고, 어떤 자료를 만들고, 누가 승인하고, 어디에 저장하는지 본다.
그다음 병목을 찾는다. 응답 지연인지, 자료 누락인지, 견적 오류인지, 현황 공유 부족인지, 대표 보고 지연인지 구분해야 한다.
병목이 보이면 P1을 정할 수 있다. 이번 계약에서 반드시 해결할 첫 범위와, 이후 단계로 넘길 범위를 나누는 것이다.
과업정의서에 들어가야 할 것
좋은 과업정의서에는 화면 목록만 있지 않다. 사용자 역할, 주요 흐름, 포함 범위, 제외 범위, 검수 기준, 제공 자료, 일정, 운영비 기준이 들어간다.
특히 제외 범위가 중요하다. 이번 P1에서 하지 않는 것을 명확히 적어야 프로젝트가 건강하게 진행된다. "나중에 필요하면 별도 과업"이라고 정리하는 것이 서로에게 좋다.
SI 프로젝트는 계약 후에도 의사결정이 계속 생긴다. 그래서 문서와 클라이언트 대시보드에 결정 사항이 쌓여야 한다. 말로만 진행하면 기억이 달라진다.
studio.bth는 SI 프로젝트 범위 산정을 견적서 작성 단계로만 보지 않는다. 사장님의 업무 흐름을 시스템으로 바꾸기 위한 첫 설계 단계로 본다.
같이 읽으면 이어지는 글
- 비즈니스 설계 없이 개발하면 벌어지는 일: 개발 전 설계가 필요한 이유다.
- 소통 비용이 프로젝트를 죽인다: 결정 사항이 흩어질 때 생기는 비용이다.
- 홈페이지 외주 계약서: 계약 범위를 문서화하는 기준이다.
- 비즈니스 문서 외주 비용: 문서 설계와 디자인 비용의 차이다.