Reasoning on technical issues
It's no secret that website development companies have problems writing technical assignments. This topic is an attempt to look at the main problems that exist in the writing of technical tasks.
If to understand, all the problems with technical tasks are on the surface, but for people who are trying to solve these problems, they are often not so obvious. Let's try to understand them in detail.
This is probably the biggest problem in the industry of creating websites. The complete lack of standards for development, design and documentation. Technical assignments all write as it should, there is no uniform format, the structure of the document and the requirements for writing it. As a result, managers and analysts responsible for drafting technical tasks, moving from one place to another, begin to write technical tasks in a new format in the image and likeness of documents created in the company earlier. As a result, people can write 3-4 types of documents, each with their own global problems.
Unfortunately, this problem is most likely not solved, at least in the foreseeable future. But to think about solving this problem would not hurt.
')
Who usually writes the terms of reference? This is usually the company's project manager, sometimes, but very rarely, the so-called analyst. Usually, all these people have extremely superficial knowledge about the development of sites, the problems of the architecture of the future site for them is something vague. They are practically incapable of designing, and they should not, I think. But such people write technical specifications in most companies. They do not like the process of writing, he burdens them, they constantly need to consult with the developer on the issues of “how it is implemented”, “and we can”, and so on.
A separate topic is analysts, seemingly a more profiled post. But there are cases when content managers, layout makers and other people distant from analysis as such become analysts. They also write technical assignments with great difficulty, since they also have a superficial understanding of how to do this.
Unlike the problem of standards, this problem has a solution - the allocation of a specialist who will be engaged in writing technical specifications. Of course, such a specialist should have a number of skills and knowledge, such as programming experience and building databases, good knowledge of the systems with which to deal, the ability to understand the protocols that will be used.
The technical task is the cornerstone of development ... Everyone knows this, everyone understands. But why, then, technical tasks are written in the conditions of a severe lack of time? Literally on the knee in the break between the "more important" things. Yes, it can be said that the terms are limited, that an increase in the terms will entail an increase in the cost. But if you calculate the time costs of specialists to correct errors made while writing a technical specification, these will be very significant figures. Much higher than the increase in the time for drafting documents by 20-30 percent.
The solution to this problem lies on the surface - learn to count! If you save a day at the stage of writing a technical task, then you will lose two or even three times more.
What should be contained in the specification? What information? I have seen documents in which even the structure of the future site was not described or integration with the external system was described in the format “the site will be integrated with 1C”. How it will be integrated and with what 1C, it is not known ... There are other extremes, for example, a block diagram of pages within a document. Who needs them there? The programmer and coder will work with the layout and layout, respectively. To the designer? Customer? Perhaps, but why not put them in a separate document application?
Think about what you are writing in the document, find out from the developers what they need to see in the document to lead the development. Formulate content requirements in a technical document.
We talk about such things as user friendliness, client's business tasks, a site as a business tool. But why do we then work with such curves and uncomfortable tools?
The format of the document in 90 percent of cases is inconvenient, the blocks of information merge with each other. The font is unreadable, there are no indents as a class. I have seen documents where the block of information on A4 page did not have paragraphs and was bold. Why, it is not clear.
Develop a style for the document, simple and convenient. With a readable font of normal size, so that it is readable at medium resolution. Consider the format and structure of the document so that it is convenient to navigate. It is so simple, you only need to spend some amount of time and brain.
Perhaps I have not touched on all the problems that exist when writing a technical task. I tried to highlight the key ones.
In any case, the purpose of this topic is to make people who are responsible for writing a technical assignment think about how they do it.
I will be glad to any constructive criticism. If this material will be of interest to the community, I am ready to share my work on the development of technical specifications in the following posts.
If to understand, all the problems with technical tasks are on the surface, but for people who are trying to solve these problems, they are often not so obvious. Let's try to understand them in detail.
Lack of standards
This is probably the biggest problem in the industry of creating websites. The complete lack of standards for development, design and documentation. Technical assignments all write as it should, there is no uniform format, the structure of the document and the requirements for writing it. As a result, managers and analysts responsible for drafting technical tasks, moving from one place to another, begin to write technical tasks in a new format in the image and likeness of documents created in the company earlier. As a result, people can write 3-4 types of documents, each with their own global problems.
Unfortunately, this problem is most likely not solved, at least in the foreseeable future. But to think about solving this problem would not hurt.
')
Human factor
Who usually writes the terms of reference? This is usually the company's project manager, sometimes, but very rarely, the so-called analyst. Usually, all these people have extremely superficial knowledge about the development of sites, the problems of the architecture of the future site for them is something vague. They are practically incapable of designing, and they should not, I think. But such people write technical specifications in most companies. They do not like the process of writing, he burdens them, they constantly need to consult with the developer on the issues of “how it is implemented”, “and we can”, and so on.
A separate topic is analysts, seemingly a more profiled post. But there are cases when content managers, layout makers and other people distant from analysis as such become analysts. They also write technical assignments with great difficulty, since they also have a superficial understanding of how to do this.
Unlike the problem of standards, this problem has a solution - the allocation of a specialist who will be engaged in writing technical specifications. Of course, such a specialist should have a number of skills and knowledge, such as programming experience and building databases, good knowledge of the systems with which to deal, the ability to understand the protocols that will be used.
Time
The technical task is the cornerstone of development ... Everyone knows this, everyone understands. But why, then, technical tasks are written in the conditions of a severe lack of time? Literally on the knee in the break between the "more important" things. Yes, it can be said that the terms are limited, that an increase in the terms will entail an increase in the cost. But if you calculate the time costs of specialists to correct errors made while writing a technical specification, these will be very significant figures. Much higher than the increase in the time for drafting documents by 20-30 percent.
The solution to this problem lies on the surface - learn to count! If you save a day at the stage of writing a technical task, then you will lose two or even three times more.
Document content
What should be contained in the specification? What information? I have seen documents in which even the structure of the future site was not described or integration with the external system was described in the format “the site will be integrated with 1C”. How it will be integrated and with what 1C, it is not known ... There are other extremes, for example, a block diagram of pages within a document. Who needs them there? The programmer and coder will work with the layout and layout, respectively. To the designer? Customer? Perhaps, but why not put them in a separate document application?
Think about what you are writing in the document, find out from the developers what they need to see in the document to lead the development. Formulate content requirements in a technical document.
Document format and style
We talk about such things as user friendliness, client's business tasks, a site as a business tool. But why do we then work with such curves and uncomfortable tools?
The format of the document in 90 percent of cases is inconvenient, the blocks of information merge with each other. The font is unreadable, there are no indents as a class. I have seen documents where the block of information on A4 page did not have paragraphs and was bold. Why, it is not clear.
Develop a style for the document, simple and convenient. With a readable font of normal size, so that it is readable at medium resolution. Consider the format and structure of the document so that it is convenient to navigate. It is so simple, you only need to spend some amount of time and brain.
Perhaps I have not touched on all the problems that exist when writing a technical task. I tried to highlight the key ones.
In any case, the purpose of this topic is to make people who are responsible for writing a technical assignment think about how they do it.
I will be glad to any constructive criticism. If this material will be of interest to the community, I am ready to share my work on the development of technical specifications in the following posts.
Source: https://habr.com/ru/post/91309/
All Articles