Discussion of article "How to create Requirements Specification for ordering an indicator" - page 3
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Mind blowing. Can we see what was meant in the end? Did the customer provide pictures initially or was it all just words at first?
Rashid, there are many pages of discussion - it's superfluous here, and I haven't made the indicator yet - the deadline is not yet looming, and other things are more important.
In my opinion, there are too many technical details in the article, which the customer will never get through.
Let's make links for the article, as is our custom. You will be able to immediately see the necessary section and jump to it - without even reading the whole article
Example - MQL5.community - User's Guide
1. Profile settings
2. Message Editor
3. Favourites
4. Private Messages
5. Service Desk
6. Work and calculations
7. Market
8. Signals
9. RSS
10. Rating
11 MQL5 Storage
The main thing for the customer is to have a clear idea of what he really wants. In order to get this idea, before going to freelancing, it would be good for the customer to try to make a simplified scheme of the indicator/expert in Excel and provide his scheme with screenshots: how this or that signal looks on the chart.
A good wish. Although it seems to me that none of the customers do it.
That's a good point. Although I don't think any of the customers do.
That's the problem.
None of them thinks in the logic of functions, formalisations and what is called for what. As they say, if grandma had a grandfather, she would be a grandfather.....
The customer perceives the chart 100% visually. Even the concept of buffer is a dark forest for them.
The customer looks at the chart and wants a line to be drawn here, this height, this width. Approaches and explanations are very specific
This is the base on which Rashid should stay. Do not even try to expand his horizons, because he will get loaded and will not do anything that you are trying to do from him, because he needs to revise his views on life, and this is a long time, and you need an indicator for yesterday.
---
It is necessary to leave the customer strictly within the framework of his concepts (which he has already invented when applying to freelancing).
And just not to the customer, but to the coder to give this template questionnaire, on which he will ask the customer for data on points and write them according to your standard.
And everything beyond that is pure communication, which (unlike writing trade experts) cannot be formalised in any way.
I mean, here's a suggestion.
- change the approach to the concept of ToR.
Now it is not a correspondence or txt or doc with pictures, but an unkillable attribute of the application itself. It is not an attached document, but a component of the service (in the form of a generated xml document).
It is the TOR in the application, drawn up with the help of your wizard and signed by both parties will be a document.
Attitude of the customer
- if you really want to load the customer with information about MT capabilities, you should not require the customer to fill in all fields when creating an application. It is enough to get from him what he was able to identify in his head within the framework of algorithmic and MQL concepts. Tick off some options for styles, graphics, etc..
Coder's attitude
- the coder is responsible for drawing up the complete TOR and formalising all the customer's functions.
He communicates with the customer, fills in the TOR component in detail, prescribes precise algorithms and concepts so that they are perceived by the customer and approved. That is, TOR creation is a process of communication and approval. TK is a part of the order.
Even if the coder refuses to work - the worked TK remains in the order and another executor can continue to work with it. The new contractor will not see the correspondence, but will see its result - TOR.
---
That's when the sheep are intact and the customer's brain is not broken.
The customer is satisfied - the coder understood him and made the TOR for him.
The coder is satisfied - he made the approved TOR with the help of the wizard, and it is open, not cramped.
The arbitrator is satisfied - no need to read third-party docs, but only to view the completed TOR document in the request.
In the future it will be possible to collect statistics on these docs, as the TOR itself is now a formal document.
---
It is necessary to leave the customer strictly within the framework of his concepts (which he has already made up for himself when applying to freelancing).
And just not to the customer, but to the coder to give this template questionnaire, according to which he will ask the customer for data on items and write them according to your standard.
And everything beyond that is pure communication, which (unlike writing trade experts) cannot be formalised in any way.
We should try. In the process of discussing this thread, I think I'm starting to change the concept of the article a bit. There will be added emphasis on drawing explanatory figures, some examples of TORs will be given, and then the current content will follow. For those who can get through the first two paragraphs.
I mean, I propose this
- change the approach to the concept of ToR.
Now it is not a correspondence or txt or doc with pictures, but an unkillable attribute of the application itself. It is not an attached document, but a component of the service (in the form of a generated xml document).
It is the TOR in the application, drawn up with the help of your wizard and signed by both parties will be a document.
I doubt that this is the way to drive mankind to paradise. To reinterpret a classic:
I doubt that's the way to get mankind into heaven. Reinterpreting a classic:
no matter how we excuse a coder from writing the TOR, but in the end it is the coder who verifies it, and the complexity of its verification is included in the budget.
That is, the customer pays for it in the end (pays for the coder's time), thinking that it is such an expensive programming, and not formalisation of his TOR).
There will be added emphasis on making explanatory drawings, some examples of TOR will be given, and then the current content will go. For those who can cope with the first two points.
yes, more screenshots or micro gifs.
especially in the wizard to make a decision on the part of the customer - what type of indicator to specify in the ToR, or what kind of lines. Not just words, but how it will look like. Because that is how he reasoned - what I will see in the end and whether it corresponds to his idea.
especially in the wizard to make a decision on the part of the customer - what type of indicator to specify in the ToR, or what kind of lines. Not just words, but how it will look like. Because this is how he reasoned - what I will see in the end and whether it corresponds to his vision
Master TK is not planned yet. Here it would be first useful article to make and evaluate the result of its appearance
Master TK is not planned yet. Here it would be first to make a useful article and evaluate the result of its appearance
Yes, for now I meant a hint article under the master.