첫 번째 의도: FMZ 그룹에서 사용자 정의 개발 결과를 찾는 것은 이상적이지 않습니다. 그룹에 보내서 많은 FMZ 그룹 친구들이 이런 문제를 겪는 것을 발견했습니다. 많은 사람들이 나와 함께, 그들은 또한 채굴 된 경험을 겪었다고 말했습니다. 인터넷 공유 정신으로, 이 깨달음을 공유하십시오.
전제 조건: 1, 기능 요구가 처음부터 끝까지 증가하지 않았습니다. 두 번째, 가격은 상대방이 말한대로, 환불되지 않습니다. 3.. 개발 주기는 서로 제공되며, 모든 연장에는 개발자가 존중받습니다.
개발자로서, FMZ는 처음으로 개발 전략에 대해 깨달았습니다. 1, 요구에 대해 잘 이야기하는 것이 좋습니다. 개발자가 당신에게 말하는 것이 간단하든 간에, 지불하기 전에 모든 부분을 확실히 이야기해야하고, 부러움을 피해야합니다. 심지어 그들이 당신을 자세히 이야기하지 않더라도 지불하기 전에 가능한 한 자세히 이야기하십시오.
2, 미리 정한 주기 연장, 기간이 끝나지 않았다는 것은 프로젝트 주기 예측이 충분하지 않다는 것입니다. 반드시 가난한 말을하기 때문에, 당신이 내가 얼마나 오랫동안 개발했는지 보시면, 마지막 부분을 끝낼 때, 불행은 정말로 나 자신입니다. 그리고 이전에 책임지지 않았습니다. 마지막 부분을 끝내는 것이 더 책임지지 않습니다. 신체적 절단.
3. 가능한 한 개발자가 먼저 실제 디스크를 테스트하여 문제가 있는지 확인하고 측면 개발의 대신 수용을 수행하십시오. 개발자는 일반적으로 자신의 전체 프로세스 테스트를 좋아하지 않는다는 것을 알게되었습니다. 모든 링크를 세밀하게 테스트했습니다.
4, 원격 보조 및 음성 통신이 필수적이며 순수 문자 통신이 아닙니다. 때로는 한 두 문장이 명확한 것을 설명 할 수 있습니다. 문자에는 강한 문화적 기반과 문자 표현 능력이 필요합니다. 또한 전문 명사가 필요합니다. 실수 할 수 없습니다.
이 맞춤형 개발의 전체 과정은 기본적으로 돈을 요구하고 지불을 촉진하는 것입니다. 가장 반복되는 것은 지불을 요구하는 것입니다. 가장 많은 것은 내가 테스트하는 데 문제가 없다는 것입니다. 당신이 사용하는 데 문제가 없다는 것입니다.
요약: 전체 오웃소싱 프로세스, 다양한 사람들이 당신을 찾습니다, 능력은 다양하고 가격이 다릅니다. 문제가 발생했을 때 자부심만 할 수 있습니다. 어디에도 불평하거나 나쁜 평가를 할 곳이 없습니다. FMZ 그룹은 다양한 능력의 인력으로 가득 차 있습니다.
결론: 다시 시작하라
조언: FMZ는 정말 잘 정리해야 할 외장 조각, 마지막
!!! 나는 채팅 기록들을 모두 포장하고, 공개하려고 했는데, 그 이유는 사람들이 더 적은 구멍을 내기 위해서였기 때문에 채팅 기록과 채팅 담당자의 이름은 공개되지 않았습니다.
시우저는 포럼에서 여러 사람들을 도와서 전략을 썼습니다. 일반적인 평가는 전략 작성자가 필요한 전략이 매우 신뢰할 수 없거나 또는 자신의 거래 인지 경험이 부족하고 일시적으로 효과적이라는 것입니다. 이 전략은
초목맞춤형 전략은 정말 문제, 자신의 생각의 문제, 의사소통의 문제, 현실의 문제 등, 완벽한 기대를 하지 마십시오.
작은 꿈우리는 여러분의 필요와 조언과 의견을 이해하는데 매우 동정심을 가지고 있습니다. 크루저 플랫폼은 정보 교환, 게시 장소, 특정 사용자 간의 오프라인 협업으로 제공되며 플랫폼은 개입하지 않습니다. 따라서 개발자와 개발자 사이의 계약이 필요하고, 개발 내용을 합의하여 계약에 따라 이행해야합니다. 부적절한 예로, 인재 시장에서 일하는 노동자, 임금, 건설 내용 등이 구체적으로 합의되어야하는 것과 같습니다. 인재의 기술, 작업 태도, 효율성, 그리고 임금은 확실히 다르지 않습니다. 인재 시장은 어느 쪽에게도 보장되지 않습니다. 인재 시장은 단지 정보, 교환, 배포의 장소입니다. 저는 여러분이 이해하기를 바랍니다. 그리고 다른 점은 `` 1, 요구에 대해 이야기하는 것이 좋습니다. 개발자가 당신에게 말하는 것이 간단하더라도 지불하기 전에 모든 부분을 확실히 이야기해야하고, 부러움을 피해야합니다. 심지어 그들이 당신을 자세히 이야기하지 않더라도 지불하기 전에 가능한 한 자세히 이야기하십시오. `` 요구자 측은 개발자가 정책을 이해하여 요구 내용을 명확히 말하지 않고 변경하기를 두려워하고, 요구자 측은 변경이 몇 줄의 코드보다 더 중요하다고 생각할 수 있습니다. 실제로 정책을 변경하는 것이 가장 곤란한 일입니다 (때로는 다시 쓰고 싶지 않습니다). 따라서 개발자, 요구자 협력의 중점은 다음과 같습니다: ** 개발 요구 사항을 정하고, 명확하고 정확하게 설명하고, 문서 양쪽의 확인을 형성하고, 합의된 프로세스에 따라 개발을 추진하십시오. **
작은 꿈좋은, 우리는 개발자 신용 기록을 추가하는 것에 대해 논의 할 수 있습니다.
에세인이 게시물은 사용자가 직접 삭제할 수 있습니다.
작은 꿈현재 Crowdsourcing에서 댓글을 달 수 있습니다.
에세인실제로 점수를 늘리는 것은 가능하지만, 결국 요구사항을 명확히 하는 능력은 개발자의 능력의 일부입니다. 서비스 태도, 주기적인 통제, 예산 평가를 포함하여 개발자의 비즈니스 통합 능력 평가의 일부입니다.
에세인이 글은 이 글의 내용에 대해 설명하고 있습니다.