My approach to creating TK for template sites

Instead of an epigraph.

Grandfather caught a goldfish. She tells him:
- What do you need, grandfather?
“I want my device to be knee-length.”
She took a fish and shortened her grandfather's legs.
Morality: put the terms of reference correctly.

Good afternoon, great and mighty Habr.
Some time ago there were a few posts on the terms of reference ( How to set a task for a simple (template) website , Why do we never compose TK. And in return? , Technical specifications Regulations ) that would like to go on and tell you about my approach to writing the TOR for template sites.

We make custom design sites, no repainting of logos, the framework is used as the basis, first it was a self-made product, then we switched to CakePHP. Despite the fact that the sites are custom, most of them are very, very similar in functionality.

We write TK ourselves and never ask the customer. We can question him, ask him to show examples, similar sites and perform other actions that will help us understand what the customer thinks and wants, understand the subject area, and then express it in the text of the terms of reference. In this, I agree with the expressed Altunik in his post How to set the task for a simple (template) site .

Our process looks like this:

1. We found a customer, talked, came to a common understanding of what we would do on the site, and announced the scale of prices.
2. Design and programming work fall into two parallel branches - design and programming. The design of TK is not written. I personally can’t imagine how TK can be written in appearance. No, we can say that they say three columns, a banner on top and a green logo, but only such a description can include both a masterpiece of design and complete sucks and, accordingly, upset the customer. Those. such TK cannot guarantee that the output will be anything good, unlike TK for the software part, where TK can guarantee that we will get what we ordered (at least theoretically). Doing TK for design is like TK for melody: “A note no more than 8 times, drums, and that would be fun” - nonsense.
3. The second branch of the work is the software part, this includes programming, layout and related work. As a rule, this process starts a little later than design, when the first layouts are already there.
4. We connect everything together and put the result on hosting.

At the dawn of our work on TK sites, no one wrote, but the customer’s wishes were simply collected, an estimate of the time and money was made on them, and work began on the site. I must say - it was not very good, because ended with a generous stream of customer Wishlist and my attempts to stop Wishlist came up against insurmountable objections like "you misunderstood me" or "I talked about this, but you forgot." As a result, the scope of work and deadlines grew, we were goats that ruined all the polymers, the amount of money earned fell, and all parties were dissatisfied.

My first attempts to write TK were awkward, often I got a TK, a half-written document that was never shown to anyone, but with this document I began to draw a site diagram each time like this:



Despite the simplicity and time-consuming time to create such a scheme, it turned out to be very useful as a kind of substitute for TK.

This scheme, agreed with the customer, made it easy to cut off a number of Wishlist. For example, after a demonstration (completed, in our opinion) of a site to a customer, he asks:
- Where is the map on the site?
- Now let's see the site diagram ... So, here is the “Main page”, here is the “News”, “About the project” ... hmm, there is no Kulverstukas! And the “Map” page should not have been. But if you want, we can complete the work according to the agreed scheme and then come back for inexpensively and make a map.

In addition, the scheme made it possible to solve another, this time internal problem. We often enough had that the designer after coordinating and approving the designs traced the key pages of the site, but forgot about some of the secondary ones. This moment turned out to be uncontrolled, the designs went into cutting, and then to the programmers who reported:
- And where is the page cut of “404”?
- But no. Forgot ...

And the circle began again: the designer completes, the layout designer cuts, the programmers pull, but as a result of such forgetfulness precious time was lost. The way out was very simple. In the diagram, as the designer sent the files, the names of the files with the designs were introduced:



So it was immediately clear what was drawn and what was not, which designs are and which are not.

Thus, the site layout has the following advantages:

• simply
• quickly
• clearly sets the set of pages on the site, cutting off all Wishlist, which could lead to a change in the composition of the pages, and this is a very, very large class of Wishlist

The disadvantage of the scheme:

• it does not describe many other features of the site and as a result, does not cut off other types of Wishlist, affecting the functionality, but not affecting the composition of the pages. For example, I suddenly wanted the product in the store to be able to display not only the price, but also indicate the old and new price, for example, like this:

Such a class of hoteloks is cut off by a description of the entities present on the site. For example, "News" is:

• Name - string up to 255 characters long
• Announcement - text with the announcement of news, length up to 200 characters
• Text - news text, up to 5000 characters
• Publication Date

In essence, this is equivalent to the description of the database fields, only in human language.
And if the customer says “I want icons for different types of news”, then we open the approved description of the news and read what is written there.

However, with such a description, without normal TK, one scheme cannot be dispensed with and one needs to sit down to write it.

As I said above in TK, we did not make a word about the appearance, giving this to the designer. Only the technical part of the site was in TK. I will not say that our TK was made according to GOST, but it was based on GOST 19.201-78, after some creative processing and rethinking.

The content of such TK was approximately as follows:

CONTENTS
1. Introduction
2. Basis for development
3. Purpose of development
3.1. Functional purpose
3.2. Operational purpose
4. Requirements for the program or software product
4.1. Requirements for the functional characteristics of the public part of the site
4.1.1 General
4.1.2 Site pages
4.1.2.1 Section "Home page"
4.1.2.3 Section "Page with conclusion and comments"
4.1.2.4 Sections "Development of the project concept", "Consulting and support projects ”,“ Marketing audit ”,“ Promotion of an object on the market ”,“ Sales by a company ”,“ Sales management ”
4.2 Requirements for the functional characteristics of the private part of the site (admin)
4.2.1 General
4.2.2 General settings
management page 4.2.3 Main page section management page
4.2.4 Contact
page section management page 4.2.5 Section management page "Page with comments"
4.2.5 Page management Section "Development of the project concept," "Counseling and support for projects," "Marketing audit", "promotion of the object on the market", "Sales of the company", "Sales management"
4.2.6 exercise Page detecting section "Conclusion"
4.4. Operating conditions
4.5. Requirements for the composition and parameters of hardware and software
4.6. Labeling and packaging requirements
4.7. Requirements for transportation and storage
5. Filling the site
6. The procedure for control and acceptance

Despite the fact that this was not an ideal TK and holes could be found in it, ambiguous interpretations and unsaid places made it possible to reduce all disputed issues to an acceptable level, so that both the customer and the contractor were satisfied. And if there were Wishlist, there were not many of them, and such that it was faster to do than to argue. As a result, the customer is satisfied, and we are ensured a sound sleep and a good appetite.

However, it turned out that there is another problem with TK. Writing TK is a boring lesson that, like hard physical labor in the fresh air, will make a person cattle.

Personally, writing TK really bothers me. Firstly, it’s a boring dry text. Secondly - all TK are similar to each other and as a rule have not so many differences, no creativity for you. But these differences, as evil, do not allow the use of the same task in different projects. Thirdly, TK is written when you already understood everything about the future site for yourself, and when you understand everything, for some reason you don’t really want to write it.

As I said, on the one hand, all TK are the same, and on the other, all are different. It seems that you write the same thing, but just copying does not work. The decision begs to make some kind of technical task generator. A study of the Internet on the subject of TK generators showed that there was no sane solution, at least I did not find one.

I absolutely did not want to put up with this state of affairs and decided to make myled the generator. As you know, when a programmer faces a task for one hour, he spends this hour writing a program that will solve the problem in one second. I took this path and started to slowly create a web service for web developers, but first of all for myself personally.

So, I wanted a site diagram editor that would allow you to quickly draw a site diagram directly in the browser, and it would be desirable to be able to connect the prepared pieces for typical parts. For example, "News" is on almost all sites, and they are not much different from each other: it is silly to draw a diagram for them every time. And you need this: he said that here in the scheme the news and all related pages were added to the scheme at a time. Themselves. Without help.

I also wanted the works of the designer, photoshop files to be attached to the pages in the diagram. Those. solve the problem of forgetting designs. There is a circuit, and for each node in the circuit there should be a design.

Naturally I wanted something for which everything was started - a technical task.

I wanted a lot more ...

What I managed to show easier than explain in words.
Here is a three-minute video that briefly demonstrates what I did.



Of course, I can’t convey all the features of the work in the review video, so if there is interest, I can explain in the comments, or make another post or even a few, because The topic is quite extensive.

I must also note that the service is not yet ready for mass use and is in testing mode. Therefore, registration by invitation. If there are people who want to test the project with a stable psyche, you are welcome for invites.

I hope you will benefit from both my experience and my service.

UPD. If you are not a habr user, and want an invite, there is a feedback form on the site.
UPD2. Direct link to the service. azalo.net