Blog
Work. Monkeys are telepathic.
Recently, a lot of thoughts related to professional activities have accumulated. In order to they are not lost in vain, I decided to write this post and tell a little about the organization of teamwork. I won’t discover anything new. Everything has long been written and chewed in smart books and on different sites for the organization of the workflow. I just tell my subjective vision of the way is happening.
{--picfiledir/martishka.jpg** Мартышки --}Work is said to have made people out of monkeys. I would like to make some refinements it was collaborating work. A new project has started in our company. I will not describe its purpose and features. I can only say that it will be quite a big web service. The team consists of 3 people: me, my colleague and the team leader. All we are about the same age. In general, this was my first experience of working in a team, so many things were unclear to me. My colleague and I were told to read the requirements specification. It is unlikely that an ordinary mortal or uninitiated person would be able to understand what's what there. My colleague and I were told to read the requirements specification. It is unlikely that an ordinary mortal or an unaware person would be able to understand the sense of this. When we were asked if everything is clear, we answered a little hesitated YES, with the hope we would understand. So we started. However "started" is an understatement. It was like a cockroach race. When you lift a glass, but they instead run to the finish line scatter in different directions. Everybody has their own image how to do it. Sometimes we wrote the same sections of code at the same time, and then it turned out that someone had already done it. We were describing the functionality that was supposed to work quite differently. In general, everyone tried as best they could and to the best of their abilities. The head didn't help to get rid of the mess. After checking, it was found out that we had done it wrong and we needed to redo it because of the head pointed some problems with this. And since we just started working together, we could not do everything for the first time, some areas were redone three times. Gradually chaos was ordered, and our team got the following form: two monkeys, writing code, and the generator of random ideas. Moreover the monkeys had to guess the new idea as correctly as possible, otherwise they were told they were bad monkeys and did not know how to do anything. This horror was lasting a few days. As a result, the so-called primates rebelled. With a whole team, so it was then called, sat in the conference room and began to sort things out. Claims and disliking about working process were discussed between our team. The main requirement of monkeys was cancellation of uncertainty and openness of plans for the project in order to they could be guided under what conditions to write functionality of the application. In that moment, the vision of the project and its logic was owned only by the head, and he did not like to share it all. These were tense meetings. As a result, we have established a dialogue. We decided to meet every day and discuss who has what questions, and the head promised to share his knowledge on the project. After that, things went well. We have become better coordinated. At the daily meetings, three main questions stood out: “What was done?”, “What have to do next?”, and “Who needs help?” It was a good decision, considering the deadline was approaching and we had to release the first release soon. Our team evolved from a pack of monkeys into a primitive society where every member negotiated with each other in order to achieve the common good. In spite of everything, we all managed to meet the deadline. The most importantly - established a dialogue with each other and with the head. It was a great experience in the team.
I made the following conclusions for myself:
- before starting any project, the manager must gather a team and tell the vision (the
purpose of the project, the method of implementation, the technologies and tools for
usage), because no matter how good the requirements specification was, everyone
still has their own ideas about different things;
- there is need to have a general agreement on the style of programming and
notation of variables, it is very helpful in reading and understanding the code of
colleagues;
- distribute tasks equally between team members as much as possible, so that there
is no confusion and the same functionality is not written twice;
- there should be motivation, it does not matter whether it is deadlines, or chocolates
for the successful completion of tasks, the main thing that was some kind of external
stimulus forcing to work harder;
- the free will to implement is very significant, this is due to some extent with the
previous paragraph, because the lack of a creative element makes the work boring
and negates all the motivation;
- there should be more of communication in the team, it promotes cohesion in the
team, as well as simplifies the development of the product and improves its quality.
Actually, all people are different, and each case should have its own approaches,
but the last point I think is the most important. A favorable environment in the team
is often tantamount to a good salary. Almost all of these points I have read before,
or heard from colleagues, but unfortunately forgot or did not attach any importance
to it. We only learn from our mistakes. I will call it a day. I will try to keep you in rate
evolution our team and putting new posts. So you are welcome for reading.