처음 생각: FMZ 그룹에서 사용자 정의 개발 결과를 찾는 것은 바람직하지 않습니다. 그룹에 가서 많은 FMZ 그룹 회원이 이러한 문제에 직면했다고 발견했습니다. 많은 사람들이 저와 함께 그들이 도자기를 경험했다고 말했습니다. 인터넷 공유 정신에 따라, 이 점을 공유하십시오.
전제 조건:
1, 기능 요구 사항이 처음부터 끝까지 추가되지 않았습니다.
2 가격은 상대방이 결정하고, 환불은 없습니다.
3개발주기는 서로 제공되며, 각 연장은 개발자를 존중합니다.
FMZ는 처음으로 개발자의 요구에 대한 개발 전략에 대한 통찰력을 얻었습니다.
1 , 요구 사항에 대해 잘 이야기하십시오. 개발자가 당신에게 더 간단하게 말하지만, 지불하기 전에 모든 부분을 확실히 이야기하십시오. 부러움을 피하십시오. 그들이 당신에게 자세히 이야기하지 않더라도 가능한 한 지불하기 전에 그에게 자세히 이야기하십시오. 전략이 누출되는 것을 두려워하지 마십시오. 변수는 제공되지 않습니다.
2, 미리 정해진 주기 연장, 만료되지 않았다는 것은 프로젝트 주기에 대한 예측이 부족하다는 것입니다. 반드시 불쌍한 말을하지 마십시오. 내가 얼마나 오랫동안 개발했는지 봐서, 결말에 이르면 손실을 입은 사람은 나입니다. 그리고 이전에는 책임감이 없습니다. 결말에 이르면 더 책임감이 없습니다.
- 가능한 한 개발자가 먼저 실판을 테스트하고 문제가 있는지 확인하고 승인을 받도록하십시오. 개발자는 일반적으로 전체 프로세스 테스트를 좋아하지 않으며, 모든 부분을 자세히 테스트합니다. 나는 이것이 내가 만난 것인지 모르겠습니다. 그러나 모든 부분을 테스트하고, 통신을하고, 실제 테스트를하고, 불필요한 부조리와 시간 낭비를 피하십시오.
4, 반드시 원격 지원과 음성 통신이 필요하며, 순전히 문자 통신이 아니라, 때로는 한 두 개의 단어가 명확하게 말할 수 있습니다. 문자에는 정말로 강한 문화적 기반과 문자 표현 능력이 필요하며, 전문적인 명어가 잘못 될 수 없습니다.
이 주문형 개발의 전체 과정은 기본적으로 돈을 요구하고 지불을 촉구하는 것입니다. 가장 반복되는 것은 지불을 요구하는 것입니다. 가장 많은 것은 테스트에 문제가 없다는 것입니다.
요약: 전체 아웃소싱 프로세스, 다양한 사람들이 당신을 찾아, 능력 차이는, 가격 차이는. 문제가 발생하면 자만 할 수 있습니다, 불평 할 수 없습니다, 심지어는 결점 평가를 할 곳이 없습니다. FMZ 그룹에는 다양한 능력으로 가득한 단독 인원이 있으며, 그 안에 큰 소가 있습니다. 그러나 나 개인적으로는 FMZ에서 보증 기능이나 평가 기능을 제공하기 전에 FMZ에서 찾을 수 없습니다.
결론: 다시 한 번
추천: FMZ는 정말 신중하게 외출을 정리할 필요가 있습니다. 마지막 <unk>은 FMZ의 뒷면일 가능성이 높으며, 브랜드 <unk>은 반드시 FMZ입니다. 맞춤형 개발을 돌보기 위해 에너지가 없다고 느끼면 잘라버립니다.
저는 채팅 기록들을 모두 포장해서 보내려고 했는데, 여러분들이 구멍을 덜 뚫고 나가도록 하기 위해서였죠. 그래서 채팅 기록과 수령자의 이름은 공개되지 않았습니다.
我帮论坛里好几个人写过策略,总的评价就是需要帮写策略的人的策略极其不可靠,或者本身交易认知经验不足,仅仅是一段时间里的有效(牛市)这些策略跟赌博没什区别,想想也是如此,如果真的有很好的策略,那是宁愿捂着手动也绝对不会与第二个人分享的,因此假如你让一个程序员帮你写一些本身没有意义的策略,其结果双方都不会满意,因为你以为的是细节有问题,而其实是你大的逻辑问题
非常感同身受的了解您的需求,以及建议和意见。
众包板块提供的是一个信息交流、发布的地方,具体用户之间的线下合作,平台是不干涉的。
所以需要开发需求方和开发者之间定好协议,约定好开发内容,按照协议履行。
举个不恰当的例子,就好比在人才市场找干活的工人,工费、施工内容等这些都是要具体约定协议的,干活人的手艺、工作态度、效率也都不相同、工费肯定也都不一样。人才市场肯定不会给任何一方担保什么,人才市场仅仅也只是一个信息交流、发布的地方。
希望您理解。
另外非常赞同一点就是
1、建议谈好需求,不管开发人员给你说的再简单,建议一定在支付之前聊清楚每个环节,避免扯皮,即使他们不找你详细聊,也尽可能的在付费之前给他详细聊清楚。不要怕策略泄露什么的,参数不提供就行了。思路随便抄,没任何意义。
需求方害怕开发者弄懂策略,没有说清楚需求内容,然后改来改去,可能需求方认为这改改不就是几行代码的事儿。实际上改策略是最麻烦的事情(有时候甚至重写都不想改)。
所以开发者、需求方合作的重中之重就是:定好开发需求、描述清楚、准确,形成文档双方确认,按约定流程推进开发。
- 1

