A little about responsibility and responsibilities

When I talk to a potential project manager, I always ask a question about the project progress process. All good managers draw it in approximately the same way, approximately as it is written in good smart books. This is how this process should go:

The project is initiated and is in full swing.
A certain project documentation has already been drawn up for it and the time is right for drawing the design. The manager sets the task for the designer, and after a week takes 10 beautifully drawn page layouts. The designer tried as best he could and that is why every pixel in this design was thought out and put in the right place.
The design is transferred to the coder who, plunging into the code, tries to complete the magnificent design of the designer with pixel accuracy. At the exit, according to the documentation, he gives out 20 certified pages.
After that, the design goes to programmers. Who collect the project and now it is no longer just a static design - this is a working Internet site.

It would seem simple, but.
When testers get to the project a few weeks after starting to build the project, they grab their heads. The layout reveals dozens of inconsistencies design. Bugs are raining on the heads of programmers and coder. Watching the assembly, the designer plunges into sadness deeper and deeper, his condition is on the border of despair, and the design is in oblivion (how can you put “it” in the portfolio ?!). The coder does not stop trying to fix bugs, but they appear faster than he can read them.
Everyone, including the project manager, forgets about the names of all methodologies and begins to “figure out”. Anarchy reigns amid impending deadline. As a result, the project is certainly ending: it appears on the network, there is a reasonable number of bugs in it, and it starts working.
This is not a tale from a smart book. That's life.

Why does this terrible anarchy arise in the battle for quality? I will give an example based on the layout and design. I think that programmers will easily find similar examples.
So.

When the designer’s mock-ups are handed over to the layout designer, a clear guide to action follows from the manager: “The design was drawn by a great professional, he thought about everything, so we’ll make sure the pages are exactly according to the design!” and starts cutting patterns.
When it encounters an element of type:


He writes code like this:
<h1> Welcome to the site! </ h1>
h1 {
font-size: 14px;
color: # 000000;
}
But then he meets some similar element, in which, however, there are differences . He remembers that it is necessary to strictly follow the design ... this is the decision of the manager. Therefore, meeting the element:
')

He, as a good coder, understands the cascading style sheet adds a new class to the previous element:
<div class = ”wrapper block “>
<h1> Password Recovery </ h1>
div.block h1 {
font-size: 16px;
font-weight: bold;
padding: 6px 0pt 4px 14px;
margin: 0pt;
}
Next, the code goes to the programmer. He clearly knows that the coder is a professional, and he clearly thought about which styles to introduce. If h1 is used for headings, it means you need to use it everywhere. When he needs to display the title on the page, he, as the right programmer, just framed the title with the h1 tag. He does not know about the block class, which he had to deliver in this particular case. Therefore…
After some time, the layout designer has a bug from testers who reasonably ask the question: “Why do we have different headings on the pages?”. The formatter courageously puts the forgotten block class wherever it is needed.
History repeats itself with enviable consistency in a circle. But already with other blocks, other characters and styles.

How to break this vicious circle? It's not time to think yet, it's time to “figure it out” ... but this is not the final yet.
There is a next round. In the course of the development of the system, the designer is ordered other pages, where there are even more inaccuracies and “mistakes”. The coder is writing another CSS code that is superimposed on the former ... but again, in exact accordance with the design. As a result, 2 codes are mixed, programmers take any “working” and layout is plunged into anarchy. One day, a typesetter jumps up from his workplace, pulls out a shred of hair and exclaims: “This is all that needs to be urgently turned over!”

What is the result of such a situation?
Someone will say that the process is not well documented. It is necessary to describe in detail the design, then describe the layout, etc. Fans of standards will immediately recall all conceivable standards from the W3C, which should remedy the situation, and “CSS frameworks were invented just for this”.
Yes. All this is true, but ...
There is a great rule of a vicious circle of constant quality reduction:
Quality is reduced at the stages of transferring work from one employee to another.

Many of these problems are generated by the team’s work process itself: instructions, instructions, administrative authority. In essence, the developers do not make mistakes, but only follow the principles that are laid down in the work of the company, or the models that they brought with them. No one thinks that the project manager may be wrong, and the director, passing by, gave just advice, and not a clear guide to action.
Errors, like a snowball, increase from one process node to another with each transfer of work. From designer to typesetter, from formatter to programmer. Each individual was afraid to take responsibility for the project and his specific area of ​​work and did not take any decisions .

“Decisions have already been made“ at the top, ”where they were supposed to eliminate every mistake” - some developers argue. “This is not my job and once the layout designer did this, this is the way it should be,” others think. “It doesn't matter what is done already badly, the main thing is not me.”
The quality of the final product leaks at every stage, like sand through your fingers. QA is essentially looking for a decision maker on a given small question. People who, in principle, should not make such mistakes begin to produce them every day.
Do you know how shoe factories work in the same Italy?

There is a conveyor, shoes are moving on it. Each individual employee has his own clear area of ​​work. If a shoe with a badly glued sole came to him, he would not stick a sock on him, but put the shoe aside, and then he would go to the shop manager and report about the marriage. What will “our” worker do? Stick a sock, because the quality ... not his work. For this we have an OTC. Quality Control Department checks at the end of the conveyor shoes and throws it like a marriage. Yes, we got rid of the marriage, but spent the time of the entire conveyor. Defective boot turned out very expensive.

Here is what I want to say:
Paper instructions, strict adherence to the administrative hierarchy are signs of weakness of mind and talent. Truly talented developers should stop being afraid to take responsibility for the quality of their work and the team as a whole, they have the right to enjoy the results of their work. Each project participant, be it a coder, programmer, designer or QA, is required to make decisions during the course of the project. Decisions at their level, because no one is gone . As a result, the quality of the project will be a reflection of the professional decisions and professional integrity of the entire project team.
Shl. People who have not yet experienced professional Tao should turn to their elder comrades for advice.

Original here: http: //yuri.shilyaev.com ...