Technical assignment to the site
UPD: Continuation of the article with an example of a technical task
Not so long ago, there were two articles on Habré ( according to the technical specifications and Why do I need TZ? I already know! ) Dedicated to technical specifications. I have both articles caused, to put it mildly, bewilderment, especially the article "According to the technical task." In my opinion, this is generally harmful article, which leads to the misunderstanding of the essence of TK. In this regard, I want to express my view on this question. I will not talk about all those. tasks, the topic is too wide, but I think I can tell you about the TK on the site.
The description of the technical specification, which will be discussed below, is not a retelling of the GOST, but rather is its creative processing, well-flavored with bitter experience. The TK approach described below does not cover all aspects of site building, but sets the general direction.
')
Most sites can be attributed to small and very small projects, the scale of the units of man-months. Due to their small size, such projects can be easily thought out and easily implemented using a waterfall model, it’s enough just not to be lazy at every stage of development (from writing TK to project delivery). There is no sense in applying flexible development methodologies to these projects, and it makes sense to apply good TK. For those sites that do not fall under the waterfall model, you should not apply the approach described below.
And why do you need to TK site? The customer says: “We need the following site: product catalog, shopping cart, order form, delivery, we are on the map, about us, feedback.” What is not clear? Nothing unusual, everything is ordinary and routine.
The developer clearly understands what needs to be done, but to do it, in his understanding, is needed like this:
At the end of the work comes the design from the customer, and when viewing it, it becomes clear that the customer understands the problem a little differently. Namely:
And here it turns out that the initial estimate of the scope of work (and, accordingly, the deadlines and cost of the project), which the developer made on the basis of his conclusions and voiced to the customer, differs from what the customer actually wants.
If we “subtract” one picture from another, make a diff, so to speak, then we will get the difference in the customer’s expectations and the developer’s plans. And this difference can be quite significant:
And here a conflict arises, where each of the parties is right: the customer did not receive what he expected for the agreed price, they are trying to “sell” him; the performer believes that he did everything exactly with the order, and the rest of the Wishlist - this is an attempt to "prokidit" it. This conflict can be resolved in different ways: either the customer accepts what is, or the developer completes everything for free, or both sides make mutual concessions. But in any case, there will be victims.
So, the task of the technical task is to minimize the difference between the views of the two parties: the customer and the contractor. A good TK gives a small diff, a bad TZ - a big one.
However, there is a very important point: those. The task should not and cannot reduce diff to zero! Let me explain why.
Both diff and TK have their value, and the value needs to be understood more broadly than just money. These are money, time, wasted nerves, spoiled relations, etc.
The cost of diff is the cost of initially unspecified modifications, the cost of the TK is, in fact, the cost of the TK. The more detailed and detailed the technical task, the higher its cost, but the smaller the value and cost of the diff, and vice versa.
If we consider the two extremes, when those. There is simply no assignment, none at all; in general, and we did photo hosting, and the customer wanted an online store, the diff will be equal to the whole project, and its cost will be equal to the cost of the project (we will have to throw out our photo hosting and make the store). In this case, the cost of the TOR is zero. At the other extreme, this is when the technical task is the actual project itself, i.e. it is fully detailed, i.e. up to lines of code, variables and css styles. In this case, the diff is zero, and the cost of the TOR is equal to the cost of the project (since the TK is already an implementation). And between these extremes is the reality, which is reflected in this graph:
The blue line is the cost of the TZ, it grows with increasing detail, the red line is the cost of diff, and its value, on the contrary, decreases with increasing detail.
The blue line indicates the total cost of the TK and alterations to be completed upon completion. As can be seen from the graph, this total value has a minimum value. Those. from a certain point, it becomes cheaper to fix the customer’s wish at the end of the work than to perfect the TK.
Hence the important conclusion: TK should describe the project well, but no more than that .
The approach described below will claim to be a TK with a degree of detail close to optimal.
A technical task is a document, a part of a contract (it does not matter if it is an agreement with seals and signatures, or only a verbal agreement) that regulates what works should be performed. All that is described in the TK should allow for an objective assessment. Those. There should be objective criteria by which it can be determined whether a particular item is made or not.
Based on this, it turns out that in the technical task there should not be a speech about design. Anyway, the task is technical, not artistic. The design does not lend itself to an objective assessment of what one likes, the other does not, and there are no objective criteria by which one can say whether a design is good or not.
The implementation of the design with the formulation of the task “in green tones, and that would be wood,” can be both a bad work and a masterpiece (and what is especially sad, the customer may not like both options). In short, fulfilling the objective criteria describing the design can lead to poor results.
In general, TK should be written as if you did not agree with the customer and your dispute will be dealt with in court, based on the text of those. tasks. And in your TZ it is written “to make a design that will appeal to the customer”. The judge asks: "Customer, do you like the design?". Customer: "No, Your Honor!". Judge: “Contractor, I award - 2 years of snow removal in Siberia for non-compliance with the terms of reference!”.
The wording should be “closed”, i.e. clearly indicate the boundaries of our work. In the TZ can not be written "admin panel should be comfortable." Convenience is a subjective factor, it is convenient for someone so, for someone else, and in the case of a dispute it will be difficult to establish who is right. The phrase "admin should be comfortable" can lead to endless alterations: "add to the admin panel to the list of products sort by columns and filtering. Without this, it is not convenient. And it is not convenient to add the loading of goods from Excel one by one. ”
“Everything that is not specified is performed at the discretion of the performer” - despite the severity of this statement, this phrase should be present in the TK. It derives from the very essence of the task: the customer wants to get a certain product, but he cannot and should not indicate how the final result will be achieved. This item protects against interfering with the depths of work (it was not enough for the customer to begin telling how to name the functions in the code and which packages to use), but also negates the ability of the customer to have any wish-list. In my opinion, it is worth going to the customer in a meeting in the Wishlist, until it goes beyond the bounds of decency. When patience breaks, we will need this item. As the song says: "We are peaceful people, but our armored train is on the siding." (The phrase “what is not specified is at the discretion of the performer”, it’s better to stick in the end of the TK, at the beginning it can be met with hostility. But if the TK is normal and at the end is this phrase, they will not protest against it).
Those. A task is a document that the customer gives us (It doesn’t matter that we write it. According to the meaning of this task, the technical task, and the task is given by the customer to the contractor, that is, to us). And from this it follows that the TK should contain formulations that tell us what to do (such as “the site should contain”, “there should be an opportunity”). In some TK I have seen, the wording of the form “there will be this and that on the site” is an incorrect wording, this is some kind of notification of the customer that will be done, but the document is called “task” and not “notification” .
This section brings up to date. Proceed from the fact that you need to give the TK to a third-party programmer, and you will not be in touch all the time working on the project until delivery. Those. the programmer should take the TK, and he should not have a single question, and the first question he could ask is: “What about the site will we do?” The section “Common words” in a free form answers this question.
In short, operational assignment is the benefit that a site should bring. In general, most often, the benefit comes down to money (if the site is somehow tied to commerce, and most of them), and in the section one could always restrict ourselves to writing that the operational purpose of the site is to earn extra money, but we will not be so cynical. Let us stop a step earlier, immediately before the "earn some money." For an online store, this will be a sale of goods (from which we will receive money), for a discount site it is to dock customers and vendors or service providers (to get a percentage of money from this), for a business card site, to advertise on the Internet (and advertising is needed to get money), etc.
This item is closer to the point. Here is a brief list of what technical means we want to get the profit described in the previous paragraph. For example, for an online store, this is a product catalog, an order basket, a page with information on delivery, return and a company.
Frequently, documents with the proud name “Technical Assignment” are published on freelance sites, which contain the three points described above. However, in reality, this is only the introductory part of the TK.
This section makes sure that the customer and the performer talk about the same thing.
The terms can be “introduced” from two sides: from you to the customer, for example, you tell him what hosting and SMTP server are, and from the customer to you.
In the second case, as a rule, it is not necessary to describe terms specific to the subject area, but not related to the project implementation. For example, for a store selling parts for sailing ships, it is not necessary to put it in terms such as a staysail and guys. Here we need a decoding of the terms with which the customer operates and puts into them a certain meaning, which may be interpreted incorrectly by us. Some simple words, but in this context, taking on special meaning. For example, the customer says: "A session with a site costs 100 MNT." The phrase "session with the site" - a contender for the description. This term can mean the length of time from the entrance to the site to the exit, or the period of work until the user’s account runs out of money. Those. we need to know exactly what a “work session” is. A misunderstanding of such a simple term can create a real problem.
Key section TK. You can say his heart. This is not the most verbose, but the most important and difficult point of the TK. If it is done right, you can be sure that the author of the task understands what needs to be done. The presence of this item imposes very strong restrictions on the product being created. This point alone, I think, "weighs" more than half of all TK.
This section contains a list of entities that are used in the project. This is very close to the description of the tables in the database or models, if we talk about frameworks with MVC. For example, we have news on our site. And what is the news? As the military definition says, a bush is a collection of branches and leaves protruding from one place. So the news is a collection of title, text and publication date. What is this definition for? Like everything in the TK - to clarify what to do and to hedge against hotelok.
The enumeration of the attributes of the entity allows you to notice the little things that, unnoticed, could lead to complications.
For example, the same news:
Suppose, in the process of work, it turns out that the news announcement was forgotten (a short text that appears in the news list). Add it is not a problem: you need to add in the table a field “announcement” of the type “text” and an additional input field in creating / editing the news. Finalization is simple.
And now, let's say, it turns out that you forgot to add the “Category News” attribute. Simply adding one field to a database table, as was the case with the announcement, is no longer enough. We'll have to add one more entity, a table of categories and the corresponding section in the admin panel for managing news categories. Such items, while remaining unnoticed in the evaluation of the project, lead to incorrect results and, as a result, to a deadline. And it is precisely this paragraph of the TK that allows to identify such problems. Those. it is better to notice the lack of "Categories" at the stage of writing the TK, than in the process.
As Cap suggests, news is news, and the list of news is a list of news.
Why describe it? Suppose we have to display the latest news on the main page. Here are the latest news, this is just such a list. And what is the "latest news"? This can already be understood in different ways, it may be the last 5 news, and maybe this is news in the last 24 hours? The given example is simple, it is inexpensive to fix and upon delivery of the project. But there are more severe cases.
For example, a customer wants a site with collective blogs, such as his own habr. And he wants that on the page where one article is displayed, there was a list of “similar articles” on the side. What are related articles? This question requires a separate investigation and description. And not paying attention to this list, we are already risking quite seriously. Those. here it is necessary to describe in detail the algorithm for determining the similarity of articles. If you skip this item at the time evaluation stage, you can miss a lot.
A section with a description of all the pages and what should be on them. In most cases, this is a rather short description, since we can use references to data and lists. For example, "on the page displays a list of the latest news." What is news, we have already described what the latest news is - too. If necessary, we can clarify that not all the given news is displayed, but only the name and the announcement.
Here it will be appropriate to describe not only what is displayed, but also how. Not in the sense that we describe the design: “the name of the news is displayed in large red letters”, but in the sense of how it works: “A window with a suggestion to enter a login and password leaves smoothly on the left”. Or like this: “when you click the“ Send comment ”button, the comment appears on the page without reloading, using AJAX”.
Is it necessary to describe the content of the page? No no need. We are writing a technical task. Describing the catalog, we do not describe all the products in it? Our task is to describe the functionality that will allow the customer to independently fill in a content page. If you plan to fill the site with content by the artist, it is better to put it in a separate document.
Naturally, it will be very cool to add a sketch to each page like this:
It is worth ensuring that the text description does not conflict with what is drawn in the sketch.
Those. If the news has a “News Category” in the illustration, and in the “Data and Lists” section the news does not have it, then this is a problem. The probability is very high that when studying TZ, the customer will remember exactly the picture with the news sketch, which has a category, and if there is no category in the finished project (according to the textual description of the news), it will be upset.
It may be worth mentioning in the text of the document that the text is primary, and the illustrations simply for ease of understanding. Although this issue is controversial.
For sites with a clear division into the admin area and the public part, it makes sense to group all the pages into two large categories: the public part and the admin area. If there is no clear separation, you must specify the permissions for each page.
If you plan to site with a high load, it is worth to say about it in advance, so that there was no embarrassment. A highly loaded site may well require specific actions to set up servers or write code. And to find out that the site should hold a huge load at the time of delivery of the project, not the best development of the situation.
It should be said separately that for reliability, you need to configure backups, because "Cases are different" and no one is immune from the evil hackers who can spoil the database or hosters that can burn with a blue flame, as has happened before.
It is obvious that such a situation may well arise, for example. Our web studio makes beautiful sites, but writes exclusively on Django. The customer found our site, saw beautiful designs and made an order. It is time to lay out the site on a hosting, to other ten sites of the customer, and there, naturally PHP. And it starts, “but I thought that everyone in PHP is doing ..., I don’t have another hosting, I have to redo it in PHP”.
In addition to such obvious problems, there are problems and more subtle. For example, for normal operation, cron is needed, but the hoster does not provide it (an absolutely real case from my practice). Or, say, a specific site that cannot work on shared hosting, it only needs VPS or VDS.
These include the requirements for interpreters, libraries, packages, gems, disk space requirements, memory, smtp, pop, ftp, external programs, and so on, which is important for the project.
This item specifies the amount of content to be filled. At a minimum, we must create the content that will allow the customer to begin operating the site. Well, at least create an account for the site administrator and tell the customer a username and password.
If we have to, for example, fill in a catalog of 500 photos, having previously processed them, then this should be described here.
The description of this section will warn us against a different understanding of who should fill 500 photos and fill the catalog with goods.
A description of the conditions upon which the settlement for work is to take place.
Possible options, for example, transfer to the customer's hosting after 100% payment. Or payment after transfer to the customer's site plus a week for running in.
By the way, 100% payment, I think, should not mean the end of the correction of bugs. In my opinion, bugs should be given a lifetime warranty, and they should be corrected always and free of charge. Although, I think, there will be other views on this problem.
Of course, this TK does not cover all aspects of the site, but for a very large number of projects it will become a good description.
Yes, this TK has gaps, for example, it does not say what to do if the site should have an API. However, having a good “data and lists” section, expanding the TK to this area will be quite simple.
I will be glad to hear criticism and, especially, a description of cases when such TK is not appropriate.
Not so long ago, there were two articles on Habré ( according to the technical specifications and Why do I need TZ? I already know! ) Dedicated to technical specifications. I have both articles caused, to put it mildly, bewilderment, especially the article "According to the technical task." In my opinion, this is generally harmful article, which leads to the misunderstanding of the essence of TK. In this regard, I want to express my view on this question. I will not talk about all those. tasks, the topic is too wide, but I think I can tell you about the TK on the site.
The description of the technical specification, which will be discussed below, is not a retelling of the GOST, but rather is its creative processing, well-flavored with bitter experience. The TK approach described below does not cover all aspects of site building, but sets the general direction.
')
Most sites can be attributed to small and very small projects, the scale of the units of man-months. Due to their small size, such projects can be easily thought out and easily implemented using a waterfall model, it’s enough just not to be lazy at every stage of development (from writing TK to project delivery). There is no sense in applying flexible development methodologies to these projects, and it makes sense to apply good TK. For those sites that do not fall under the waterfall model, you should not apply the approach described below.
1. Justification of the need for TK
And why do you need to TK site? The customer says: “We need the following site: product catalog, shopping cart, order form, delivery, we are on the map, about us, feedback.” What is not clear? Nothing unusual, everything is ordinary and routine.
The developer clearly understands what needs to be done, but to do it, in his understanding, is needed like this:
At the end of the work comes the design from the customer, and when viewing it, it becomes clear that the customer understands the problem a little differently. Namely:
And here it turns out that the initial estimate of the scope of work (and, accordingly, the deadlines and cost of the project), which the developer made on the basis of his conclusions and voiced to the customer, differs from what the customer actually wants.
If we “subtract” one picture from another, make a diff, so to speak, then we will get the difference in the customer’s expectations and the developer’s plans. And this difference can be quite significant:
And here a conflict arises, where each of the parties is right: the customer did not receive what he expected for the agreed price, they are trying to “sell” him; the performer believes that he did everything exactly with the order, and the rest of the Wishlist - this is an attempt to "prokidit" it. This conflict can be resolved in different ways: either the customer accepts what is, or the developer completes everything for free, or both sides make mutual concessions. But in any case, there will be victims.
So, the task of the technical task is to minimize the difference between the views of the two parties: the customer and the contractor. A good TK gives a small diff, a bad TZ - a big one.
However, there is a very important point: those. The task should not and cannot reduce diff to zero! Let me explain why.
Both diff and TK have their value, and the value needs to be understood more broadly than just money. These are money, time, wasted nerves, spoiled relations, etc.
The cost of diff is the cost of initially unspecified modifications, the cost of the TK is, in fact, the cost of the TK. The more detailed and detailed the technical task, the higher its cost, but the smaller the value and cost of the diff, and vice versa.
If we consider the two extremes, when those. There is simply no assignment, none at all; in general, and we did photo hosting, and the customer wanted an online store, the diff will be equal to the whole project, and its cost will be equal to the cost of the project (we will have to throw out our photo hosting and make the store). In this case, the cost of the TOR is zero. At the other extreme, this is when the technical task is the actual project itself, i.e. it is fully detailed, i.e. up to lines of code, variables and css styles. In this case, the diff is zero, and the cost of the TOR is equal to the cost of the project (since the TK is already an implementation). And between these extremes is the reality, which is reflected in this graph:
The blue line is the cost of the TZ, it grows with increasing detail, the red line is the cost of diff, and its value, on the contrary, decreases with increasing detail.
The blue line indicates the total cost of the TK and alterations to be completed upon completion. As can be seen from the graph, this total value has a minimum value. Those. from a certain point, it becomes cheaper to fix the customer’s wish at the end of the work than to perfect the TK.
Hence the important conclusion: TK should describe the project well, but no more than that .
The approach described below will claim to be a TK with a degree of detail close to optimal.
2. What should be in it and what is not. Formulations
A technical task is a document, a part of a contract (it does not matter if it is an agreement with seals and signatures, or only a verbal agreement) that regulates what works should be performed. All that is described in the TK should allow for an objective assessment. Those. There should be objective criteria by which it can be determined whether a particular item is made or not.
Based on this, it turns out that in the technical task there should not be a speech about design. Anyway, the task is technical, not artistic. The design does not lend itself to an objective assessment of what one likes, the other does not, and there are no objective criteria by which one can say whether a design is good or not.
The implementation of the design with the formulation of the task “in green tones, and that would be wood,” can be both a bad work and a masterpiece (and what is especially sad, the customer may not like both options). In short, fulfilling the objective criteria describing the design can lead to poor results.
In general, TK should be written as if you did not agree with the customer and your dispute will be dealt with in court, based on the text of those. tasks. And in your TZ it is written “to make a design that will appeal to the customer”. The judge asks: "Customer, do you like the design?". Customer: "No, Your Honor!". Judge: “Contractor, I award - 2 years of snow removal in Siberia for non-compliance with the terms of reference!”.
The wording should be “closed”, i.e. clearly indicate the boundaries of our work. In the TZ can not be written "admin panel should be comfortable." Convenience is a subjective factor, it is convenient for someone so, for someone else, and in the case of a dispute it will be difficult to establish who is right. The phrase "admin should be comfortable" can lead to endless alterations: "add to the admin panel to the list of products sort by columns and filtering. Without this, it is not convenient. And it is not convenient to add the loading of goods from Excel one by one. ”
“Everything that is not specified is performed at the discretion of the performer” - despite the severity of this statement, this phrase should be present in the TK. It derives from the very essence of the task: the customer wants to get a certain product, but he cannot and should not indicate how the final result will be achieved. This item protects against interfering with the depths of work (it was not enough for the customer to begin telling how to name the functions in the code and which packages to use), but also negates the ability of the customer to have any wish-list. In my opinion, it is worth going to the customer in a meeting in the Wishlist, until it goes beyond the bounds of decency. When patience breaks, we will need this item. As the song says: "We are peaceful people, but our armored train is on the siding." (The phrase “what is not specified is at the discretion of the performer”, it’s better to stick in the end of the TK, at the beginning it can be met with hostility. But if the TK is normal and at the end is this phrase, they will not protest against it).
Those. A task is a document that the customer gives us (It doesn’t matter that we write it. According to the meaning of this task, the technical task, and the task is given by the customer to the contractor, that is, to us). And from this it follows that the TK should contain formulations that tell us what to do (such as “the site should contain”, “there should be an opportunity”). In some TK I have seen, the wording of the form “there will be this and that on the site” is an incorrect wording, this is some kind of notification of the customer that will be done, but the document is called “task” and not “notification” .
3. Sections of TK
3.1 Common words
This section brings up to date. Proceed from the fact that you need to give the TK to a third-party programmer, and you will not be in touch all the time working on the project until delivery. Those. the programmer should take the TK, and he should not have a single question, and the first question he could ask is: “What about the site will we do?” The section “Common words” in a free form answers this question.
3.2 Operational. purpose
In short, operational assignment is the benefit that a site should bring. In general, most often, the benefit comes down to money (if the site is somehow tied to commerce, and most of them), and in the section one could always restrict ourselves to writing that the operational purpose of the site is to earn extra money, but we will not be so cynical. Let us stop a step earlier, immediately before the "earn some money." For an online store, this will be a sale of goods (from which we will receive money), for a discount site it is to dock customers and vendors or service providers (to get a percentage of money from this), for a business card site, to advertise on the Internet (and advertising is needed to get money), etc.
3.3 Functional purpose
This item is closer to the point. Here is a brief list of what technical means we want to get the profit described in the previous paragraph. For example, for an online store, this is a product catalog, an order basket, a page with information on delivery, return and a company.
Frequently, documents with the proud name “Technical Assignment” are published on freelance sites, which contain the three points described above. However, in reality, this is only the introductory part of the TK.
3.4 Terms and Definitions
This section makes sure that the customer and the performer talk about the same thing.
The terms can be “introduced” from two sides: from you to the customer, for example, you tell him what hosting and SMTP server are, and from the customer to you.
In the second case, as a rule, it is not necessary to describe terms specific to the subject area, but not related to the project implementation. For example, for a store selling parts for sailing ships, it is not necessary to put it in terms such as a staysail and guys. Here we need a decoding of the terms with which the customer operates and puts into them a certain meaning, which may be interpreted incorrectly by us. Some simple words, but in this context, taking on special meaning. For example, the customer says: "A session with a site costs 100 MNT." The phrase "session with the site" - a contender for the description. This term can mean the length of time from the entrance to the site to the exit, or the period of work until the user’s account runs out of money. Those. we need to know exactly what a “work session” is. A misunderstanding of such a simple term can create a real problem.
3.5 Data and Lists
Key section TK. You can say his heart. This is not the most verbose, but the most important and difficult point of the TK. If it is done right, you can be sure that the author of the task understands what needs to be done. The presence of this item imposes very strong restrictions on the product being created. This point alone, I think, "weighs" more than half of all TK.
Data
This section contains a list of entities that are used in the project. This is very close to the description of the tables in the database or models, if we talk about frameworks with MVC. For example, we have news on our site. And what is the news? As the military definition says, a bush is a collection of branches and leaves protruding from one place. So the news is a collection of title, text and publication date. What is this definition for? Like everything in the TK - to clarify what to do and to hedge against hotelok.
The enumeration of the attributes of the entity allows you to notice the little things that, unnoticed, could lead to complications.
For example, the same news:
- Headline
- Text
- Date of publication
Suppose, in the process of work, it turns out that the news announcement was forgotten (a short text that appears in the news list). Add it is not a problem: you need to add in the table a field “announcement” of the type “text” and an additional input field in creating / editing the news. Finalization is simple.
And now, let's say, it turns out that you forgot to add the “Category News” attribute. Simply adding one field to a database table, as was the case with the announcement, is no longer enough. We'll have to add one more entity, a table of categories and the corresponding section in the admin panel for managing news categories. Such items, while remaining unnoticed in the evaluation of the project, lead to incorrect results and, as a result, to a deadline. And it is precisely this paragraph of the TK that allows to identify such problems. Those. it is better to notice the lack of "Categories" at the stage of writing the TK, than in the process.
Lists
As Cap suggests, news is news, and the list of news is a list of news.
Why describe it? Suppose we have to display the latest news on the main page. Here are the latest news, this is just such a list. And what is the "latest news"? This can already be understood in different ways, it may be the last 5 news, and maybe this is news in the last 24 hours? The given example is simple, it is inexpensive to fix and upon delivery of the project. But there are more severe cases.
For example, a customer wants a site with collective blogs, such as his own habr. And he wants that on the page where one article is displayed, there was a list of “similar articles” on the side. What are related articles? This question requires a separate investigation and description. And not paying attention to this list, we are already risking quite seriously. Those. here it is necessary to describe in detail the algorithm for determining the similarity of articles. If you skip this item at the time evaluation stage, you can miss a lot.
3.6 Pages with description
A section with a description of all the pages and what should be on them. In most cases, this is a rather short description, since we can use references to data and lists. For example, "on the page displays a list of the latest news." What is news, we have already described what the latest news is - too. If necessary, we can clarify that not all the given news is displayed, but only the name and the announcement.
Here it will be appropriate to describe not only what is displayed, but also how. Not in the sense that we describe the design: “the name of the news is displayed in large red letters”, but in the sense of how it works: “A window with a suggestion to enter a login and password leaves smoothly on the left”. Or like this: “when you click the“ Send comment ”button, the comment appears on the page without reloading, using AJAX”.
Is it necessary to describe the content of the page? No no need. We are writing a technical task. Describing the catalog, we do not describe all the products in it? Our task is to describe the functionality that will allow the customer to independently fill in a content page. If you plan to fill the site with content by the artist, it is better to put it in a separate document.
Naturally, it will be very cool to add a sketch to each page like this:
It is worth ensuring that the text description does not conflict with what is drawn in the sketch.
Those. If the news has a “News Category” in the illustration, and in the “Data and Lists” section the news does not have it, then this is a problem. The probability is very high that when studying TZ, the customer will remember exactly the picture with the news sketch, which has a category, and if there is no category in the finished project (according to the textual description of the news), it will be upset.
It may be worth mentioning in the text of the document that the text is primary, and the illustrations simply for ease of understanding. Although this issue is controversial.
For sites with a clear division into the admin area and the public part, it makes sense to group all the pages into two large categories: the public part and the admin area. If there is no clear separation, you must specify the permissions for each page.
3.7 Reliability Requirements
If you plan to site with a high load, it is worth to say about it in advance, so that there was no embarrassment. A highly loaded site may well require specific actions to set up servers or write code. And to find out that the site should hold a huge load at the time of delivery of the project, not the best development of the situation.
It should be said separately that for reliability, you need to configure backups, because "Cases are different" and no one is immune from the evil hackers who can spoil the database or hosters that can burn with a blue flame, as has happened before.
3.8 Hosting Requirements
It is obvious that such a situation may well arise, for example. Our web studio makes beautiful sites, but writes exclusively on Django. The customer found our site, saw beautiful designs and made an order. It is time to lay out the site on a hosting, to other ten sites of the customer, and there, naturally PHP. And it starts, “but I thought that everyone in PHP is doing ..., I don’t have another hosting, I have to redo it in PHP”.
In addition to such obvious problems, there are problems and more subtle. For example, for normal operation, cron is needed, but the hoster does not provide it (an absolutely real case from my practice). Or, say, a specific site that cannot work on shared hosting, it only needs VPS or VDS.
These include the requirements for interpreters, libraries, packages, gems, disk space requirements, memory, smtp, pop, ftp, external programs, and so on, which is important for the project.
3.9 Filling content
This item specifies the amount of content to be filled. At a minimum, we must create the content that will allow the customer to begin operating the site. Well, at least create an account for the site administrator and tell the customer a username and password.
If we have to, for example, fill in a catalog of 500 photos, having previously processed them, then this should be described here.
The description of this section will warn us against a different understanding of who should fill 500 photos and fill the catalog with goods.
3.10 Delivery and Acceptance
A description of the conditions upon which the settlement for work is to take place.
Possible options, for example, transfer to the customer's hosting after 100% payment. Or payment after transfer to the customer's site plus a week for running in.
By the way, 100% payment, I think, should not mean the end of the correction of bugs. In my opinion, bugs should be given a lifetime warranty, and they should be corrected always and free of charge. Although, I think, there will be other views on this problem.
Conclusion
Of course, this TK does not cover all aspects of the site, but for a very large number of projects it will become a good description.
Yes, this TK has gaps, for example, it does not say what to do if the site should have an API. However, having a good “data and lists” section, expanding the TK to this area will be quite simple.
I will be glad to hear criticism and, especially, a description of cases when such TK is not appropriate.
Source: https://habr.com/ru/post/138749/
All Articles