TK for web developer

Writing a good TK for website development is still a problem, and I will share my experience in creating a “human-friendly” description for a customer for a developer.


I will start from afar, do not judge strictly (all pictures are clickable) ...

Step zero. Customer.

Manipulation.

')
Let's start with the first meeting with the customer. To give the impression of a serious person with whom you can and should work - this is your main task - so set aside your favorite khaki suit - jeans and a shirt - it will be the most.
The meeting place is also very important - MacDonalds is not the best choice - I personally choose coffee shops - a quiet and calm atmosphere is conducive to a productive conversation. By the way - here you and the first bell - if the customer treats - this is good, otherwise - work on a prepaid basis.
At this first meeting, you must convince the customer that of the two of you it is you who are professional, and that you know what he wants. Take the initiative during business meetings and negotiations. Do not hesitate to give hints to the customer, give examples, but only those that you like, and they are beneficial to you (for example, you have a stash in your nest egg). It doesn’t matter if the customer sits on your head - maybe he is somewhere and the director, but not with you - for you he is just one of many.

Analogs.

Get from the customer analogs of his offspring (I strongly doubt the uniqueness of the idea, such are extremely rare), so you quickly understand the essence of what you are seeking from. It is very good if you have a laptop with access to and no, and you can see everything at once. (fork over a PCMCIA GSM modem - it makes an impression).

Money.

Here you need to be very careful - you need to accurately understand and understand how the project will earn (albeit in the future). It is clear that this does not apply to business cards.

TK.

During a conversation, write down important points - do not rely on memory - be sure to pierce. If you have any questions - ask them, the answers again should be recorded. At the end of the conversation before you should be a draft of TK.

And now comes the most difficult moment - you have to convince the customer that you are writing the statement of work, and he must pay for it. If it didn’t work out - send him a sample - let him suffer, as a result, if he values ​​his time - he will accept your services.

Step one. TK.

Writing

Before you start working on the TZ, you must firmly understand for yourself - this document must be interpreted unequivocally not only by you and the customer, but also by any other developer, and this is a rather complicated task.

A small lyrical digression in the beginning of the path - IMHO, I believe that one of the most correct ways to present information is graphic, i.e. Better to see once than hear a hundred times. So we will draw layouts (mock-ups) of pages - even MS Word is suitable for this (although of course it is better to use something like Axure RP Pro ):

As an experimental, we take a website that is a bulletin board for buying and selling cars.

As you can see, this is the main page of the site, it took me a little less than 5 minutes to “draw” it, now you can try to describe it with the words:

The logo should be located above, the user authorization form should be located to the right, the site links just below the logo, the top commented news below the links, and the advertising block below. In the center should be a search form, under it - the last added ads, then a block of advertising, and the latest news. Under the authorization form should be located block with the latest comments on the forum, and below the block of advertising. At the bottom of the page will be puzomerki counters, as well as copyrights

Wow, the description of course - a lot of beeches, and a lot of questions, mockstick more unambiguous. Okay, let's go further, closer to the point.

First you need to select entities, user roles and define access levels (I will be brief - I will give a table):

Role / Entity	User	ads	Comments to announcements	news	Comments to the news
a guest	check in	R	R, W *	R	R, W *
User	E *	R, W	R, W	R	R, W
Administrator	X	M	M	X	M

Where:

• R - reading
• W - creation
• E - Editing
• X - full access (create / edit / delete)
• M - moderation (edit / delete)
• * - implementation features are displayed in the documentation.

Now we have the following task:

• For all R - create page layouts
• For all W , E - describe completely the forms - i.e. which fields are editable, and by what rules
• For all X , M - mock ups of pages with navigation + form creation / editing

Let's start with a simple - R - for ads:



And for news:



The following is an example of a description of the form for comments ( W ):

• Name - Cyrillic and Latin letters, numbers, underscore and hyphen, mandatory
• E-mail - in accordance with the standard RFC-2822 , mandatory
• Link to the Website - in accordance with the standard RFC-2616
• Text - non-empty field of more than 3 non-whitespace characters.
• CAPTCHA - Turing test for spam protection, mandatory

And the corresponding mock up:



As you can see, such layouts are quite informative, and also prepare the customer for a future product.

Just do not forget to prepare the letter templates (here's an example):



A use case diagram is also useful (it is quite likely that you could have drawn it at the stage of discussing the project with the customer):

Architecture design and database.

Why did I include this item here? Everything is very simple - from my own experience I will say - when the project documentation comes into the department and the development of architecture and database begins, there are a lot of questions about which even the thoughts did not arise while reading the docks. As a result, the project team is idle, while the manager, redder in front of the customer, finds out these nuances. It would be much more logical to be one step ahead, and to sketch the architecture and the database already at this stage — 3-4 hours of work, which can save both time and money, and nerves (of course, the architecture in this version will be too cheese, but it can reveal a few pitfalls).

I will not describe the architecture - since in this example, there is nothing much to design, and the low-level will be dictated to us by the framework.

But an approximate sketch of the database is always welcome (again, especially without bothering about the details):

Step two. Evaluation of the project.

On this stage I advise you to read the article " Evaluating Projects "

Conclusion

I very much hope that this article will help you to avoid mistakes at the first stage of the project’s life, often it is the misunderstanding of the developer of the project TOR that leads to an increase in the cost of development, delaying the time, as well as more serious consequences

Taki cross-post: TZ for web-developer