그래서 고객이 내게 와서 약간의 작업이 필요하다고 말합니다. 기본적으로 4 가지 작업으로 특정 가격으로 수행하기로 동의했습니다. 고객이 ODesk에서 구인 (고정 된 시간과 가격의 구인)을 작성하는 데 동의하지만 고객이 해당 직무를 기반으로 계약을 시작하는 데 며칠이 걸리고 계속 상기시켜줍니다.

문제는 원래 작업이 완료되었고, 계약이 여전히 유효하고, 아직 지불하지 않았으며, 고객은 프로젝트가 완료 될 때 비용을 지불하겠다고 말한 다음 새 작업이 지속적으로 발생하거나 이전 작업으로 변경된다는 것입니다 요소를 완전히 다시 실행해야합니다. 이 모든 것에 대해 고객은 지불을 약속합니다. ODesk에서이 클라이언트의 업데이트가 없으며 새로운 작업이 없습니다. 고객에게 관리 문제를 정렬하는 것에 대해 계속 상기하지만 결과는 없습니다. 동시에 프로젝트가 곧 시작되기 때문에 클라이언트는 계속 작업을 진행합니다.

어떻게해야할지 모르겠습니다.

• 관료주의없이 업무를 수행하지 않으면 프로젝트가 늦어 질 것입니다. 하지만 내 잘못이 아닙니까? 이 경우 부정적인 피드백을 받거나 더 악화 될 수 있습니다.
• 이 프로젝트에서 탈락하면 내가 얻은 것을 얻지 못할 것입니다.
• 이렇게 계속하면 여기 에 설명 된 것과 비슷한 작업을 수행하는 데 많은 시간을 낭비 하지만 프로그래머는 이미 많은 하드 코딩 된 콘텐츠에 대해 비슷한 요청을 받았습니다.

그러한 상황에서 그러한 고객과 의사 소통하는 방법은 무엇입니까? 충돌을 피하려면 어떻게해야합니까?

추신 클라이언트는 소규모 회사입니다. 각기 다른 사람들이이 프로젝트의 다양한 측면을 다루고 있으며, 모든 사람들은 원래 사양에 자신의 변화를 소개합니다.

2 년 후 : 와우! 매우 질문! 많은 인기!
나는이 이야기의 끝 부분에 모든 사람을 허용하기로 결정했습니다. 나는 고객과 대면하고 내가 한 일에 대한 보수를받을 때까지, 그리고 시간당 계약이 열릴 때까지 일하지 않을 것이라고 설명했다. 그들은 다음날 나에게 돈을 지불하고 계약을 맺었다. 유익하지만 짧은 협력이 시작되었습니다. 모두 행복했다. 피드백을받지 못했다면 빼고

오, 난 프리랜서 였을 때이 위치에 여러 번 있었는데 지금 네 고통을 느끼고있어

고객에 대한 생각을 바꾸었을 때 모든 것이 바뀌 었습니다. 모든 고객은 사기꾼입니다.

다시 말해 보겠습니다.

모든 고객은 예술가입니다

이 관점으로 변경하면 백업 계약이없는 경우에도 실제로 대부분의 레버리지가 있음을 알 수 있습니다.

여기 당신이하는 일이 있습니다 :

• 당신이 이미 배달 한 경우, 당신은 이미 망 .이 시점에서 계속 고정 상태를 유지하고 클라이언트가 계속 b ****를 만들도록 결정해야합니다.
• 당신이 배달하지 않은 경우 희망이 있습니다 : 발사는 당신의 레버리지이며 여전히 지불받을 수 있습니다. 적어도 50 %의 지불을 협상하거나 전체 프로젝트를 포기하고 운을 내버려 두십시오 . 이것이 바로 귀하의 레버리지 입니다. 나는 적어도 두 번이 위치에 있었고 내가 할 수있을 때 기회를 얻지 못했습니다. 나에게 나쁜 일이 있었고 가격을 지불했습니다. 냉담한 것처럼 들리지만 이것은 종종 돌아올 수없는 요점입니다 .

• 이것이 단지 의사 소통 문제라고 생각한다면, 문제를 해결할 수 있습니다 (클라이언트가 원할 경우에만) : 이전을 여전히 레버리지로 사용할 수 있지만 해결책은 클라이언트에게 단일 담당자를 지정하도록 요청하는 것입니다. 프로젝트에 가장 적합한 옵션은 다음과 같습니다.

  • 프로젝트 소유자
  • 프로젝트 소유자가 지정한 이해 관계자
  • 소유자의 "오른손"

  이렇게하면 모든 요청을 효과적으로 처리 할 수 ​​있으며 한 지점으로 물건을 분류 할 수 있습니다. 기능 크립 과 기대 관리 부족이 혼합되어 있습니다 .

어쨌든 내가 당신이라면, 나는이 사건에 대한 도움을 위해 oDesk에 연락 할 것입니다. 계약자 로부터 더 많은 작업을 수행 하기 위해 이와 같은 동작을하는 많은 클라이언트가 있다고 확신합니다 . 계약에 따라 프로젝트가 완료되었다는 증거가있는 경우 계약을 무기로 사용하십시오. .

나는 oDesk가 무언가 를 계약했다고 확신 한다 .

또한, 콜드 마음 것처럼 보일 수 있지만,이 나사 나사 여부를 점점 아래로 올 때, 그들의 출시, 데드 라인, 그들의 마음 FAPS은 자신의 당신은 문제가되지 않습니다.

나는 내 시대에 고객에 대해 너무 많은 관심을 기울이는 실수를했지만 꼭 그럴 필요는 없습니다.

편집 : 마지막 조언, 최종 지불을 할 때까지 최종 배달을하지 마십시오. 항상 자신의 랩톱 / 구내에서 데모를 제공하여 모든 것이 작동하는지 확인할 수 있습니다.

또는 선택의 여지가없고 고객이 지불하도록 애플리케이션을 배포해야하는 경우 (계약서에 있거나 그렇지 않은 경우), 자체 인프라에 배치하고 다른 사람에게 액세스 권한을 부여하지 마십시오. 당신이 당신의 삶을 신뢰하는 사람들에게 (나는 이것을 진지하게 생각합니다). 이것은 "지불 할 X 일이 있거나 서비스가 중단됩니다"라고 말할 수있는 마지막 수단입니다. 그가 당신이 소유 한 집을 임대하고 있다고 가정하면, 그는 언젠가 발표하지 않고 그 사람을 추적하거나 그에게 지불 할 이유를주지 않을 것입니다.

oDesk는 분쟁 해결 팀 / 정책을 보유하고 있습니다. 특히 추가 작업에 대한 위의 세부 정보를 포함하여 연락 할 수 있습니다.

일반적으로 나쁜 징후 인 업데이트를 위해 클라이언트를 사냥해야 할 때.

나는 또한 oDesk에서 일합니다. 앞으로는 시간별 계약에 대해 독점적으로 작업하고 몇 시간이 걸리거나 작업을 수행하는지 미리 예측하는 것이 좋습니다.

시간별 계약에서는 작업 한 내용과 빚진 금액을 정확하게 표시 할 수 있습니다. 클라이언트가 비용을 지불하도록 oDesk를 얻는 것이 훨씬 쉽습니다.

고정 가격 계약에서는 기회가 없습니다. 당신의 클라이언트와 당신의 클라이언트 만이 지불 할시기와 금액을 결정합니다. oDesk는 설명서 / 지원 사이트에서도 그렇게 말합니다. 프로젝트 가격이 고정되어 있다면 유감입니다. 몸값을 위해 일을하고 당신이 얻을 수있는 모든 것을 요구한다고 말하고 싶습니다.

이와 같은 고객은 당신의 삶을 빨아들입니다.

'완료'는 무엇을 의미합니까? '계약의 모든 작업이 완료되었습니다'라는 의미입니까? 만약 그렇다면, 당신의 고객은 계약을 위반 한 것이 분명하며, 변호사에게 그의 친절한 의무를 상기시켜주는 '친근한'편지를 쓰도록 고려해야합니다. 그러나이를 최후의 수단으로 유지하고 계약에 재협상을 시도하는 등 외교적 접근을 시도해야합니다. 최초 계약 조건에 따라 b) 추가 작업에 대한 대가도 지급됩니다.

그러나 프로젝트가 '완료'되었을 때 계약금을 지불하겠다고 명시한 경우 문제가있을 수 있습니다. 좋은 개발자에게 물어 보면 소프트웨어가 완성되지 않았거나 유지 관리 중이거나 폐기되었다고 말할 것입니다. 고객이 완료시 비용을 지불 할 수 있고 법원에 갈 수 있다는 데 동의 한 경우, 자신이하지 않은 프로젝트에 추가 한 요구 사항 목록이 많기 때문에 프로젝트가 완료되지 않았을 가능성이 있습니다.

계약서에 정의 된 요구 사항을 이행하면 귀하에게 계약금이 지급 될 것이라고 계약서에 명시하기를 바랍니다. 그렇다면, 고객이 고의로 당신을 and 아 내고 동의하지 않은 작품을 추출하려고 시도하는 것이 분명하다면 옵션이 있습니다. "완료시 지불"이라고 표시되면 옵션이 훨씬 적을 수 있습니다. 계약 재협상을 시도 할 수 있지만 그가 기꺼이 버리지 않는다면 어디에서 갈 수 있는지 잘 모르겠습니다.

추가 편집: 귀하의 질문 끝에 "모든 사람이 요구 사항을 계속 추가하고 있습니다"라는 의견은 심각한 알람 벨을 울립니다. 작업 목록에 대해 협상 한 사람 이외의 다른 요구 사항은 수락하지 않았기를 바랍니다. 한 사람의 요구 사항과 변경 요청 만 수락해야합니다. 그렇지 않으면 혼돈이 발생할 수 있습니다. 피처 A는 프로젝트에 피처 X를 추가하면 깔끔하다고 생각할 수 있지만, 지불하는 B 피고인이고 A는 피처 A가 피처를 추가 한 것을 모른다면, 물건을 추가하고 있다는 인상을받을 수 있습니다. 더 많은 돈을 벌기 위해 프로젝트를 요구하지 않았습니다. 혈액이 나빠질 수밖에 없습니다. 더 나쁜 것은, 충돌하는 요구 사항과 코드가 많은 프로젝트로 인해 혼란 스러울 수 있습니다. t 다른 이해 관계자들도 기뻐하려고하기 때문에 원래의 목적을 달성하지 마십시오. 요구 사항을 추가하려면 잘 정의 된 프로세스가 있어야하며 청구서를 지불하는 사람은 추가되는 요구 사항을 완전히 알고 있어야합니다.