수정 / 버그에 대한 비용은 누가 지불해야합니까? [닫은]

그래서 저는 방금 데스크톱 / 웹 개발과 이미 내 작업을 수락 한이 클라이언트에서 프리 랜싱을 시작했으며, 버그 등을 발견 할 때마다 계속 내게 돈을 지불했습니다. 비어 있는. 괜찮습니까, 아니면 지원 수수료를 청구해야합니까?

예상되고 완료된 작업에 대한 수정 사항을 처리하는 가장 좋은 방법은 무엇입니까?

계약서의 일부에는 승인 테스트, 즉 고객이 수행 할 테스트와 계약을 이행하기 위해 응용 프로그램이 통과해야하는 테스트가 설명되어야합니다. 이 테스트에서 다루지 않은 것은 고객의 책임입니다. 그들에 의해 커버되는 것은 당신의 것입니다.

(특히 비 기술적 인 고객의 경우) 모든 가능한 문제를 볼 수 없기 때문에 계약의 일부로 새로운 문제를 해결하는 기간을 지정하는 조항을 연락처에 추가해야합니다. 그 후에는 유료 지원 만 제공해야합니다.

따라 다릅니다.

첫 번째 경우 작업이 완료되지 않았다고 주장 할 수 있으므로 지불해야합니다.

나중에 고객은 지속적인 지원에 대한 비용을 지불해야합니다.

그러나 문제는 경계의 위치와 버그를 구성하는 요소 및 새로운 기능을 결정하는 데 있습니다. 요구 사항 및 / 또는 승인 테스트는이를 정의하는 데 큰 도움이됩니다.

작품을 제공하기 전에 이러한 것들을 제자리에 두어야하지만, 아직 그렇지 않은 경우 아마도 다음과 같이 말할 것입니다. "다음 N 일 / 주 동안 무료로 지원할 것입니다. 지원 계약에 대해 논의해야합니다 "("저희 "에 중점을 둡니다).

모든 것을 말했지만 무료로 버그를 수정하고 적중해야 할 때가 있습니다. 다른 것이 없다면 선의를 쌓을 수 있습니다.

위에 주어진 모든 답변이 좋습니다. 그러나 고려해야 할 몇 가지 글 머리 기호를 추가합니다.

• 고객이 당신에게 가치가 있습니까? 고객이 자신에게 가치가 있다고 생각하고 앞으로 더 많은 일을 할 수 있다면 고객을 행복하게하기 위해 여분의 야드를가는 것이 좋습니다. 엄격함과 유연성 사이의 균형을 찾아야하며 이는 고객마다 다를 수 있습니다. 수정하기 쉬운 버그가 범위를 벗어났다고 단호하게 생각하여 향후 작업을 잃어 버릴 필요는 없습니다. 반면에, 당신은 클라이언트가 당신을 온통 걸어 다니게하고 싶지 않습니다. 미묘한 균형입니다!

• 사용자 테스트에서 쉽게 놓칠 수있는 버그입니까? 예를 들어, 특정 연도를 입력 할 때만 발생하는 날짜 관련 버그 (밀레니엄 버그 등)를 생각해보십시오. 테스트하는 동안 고객은이 문제를 합리적으로 예상 할 수 없었으므로 고객은이를 해결해야합니다.

자유 계약을 체결 할 때 기본 고객 계약에 "수락"이라는 조건이 정의되었습니다.이 조건은 프로젝트를 대중에게 공개하기 전에 필요합니다. 받아들이는 순간, "지원 및 운영"이라고하는 30 일의 기간이 시작되었습니다. 30 일 후에는 진행중인 프로젝트 작업에 시간당 비용이 청구되었습니다.

이 고객과 좋은 관계를 유지하고 있다면 현재 상황이 귀하에게 얼마나 어려울 지에 대해 마음에 새기고 지속적인 유지 보수 및 지원을위한 시간당 요금을 제안하십시오. 사람들은 때때로 맞춤형 소프트웨어를 구매하는 것이 샌드위치 나 다른 것을 구매하는 것과 같다고 생각합니다. 그런식이 아닙니다.

일반적으로 응용 프로그램을 제공 한 후 정해진 기간 동안 무료 지원을받을 수 있습니다. 평생 무료 지원은 가능하지 않습니다.

발생한 버그가 버그이며 기존 기능의 변경 사항이 아닌지 확인하십시오. 기능 변경에 대해서는 요금을 청구해야합니다.

그가 그것을 테스트하고 서명했다면, 당신은 그가 지불해야한다고 주장 할 수 있습니다.

당신의 일을 자부하고 소중히 여기면 코드를 고칠 것이라고 주장 할 수 있습니다. 경험을 통해 배우고 다음에 더 효율적으로 더 나은 코드를 작성하십시오. 또는 버그 수정을 위해 더 많은 수익을 창출하십시오.

프로그램이 입력에 대해 바람직하지 않거나 예상치 못한 일을하는 경우, 버그이므로 수정해야합니다.

초기 개발 작업에 대한 추가 비용으로 지원 비용을 선포 할 수 있습니다.

계약서에서 시간당 요금을 지정하고 시간을 추적하십시오. 고객에게 가격을 책정 할 때 이는 추정치이며 실제 결과는 더 적거나 많을 수 있음을 지정하십시오.

고객에게 진행 상황에 대한 최신 정보를 제공하고 필연적으로 제안을 할 때 변경 사항이 원래 사양을 벗어난 경우 시간을 알려 주면 변경 사항이 가치가 있는지 여부를 결정할 수 있습니다. 따라서 그에게 중요한 변경 사항 만 추가됩니다.

나는 계약서에서 허용 가능한 버그와 허용되지 않는 버그 (유료 지원 대 무료 지원)를 개인적으로 다루겠다. 그는 왜 당신이 그 절이 필요한지 궁금해 할 것이므로, 새로운 OS 업데이트가 나오면 문제가 생길 경우 무료 지원이 아니라고 미리 설명하십시오. 그러나 지정된 플랫폼의 원래 사양에 따른 코드 버그는 다루어집니다.

그러나 프로그래밍보다는 프리랜서 IT 작업 만 수행했다고 언급해야합니다. 이것은 고객을 놀라게 할 수도 있지만, 자신의 작업이 다른 회사보다 더 전문적이고, 나가고, 도움이되며,보다 엄격한 계약을 체결 한 이유를 다룰 수 있도록하십시오.

게다가, 그 조항을 받아들이지 않는 고객은 나쁜 고객 일 가능성이 높습니다.