Notes self-taught art director: do not growl at the programmer

You create a startup with a small team (no matter, mobile, web or desktop application). Perhaps part of the team works remotely and you communicate with them via Skype. And everything is fine with you. Development is carried out in small iterations, the designer designs, the designer draws, programmers get a clear task and embody it in an elegant and flexible program code that does not have to be redone. The leadership is pretty, mutual understanding and trust prevail in the team, the project is moving towards completion and everyone already sees themselves reaping the sweet laurels of victory.

If this is true - hats off to you. I just dream to meet you and learn from your experience. Then you can not read - the article is not for you.

We are a little different, although the original data are the same. Startup, web application, distributed team, small iterations. There is a common vision and goal that we want to achieve. There is no TZ and a clear description of the requirements (the same startup). The head manages, the designer designs, he himself draws and sets tasks for programmers, programmers program. But for some reason, little is done the first time. The solution of simple problems stretches for weeks. Again and again we return to the discussion of the same issues. Unjustified restrictions emerge from the category of "if you do it here, the right thing will break somewhere somewhere." In the application there are strange artifacts, the purpose of which no one can explain.

Often in such a situation, mutual claims and a search for the guilty begin. And this only divides the team, slows down the development, reduces motivation and team spirit.
')

What is the root of all evil?

Unexpectedly, I came across a way to solve such problems in the book “Business from scratch. The Lean Startup Method for Quickly Testing Ideas and Choosing a Business Model ”by Eric Rees, namely, in the chapter on the Five Why Method. The essence of the method is that if any difficulty arises, you need to consistently ask the question “Why?” Five times and get to the bottom of the problem.

It all started with the fact that, while reading this chapter, I automatically asked a question that wondered me: “Why, instead of doing a new feature, we again redid the old one and spent two weeks on it?”. The answer is obvious:
- Because it worked incorrectly and misled the user.
Ask the following question:
- Why did she work wrong?
- Because programmers programmed it this way.
“Why did they program it this way?”
“They say I told them so.” And they didn’t like this idea from the very beginning.
- Why did they do something with which they disagree and consider it unreasonable?
“Uh ... they don't know."

Why does the programmer agree to do what he does not understand or disapprove? Because: used to work on the TZ; lazy to think; afraid to seem stupid; does not want to contradict; thinks that “the boss knows best”; does not want to take responsibility; I took up the position of the hero a la “here he again came up with a heresy, but I have to do” ... the necessary stress.

As a result, we observe the following picture. The designer said one thing, the programmer heard another. He cursed in his heart, grimaced, but did not give a sign and went to gash. Sawed week wondering why this could be needed. Gash. Brought To the question "What is it?" Answers - "you told me to do it myself - I did." But I meant something completely different! As a result, a week is lost, instead of an application - a monster on crutches, the team spirit below the plinth and everyone blames each other.



And this is just one little task. And how many such problems in a relatively large project? Dozens, hundreds? And another one clings to one, then the third, and a very quick moment comes when it is extremely difficult to correct a curved solution because the whole leaning tower of code written later is based on it. The project is swelling, dissatisfaction is growing, deadlines are being broken.

What to do?

So, we found out that the problem is in elementary misunderstanding, and not at all in the lack of professionalism of individual employees. How to fight? All document and write TK? But, first, it will become obsolete even before it is written. And secondly, I want the programmers to participate in decision making and take responsibility for them and not just encode. In vain, perhaps, we have gathered the best programmers in the CIS.

There is another option - to express your doubts, listen to what other team members say, ask questions and try to figure out why this or that solution is proposed. After all, if you think about it, the problems could have been avoided if the programmer, instead of “I have to, I’ll do it,” said, “What nonsense, I won’t do it because ...”. Or the designer did his best to make sure that he was properly understood, and when he heard a sullen tone he did not dismiss, but asked “What do you dislike? Let's discuss.

The theoretical “could be if” sound unconvincing and trite. Therefore, here are the results of a lively genuine experiment.

We make a rather complicated web application with several sections, a bunch of content and different layout on the pages. There is still an unresolved issue with the sidebar in some sections. It clutters the page at a narrow resolution, but contains useful navigation controls. And interfere, and can not be removed. I say to the programmer "on page A, the sidebar is not critical, let's hide it on small screens - there will be more space for useful content." The programmer responds in monosyllables, "I must, I will." I think "Yeah, got caught!" Obviously he does not like something. "

I ask what is wrong. He says "On the B page in the sidebar, an important button, if you hide it, the button will be inaccessible." Bingo! Elementary misunderstanding almost led to several hours of useless work and negativity. I'm talking about one page - “Page A”, but he understood that we are talking about all sections. One simple question asked in time saved a lot of time and nerves.

It may seem that this approach leads to unnecessary chatter and reduces work efficiency. Like, why waste time talking, let's figure it out. But in practice, it reduces development time, reduces rework and improves product quality. Moreover, such an approach allows bringing a team together and raising the team spirit due to the fact that people communicate, jointly find solutions, develop a common understanding and a common point of view.

Gradually I start testing this approach on our programmers. It turns out not always. But when it turns out, I see sincere joy from the fact that people are finally beginning to understand what they are doing. I see the enthusiasm, interest and acceleration of work, I see the desire to understand and understand. Yes, for the sake of this, sometimes you have to postpone your own burning business and spend time explaining, or, conversely, questions and deepening in those areas that do not directly concern me. But I bet it is worth it.

What is the moral of this fable?

And the moral is very simple. If a team argues about who is guilty of misbehavior, there are mutual claims and accusations, the worst thing you can do is arrange a hunt for witch programmers . It is much more reasonable to sit down, take one small specific problem situation and start digging deeper - get to the bottom of the problem that lies at the root. She is always there. It only needs to be found. It can be anything from unreasoned processes and a slow Internet to habits and cultural differences. Often the problem can be easily fixed, sometimes you have to go around or learn to live with it, but the first and most important step is to find and recognize it. This alone can raise the team spirit, bring the team together and improve work efficiency. And this is exactly what any startup needs.