Technical task - To be or not to be?

Read an article by Stanislav Malkin - For customers: if there is no TZ .

In general, everything is written correctly, consistently and clearly.
The promising conclusion was made - to be a technical task - to be! (Definitely! I said! © Zhirinovsky)

And to be him, according to Stanislav, should be in three options:

1. TK written by the customer.
2. TK is written by the developer of the ordered system.
3. TK is written by a professional compiler of TZ.

')
I think that the first option has the right to life only if the customer already has experience in writing TK, based on the second and / or third option.
For now let's skip the second option and turn immediately to the third. As far as can be judged by the article - Stanislav considers this option the most acceptable, especially for novice customers. However, I see much more disadvantages than indicated in the article (the only specified minus is the additional costs of writing the technical specifications):

• Quality.
  Based on what the customer will be able to judge how well written terms of reference. There are no clear evaluation criteria. Yes, there are all sorts of GOSTs for writing technical assignments, but they very quickly become obsolete, and for Internet technologies they can only be of a recommendatory nature. But GOSTs do not allow to determine the quality of the written technical specifications.
• Time.
  To write a high-quality technical task, a technical writer must sufficiently study the subject area. What is the minus here you ask - and the minus is that no matter how high quality, more precisely, the technical task is written - the end developer will have to spend the same time studying.
• Standards.
  There are no common standards. GOSTs are, no one argues, but GOSTs rather determine the format of the document, not the content and form.
  Imagine a situation - the customer comes to the developer with a TK written by a third party. If the developer is not a novice, he should already have his own internal standard for writing TK. The TK delivered naturally will not meet him and, most likely, the developer will insist on not rewriting the TK to his standard, to his habits. Certainly brought TZ will be supplemented and expanded in order that it was clear to the final developer.
  Total - at this stage, the customer will lose time, money and nerves.
• Big Brother.
  How to behave to the customer if, having brought the written by someone TZ, the final developer will say - “Who wrote you this shit? That's bullshit! This is how we see it ... ”The effect of this way of writing TK may be the opposite - the customer not only doesn’t save his nerves, time and money in general (having a good TK saves money - take my word for it :)), but also seriously worsen the relationship with the developer.

So, based on what was written, the conclusion is clear - the most correct way to write TK is to create a triple: developer-customer-technical writer (professional in compiling TK) . In this case, most likely, everyone will be satisfied. Although practice shows that the developers exclude a third party (technical recorder) and make up the TZ independently, well, naturally with the participation of the customer.

And finally, a few links:
Habrahabr
TK: layouts or text?
TK for web developer
About GOSTs
How to write a technical task?
Classic
Yuri Shilyaev - What is good TK on the site?

Cross post from my blog.