Ifthere is even the slightest chance that you will be misunderstood, you will definitely be misunderstood. This truth or the law of meanness (call it as you like) works almost always, and in any field of activity. It can also be attributed to website development.
To give one example, the customer wanted a social network like Facebook, and as a result got a forum for sports fans. Something clearly went wrong. And the developer is to blame, because he did not guess the customer’s desire.
To avoid any problems, you need to correctly and competently draw up the technical task (TK). That is exactly what we will talk about now.
What is a technical task?
The technical task is a list of specific requirements for the future resource. It is important to make the document as detailed as possible. After all, the final result of the site development depends on it.
The main purpose of the TT is to make sure that the customer and the developer understand each other correctly and they equally represent the goals of the project and the content.
Why do you need to make a technical task for the site?
Of course, you can do without a technical task, however, it is not advisable to work in this way, because as a result, the customer may have many questions.
Why do you need this task?
Everything is simple. It simplifies the life of the customer, because:
- determines the preliminary cost of the project;
- accelerates the coordination of basic issues;
- allows you to collect requirements and wishes for the future project;
- specifies how the site should look and work.
- speaking about the performer, it
gives him a clear understanding of the main tasks; - some kind of insurance against performing uncoordinated tasks.
The terms of reference are equally important for both parties. At least because they receive some protection in case of disputes, claims. For example, when delivering the project to the customer did not like the design, the developer can safely refer to the TT, where everything was spelled out in advance.
How to make it up correctly?
Just writing three points on a piece of paper is not enough. Remember that the more detailed the technical task is written, the better. So, what should a competent and correct TT consist of?
The technical task is made by the developer
Only the developer (developer or project manager) can make a good TOR. Obviously, it is he who understands the essence of creating a website the most.
The business owner just needs a finished project and it is probably not so important for him what will be written in the terms of reference. He needs the result. The result is as follows: the developer draws up the TOR, and the customer simply approves it. But at the same time, the customer is directly involved in the process:
- tell the developer about who he is, what his company does;
- get acquainted with the product and the target audience;
- tell why he needs the site and what he wants from it (as advertising or to sell a product/service);
- show examples of resources that the developer can take as a sample.
It is important that both parties work in harmony, because the result of the future project depends on it.
It is necessary to write without ambiguity
Beautiful, reliable, modern – leave these words for writing a blog article. It is better not to use them in the TOR, as they have no specifics.
Avoid vague wording:
- the site should be convenient – convenient for whom?
- the resource should have quality content – what quality content?
- the customer should like the project – and if he got off on the wrong foot?
All wording should be clear, unambiguous. A few examples:
- the resource should load quickly – each page of the site should have at least 80 points in Google PageSpeed Insights;
- the main page should have lists of articles – display the last 4 articles.
Specify information about the company
It is important that each team member understands what the client’s company does and who its target audience is. In order not to get confused in projects, immediately write everything in the TT.
Also write down the purpose of the project, so that in the end you do not get a blog instead of a news project.
Explain complex terms
It is important that there are no complicated words in the ToR. Both parties must understand what they mean. If the developer uses professional slang, you need to explain them to the customer.
For example, not everyone knows what CMS is – the engine on which the site is made, its management system.
Describe the tools and hosting requirements
The TT must specify the tools used in the work so that there are no problems and surprises from the customer. It is necessary to describe the engines, libraries, tools, etc. used. The requirements for hosting are also indicated so that the customer does not have any questions about what PHP and NET are.
Write down the requirements for the site
Obviously, the resource must work in all browsers and on all devices (must be adapted). Yes, it is obvious, but it is better to write it in the TOR. Here you can add requirements for site loading speed, as well as resistance to loads.
Create a site structure
In order for the site to turn out as the customer wants, before its reproduction and layout, you need to agree with the client on the structure of the future project.
For everything to go smoothly, a whole team of professionals should gather: developer; SEO specialist; marketer, etc.
At the stage of drawing the structure, it is decided which pages are needed on the site and how they will be interconnected. It is also important to understand from which page you can go to.
You can visually draw a flowchart. Thus, everything will be clear and accessible to everyone. The structure is the foundation. Keep this in mind.
Explain the content of the pages
The customer should understand what will be on each page of the site. There are several ways to show this:
Create a prototype of each page. The developer visually draws sketches of each page and attaches them to the TT. The customer sees the future elements of the page and says what he likes and what he does not like.
List all available elements. This is a lazy option, where the developer prescribes where each block is located and what it does.
Write down the options for using the site
Customers love to stand out. They can set a difficult task for the developer to create a resource with a non-standard interface. In this case, showing one page structure is not enough. Everyone should understand (the client and all performers) how the visitor will use the finished site.
A simple scenario is suitable for this task: “user action … – … site response … – … – … result”
Let us consider an example. A visitor of an online store decided to place an order. He clicks on the “Order” button – the site opens a simple order form – the user enters the necessary data (phone number, full name, etc.) and clicks “Ok” – the site accepts the application and displays the message “Order placed” – the manager receives an email with the customer’s contact information. Using this scheme, the customer will understand how his site will work and if there is a need to change something, it can be done before the completion of the project.
Decide on the content
Some developers offer a ready-made project with content, others can give an empty site. Some companies offer writing texts for a fee. This should be agreed on the shore. If the customer wants a site with content, then immediately fix what kind of content he expects.
It is true that texts should be unique. But it is important to write everything clearly, in detail. Be sure to note the services on which the texts will be checked. Again, the phrases “high-quality text”, “useful for the target audience” should also be avoided, because there are zero specifics here.
Speaking of articles, there are separate rules for drawing up TK for article authors.
Describe the design
A lot depends on the design of the site, but it is difficult to come up with objective criteria for evaluating this item. The task of the developer is to identify the smallest details.
Find out in what color scheme the customer wants the site and describe it. Clarify whether the company has a brand book and what font format it wants. If the client does not care and he fully relies on the performer, then do not rush to skip this point. Offer your option to prescribe it in the TT, thereby protecting yourself.
Instead of the conclusion
The structure of the technical task In fact, even the phrase “I want an online store” is already a technical task. But it is too vague and does not give any understanding to the customer, and the client himself does not really understand what he means by this phrase.
Often clients, showing an example site, say: “I want such and such”. Of course, this is a little more specific, but it is still not enough. But it is important to understand that the TT should not show the developer how to make the site, it is necessary to understand what exactly it will be. This is an important difference.
Each technical task should have the following structure:
- the purpose of the site;
- information about the company and the target audience;
- explanation of narrowly focused terms used by the developer;
- requirements for the site and layout; hosting requirements and description of the technologies used by the developer;
- detailed structure of the site;
- detailed prototype of the page, where each element and its task is described;
- optional scenario of using the site, if there is a non-standard interface;
- list of content and requirements for it, if it is made by the developer;
- design requirements.
