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

You are creating a startup with a small team (it doesn’t matter if it’s a mobile, web or desktop application). Perhaps part of the team works remotely and you communicate with them on Skype. And everything is fine with you. Development takes place in small iterations, the designer designs, the designer draws, programmers get a clear task and translate it into elegant and flexible program code that does not have to be redone. The management is pretty, mutual understanding and trust reigns in the team, the project is moving towards completion and everyone already sees themselves reaping the sweet victory laurels.

If this is true - I take off my hat to you. I just dream to get to know you and learn from your experience. You can not read further - the article is not for you.

Everything is a little different with us, although the initial data is the same. Startup, web application, distributed team, small iterations. There is a common vision and goal that we want to achieve. There is no TK and a clear description of the requirements (the startup is the same). The leader directs, 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 to 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, somewhere the right thing will break there." The application reveals strange artifacts, the purpose of which no one can explain.

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

What is the root of all evil?

Suddenly, I came across a way to solve such problems in the book “Business from scratch. Lean Startup method for quick testing of ideas and choosing a business model ”by Eric Rhys, namely in the chapter on the Five Method“ Why? ”. The essence of the method is that if you encounter any difficulty you need to ask the question “Why?” Five times in a row. and you’ll get to the root of the problem.

It all started with the fact that, while reading this chapter, I asked the machine a troubling question: “why, instead of engaging in a new feature, we again remade the old one and spent two weeks on this?” The answer is obvious:
- Because it worked incorrectly and misled the user.
We ask the following question:
- And why did it work incorrectly?
“Because the programmers programmed it that way.”
“Why did they program it like that?”
“They say I told them so.” And they did not like this idea from the very beginning.
- And why did they do something with which they disagree and consider it unreasonable?
- Uh ... they don’t know.

Why does a programmer agree to do something that he does not understand or disapproves of? Because: used to work on TK; lazy to think; afraid to seem stupid; does not want to argue; believes that "the boss knows better"; does not want to take responsibility; stood in the position of the hero a la "here again came up with heresy, but I do" ... emphasize the necessary.

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 look and went to gash. Sawed for a week wondering why this might be needed. I washed it down. He brought it. To the question "What is this?" he answers - "you told me to do it yourself - I did." But I had something completely different in mind! As a result, a week was lost, instead of an application - a monster on crutches, team spirit below the baseboard and everyone blames each other.



And this is only one small task. And how many of these problems are in a relatively large project? Tens, hundreds? And another clings to one, then the third, and very quickly there comes a moment when it is extremely difficult to fix a crooked solution because it is based on a whole falling tower from the code written later. The project is swelling, discontent is growing, deadlines are breaking.

What to do?

So, we found out that the problem is in an elementary misunderstanding, and not at all in the lack of professionalism of individual employees. How to fight? All document and write TK? But, firstly, it will become obsolete even before it is written. And secondly, I want programmers to participate in decision-making and take responsibility for them, and not just code. In vain, or something, we 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 a particular solution is proposed. After all, if you think about it, problems could be avoided if the programmer instead of “I have to do it” said “What nonsense, I won’t do it because ...”. Or the designer bothered to make sure that he is understood correctly, and when he heard a sullen tone he didn’t wave it off and asked, “What do you dislike? Let's discuss. ”

Theoretical “it would be possible if” sound unconvincing and trite. Therefore, here are the results of a live genuine experiment.

We make a rather complicated web application with several sections, a bunch of content and a 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 elements. And it gets in the way, and you can’t remove it. I tell the programmer "on the page A the sidebar is not critical, let's hide it on small screens - there will be more space for useful content." The programmer monosyllabic answers "I must do it." I think, “Yeah, I got it! He obviously doesn’t like something. ”

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

It may seem that this approach leads to unnecessary chatter and reduces work efficiency. Like, why waste time talking, we'll figure it out along the way. But in practice, it reduces development time, reduces the number of alterations and improves the quality of the product. Moreover, this approach allows you to bring together a team and raise team spirit due to the fact that people communicate, jointly find solutions, develop a common understanding and a common point of view.

Gradually, I begin to test this approach on our programmers. It does not always work out. But when it turns out, I see genuine joy from the fact that people are finally beginning to understand what they are doing. I see enthusiasm, interest and acceleration of work, I see a desire to understand and understand. Yes, for the sake of this, sometimes you have to put off 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's worth it.

What is the moral of this fable?

And the moral is very simple. If the team disputes about who is to blame for the deadline, mutual claims and accusations appear, then the worst thing to do is to arrange a hunt for witch programmers . It’s much wiser to sit down, take one small specific problematic situation and start digging deeper - to get to the bottom of the problem. She is always there. She only needs to be found. It can be anything - from ill-conceived processes and a slow Internet to habits and cultural differences. Often a problem can be easily fixed, sometimes you need to get around or learn to live with it, but the first and most important step is to detect and recognize it. This alone is able to raise team spirit, bring the team closer and increase work efficiency. And this is exactly what any startup needs.