Turn: What to save you, my team

I always think that software development is like building a house or building a magnificent building, depending on the size of the project. In fact, many aspects of software engineering are based on architectural knowledge. The term "engineering" is introduced from architecture, and similar concepts are also derived from architecture. In this case, the development of software is the same as the construction of houses. If you have to build a small bungalow by yourself, it is not impossible, but please note that it must be a small one.

In fact, the biggest headache for team development is not the technical issue, but the issue of cooperation between players. In particular, when encountering a team with many contradictions, the progress of the project will be slow. Team development is by no means a few level SVN pullsProgramYou can start something! You need to pay attention to many aspects before you can cooperate well to complete a project.

 

L awesome project manager (Project Leader)

First, the Project Manager (Project Leader) must fully understand the project requirements and discuss with the team members a set of reasonable solutions. In this process, project managers (project leaders) of different solutions should dare to make decisions and take responsibility. No matter whether you select the right or wrong option, it is better than not selecting the option. When you select the option, the project will only be postponed, and the next upgrade version will be too big. Generally, when functions are implemented, users are more concerned with the completion date rather than the performance. Because every one minute the user's confidence in the implementation of the software is reduced by one point.

Secondly, the project manager (Project Leader) must be domineering. I believe that every team may encounter a team member who does not cooperate with each other. For such a team member, try to assign him some less flexible work. If a team member seriously affects cooperation, the project leader (Project Manager) is required to come forward and let you do what you want. Don't talk nonsense. I will bear the burden when something goes wrong! After all, the project manager is the largest in a project. If a problem occurs in the project, the customer or the boss will not blame a programmer, and he will directly yell at the Project Manager (project leader ). Therefore, the team members have the obligation and responsibility to listen to the arrangement of the Project Manager (project leader. This is also why the project manager (Project Leader) pays special attention to the cooperation ability of the team members when recruiting (whether to follow the arrangement is also a kind of cooperation ability ), how depressing it is to recruit an disobedient person.

 

L dare to deny yourself

During the project design stage, we will discuss specific solutions. Most of the time, you are unwilling to deny your solutions for the sake of face. In fact, this is easy to understand. Everyone comes from programmers. A common problem for programmers is that they often blindly appreciate their ownCodeIn the software design, it is still difficult to "Nature" and cannot be left behind for your own design. Once others say they have problems with their design, they can't wait to argue with them for three hundred rounds. Debate is definitely a good thing for software design. The more you argue about the demand and design of software, the clearer it is. But when necessary (when most people are not sure about themselves), you should think about it well: is it because your ideas are perfect and impeccable? Do other people's ideas really mean they can't do anything they want? If it is the former, no matter who you are (ordinary team members or project leader) for the whole project, for the team, please put down your face and deny yourself !!!

 

L do not contradict others' opinions.

Never Deny the opinions of the team members at any time, even if you are a project leader (or project manager!

In the project design phase, when the team members propose other opinions for the system, if you feel reasonable, you do not have to say that you agree. If you think it is unreasonable, all you have to do is to compare your point of view with his point of view, so that all the team members can discuss and choose which one is more conducive to the implementation of software.

Once the project design is complete, no good solutions should be adopted by the team members !!! At this time, you only need to remember to prepare for the system upgrade in the future. This is also why software of large companies (such as Windows systems) are often prepared for the next version when the previous version is not released. In many cases, developers generate better solutions in the development process. Good solution-record the next system upgrade and start from some aspects.

Why cannot I "complete" after the design is complete "?

If you modify the design after the project design is completed, it may affect other parts of the project. After a long period of design, we can say that there are few conflicts between the system and the system. If a sudden change in one aspect of the design, there is a high probability that it will lead to a systemic result, even because the entire software is in conflict with each other as a result of this small change, which will eventually lead to the consequences of a new start. (What proportion of the header is worse ?!!)

 

L be good at using third parties to avoid "playing the ball"

I have to say that no detailed design document, no UML diagram will take care of all the details of the system. After all, the document and UML are just an approximate form of modeling. In this way, it is inevitable that the details are not involved. Unfortunately, these details are exactly the same between two developers' tasks. It is inevitable to "kick the ball" with each other, similar to the following, it will become the main language of the team.

A: "Why isn't your method ...... Data processing. I have to process it again !"

B: "Shouldn't you process this data ?"

A :......

It may take only one hour to process the data, but it takes several hours to argue who is responsible. This is also one of the reasons for the team's slow development progress. However, if another person is present (if the project manager is the best), no matter who the third person is, the ratio of personnel in this "war" must be. This will greatly shorten unnecessary debate time for the entire project.

The entire expected dialog is as follows:

A: "Is your *** method not handled ...... Data ?"

B: "Where should I handle this data? C are you right ?"

C: "In principle, this should be B's responsibility. You see, I think so ......"

A: "I think so too, and there is ......, B, what do you say ?"

B: "Okay, I am going to add it here" (although there are one thousand do not want to, although there are 10 thousand cursing, ...... You know !)

 

L The communication method is extremely important: Change your words, change your world (Click me)

Pay attention to your own way of speaking. The expression of the same meaning is different, and the effect is different. You don't need to use a second person, but you need to start with a pronoun like "we", "we", "you", or a nickname (* brother, * Sister, etc. Try to compare the following sentence

Method 1: "Why don't you write this method ?"

Method 2: "Why don't we write this method ?"

There is no doubt that the first sentence has a harsh tone. Although you may not mean it when you say it, it is easy for the listener to think so. If the task is heavy and the mood is excited, it will inevitably lead to discord within the team.

Use polite language no matter how bad your mood is! Try to compare the following conversations.

Conversation 1:

A: "You have finished writing that method. Hurry up! Waiting for the test !"

B: "Oh" (who is it with TMD? What is it, panic, your sister, hurry up! I won't write it to you !)

Conversation 2:

A: "* elder brother (* elder sister) Did we implement the ** method? Please hurry up. You can basically finish it when you get it done, let's have tea together."

B: "Okay, right away ~~"

Two different expressions with the same meaning have completely different feelings. The first one is hard to accept. It is difficult for normal people to listen to. Although the words in the brackets are not mentioned, it has affected the harmonious atmosphere within the team. We should try our best to use the second kind of fascinating words to make the team more effective!

In fact, Chinese people generally do not do well in terms of polite terms. Many people think that everyone is their own people. It is too false to speak in that way. On the contrary, because they are their own people, they need to respect each other more! In terms of foreign information (such as foreign languages and American dramas), you can respect each other very much in foreign countries, whether between people you don't know or close relatives. Although China is a "state of courtesy", its domestic and foreign comments on Chinese courtesy are generally not high. I think this may also be one of the reasons why China cannot create large software (operating systems, databases, and so on. Lack of friendly communication, the team members are not convinced of each other, the entire team is in conflict with each other, and this team is still working together !!!

The above aspects are my feelings during the cooperation, and I hope to help your team better cooperate. Please remember that the final result of a team without cohesion must be "let the birds go to the forest, the vast land is really clean!"
This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/beijiguangyong/archive/2011/05/23/6438988.aspx