請求されたのですが、その内容はどこで確認できますか? - ページ 42 1...353637383940414243444546474849...57 新しいコメント Armen 2013.12.06 18:27 #411 zfs: 私も全く同じ状況でした。その5%も覚えています)。作品を作っているお客様は、すでにサービスサイトを利用しています。この場合、お客さんが書いた仕事は完成できないので、当然プログラマーはお金を返さなければならない。そして、返金はサイトがお金を取ります。契約を結ぶ前に状況を明らかにすることができたはずだ。弁護士費用を負担しなければならない)。お客様側に落ち度がない場合でも1.4から5への対応について、何が不可能なのか?2.なぜ無理難題に挑むのか、それは演者のレベルについて...。 Vasiliy Smirnov 2013.12.06 20:04 #412 Armen:1.4から5への対応について、何が不可能なのか?2.なぜ無理難題に挑むのか、それは演者のレベルについて...。 実装の方法はさまざまです。クライアントは、可能な限りのバリエーションに満足していない。 Armen 2013.12.06 20:12 #413 zfs: 実行方法はさまざまです。可能な選択肢の中で、お客様が満足されなかったのは、まさにこのことだったのです。 お客様には、作業費を4倍にする以外の選択肢は提示されませんでした。 Alan Petrashen 2013.12.06 20:12 #414 ToR(合意済み、逸脱なし)の確認後、業務遂行を拒否するのは、発案者の責任となります。しかし、仕事の結果にかかわらず、その価値の5%を没収される当事者が、クライアントには必ず存在するのだ。これは明らかな間違いだ...。MQは、このような場合、少し利他的になって顧客に100%お金を返すか(これは確かに稀な悪用を引き起こすかもしれません)、少し手順を変えて、作業コストの5%と開発者から(ここですでに議論されているように)凍結する必要があります。そちらのMQ。このような非加算の「評判配当」スレッドの作成が発生しないようにする。は、どうせ5%はもらえるが、本当は罪人からもらう。というのも、新しい「実演家」は少なくとも1回は資金を預ける必要があり、「作品」のために常にいくらかの予備を持つ必要があるからです。だから、なぜMQがこの問題をはぐらかすのか理解できない(フォーラムの最初の20ページで形成された意見)。間違いが発見され、それを解決することでビジネスの効率をもう少し上げられると、私が彼らだったら喜びます。 Armen 2013.12.06 20:17 #415 ここでは、仲裁が仕事の量に対応できないと言われていますが......。クライアントから5%もらえば、話は終わりですから。ps もし、ワークロードを処理できないなら、何かが間違っている ...何かを変えなければならない......多分、より大きなスタッフ。 Alan Petrashen 2013.12.06 20:24 #416 Armen:ここでは、仲裁が仕事の量に対応できないと言われていますが......。クライアントから5%もらえば、話は終わりですから。ps もし、ワークロードを処理できないなら、何かが間違っている ...何かを変えなければならない......多分、より大きなスタッフ。"新しい契約者は、少なくとも1回資金を入金する必要があります+常に仕事のためのいくつかの準備を持っているので、彼らの支払システムの口座に流入/残基を増加させます。" この経済的なメリットによって、スタッフ増員のコストをすべてとは言わないまでも、ある程度は補うことができるのではないでしょうか。 Alan Petrashen 2013.12.06 21:40 #417 Armen:ここでは、仲裁が仕事の量に対応できないと言われていますが......。クライアントから5%もらえば、話は終わりですから。ps もし、ワークロードを処理できないなら、何かが間違っている ...何かを変えなければならない...たぶん - スタッフを増やしてください。手間をかけないシンプルな解決策は、コストを100%お客様に還元することです。そんなケースはあまりないだろうし、これからもないだろうけど...。MQは、変更オプションに基づいて統計を計算/予測し、自分たちにとって最適なものを選ぶべきだと思います。誰もがその恩恵を受けることができるのです。変革は必要だ...。 Vasiliy Smirnov 2013.12.06 22:26 #418 Armen: クライアントには、4倍のコストにする以外の選択肢は提示されていない。 も選択肢の一つです)。つまり、選択肢があったのです。 Vasiliy Smirnov 2013.12.06 22:34 #419 Petral:ToR(合意済み、逸脱なし)の確認後、業務遂行を拒否するのは、発案者の責任となります。しかし、仕事の結果にかかわらず、その価値の5%を没収される当事者が、クライアントには必ず存在するのだ。これは明らかな間違いだ...。MQは、このような場合、少し利他的になって、顧客に100%資金を返すか(確かに稀に悪用されるかもしれない)、仕事の手順を少し変えて、(すでにここで議論したように)作業コストの5%とデベロッパーから凍結するか、どちらかにしなければなりません。そちらのMQ。このような付加価値のない「風評被害」スレッドを立てないようにする。は、どうせ5%はもらえるが、本当は罪人からもらう。というのも、新しい「実演家」は少なくとも1回は資金を預ける必要があり、「作品」のために常にいくらかの予備を持つ必要があるからです。だから、なぜMQがこの問題をはぐらかすのか理解できない(フォーラムの最初の20ページで形成された意見)。間違いが発見され、それを解決することでビジネスの効率をもう少し上げられると、私が彼らだったら喜びます。 そして、プログラマーの何が悪いのかというと、プログラマーにはいつでも仕事を断る権利がある、商売のコツに手を出すことですでにリスクを背負っているのです。この場合、お客さまはとんでもない課題を設定しました。そして、メタクオーターは仕事の依頼を受けたのです。プログラマーだけが、お客さまからの評価を落とすことができるのです。合意はしていない。プログラマーを締め付けると、仕事に直接対価を支払う以前のように、仕事が副業として残ってしまいます。プログラマーがリスクを負うことに何の意味があるのか?一理あるかもしれませんが、作品の値段が上がります。 Alan Petrashen 2013.12.07 19:55 #420 zfs: で、プログラマーに何の落ち度があるのかというと、プログラマーにはいつでも仕事を断る権利がある、仕事のトリッキーな部分に手を出してすでにリスクを負っているのである。この場合、お客さまはとんでもない課題を設定しました。そして、メタクオーターは仕事の依頼を受けたのです。プログラマーだけが、お客さまからの評価を落とすことができるのです。合意はしていない。プログラマーを締め付けると、仕事に直接対価を支払う以前のように、仕事が副業として残ってしまいます。プログラマーがリスクを負うことに何の意味があるのか?一理あるのかもしれませんが、仕事の対価が増える。 プログラマがTORの合意を確認したのだから、起こりうる「仕掛け」を想定しなければならない、あるいは「顧客がとんでもない仕事を設定してきた」場合はTORを確認せず、議論と合意を継続しなければならない、という落ち度があるのだ。したがって、まともな責任あるプログラマーにとっては、何のリスクもない。"プログラマを取り締まれば "契約が無責任に破られることが少なくなり、常に金銭的に片手間で帳消しになるような、より質の高いサービスが 提供されます。その後、アービトラージのケースも少なくなっていくのでしょう。 1...353637383940414243444546474849...57 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか? Googleでログイン
私も全く同じ状況でした。その5%も覚えています)。作品を作っているお客様は、すでにサービスサイトを利用しています。この場合、お客さんが書いた仕事は完成できないので、当然プログラマーはお金を返さなければならない。そして、返金はサイトがお金を取ります。契約を結ぶ前に状況を明らかにすることができたはずだ。弁護士費用を負担しなければならない)。お客様側に落ち度がない場合でも
1.4から5への対応について、何が不可能なのか?
2.なぜ無理難題に挑むのか、それは演者のレベルについて...。
1.4から5への対応について、何が不可能なのか?
2.なぜ無理難題に挑むのか、それは演者のレベルについて...。
実行方法はさまざまです。可能な選択肢の中で、お客様が満足されなかったのは、まさにこのことだったのです。
ToR(合意済み、逸脱なし)の確認後、業務遂行を拒否するのは、発案者の責任となります。しかし、仕事の結果にかかわらず、その価値の5%を没収される当事者が、クライアントには必ず存在するのだ。これは明らかな間違いだ...。MQは、このような場合、少し利他的になって顧客に100%お金を返すか(これは確かに稀な悪用を引き起こすかもしれません)、少し手順を変えて、作業コストの5%と開発者から(ここですでに議論されているように)凍結する必要があります。そちらのMQ。
ここでは、仲裁が仕事の量に対応できないと言われていますが......。
クライアントから5%もらえば、話は終わりですから。
ps もし、ワークロードを処理できないなら、何かが間違っている ...何かを変えなければならない......多分、より大きなスタッフ。
ここでは、仲裁が仕事の量に対応できないと言われていますが......。
クライアントから5%もらえば、話は終わりですから。
ps もし、ワークロードを処理できないなら、何かが間違っている ...何かを変えなければならない......多分、より大きなスタッフ。
- "新しい契約者は、少なくとも1回資金を入金する必要があります+常に仕事のためのいくつかの準備を持っているので、彼らの支払システムの口座に流入/残基を増加させます。"
この経済的なメリットによって、スタッフ増員のコストをすべてとは言わないまでも、ある程度は補うことができるのではないでしょうか。ここでは、仲裁が仕事の量に対応できないと言われていますが......。
クライアントから5%もらえば、話は終わりですから。
ps もし、ワークロードを処理できないなら、何かが間違っている ...何かを変えなければならない...たぶん - スタッフを増やしてください。
手間をかけないシンプルな解決策は、コストを100%お客様に還元することです。そんなケースはあまりないだろうし、これからもないだろうけど...。
MQは、変更オプションに基づいて統計を計算/予測し、自分たちにとって最適なものを選ぶべきだと思います。誰もがその恩恵を受けることができるのです。変革は必要だ...。
クライアントには、4倍のコストにする以外の選択肢は提示されていない。
ToR(合意済み、逸脱なし)の確認後、業務遂行を拒否するのは、発案者の責任となります。しかし、仕事の結果にかかわらず、その価値の5%を没収される当事者が、クライアントには必ず存在するのだ。これは明らかな間違いだ...。MQは、このような場合、少し利他的になって、顧客に100%資金を返すか(確かに稀に悪用されるかもしれない)、仕事の手順を少し変えて、(すでにここで議論したように)作業コストの5%とデベロッパーから凍結するか、どちらかにしなければなりません。そちらのMQ。
で、プログラマーに何の落ち度があるのかというと、プログラマーにはいつでも仕事を断る権利がある、仕事のトリッキーな部分に手を出してすでにリスクを負っているのである。この場合、お客さまはとんでもない課題を設定しました。そして、メタクオーターは仕事の依頼を受けたのです。プログラマーだけが、お客さまからの評価を落とすことができるのです。合意はしていない。プログラマーを締め付けると、仕事に直接対価を支払う以前のように、仕事が副業として残ってしまいます。プログラマーがリスクを負うことに何の意味があるのか?一理あるのかもしれませんが、仕事の対価が増える。