Technical task: how to protect yourself from mistakes and risks
What to do if the development of TK is not the most difficult project takes a couple of months? What steps in the development of TK can protect against risks and mistakes? In this article we will consider the problem of not the content of the document, but the methodology for its development.
Technical task - only part of the project. Be it a startup or a new service inside an existing product.
In any case, the TK should present the fantasies of Customers and Executors in an adequate and possible form for realization. When we talk about development methodology, it’s not worth dividing TK into TK for small or large projects. This is always a serious document, in which case the developer of the technical task (and the manager, of course) will be guilty.
Stages of development of technical specifications
')
1. Preliminary study of the brief / task
As a rule, there is an ephemeral idea of ​​what the customer wants - in the form of a brief, a letter with Wishlist, TK. Examine the subject area, make a list of questions.
Collect information about the company, market, customers, competitors. Viewed information will give you an understanding of the customer's business, which, in turn, will lift you up in his eyes.
2. Meeting
Always make a specific list of questions and slowly find out everything from the customer.
Do not hold the meeting as a survey, the customer may feel at the interrogation and withdraw. You should start with “tell us about the project that you expect to receive from it”. The customer will relax, they will talk a lot, and in the meantime, you will take notes that coincided with your vision and understanding, and what does not.
Fix the answers next to the questions, re-read them.
If the answer is not received (it happens that the customer answers the question in the abstract, and as a result there is no answer), ask the question again, changing the wording. For example, “I imagine this functionality so ... Do I understand you correctly? Does this coincide with your vision? ”
Do not be afraid to ask questions, no matter how unexpected they may seem. Many things are so obvious inside a particular business that you may forget to mention them.
3. Concept development
The concept usually contains a brief summary of the future TK, namely:
Always develop a concept - an outline of a future project. Often, this allows you to reduce risks, as well as to dot the i and for you and for the customer.
4. Clarification of requirements
After approval of the concept, you specify and formalize the missing requirements. Fix the requirements in the TZ, form them into ready-made blocks with descriptions (and preferably with interfaces). It is easier for the customer to perceive information about what he wants when there is a graphic accompaniment of the described requirements.
Go through several iterations on the development of TZ, each time complementing and changing the document according to the customer's comments.
Even if everything seems clear and obvious, you need to ask the question whether you understand correctly. This will reduce a lot of time and nerves. Even speaking of simple news, you should not forget that there are concepts of “publication frequency”, who updates, what materials can be in the news, etc. From answers to such questions, the structure of the page and the priority of information can change dramatically.
5. TK approval
Customers are divided into two types - those who are not serious about TK and think “they will do it anyway, as I say,” and those who are trying to fit into the TK what is possible and impossible. In the project it is important to make a good working product. No excess.
An example of an argument for splitting a project into stages: “Let's first implement a good working version, with basic functions, and then we will refine and come up with additional features. But in the opportunity described by you, we initially pawned. "
Try to always think about who will use the product. Providing all the features to the user is possible, but either to the detriment of convenience, or to the detriment of the implementation time.
1. Breaking deadlines
Sometimes it happens that there is no so-called muse to write a document. Sit down, read an interesting book, watch an interesting show or cartoon. No need to "surf the net." New emotions from a book or scanned can greatly develop the imagination, give strength and inspiration. Do not postpone everything to the very last day.
Do not give a false idea of ​​the timing of the project and your capabilities; put deadlines in the work plan for approval. Plan the time allotted for the project: paint the days by tasks, and stick to the developed schedule.
2. Price-time-scope of work
Always think that any task has a deadline and price. It is important to suggest solutions that do not abstract from these values.
3. Feedback
Always answer letters and calls. For the customer is important the presence of feedback from you. He must be sure that in the event of controversial issues, questions, clarifications, he can call or write and get answers.
4. Try to fix everything you agree on.
All wishes of the customer, transferred to you in a conversation or in person, confirm with a letter listing the items to be carried out; Spell out the deadlines for the above.
If the customer sends 15 letters a day with wishes, ask the customer to collect wishes in one letter. So you reduce the risk that some of the information will be lost in the correspondence, and you will have to spend time on making changes.
5. Present the result
Many ideas are rejected because they were not filed with the correct description. For example, if a customer wants to implement a function in one way, and you disagree with it, develop your version, justify it, describe the idea of ​​implementation, and tell about the advantages of your solution.
Try not to do only as desired by the customer. As a rule, the worst option in this case will be accepted.
When you are not the first time working on the creation of technical specifications, follow your own rules. For example, the rules may be the following:
Mental maps
Technique Mind Maps. Develop TK with mental maps. The essence of the process is that you initially draw the future project in the form of a diagram. You divide the product into entities, concepts; at the same time in each paragraph of the tree should not be more than 3-4 words. Such a scheme is quickly read by all project participants, it is easy to change and supplement the tree. There are many programs for developing such maps.
Versions and file names
Name the files correctly. For example, it can be the name of the project - coded or entirely. Write in the name of each file version. So it will be easier for you to understand which file was the last.
From experience it is convenient to make the names and versions of the following:
NameProject.0.1.doc ,
Where NameProject is the name of the project,
0 - the version sent to the client; if 0 - it means that it was not sent while working within the company (department);
1 - the version that you create within the company (department).
For example, you sent version 0.1 to a client, while working on the TOR further. You are creating version 0.2, because this is a change, but already your internal or within the company. You receive comments from the client and create an even newer version - 1.3.
If there are several documents (for example, concept, TOR), add the document type in the document name - NameProject.Concept.0.1.
Structure
Have a clear structure for TK. When collecting information as well as developing a document, follow it. Depending on the expectations of the customer, there are 4 alternatives for selecting the specification template. This can be a GOST, IEEE, Corporate template, your own template (or a company template in which you work).
Formatting
A good document is a literate and well-formed document. Well-designed documents are easy to read, because there are no dozens of styles in them, a multitude of blocks of text of various designs.
findings
Try new templates, description formats. You are the one who can solve a business problem by proposing a competent and good solution; the one who can make users of the product happier (at the expense of a convenient and logical interface). Appreciate yourself and your time, because the finished product is the result of your efforts.
What and how
Technical task - only part of the project. Be it a startup or a new service inside an existing product.
In any case, the TK should present the fantasies of Customers and Executors in an adequate and possible form for realization. When we talk about development methodology, it’s not worth dividing TK into TK for small or large projects. This is always a serious document, in which case the developer of the technical task (and the manager, of course) will be guilty.
Stages of development of technical specifications
')
1. Preliminary study of the brief / task
As a rule, there is an ephemeral idea of ​​what the customer wants - in the form of a brief, a letter with Wishlist, TK. Examine the subject area, make a list of questions.
Collect information about the company, market, customers, competitors. Viewed information will give you an understanding of the customer's business, which, in turn, will lift you up in his eyes.
2. Meeting
Always make a specific list of questions and slowly find out everything from the customer.
Do not hold the meeting as a survey, the customer may feel at the interrogation and withdraw. You should start with “tell us about the project that you expect to receive from it”. The customer will relax, they will talk a lot, and in the meantime, you will take notes that coincided with your vision and understanding, and what does not.
Fix the answers next to the questions, re-read them.
If the answer is not received (it happens that the customer answers the question in the abstract, and as a result there is no answer), ask the question again, changing the wording. For example, “I imagine this functionality so ... Do I understand you correctly? Does this coincide with your vision? ”
Do not be afraid to ask questions, no matter how unexpected they may seem. Many things are so obvious inside a particular business that you may forget to mention them.
3. Concept development
The concept usually contains a brief summary of the future TK, namely:
- Targets and goals;
- Purpose;
- Roles;
- Structure;
- Content;
- The list of opportunities (in the form of services - briefly).
- Sometimes a concept contains a detailed description of a business idea, in order to understand how a project is won.
Always develop a concept - an outline of a future project. Often, this allows you to reduce risks, as well as to dot the i and for you and for the customer.
4. Clarification of requirements
After approval of the concept, you specify and formalize the missing requirements. Fix the requirements in the TZ, form them into ready-made blocks with descriptions (and preferably with interfaces). It is easier for the customer to perceive information about what he wants when there is a graphic accompaniment of the described requirements.
Go through several iterations on the development of TZ, each time complementing and changing the document according to the customer's comments.
Even if everything seems clear and obvious, you need to ask the question whether you understand correctly. This will reduce a lot of time and nerves. Even speaking of simple news, you should not forget that there are concepts of “publication frequency”, who updates, what materials can be in the news, etc. From answers to such questions, the structure of the page and the priority of information can change dramatically.
5. TK approval
Customers are divided into two types - those who are not serious about TK and think “they will do it anyway, as I say,” and those who are trying to fit into the TK what is possible and impossible. In the project it is important to make a good working product. No excess.
An example of an argument for splitting a project into stages: “Let's first implement a good working version, with basic functions, and then we will refine and come up with additional features. But in the opportunity described by you, we initially pawned. "
Try to always think about who will use the product. Providing all the features to the user is possible, but either to the detriment of convenience, or to the detriment of the implementation time.
Difficulties and how to avoid
1. Breaking deadlines
Sometimes it happens that there is no so-called muse to write a document. Sit down, read an interesting book, watch an interesting show or cartoon. No need to "surf the net." New emotions from a book or scanned can greatly develop the imagination, give strength and inspiration. Do not postpone everything to the very last day.
Do not give a false idea of ​​the timing of the project and your capabilities; put deadlines in the work plan for approval. Plan the time allotted for the project: paint the days by tasks, and stick to the developed schedule.
2. Price-time-scope of work
Always think that any task has a deadline and price. It is important to suggest solutions that do not abstract from these values.
3. Feedback
Always answer letters and calls. For the customer is important the presence of feedback from you. He must be sure that in the event of controversial issues, questions, clarifications, he can call or write and get answers.
4. Try to fix everything you agree on.
All wishes of the customer, transferred to you in a conversation or in person, confirm with a letter listing the items to be carried out; Spell out the deadlines for the above.
If the customer sends 15 letters a day with wishes, ask the customer to collect wishes in one letter. So you reduce the risk that some of the information will be lost in the correspondence, and you will have to spend time on making changes.
5. Present the result
Many ideas are rejected because they were not filed with the correct description. For example, if a customer wants to implement a function in one way, and you disagree with it, develop your version, justify it, describe the idea of ​​implementation, and tell about the advantages of your solution.
Try not to do only as desired by the customer. As a rule, the worst option in this case will be accepted.
Little recommendations
When you are not the first time working on the creation of technical specifications, follow your own rules. For example, the rules may be the following:
Mental maps
Technique Mind Maps. Develop TK with mental maps. The essence of the process is that you initially draw the future project in the form of a diagram. You divide the product into entities, concepts; at the same time in each paragraph of the tree should not be more than 3-4 words. Such a scheme is quickly read by all project participants, it is easy to change and supplement the tree. There are many programs for developing such maps.
Versions and file names
Name the files correctly. For example, it can be the name of the project - coded or entirely. Write in the name of each file version. So it will be easier for you to understand which file was the last.
From experience it is convenient to make the names and versions of the following:
NameProject.0.1.doc ,
Where NameProject is the name of the project,
0 - the version sent to the client; if 0 - it means that it was not sent while working within the company (department);
1 - the version that you create within the company (department).
For example, you sent version 0.1 to a client, while working on the TOR further. You are creating version 0.2, because this is a change, but already your internal or within the company. You receive comments from the client and create an even newer version - 1.3.
If there are several documents (for example, concept, TOR), add the document type in the document name - NameProject.Concept.0.1.
Structure
Have a clear structure for TK. When collecting information as well as developing a document, follow it. Depending on the expectations of the customer, there are 4 alternatives for selecting the specification template. This can be a GOST, IEEE, Corporate template, your own template (or a company template in which you work).
Formatting
A good document is a literate and well-formed document. Well-designed documents are easy to read, because there are no dozens of styles in them, a multitude of blocks of text of various designs.
findings
Try new templates, description formats. You are the one who can solve a business problem by proposing a competent and good solution; the one who can make users of the product happier (at the expense of a convenient and logical interface). Appreciate yourself and your time, because the finished product is the result of your efforts.
Source: https://habr.com/ru/post/139835/
All Articles