소프트웨어 제안요청서, 즉 RFP는 원래 여러 공급업체를 나란히 놓고 비교할 수 있게 만드는 문서입니다. 그런데 실제로 오가는 문서 대부분은 정반대의 결과를 냅니다. 해법을 지나치게 자세히 지정해 답변의 폭을 묶어 놓으면서, 정작 가격을 산출하는 데 누구에게나 필요한 정보는 빠뜨리기 때문입니다. 그 결과 자릿수가 하나 차이 나는 다섯 개의 견적이 나란히 도착하고, 형식상으로는 모두 요구에 응답했지만 같은 것을 재고 있는 견적은 하나도 없습니다.

흔한 진단은 공급업체가 말을 흐린다는 것입니다. 가끔은 사실입니다. 그러나 훨씬 더 자주 벌어지는 일은, 문서가 그 안에 담긴 내용만으로는 도출할 수 없는 숫자를 요구했고 각 업체가 그 빈칸을 저마다 다른 가정으로 채웠다는 것입니다. 가정이 다르면 금액이 달라지는 것은 당연하며, 여기에 정직성 문제는 끼어들지 않습니다.

당신의 RFP가 작동할지 가려내는 시험: 서로 다른 두 공급업체가 이 문서를 읽고 실질적으로 같은 범위에 도달할 수 있습니까? 문서에 ‘사용자 관리’라고만 적혀 있고 역할이 몇 개인지, 권한이 레코드 단위로 달라지는지, 기존 디렉터리와 연동해야 하는지가 없다면 한 곳은 일주일로, 다른 곳은 두 달로 견적합니다. 둘 다 정직하게 답한 것입니다. 그리고 당신은 그 둘을 비교할 수 없습니다.

기능 목록이 잘못된 출발점인 이유

기능 목록은 당신이 무엇을 결정했는지를 공급업체에 알려 줄 뿐, 당신에게 무엇이 필요한지는 알려 주지 않습니다. 이것이 문제가 되는 이유는 그 결정 자체가 틀렸을 수 있고, 그 사실을 알아본 사람에게는 당신이 강제한 문서 구조 안에서 그것을 말할 자리가 없기 때문입니다.

게다가 기능 목록은 비용을 움직이는 정보를 가립니다. 소프트웨어에서 공수는 성가신 부분에 몰립니다. 외부 시스템에 몇 개나 연결해야 하는지, 기존 데이터를 얼마나 이관해야 하고 그 상태가 얼마나 깨끗한지, 권한이 서로 다른 사용자 유형이 몇 가지인지, 그리고 지켜야 할 규제 의무가 무엇인지입니다. 기능 목록은 얼마든지 길어질 수 있지만, 그 길이 안에 이런 항목이 하나도 없는 경우가 태연히 벌어집니다.

대안은 모호함이 아닙니다. 문제를 정확히 기술하고, 정말로 고정된 제약만 밝히고, 접근 방식에 대한 설명은 제안서 쪽에 맡기십시오. 돌아오는 답은 서로 다르겠지만, 그 차이는 잡음이 아니라 판단 재료가 됩니다. 어디에서 의견이 갈렸는지가 곧 검토해야 할 쟁점 목록이 되기 때문입니다.

소프트웨어 RFP에 실제로 담아야 할 것

비즈니스 문제와 성공의 정의. 지금 무슨 일이 벌어지고 있는지, 대신 무엇이 벌어져야 하는지, 그리고 그것이 통했다는 것을 무엇으로 알 것인지. 공급업체는 이 대목을 근거로 범위 자체에 이의를 제기하며, 이 단계에서 그들이 해 줄 수 있는 가장 값진 일이 바로 그것입니다.

규모와 수량을 숫자로. 사용자 수, 거래 건수, 레코드 건수, 예상 성장. 이것만 적어도 견적 편차의 큰 몫이 사라집니다.

연결해야 하는 시스템을 고유명으로 적고, 각각에 문서화된 API가 있는지 한마디 덧붙이십시오. 문서가 없는 레거시 연동 하나가 나머지 전부를 합친 비용을 넘어설 수 있습니다.

이미 가지고 있는 데이터. 양은 얼마이고, 어디에 있으며, 상태는 어떤지. 이관은 어느 프로젝트에서든 어김없이 가장 과소평가되는 항목입니다.

정말로 고정된 제약. 규제 의무, 지정된 호스팅 위치, 이미 쓰고 있는 인증 공급자, 움직일 수 없는 일정. 어느 것이 절대 조건이고 어느 것이 선호인지 구분해 적으십시오. 절대 조건은 공급업체가 방어적으로 가격을 매기는 대상이기 때문입니다.

요청하지 않는 것. 대상 밖을 명시적으로 적어 두는 것은 견적 편차를 줄이는 가장 값싼 방법 중 하나입니다.

예산 범위. 감춘다고 가격이 내려가지 않습니다. 아무도 모르는 예산에 맞춰 범위를 잘라 낸 제안이 모이고, 그다음에 다시 만들어야 할 뿐입니다. 범위를 밝히면 그 안에서 무엇이 가능한지 공급업체가 먼저 말해 줍니다. 금액 구간별로 무엇을 살 수 있는지는 맞춤형 소프트웨어 개발 비용 가이드에 정리해 두었습니다.

공급업체를 갈라놓는 질문

질문은 수를 줄이고 질을 높이십시오. 다음 질문들은 백 줄짜리 준수 항목표보다 더 많은 것을 드러냅니다.

무엇을 먼저 만들겠습니까, 그리고 왜 그렇습니까? 착수 순서에는 상대가 문제를 이해했는지, 아니면 문서만 이해했는지가 드러납니다.

여기서 가장 위험한 부분은 무엇이고 어떻게 줄이겠습니까? 실재하는 위험을 짚어내는 공급업체가 위험이 없다고 보고하는 공급업체보다 믿을 만합니다.

구체적으로 누가 이 일을 합니까? 이름, 경력 수준, 그리고 그들의 시간 중 몇 할을 쓰는지. 제안서를 쓴 사람이 구현에 참여하지 않는 것은 익숙한 실망입니다.

범위가 바뀌면 어떻게 됩니까? 범위는 반드시 바뀝니다. 그 답에는 압박이 걸렸을 때 이 관계가 어떻게 작동하는지가 담겨 있으며, 이것은 일당 단가보다 중요합니다.

저희에게서 무엇이 필요합니까? 프로젝트는 공급업체의 역량 부족만큼이나 자주 발주사 쪽 인력이 확보되지 않아 실패합니다. 그것을 말하는 공급업체는 파는 대신 현실을 설명하고 있는 것입니다.

끝났을 때 무엇이 저희 것이 됩니까? 소스 코드, 인프라, 각종 계정, 데이터. 이것은 선정 이후가 아니라 선정 이전에 문서로 확인하십시오.

응답을 읽는 법

가장 싼 견적은 대개 효율이 가장 좋다는 뜻이 아니라 범위를 가장 좁게 해석했다는 뜻이며, 그 차이는 작업이 시작된 뒤 변경 요청이라는 형태로 드러납니다.

각 업체가 어디에 공을 들였는지 보십시오. 연동과 데이터 이관에 분량을 쓴 제안서는 난이도가 어디에 있는지 이해한 것입니다. 방법론과 조직도와 팀 사진에 분량을 쓴 제안서는 문제 자체와 마주하지 않은 것입니다.

요청하지 않은 반론은 좋은 신호로 다루십시오. 범위의 일부가 불필요하다고 말하는 공급업체, 또는 당신이 내건 제약이 그 값어치보다 더 큰 비용을 부른다고 지적하는 공급업체는 당신이 정말 원하는 일을 하고 있는 것입니다. 무엇에나 동의하는 공급업체는 읽기는 편하지만 함께 일하기는 나쁩니다.

그리고 모든 견적이 같은 질문에 답하고 있는지 확인하십시오. 두 견적이 세 배 차이가 난다면 그중 하나는 문서에 없던 무언가를 가정한 것이며, 그것이 무엇인지 알아내는 편이 어떤 평가표보다 유용합니다.

RFP를 내지 말아야 할 때

일이 작거나, 탐색적이거나, 무엇이 필요한지 아직 모른다면 RFP는 잘못된 도구입니다. 양쪽 모두에게 몇 주를 쓰게 하고 정밀하다는 잘못된 인상만 남깁니다.

그런 경우에는 유료 디스커버리가 대개 더 낫습니다. 짧은 기간에 이후 시장에 들고 나갈 수 있는 명세서를 만들거나, 아니면 애초에 만들 가치가 없다는 결론을 내는 것입니다. 어느 쪽 결과든 아무도 정의하지 못한 범위를 놓고 경쟁을 붙이는 것보다 낫습니다. 범위를 좁히는 요령은 MVP 소프트웨어 개발 가이드의 방식이 그대로 적용됩니다.

Mecanik은 소프트웨어 개발 업무의 일부로 RFP에 응답하기도 하고, 조직이 RFP를 쓰는 것을 돕기도 합니다. 좋은 견적을 이끌어 내는 문서는 예외 없이 더 짧은 쪽이며, 그 안에 실제 숫자가 들어 있습니다.

자주 묻는 질문

소프트웨어 RFP에는 무엇을 담아야 합니까? 비즈니스 문제와 성공의 정의, 실제 숫자로 표시한 규모와 수량, 연동해야 하는 시스템의 고유명과 각각에 문서화된 API가 있는지 여부, 이관 대상 데이터의 상태, 어떤 제약이 정말로 고정되어 있는지, 무엇이 명시적으로 범위 밖인지, 그리고 예산 범위입니다.

RFP에 예산을 적어야 합니까? 적어야 합니다. 감춘다고 가격이 내려가지 않고, 아무도 모르는 예산에 맞춰 잘라 낸 제안이 모인 뒤 다시 만들어야 합니다. 범위를 밝히면 그 안에서 현실적으로 무엇이 가능한지 공급업체가 답할 수 있고, 응답끼리 비교가 가능해집니다.

같은 소프트웨어인데 견적이 이렇게까지 차이 나는 이유는 무엇입니까? 대개 문서가 빈칸을 남겼고 각 업체가 그것을 서로 다른 가정으로 채웠기 때문입니다. ‘사용자 관리’라는 한 줄만으로는 역할 수도, 레코드 단위 권한도, 디렉터리 연동 여부도 알 수 없으므로 일주일로도 두 달로도 정직하게 견적할 수 있습니다. 편차는 공급업체의 성질이 아니라 RFP의 성질입니다.

좋은 소프트웨어 공급업체를 가려내는 질문은 무엇입니까? 무엇을 먼저 만들고 왜 그런지, 가장 위험한 부분이 무엇이고 어떻게 줄일 것인지, 구체적으로 누가 시간의 몇 할을 써서 일하는지, 범위 변경을 어떻게 처리하는지, 당신에게서 무엇이 필요한지, 그리고 끝났을 때 무엇이 당신 것이 되는지입니다.

RFP를 쓰지 말아야 할 때는 언제입니까? 일이 작거나, 탐색적이거나, 필요한 것을 아직 정의하지 못했을 때입니다. 정의되지 않은 범위로 경쟁을 붙이면 양쪽 모두 몇 주를 잃고 정밀함이라는 착각만 남습니다. 명세서를 만들어 내거나 그 프로젝트가 할 가치가 없다고 결론짓는 유료 디스커버리가 더 나은 도구입니다.