About the benefits of conciseness

On the one hand, programmers are, to put it mildly, not the most sociable people in the world. This is normal, because if developers suddenly become talkative, who will write the code? On the other - the time of loners has passed. Modern software is developed by teams and even the most conservative companies, like Sberbank, are introducing Agile . Agile manifest promotes certain values , including: “ People and interaction are more important than processes and tools .” So communication with colleagues is not a whim, but a need. This article focuses on flexible development teams: developers, team leads, analysts, testers, etc.

Professional PMs are unlikely to find anything new here. If you are a “techie” and want you to be distracted from the main activity as little as possible and you are interested in what does Sparta have to do with it, welcome to cat.

Business communication differs from friendly gatherings primarily in focusing on the result, not the process. We say goodbye to friends with the words “we sat perfectly”, and not “thanks, colleagues, it was effective.” How is communication effectiveness measured? Back in 1975, Brooks noted that one of the most important barriers to scaling development is communication costs:

If there are N programmers, then the number of pairs of programmers is N (N – 1) / 2, that is, with an increase in the number of programmers, the time spent on interaction increases quadratically. Therefore, starting with some N, an increase in the number of programmers slows down the execution of the project.

and emphasized the interaction between developers:

To prevent a disaster, development teams should interact with each other in every possible way. Instead of making assumptions about the function that he implements, the developer should ask the architect clarifying questions, since the assumptions may turn out to be completely wrong. "Assumption is the mother of failure."

His conclusions on this subject were not only never questioned, but were repeatedly confirmed. Thus, developers need to communicate as much as possible, to clarify requirements and limitations, in no case relying on assumptions (because they are often incorrect) and at the same time communicate as little as possible in order to reduce communication costs, growing quadratically, in contrast from a growing linear performance gain by adding additional development team members. At first glance, we have a clear contradiction. However, history knows at least one example where an entire city has managed to maintain a culture of effective communication.

“... If anyone wanted to get closer to the most worthless of the Lakons, then at first glance they would find him rather weak in speeches,” warned the philosopher Socrates of his fellow countrymen, “but suddenly, anywhere in the speech, he throws, like a mighty shooter, some- some exact saying, short and concise, and the interlocutor seems to him a small child. ”

If Tsar Leonid was our contemporary, he could probably say something like:

Communication on the project is effective if it takes the shortest possible time necessary to make high-quality decisions and bring them to the team members.

Stand-up

Everyone knows that a meeting is a great alternative to work. Stand-up meeting, daily scrum or, more simply, “planning meeting” is the only regular meeting in agile methodologies. A meeting is held daily by the whole team, at which everyone answers questions:

1. What did you do yesterday? (pride)
2. What problems did you encounter? (request for help)
3. What will you do today? (Promise)

It is highly desirable that the “stand-up” be held in the morning. Not too early to exclude delays, give participants time to prepare and a cup of aromatic coffee. It is imperative that all team members are present and adhere to a formal plan: answer three questions and pass the floor. Problems should be discussed after and only interested parties should be involved. Otherwise, the “planning meeting” grows into an elemental bazaar. The optimal time for a daily meeting is no more than 15 minutes. The optimal number of teams - no more than 7 people. If your team is larger, and you are going for an hour or more, most likely the team needs to be divided. Offer it to team lead or project manager.

To meet in 15 minutes to "stand-up" you need to prepare. If you have difficulties with public speaking, open a notebook (electronic or a piece of paper) and write down the answers to your questions. And then imagine yourself a real Spartan and cross out all that is superfluous: interjections, active participles, lyrical digressions. Leave the bare facts. Avoid ambiguity. If you have a problem, you don’t need to hush it up: clearly and concisely formulate and ask for help. If you think you know how to solve, explicitly say so and ask for confirmation that your solution is optimal and no additional discussion is required. Do not overdo it. Task numbers from the task tracker are not enough. Your colleagues do not remember what is hidden behind the task number 100500. It is worth voicing the name of the task.

“Stand-up” can be compared with rehearsal of a musical group. Team members are not required to know the parties of other participants in detail, because they have different specializations. However, musicians need to rehearse together in order to get a really high-quality sound, because the “quality” is created due to attention to details. By the way, in professional groups it is not customary to make other people wait. Appearing at a rehearsal without knowing your party is equivalent to demonstrating an extreme degree of disrespect and neglect. You will come a couple of times without getting ready and you will be asked politely or not very.

Ideally, after the “stand-up”, everyone in the team knows the operational situation on the project and continues to do their own thing. Problems are identified at an early stage. Only necessary people are involved in solving problems. While everything is going well, we spend no more than 15 minutes a day on communication and resolve all issues in a quality manner . Oh, if everything always went like clockwork :)

You can read more about the best and worst practices of stand-ups on the AlexanderByndyu blog .

Prompt communication throughout the day

In the real world, we face countless challenges. It’s time to take the task to work, but the requirements are not yet complete, the layouts are not ready, the API is not documented, a critical bug was found in the library used and you need to write support ... Continue the list yourself. How to solve such problems? Answer the following questions:

1. How many people (minimum) are needed to resolve the issue, and who are they?
2. Who should be notified of the decision and when?
3. Which communication channel to use?

Communication channels

Different companies have adopted different standards of corporate communication. Without claiming to be the ultimate truth, I’ll tell you how it is customary with us.

1. Personal communication / skype, phone: the most urgent issues that do not require urgency or issues that can not be solved otherwise in the course of a long time.
2. Messenger: questions that need to be answered during the day and do not require decisions affecting other team members.
3. Task tracker: questions that need to be answered within a week and / or changes / fixing requirements.
4. Mail: notifications not directly related to the project activity: leaving on vacation, absence due to illness, connecting a new employee or leaving the employee from the project. Communication by mail is a separate topic, most likely related to the work of the manager, so we will not talk about it anymore.

Communication channels are sorted in order of speed of resolution of issues and “cost”. Let's start with the fastest and the most expensive.

Personal communication / skype, phone

Imagine a situation: you are sure that your colleague Innocent is exactly aware of how to solve the problem. The fastest way is to approach him, pat him on the shoulder and ask: " Kesha, but I have such a thing here, as if I had to play it so that ... ". Most likely Innocent will not be delighted with the invasion of his privacy. The stand-up comes to the rescue again. If Innocent is on your team, book him right after the planning meeting. Anyway, he was already distracted, another 10 minutes of weather will not.

It so happens that Innocent is needed by everyone. For example, if you assembled a team of one experienced developer and three students. I believe that this is a management issue, not a communication one. If you are Innocent, talk with the leadership on the topic “I work after lunch, and I teach part-time until lunch”. If you are a student, get in line. Unfortunately, until now, many unfortunate managers believe that the team leader writes code for eight hours, and does the rest somehow in between. If the team includes an architect and experienced programmers, but the architect makes changes to the structure of the application, because he “sees” and does not document, this is again a management problem, not a communication problem. Sufficient time should be allocated for design, documentation and consultation. If the architect does more harm than good, he may not need it at all.

I have a pretty busy working schedule, so from a certain point I have been conducting a public google calendar. Some of my colleagues and acquaintances do this.
If you are team lead / tech. a deer / architect and a significant part of the time is occupied by meetings, perhaps organizing working hours with a calendar will be useful to you.

Messenger

Well suited for short clarification questions, like:

• “I noticed that in task A, requirement B does not look logical, because in the code line C implements another business rule. I think that it is necessary to adjust the formulation as follows. It's right?"
• “I am working on task A and want to use library B, but fact C worries me. Should I use an alternative and which one?”
• “Problem A was asked to be posted on production today. I think I’ll finish in an hour, but I need you to conduct a code-review, and Vasily conduct a regression. Can you check the pull request by 14:00 if I send it at 13:00? ”

If the communication is delayed, this may indicate that you do not understand each other and you need to phone or the problem turned out to be more complicated than expected and will require the involvement of additional participants. In the second case, you may need to postpone the issue or attract additional participants.

Task tracker

Effective communication in the tracker requires discipline and a certain level of processes. The key to success is the lack of information not directly related to the task and lengthy discussions. A tracker is not a forum. Many tasks are so overloaded with commentary that it takes hours to study them later. It is necessary to clearly indicate whose reaction is required. If your tracker does not support notation @userName, then I have bad news for you. Messages should be worded as concisely and concisely as possible and not be ambiguous. Before sending a message, re-read it several times:

1. Who is it addressed to? Indicate.
2. Is there enough information? Add to have enough.
3. Is there any extra information? Remove excess.
4. What kind of reaction do you expect? Write clearly.

A separate problem is bug reports. Significant success can be achieved if you do not take it to work until the bug is properly registered, for example:

1. Environment
2. How to play
3. Expected Behavior
4. Actual behavior

Synchronous and asynchronous communication model

Personal communication and telephone is a synchronous communication model. Participants exchange information intensively. Due to this, issues can be resolved more quickly. The payoff is the loss of multitasking. At the time of communication, all participants are “blocked” and can no longer do anything. If the only way to resolve the issue is to use the skype hour call, then you have to do it. Fortunately, most often these extremes can be avoided. Moreover, whenever possible , a synchronous communication model should be avoided . Respect the time of colleagues!

Written communication, on the contrary, is asynchronous, with mail and tracker timeouts exceeding one working day, and the timeout in instant messengers, on the contrary, is limited to a working day. Imagine your colleague as a web server serving a lot of incoming requests (calls to messengers, mail and tracker). You do not know what the load on the web server is at a given time, but the sooner you send the message, the sooner you will queue. If the server is not overloaded, then after a while it will respond. Keep this in mind and send requests in advance, and not when everything is on, it’s gone and urgently needed! If the “server” is not responding, try contacting later or use an alternative channel. Only, please, not at the same time, otherwise the server will enable DDOS protection and will be right.

Instead of a conclusion

One of Leonid’s most famous phrases refers to how he prepared to go to war with the Persians. When his wife Gorgo asked what to do if she dies, Leonid answered: " Take a good husband and give birth to healthy children ." Someone may be shocked by such a relationship between spouses. Consider another option. Gorgo could begin to sob and persuade her husband to stay at home, give way to the Persians. Would Leonid listen to her? Not. After becoming king of Sparta, he made a commitment to protect his city and people. In addition, such behavior of his wife would adversely affect the fighting spirit of the king. Instead, Gorgo asked the only possible question in the most accurate wording and received the most accurate and altruistic answer: " Be happy ."

In the framework of business communication, we all represent the interests of organizations and are bound by certain obligations. You should take this into account and act rationally, not allowing emotions to take over. Conflicts of interest are inevitable, and personal conflicts, on the contrary, can and should be avoided in every way.