С запуском сервиса "Работа" MQL5.community становится идеальным местом для размещения заказов и оказания услуг программирования. Тысячи трейдеров и разработчиков ежедневно посещают этот ресурс и с легкостью могут помочь друг другу. Для трейдера сервис "Работа" - это легкая возможность получить свой собственный эксперт. Для MQL5-разработчика это возможность легко найти новых клиентов. В данной статье мы рассмотрим возможности этого сервиса.
papaklassの 言うとおりだ。ボールに定式化されたアルゴリズムのコストを仕事のコストに入れる。
あるいは、最も複雑なケースでは、タスクを形式化するコストを規定する。しかし、彼らがこれに同意することはめったにない。
そして、経験を積めば、どんな文字でも一度に、そして十分に正確に見積もることができるようになる。筆跡で、ニックネームで、語彙で......。
papaklassの 言うとおりだ。ボールに定式化されたアルゴリズムのコストを仕事のコストに入れる。
あるいは、最も複雑なケースでは、仕事を形式化するコストを規定する。もっとも、彼らがそれに同意することはめったにないが。
そして、経験を積めば、どんな文字でも一度に、そして十分に正確に見積もることができるようになる。筆跡で、ニックネームで、語彙で......。
komposter、私はあなたに反対させてください...誰もが彼自身の真実を持っていますが。良心的かどうか - 潜在的なクライアントを考慮する方法という意味では？
彼は "注文しないリスク "のために支払うので、あなたの仕事の コストに ボールの上に定式化されたアルゴリズムのコストを 入れた 場合、定義によって、クライアントは、善意とはみなされません。これは、例えば窃盗という点では、小売業者が行っていることである。私たちは皆、店が私たちから盗んだのとまったく同じだけ、商品を買い過ぎている......。
MQサイトを通じて顧客と業者の関係を構築する仕組みがあれば、多かれ少なかれ公平に構築することができる......あるいはそうしようとすることができる......。
abrokの 意見にまったく同感である：
例えば、あなたが演奏家だとしよう。あなたは3～4日間、顧客と話し合い、正しいTORを作成する。では、 パパクラスが言うように 、マネージャーを見てみよう。彼は少なくとも1時間以上、潜在的な買い手とコミュニケーションをとるだろうか？
熟練したライターは、あるとき腰を落ち着けて、通常の仕事と吹き出しの仕事に かかる時間を計算し、通常の仕事と吹き出しの収入の比率を比べてみる。30対70、70対30といったところだろう。なぜ通常の顧客がバルーニストに報酬を支払わなければならないのか？仕事のコストには、その仕事について議論するためのコストも含まれるべきですが、妥当な金額（質疑応答を含む読書と2～3サークル）では、通常の顧客はバルーン奏者に支払うべきではありません。
...では、 papaklassが言うように 、セールスマンを見てみよう。彼は少なくとも1時間以上、購入希望者とコミュニケーションをとるだろうか？
熟練したライターの皆さんは、あるとき腰を落ち着けて、通常の仕事とバルーンの仕事をこなすのにかかる時間を計算し、通常の仕事とバルーンの仕事の収入の比率を比べてみてください。30対70、70対30といったところだ。
そういうものだ。お客さんがお金を払いたくないと思えば思うほど、理解できない仕事が多くなり、傲慢で気取った態度になる。
市場価格には、顧客の要求に対するプログラマーの作業価格がすでに 含まれていることを理解すべきである。
プログラマーがこのことを理解していなければ、競争力を低下させる運命にある。
顧客の要求に対する価格と、コードそのものに対する作業に対する価格とを分離して請求する方法を考え出そうとしても、それはユートピア的である。
TORの価格とコード自体の作業価格を分けて顧客に請求する方法を考えようとするのはユートピアだ。
TORの分析と承認に固定料金を設定することは可能である。そして、注文が実現 するかどうかは別の問題である。:)
修理代は、修理の複雑さとスペアパーツの値段によります。
市場価格には、顧客の要求に対するプログラマーの作業価格がすでに 含まれていることを理解すべきである。
プログラマーがこのことを理解していなければ、競争力を低下させる運命にある。
要求仕様の価格とコード自体の作業の価格を切り離して顧客に請求する方法を考え出そうという試みは、ユートピアである。
プログラマーの労働力の配分の問題でもなく、価格政策の問題でもなく、顧客がどのような風船主義者で、どのようなプログラマーが常にちやほやされているかという問題でもなく、「仕事」サービスには 発注手続きに重大かつ根本的な欠陥があるという事実、すなわち
1) 施行者は仕事を断ることができるべきである
2) 施行者は仕事のコストを下げることができるべきである
3) 顧客は仕事のコストを上げることができるべきである。
TORの分析と承認に固定料金を設定することは可能である。また、注文が実現するかどうかは別問題である。:)
修理代は、修理の複雑さとスペアパーツの値段によります。
TORの開発とその支払いに関する問題については、「仕事」というサービスでは、すべてが普通に考えられている。顧客はTORを添付し、2番目のボタンを押す。つまり、プログラマーはTORに取り掛かる前に、クライアントに支払い能力があることを確認する。そして、タスクは何度でも編集し、置き換えることができる。
私は、値切り交渉をし、値引きを要求し、支払い能力があるという前提があまりにももっともらしく思えたので、TORの手伝いを引き受けた外国人を相手にしたことがある。
このことから導き出される結論は、プログラマーはルールに従って、顧客が第2ボタンを押すまではTORでの作業を開始しないということである。顧客の支払能力を判断するのに使えるのは、顧客が第2ステップ（TOR）を確認するという事実だけである。それ以外には何もない（多くのインターネット・ユーザーは、ロシア語を話す人も英語を話す人も、暗示と見せかけの技術において完璧を達成している）。
TORを変更した場合の作業コストの修正については、正直なところ、どのように実施すべきかわからない。しかし、プログラマーが作業コストを下げるのも、顧客が上げるのも、なんだか非論理的だ。このような奇妙な可能性を誰が使うだろうか？