How to write good specifications for development to avoid constant improvements?

Question

Agile

Colleagues,
there is a problem.
We are a small company. About 40 people are involved in the development, about the same number of project managers. Five people are engaged in the "Product". In JIRA, we have two separate processes: for functional specifications and for technical ones. The first process gradually flows into the second and from there floats into development. However, almost always there is such a "surprise" that the client wanted a square stool, and as a result they try to sell him a round chair. After all, it performs the function :)
Now the following is happening:

1. The client tells the PM what functionality is needed.
   
2. The PM makes a "request" in the form of a couple of sentences from the Product Manager.
   
3. The product "chews" this request into functional components.
   
4. Next, the Development Team Lead discusses them with the product and compiles Jira Stories for developers.
   
5. The developer did everything, sent it to the tester.
   
6. The tester checked everything and sent the PM.
   
7. And then fierce ping-pong periodically begins from the series: “no-no-no, I need something else” “oh, I also forgot this one” “can I have mother-of-pearl buttons” > as a result, a lot of friction and loss of time. Sprint constipation.
   

How do you solve the problems of weak specifications?

Answer 1

The most reasonable thing is to make prototypes. In this case, no matter how weak the specifications are, the client will eventually get what he wanted for a relatively reasonable price (compared to reworking the finished functionality).
It will never be possible to describe everything, especially with such a long process and a large number of responsible links.

Answer 2

At the seventh point, who starts to say that everything is wrong? PM or Client?
If the Client, then PM-and on the soap, since he cannot understand what the client wants, and passes on the corrupted data.
Also, why do you have a tester at the very end?
Usually the tester checks and writes the requirements, so he must be
a) competent
b) be present in paragraph 2 or even 1

Answer 3

Several iterations of discussion with the customer about his wishes can help. It is better that the person who makes the requirements does it.

Answer 4

Two poles - a prototype and TK with a detailed specification.
User stories hang in the middle, but they are closer to prototyping, although you can connect them with the specification as the first stage.
Another dimension is frequency, the more the better.
Test scripts can help a lot (the same user stories, in fact): detailed steps on how we will check the development, what should be the output, how the user will check. In this way, in theory, we remove most of the risks.