고정가 계약과 투입 정산 계약 가운데 무엇을 고를 것인가 하는 문제는 대개 리스크에 관한 선택으로 설명됩니다. 그 설명 자체는 옳지만, 바로 다음 단계에서 잘못 다뤄집니다. 발주사와 수행사 모두 리스크가 자리를 옮길 뿐이라는 사실을 잊고, 어느 한쪽을 고르면 리스크가 사라진다고 가정하기 때문입니다.

리스크는 사라지지 않습니다. 고정가 방식에서는 견적이 틀릴 위험을 공급사가 떠안고, 그 위험을 제시 금액 안에 미리 얹어 둡니다. 투입 정산 방식에서는 같은 위험을 발주사가 떠안습니다. 질문은 어느 쪽이 불확실성을 없애 주느냐가 아닙니다. 어느 쪽이 그 불확실성을 더 잘 다룰 수 있는 위치에 있는가, 그리고 위험을 넘기는 값을 치를 만한가입니다.

어느 쪽이 통할지 미리 알려 주는 시험: “완료”가 무엇을 뜻하는지, 두 사람이 그 상태에 도달했는지 여부를 두고 같은 판단을 내릴 만큼 자세히 적을 수 있습니까? 적을 수 있다면 고정가 계약은 쓸 수 있는 선택지이며 대체로 합리적입니다. 적을 수 없다면 고정가 계약은 모호함을 없애 주지 않습니다. 앞으로 생길 모든 이견을 기술적 대화가 아니라 상업적 협상으로 바꿔 놓을 뿐입니다.

고정가 계약이 실제로 사주는 것

청구서 금액에 대한 확실성, 그것 하나뿐입니다. 특히 결과물의 내용, 일정, 품질에 대한 확실성은 사주지 않습니다. 구매자들은 이 세 가지가 묶여서 따라온다고 생각하지만 실제로는 그렇지 않습니다.

여기에는 값도 붙습니다. 고정가로 견적을 내는 공급사는 초과분을 스스로 떠안기 때문에 반드시 예비비를 얹습니다. 그 예비비의 크기는 요구사항이 모호할수록 커집니다. 범위가 잘 정의된 일이라면 예비비는 소박한 수준에 머무릅니다. 느슨하게 기술된 일이라면 작업 자체의 비용에 근접할 수도 있으며, 위험이 실제로 터지든 터지지 않든 발주사는 그 금액을 지불합니다.

두 번째 비용은 행동에서 나타납니다. 금액이 고정되는 순간부터 모든 모호함은 일을 덜 하는 방향으로 정리됩니다. 이제 공급사의 이익이 그쪽에 있기 때문입니다. 이는 나쁜 의도가 아니라 계약이 스스로 만들어 낸 유인입니다. 구현 도중에 더 나은 방법을 발견한 공급사에게는 그것을 꺼낼 이유가 없고, 요구사항이 잘못됐다는 것을 깨달은 발주사 앞에 놓이는 것은 대화가 아니라 변경 요청서입니다.

고정가는 경계가 진짜로 그어지는 일에서 잘 작동합니다. 출발지와 목적지가 알려진 마이그레이션, 문서가 갖춰진 API와의 연동, 합의된 디자인에 따라 만드는 정해진 화면 묶음 같은 것들입니다. 반대로 탐색적인 성격이 조금이라도 있는 일에서는 형편없이 작동합니다.

투입 정산이 더 저렴해지는 경우

직관과 달리 그런 경우는 자주 있습니다. 예비비를 내지 않고, 변경 요청을 처리하는 비용도 내지 않기 때문입니다.

범위가 정당한 이유로 바뀌게 될 일에 어울립니다. 방향이 사용자의 실제 행동에 달려 있는 첫 버전, 아무도 문서를 남기지 않은 시스템과의 연동, 열어 보기 전에는 상태를 알 수 없는 코드베이스의 구조 작업 같은 것들입니다. 이 모든 경우에 고정가란 사실상 추측에 붙인 확정 금액입니다.

이 방식이 발주사에 요구하는 것은 관심입니다. 참여 없는 투입 정산은 끝이 열린 청구서가 됩니다. 전형적인 실패는 지난주에 무엇이 나왔는지 아무도 묻지 않는 채 몇 달씩 굴러가는 프로젝트입니다. 통제는 계약 조항이 아니라 운영에서 나옵니다. 눈에 보이는 백로그, 일정한 간격의 시연, 그리고 우선순위를 바꿀 권한을 가진 발주사 쪽 담당자, 이 세 가지입니다.

그 관심을 낼 사람이 조직 안에 없다면 솔직하게 말하는 편이 낫습니다. 투입 정산은 잘 굴러가지 않을 것이고, 어떤 조항도 이를 고쳐 주지 못합니다.

대부분의 프로젝트가 택해야 할 세 번째 방식

상한을 두거나 단계로 나눈 계약입니다. 앞의 두 가지 어느 쪽도 아니면서, 실제로는 둘 중 어느 것보다 더 많은 소프트웨어 작업에 맞습니다.

상한 있는 투입 정산. 작업은 시간으로 청구하되 합의된 상한을 둡니다. 발주사는 방향을 바꿀 유연성을 유지하고, 공급사는 상한을 넘어서는 잔여 위험을 떠안습니다. 양쪽 모두에게 효율을 높일 이유가 남는데, 이는 순수한 두 모델 어느 쪽도 만들어 내지 못하는 성질입니다.

단계별 고정가. 짧고 유상인 분석 단계가 요구사항 명세를 만들고, 그 뒤에야 구축 단계가 실재하는 대상을 놓고 고정가로 견적됩니다. 이것이 고정가의 정직한 형태입니다. 견적이 미지의 요소를 줄인 뒤에 나오기 때문입니다. 그 명세에 무엇을 담아야 하는지는 소프트웨어 제안요청서 작성 안내에서 다룹니다.

증분 단위 고정가. 각 단계를 따로 견적하고 따로 합의합니다. 예산 예측 가능성을 조각 단위로 얻으면서 멈출 권리가 남습니다. 멈출 권리는 발주사가 가진 가장 값진 권리이며, 긴 고정가 계약이 정확히 그것을 가져갑니다.

공통점은 하나입니다. 일부라도 작업이 진행된 뒤에는 견적 정확도가 비교할 수 없을 만큼 좋아진다는 사실입니다. 그 사실을 활용하도록 상업적 구조를 짜는 일은 어떤 조항보다 값집니다.

고정가 프로젝트가 실제로 무너지는 지점

금액이 아닙니다. 범위와 변경 사이의 경계입니다.

모든 고정가 프로젝트는 변경 요청을 만들어 냅니다. 명세가 누군가 그것을 써 보기 전에 작성되기 때문입니다. 계약의 건강 상태는 그 요청들을 어떻게 다루느냐에 전적으로 달려 있고, 그것은 시작 시점에 범위를 얼마나 정밀하게 정의했느냐로 결정됩니다. 누군가의 선의로 결정되는 것이 아닙니다.

마찰을 줄이는 방법은 두 가지입니다. 변경이 생겼을 때 무슨 일이 벌어지는지 문서로 합의하십시오. 누가 평가하는지, 어떤 근거로 값을 매기는지, 얼마 만에 처리하는지입니다. 그리고 발주사 쪽에도 예비 예산을 두십시오. 발주사에 변경 예산이 없는 고정가 계약은 새로운 발견이 나올 때마다 말다툼을 만들어 냅니다.

또 하나 흔한 실패는 검수입니다. 완료를 어떻게 증명하는지 계약이 정하지 않으면 마지막 대금은 의견 다툼이 됩니다. 검수 기준을 범위 옆에 나란히 적고, 누군가 판단해야 하는 기준보다 누군가 시험할 수 있는 기준을 택하십시오.

실무에서 고르는 법

진짜로 모르는 것이 무엇인지 물으십시오. 답이 거의 없다면 고정가는 합리적이며, 그 확실성의 대가로 예비비를 낼 각오를 해야 합니다. 모르는 것이 아주 많다면 고정가는 기술적 불확실성을 상업적 마찰로 바꿔 놓을 뿐입니다.

다음으로 무엇을 챙겨볼 수 있는지 물으십시오. 투입 정산은 관심에 보답하고 무관심을 벌합니다. 고정가는 매주 요구하는 것이 적은 대신 초반, 즉 명세 단계에서 훨씬 많은 것을 요구합니다. 그 단계의 실수는 비용은 싸지만 알아채기는 더 어렵습니다.

그리고 확실성이 얼마짜리인지 물으십시오. 이사회가 숫자 하나를 필요로 하는 상황은 실제로 있고, 그때 예비비는 정당한 값입니다. 이것은 고정가를 고르는 타당한 이유이며, 고정가가 리스크를 없애 준다고 믿는 것보다 훨씬 나은 이유입니다.

Mecanik은 소프트웨어 개발 서비스의 일부로 세 가지 방식을 모두 운영하며, 가장 자주 권하는 것은 단계로 나눈 형태입니다. 두 주간의 분석을 거쳐 나온 견적은 그 전에 나온 견적보다 양쪽 모두에게 더 값집니다.

자주 묻는 질문

고정가 계약이 투입 정산보다 안전한가요? 더 예측 가능할 뿐, 안전한 것과는 다릅니다. 고정가는 견적 리스크를 공급사에 넘기고, 공급사는 그 리스크를 예비비로 금액에 반영하므로 리스크가 터지든 아니든 발주사가 그 값을 냅니다. 청구서 금액에 대한 확실성을 살 뿐, 결과물이나 일정이나 품질에 대한 확실성을 사는 것은 아닙니다.

투입 정산이 더 싼 경우는 언제인가요? 범위가 정당한 이유로 바뀌게 될 때입니다. 방향이 사용자 행동에 달린 첫 버전, 문서가 없는 시스템과의 연동, 열어 보기 전에는 상태를 알 수 없는 코드베이스 작업이 여기에 해당합니다. 이런 경우에는 예비비와 변경 요청 처리 비용을 모두 피할 수 있습니다. 여기서의 고정가는 결국 추측에 붙인 확정 금액이기 때문입니다.

상한 있는 투입 정산이란 무엇인가요? 시간으로 청구하되 합의된 상한을 두는 방식입니다. 발주사는 방향을 바꿀 유연성을 유지하고 공급사는 상한을 넘는 위험을 떠안습니다. 양쪽 모두에게 효율을 높일 이유가 남으며, 순수한 고정가도 순수한 투입 정산도 이것을 만들어 내지 못합니다.

고정가 소프트웨어 프로젝트는 왜 어긋나나요? 거의 언제나 금액이 아니라 범위와 변경의 경계에서 어긋납니다. 명세는 누군가 소프트웨어를 써 보기 전에 작성되므로 변경 요청은 불가피합니다. 건강 상태는 누가 변경을 평가하고 어떻게 값을 매길지 미리 합의했는지, 그리고 발주사가 자체 예비 예산을 들고 있는지에 달려 있습니다.

검수 기준을 계약서에 넣어야 하나요? 넣어야 합니다. 범위 옆에 나란히 적으십시오. 완료를 보여 줄 방법이 정해져 있지 않으면 마지막 대금은 의견 다툼이 됩니다. 누군가 판단해야 하는 기준보다 누군가 시험할 수 있는 기준을 택하십시오. 시험 가능한 기준은 이견을 끝내고, 판단에 기대는 기준은 이견을 늘립니다.