개발사 세 곳에 같은 설명을 했는데 제안서가 세 가지 크기로 돌아옵니다.
어떤 곳은 간단하다고 하고, 어떤 곳은 몇 배로 잡습니다.
누가 맞는지 판단이 서지 않아 결국 중간을 고르거나 가장 싼 곳을 고릅니다.
그런데 세 제안서는 같은 일을 다르게 값 매긴 것이 아닙니다. 다른 일을 값 매긴 것입니다.
같은 설명도 빈칸을 어떻게 채우느냐에 따라 다른 일이 됩니다
발주자의 설명은 기능 목록입니다. 토큰 발행, 지갑 연결, 예치와 보상 지급.
이 목록은 무엇을 만들지를 말하지만, 어디까지 만들지는 말하지 않습니다.
개발사는 그 빈칸을 각자 채웁니다. 어떤 곳은 최소로 채우고, 어떤 곳은 자기 경험에서 나온 위험 요소까지 채웁니다.
채운 방식이 다르니 범위가 다르고, 범위가 다르니 제안서가 다릅니다.
그래서 제안서를 비교하기 전에 할 일은 각 제안서가 빈칸을 무엇으로 채웠는지 읽는 것입니다.
금액 옆에 적힌 범위 설명이 실제 비교 대상입니다.
변수 1 · 요구사항이 얼마나 정해져 있는가
"예치 기능"이라는 한 줄은 개발사에 따라 전혀 다른 일이 됩니다.
락업 기간은 하나인지 여러 개인지.
보상은 고정인지 변동인지.
중도 해지가 있는지, 있다면 대가는 어떻게 계산하는지.
이 값들을 나중에 바꿀 수 있어야 하는지.
발주자가 이 질문에 답을 갖고 있으면 개발사는 그대로 값을 매깁니다.
답이 없으면 개발사는 두 가지 중 하나를 합니다. 가장 단순한 형태를 가정하고 작게 잡거나, 나중에 바뀔 것을 대비해 크게 잡거나.
둘 다 틀린 것이 아닙니다. 요구사항이 정해지지 않았다는 사실이 제안서에 다르게 반영된 것입니다.
작게 잡은 곳은 나중에 추가 비용을 청구할 것이고, 크게 잡은 곳은 처음부터 그것을 넣은 것입니다.
변수 2 · 운영이 들어 있는가
개발이 끝나면 일이 끝난다고 가정하는 제안서와, 배포 뒤 운영까지 넣은 제안서는 크기가 다릅니다.
배포 뒤에 필요한 일은 적지 않습니다.
모니터링.
장애 대응.
거래소 연동 지원.
지갑 호환 대응.
감사 지적 사항 반영.
체인 업그레이드 대응.
이 항목이 제안서에 있는지 없는지가 범위 차이의 큰 부분입니다.
없다고 나쁜 제안서가 아닙니다. 운영을 자체 인력이 맡을 수 있는 팀이라면 개발만 받는 것이 맞습니다.
문제는 운영을 맡을 사람이 없는데 운영이 빠진 제안서를 골라, 배포 다음 날부터 대응할 주체가 없는 경우입니다.
운영이 포함된 제안서는 기간도 함께 봐야 합니다. 몇 달인지, 그 뒤에는 어떻게 되는지까지 확인해야 비교가 됩니다.
FD인터내셔널이 전략을 만들 때 그 계획을 실제로 실행해야 할 사람과 조직의 역량까지 포함해서 설계하는 이유입니다.
변수 3 · 책임의 경계가 어디에 있는가
컨트랙트에 문제가 생겼을 때 누가 책임지는가.
감사는 누가 받고 지적 사항은 누가 고치는가.
배포는 누가 하고 키는 누가 보관하는가.
요구사항이 바뀌면 그 비용은 누가 부담하는가.
이 질문에 대한 답이 제안서마다 다르고, 그 답이 크기를 바꿉니다.
책임을 넓게 지는 제안서는 크고, 좁게 지는 제안서는 작습니다.
작은 제안서가 싼 것이 아니라 책임을 발주자 쪽에 남겨둔 것일 수 있습니다.
책임의 경계는 계약서에서 가장 나중에 읽히는 부분이지만, 문제가 생기면 가장 먼저 열어보는 부분입니다.
세 변수를 발주자가 먼저 정해야 제안서가 비교 가능해집니다
세 변수를 발주자가 먼저 정하면 개발사들은 같은 일을 값 매기게 됩니다.
요구사항을 정하고, 운영 포함 여부를 정하고, 책임의 경계를 문서로 제시하는 것입니다.
이 작업은 개발사가 대신해줄 수 없습니다.
발주자만이 자기 사업에서 무엇이 정해졌고 무엇이 미정인지, 운영을 누가 맡을지, 어디까지 책임을 넘길지를 압니다.
세 변수가 정해진 뒤에 받은 제안서는 대개 크기가 비슷해집니다. 남는 차이는 개발사의 방식과 경험의 차이이고, 그것이 실제로 골라야 할 차이입니다.
그래도 크기가 다르다면 큰 쪽에 먼저 이유를 묻습니다
세 변수를 맞췄는데도 제안서 크기가 크게 다르다면, 그때는 큰 쪽에 이유를 묻는 것이 순서입니다.
우리가 보지 못한 위험을 봤을 수 있습니다. 그 답이 구체적이면 그 위험은 실제일 가능성이 높고, 답이 뭉뚱그려지면 관행일 가능성이 높습니다.
작은 쪽에도 같은 질문을 합니다. 무엇을 빼고 이 크기가 됐는지.
뺀 항목이 우리에게 필요 없는 것이면 그 제안서가 정확한 것이고, 필요한 것이면 나중에 돌아옵니다.
정확한, 필요한 서비스만 제공하고, 더 많이 해결합니다.
발주자 쪽에서 이 원칙을 적용하면, 가장 싼 제안서도 가장 큰 제안서도 아니라 우리 범위와 정확히 맞는 제안서를 고르게 됩니다.
제안서 세 장은 대개 서로 다른 일을 제안하고 있습니다
FD가 제안서 세 장을 놓고 보시는 분들께 먼저 여쭙는 것은 금액이 아니라 각 제안서의 범위 설명입니다.
나란히 놓으면 대개 한 곳은 운영이 빠져 있고, 한 곳은 요구사항을 최소로 가정했고, 한 곳은 감사와 재작업을 넣었습니다.
세 곳은 서로 다른 일을 제안한 것이라 금액 비교가 애초에 성립하지 않았습니다.
이 구분이 되고 나면 대개 발주자가 스스로 고르십니다.
FD가 하는 일은 어느 개발사가 좋은지 말하는 것이 아니라, 세 제안서가 왜 다른지를 읽을 수 있게 하는 것까지입니다.
FD인터내셔널이 모든 결정을 대신 내려주는 것을 목표로 하지 않는 이유입니다. 최종적으로 사업을 운영하고 책임지는 사람은 프로젝트의 대표와 팀입니다.
개발의 규모가 프로젝트의 실력을 증명하는 것은 아닙니다. 사업에 필요한 기술을 정확하게 구현하는 것이 더 중요합니다.