記事"インジケーターの開発を依頼するための要件定義を作成する方法"についてのディスカッション - ページ 3

新しいコメント
 
Rashid Umarov:

心を揺さぶる。最終的に何が言いたかったのかわかりますか？顧客が最初に写真を提供したのか、それとも最初は言葉だけだったのか？

ラシード、議論は何ページもある。ここでは余計なことだし、私はまだ指標を作っていない。締め切りはまだ迫っていないし、他のことの方が重要だ。

 
Vasiliy Sokolov:

私の意見では、記事には技術的な詳細が多すぎて、顧客は決して理解できないだろう。

私たちの習慣に従って、記事にリンクを張りましょう。そうすれば、記事全体を読まなくても、必要なセクションをすぐに見ることができ、そこに飛ぶことができます。

例 -MQL5.community - ユーザーガイド

1.プロフィール設定
2.メッセージエディター
3. お気に入り
4.プライベートメッセージ
5.サービスデスク
6.仕事と計算
7.マーケット
8.シグナル
9.RSS
10.レーティング
11 MQL5 ストレージ

 
Vasiliy Sokolov:

顧客にとって重要なことは、顧客が本当に望んでいるものを明確に把握することである。このアイデアを得るために、フリーランスになる前に、顧客がエクセルでインジケータ/エキスパートの簡略化したスキームを作成 し、そのスキームをスクリーンショットで提供するのが良いでしょう。

良い願いだ。しかし、それをする顧客は皆無のようです。

 
Rashid Umarov:

それはいい指摘だ。でも、お客さんの中にはそんな人はいないと思うよ。

それが問題なんだ。

誰一人として、関数や形式化、何に対して何が呼ばれるかというロジックで考える人はいない。おばあちゃんにおじいちゃんがいたら......と言われるようにね。

顧客は100％視覚的にチャートを認識する。バッファーという概念さえ、彼らにとっては暗い森なのだ。

顧客はチャートを見て、ここに線を引いて ほしい、この高さで、この幅で、と求める。アプローチと説明は非常に具体的


これがラシードがとどまるべきベースだ。彼の視野を広げようとしてもだめだ。なぜなら、ラシードには人生観を見直す必要があるからだ。

---

フリーランスに応募する際、彼はすでに考案した）彼の概念の枠組みの中で厳密に顧客を残すことが必要である。

そして、顧客にではなく、コーダーに このテンプレートの質問票を渡すだけで、彼は顧客にポイントのデータを求め、あなたの基準に従ってそれを書く。

そして、それ以上のことはすべて純粋なコミュニケーションであり、（ライティングの専門家とは違って）いかなる形でも形式化することはできない。

 

つまり、これが提案だ。

- ToRの概念へのアプローチを変える。
ToRは、通信文やtxtや画像付きドキュメントではなく、アプリケーション自体の実行不可能な属性です。
これはアプリケーションの TOR であり、ウィザードの助けを借りて作成され、両者が署名した文書になります。

顧客の態度
- もし本当に MT の能力に関する情報を顧客に提供したいのであれば、アプリケーションを作成するときに、 顧客がすべてのフィールドに記入することを要求すべきではありません。アルゴリズミックとMQLの概念の枠組みの中で、彼が頭の中で特定できたことを彼から得るだけで十分です。スタイルやグラフィックなどのオプションにチェックを入れてください。

コーダーの姿勢
- コーダーは、完全なTORを作成し、顧客のすべての機能を形式化する責任がある。
彼は顧客とコミュニケーションをとり、TORの構成要素を詳細に記入し、正確なアルゴリズムと概念を規定し、それらが顧客に認識され、承認されるようにする。つまり、TORの作成はコミュニケーションと承認のプロセスである。TKは発注書の一部である。
たとえコーダーが作業を拒否しても、作業済みのTKは発注書に残り、別の実行者がそれを使って作業を続けることができる。新しい契約者は通信を見ることはできないが、その結果である TOR を見ることができる。

---

羊が無傷で、顧客の脳が壊れていないときだ。


コーダーは満足する。ウィザードの助けを借りて承認されたTORを作成したが、それは窮屈なものではなく、オープンなものであった。
仲裁人は満足する。サードパーティのドキュメントを読む必要はなく、リクエストの中で完成したTORドキュメントを見るだけでよい。

将来的には、TOR自体が正式な文書となるため、これらの文書に関する統計を収集することが可能になるだろう。

 
o_o:

---

顧客のコンセプト（フリーランスに応募する際に、顧客自身がすでに作り上げているもの）の枠内に、厳格に委ねることが必要である。

そして、顧客にではなく、コーダーに このテンプレートのアンケートを渡し、それに従って、彼は顧客に項目のデータを求め、あなたの基準に従ってそれを書く。

そして、それ以上はすべて純粋なコミュニケーションであり、（ライティングの専門家とは違って）形式化することはできない。

やってみるべきだ。このスレッドを議論する過程で、私は記事のコンセプトを少し変え始めているように思う。説明用の図を描くことに重点を置き、TORの例をいくつか示し、その後に現在の内容が続く。最初の2段落を読み切れる人のために。

 
o_o:

つまり、私はこう提案する。

- ToRの概念へのアプローチを変える。
今、ToRは、通信文やtxtや画像付きドキュメントではなく、アプリケーション自体の殺すことのできない属性です。
アプリケーションのTORであり、ウィザードの助けを借りて作成され、両当事者によって署名された文書になります。

私は、これが人類を楽園に導く方法であるとは思わない。古典を再解釈すると

「仕様書を売ることはできない（誰もそれにお金を払いたがらないという意味で）。

しかし、コーダーを雇うことはできる。"

 
Rashid Umarov:

それで人類が天国に行けるとは思えない。古典の再解釈

「技術仕様を売ることはできない（誰もそれにお金を払いたがらないという意味で）。

しかし、コーダーを雇うことはできる。

コーダーがTORを書くことをどう言い訳しても、結局それを検証するのはコーダーであり、その検証の複雑さは予算に含まれている。

つまり、顧客は、TORの形式化ではなく、そのような高価なプログラミングであると考え、最終的にその代金を支払う（コーダーの時間を支払う）のである。）

ラシッド・ウマロフ：

今後、説明用の図面を作成することに重点を置き、TORの例をいくつか示し、その後、現在の内容を進めていく。最初の2点に対処できる人のために。

そう、スクリーンショットやマイクロGIFを増やす。

特にウィザードでは、TORにどのようなインジケータを 指定するか、あるいはどのようなラインを指定するか、といった顧客側の判断が必要になる。言葉だけでなく、どのように見えるか。最終的に私が何を見るか、それが彼の考えと一致するかどうか。

 
o_o:

特にウィザードでは、ToRにどのような指標を 明記するか、あるいはどのような線を引くか、といった顧客側の決断が求められる。言葉だけでなく、どのように見えるか。最終的に私が何を見るか、そしてそれが彼のビジョンと一致するかどうか。

マスターTKはまだ計画されていない。ここでは、その外観の結果を作成し、評価するための最初の有用な記事だろう

 
Rashid Umarov:

マスターTKはまだ計画されていない。ここでは、まず役に立つ記事を作り、その見た目の結果を評価することになるだろう

そうですね、今のところはマスターの下にヒント記事を作るということです。

12345678
新しいコメント