Thoughts on the military rules of regular army

The management of development and development teams is an eternal topic in software development. Fortunately, some leading practitioners have summed up a lot of experience and skills. These experiences and techniques are targeted at what we may encounter almost every day at our fingertips. Learning from these things that cannot be learned from textbooks is very helpful for guiding our work. Recently, I have the honor to see such an article. I basically agree with the point of view in this article. It is recommended at the end of this article.

However, I have never heard of myself. I have made some progress on some ideas in this article, so that I can view them in the future and want to hear your thoughts.

Because the task is urgent, there is no time to think: "There is no time to think" is a strange concept. That is, "Ctrl + C" and "Ctrl + V" should also consider whether the ins and outs are appropriate. Do we write code with our eyes closed and sleepwalking every day? The Ideological Root behind "No time thinking" is to escape and shirk responsibility, typing, copying, and pasting ...... Finished and handed over, "even if I die, it will flood the sky ". In this way, the production of software is hard to avoid, not to mention the creativity, that is, the general bug is also difficult to avoid. errors will be inherited from the version generation, and will never be detected or corrected.
Therefore, it is recommended that you use the your head for even 10 minutes every day, which will be of great benefit to improving the software quality and improving your own technology.

At the last moment, I told the leader that the code was finished, even if the development task was completed: I would rather believe this is a means for the coder to deal with the leader. The completion time and scheduled time of a development task are exactly one second. Generally, the completion time is less than the scheduled time. After the coders complete the task, they should deliver the work results to the leader in a timely manner. If it is delivered in the last second, there will be no time for acceptance. The coders will think that the leader will save the acceptance step, and they will be lucky enough to pass through the process without any effort to rework.
Many projects are delayed or even failed due to the delay and poor quality of small tasks.

Leaders are right. I have no opinion: this is a typical practice of shirking responsibility. "Yes! Yes! Yes !" I have no suggestions on my own ideas. In fact, the sub-line is: this may be the idea of your leadership, and I will not assume any responsibility in the future. There is another possibility: either this person is an idiot, or this person is full of ass, unwilling or afraid to oppose the leadership.
Many companies either have no democracy or leadership, which leads to employee reluctance to take responsibility. You can either let yourself flow and manage without doing anything. Employees are willing to do whatever they want, like a flood of sand, and cannot form effective productivity or low efficiency.

Team leaders help check everything: this is also a typical practice of shirking responsibility. I was so happy to push the responsibility to the leaders. Not much.

Solving the problem is a matter of leader or PM: it is also the practice of shirking responsibility. That's not enough.

Since my work is handed over to me, I should trust me: this is indeed a misunderstanding, but it is often overlooked. The problem lies mainly in the understanding of "trust. "Trust" is not laissez-faire, not full handover. Remember that all "trust" is trust under certain conditions. Although "trust", certain supervision and process control are still essential.

When you go to work, there is no problem browsing the technical Website: Companies and team leaders encourage everyone to learn, saying "Creating a learning organization ". The fact is that no one is able to control the ability to put himself into work immediately after learning, or to study online after work. Online learning is often a legitimate excuse for wasting time. "Online Learning" is often used to chat in QQ or get lost in the jungle of the Internet.
Suggestion: the LAN used for development in the company is not connected to the Internet, and a dedicated Internet Data Center/machine is set up for supervision by the leaders.

If you have a good working attitude and have a long working life, you can lead the job: Not necessarily. A good working attitude is a good employee with many years of work, but it is only one of the necessary conditions for being a leader and many other conditions for being a leader, for example, the communication and coordination capabilities of administrators and administrators.
However, the company must pay attention to the fact that employees who have a good working attitude and long working life must be given sufficient respect. Even if they cannot be leaders, they cannot be financially disadvantaged. These employees are a valuable asset of the company and a step-by-step inheritance of the company's culture and business, achieving the company's today and tomorrow. However, old qualifications cannot interfere with or obstruct the work of current leaders. How to strike a balance depends on higher leadership capabilities.

Provide the opportunity to train the team member's presentation ability: This is a good practice! Communication and information transmission are important steps in the work. And whether it is effective and accurate (!) Communication is completely dependent on the employee's presentation ability. I don't know why (is it because of the Chinese education system ?), Nowadays, many programmers have poor language skills (both verbal and written). They can't say what they can, but cannot write what they can. Therefore, "providing opportunities to train the expression ability of team members" is a good way to make up for and improve the language ability of employees. In fact, this is also very beneficial to shape the personal personality of employees.

If you want to ask for help, you must stand on the other side to consider the problem: I agree with your hands! The truth is no longer arrogant. I suggest promoting this principle, not only in software development organizations, but also in social life. If others do not owe you, no one is obligated to help you unconditionally. Therefore, it is an ideological method and a moral character to consider the problem first.

Zhang Qing (mesh) 2009-3-5
From mesh horizon: http://blog.why100000.com
Why 100,000 computer learning networks: http://www.why100000.com
Csdn blog: http://blog.csdn.net/zhangking

/*************************************** ********************************
Reprinted the "[reprinted] Regular Army Military Rules" from the programmer's Club"
(Http://club.xasoft.org /? Uid-4-action-viewspace-itemid-7464)
Programmer club source [http://www.javaeye.com/topic/296128]
**************************************** *******************************/

The following article is an email from my boss Anderson, who summarizes some of our team's problems and shares their experiences. Many of them can be shared with you, so I posted the original article here after obtaining the author's consent.

PS: the name of the document "Regular Army Military Rules" is slightly hats, but my current team is indeed the most formal team after my work, in addition, I think the development team we strictly implement through cm5 can also be called regular army. Every process from project initiation to project release is very strict, in addition, the requirements in our team are more strict. We are the team with the least quality bug in the entire project. However, the content of this article is only a summary of some internal experiences of our team. Different teams should have different military rules.

Misunderstanding of coding personnel

Misunderstanding 1: There is no time to think about it because the task is urgent.

Some people think that it is the most important and urgent task to complete within the time specified by the leadership. If the direction is correct, there is no time to consider whether the functions are complete.

These people are stuck in the illusion that writing more code and programs will be safe. But the direction is wrong. The faster you run, the greater the loss.

The root cause of such an idea is that they are not confident, do not know how to analyze the problem, find the best solution, and carefully assess the impact. Therefore, they cannot propose a more reasonable time to their superiors.

For example, the designers of bulk address feature also say that the time is tight and there is no time to think about it. The result is that the design and code of this feature were overturned and redone again and again. Our leader repeatedly explained to Jerry Lu whether or not he could accept our new solution because of the previous mistake, which led to Jerry Lu's dislike.

Misunderstanding 2: Tell the leader at the last moment that the development task is completed after the code is written.

This kind of person thinks that as long as the code is written to the team leader, they will be able to communicate.

If you do something wrong, you cannot redo it;

If it is missed, it will be a big deal;

If there are many bugs, fix the bug;

I didn't take it into consideration. I also had a team leader.

For example, the development time allocated to the Multi Agency admin code owner is sufficient. However, after writing the code, he only verified the basic addition, deletion, modification, and query functions, and did not test the main business logic and other functions of the edge corner, he told leader that the task was completed until the last time the task was completed.

There are two serious consequences:

-Due to the lack of responsibility of the developer, we had to spend more than 30% more time completing and completing tests than originally planned.

-The developer is not aware that his leader is not familiar with his capabilities, so he will be given more time than normal. The task can be completed in advance as long as the normal ability and sense of responsibility are put into play. As a result, he not only failed to complete the task, but also wasted the time reserved for him. In this case, his leader's evaluation of his ability will only be worse, but also increases the leader's distrust of his ability.

Misunderstanding 3: leaders are right. I have no opinion.

For example, when a leader explains requirements and designs to the team members, he hopes that everyone can raise their own questions and ideas. A member of the team told this leader that you have better analytical and design capabilities than I have, and have more work experience than I have. What you have said about me.

In this case, both the developer and team leader need to be improved.

Developers may say the following:

1) He was in a bad mood at the time. At this time, developers should control their emotions.

2) he really understands it. Just answer "I understand it all ".

3) if he does not understand most of the content, he can answer "I cannot fully understand what you have said for the moment. I'll take a closer look at the document. I guess I will ask you 30 minutes later ?"

The team leader can take the following measures for those with weak capabilities:

1) give the team members some preparation time and tell them to focus on that part of the Content Before explaining it.

2) After the explanation, the team member can explain which analysis points he did not think of before and how to analyze them comprehensively.

3) if the analysis capabilities of the team members are too weak to tell anything, we can encourage them to tell what they don't understand.

In this way, the requirements for groups can be customized and specific. What we need is what the team members can do. The team leader should learn how to gradually improve the team members by case.

Misunderstanding 4: team leaders help check everything

For example, hikelee asked a team member to write an email to the customer. Soon the team member told hikelee that the writing was complete.

Hikelee asked Him, "can I send this email directly to Anderson without making any changes ?" The team member replied no. Hikelee asked him to take it back and refer to similar emails sent by hikelee in the past, and send it back after reaching this standard.

After a while, the team member said that he had finished writing. Hikelee asked him again this time whether Anderson could send this email to our customers without making any changes? The team member replied that no. Hikelee told him that he was looking at how Anderson replied to the customer's questions in the past. He found the difference and then sent it to me.

Misunderstanding 5: only raise the problem and not solve it. Solving the problem is a matter of leader or PM.

For example, some team members may ask, our release overtime seems to be a little less than the previous release, but to tell the truth, it is still too frequent. Can we add less classes?

The Q & A team members only raised questions, but did not think about whether they are responsible for tasks that must be completed by working overtime? If so, what do you think can reduce or avoid similar overtime work?

After our analysis, the main reasons for such overtime work are:

1) improper employment. Too many design mistakes are caused by the analysis and design by persons with insufficient capabilities. More time is required to check and repair the problems.

2) Lack of effective analysis and design skills leads to lack of knowledge in the business field, resulting in insufficient effort estimation

3) The encoding and UT quality is poor, and it takes several times to repair and rework.

4) low work efficiency leads to overtime due to failure to complete the task within the specified time

5) improper working methods and unnecessary waiting lead to overtime

We can adopt different policies for different reasons.

Misunderstanding 6: writing code all day is too monotonous and boring

Some developers feel that they have been writing code all day, and they are not able to fix the bug. The tasks assigned by superiors are also too serious. You are doing things with the mentality of dealing with errands. If you assign one task to me, you can do what you say, the same is true for running well.

In fact, we should realize that no matter who we are, no matter whether we are capable or not, we must satisfy the leaders with each of their jobs to accept jobs that are more difficult and challenging, his position and salary will gradually increase as the difficulty of his work increases.

For example, in my case, the team leader is already transferred to the accela department. But I am still scheduled to start with the basic encoding and take charge of a feature. I regard this arrangement as a test for me and do my best. As a result, this feature is well performed, and demonstrates excellent technical, learning, communication, and coordination skills, a high sense of responsibility, and a sense of mission. It proves that I am a team leader. Therefore, the role of team leader is returned in the new Department. In the process of working as a team leader, I was promoted to PM because of the strong combat capability of the team I led and the high quality of the team members.

A developer can obtain the requirement analysis and design work only when the code is well written. Only when the demand analysis and design work is well done, only when the feature owner does a good job can the feature owner be a team leader.

Misunderstanding 7: Since the work is handed over to me, you should trust me.

You must know that "using people without doubts" is only a result rather than a process. Each of us must undergo rigorous tests to gain the trust of our leaders. When the task is completed, the leader can observe our ability level. In the future, when assigning tasks within our capabilities, he can feel at ease and put less energy into it. On the contrary, if he has arranged work beyond our capabilities, he must invest a lot of energy in supervision. Therefore, trust is not absolute.

If we want to gain the trust of our leaders, we must do our best to do a good job in the leadership arrangement, improve our understanding of our abilities, and ensure that leaders can rest assured in everything.

Misunderstanding 8: Because issue is not mentioned in the bug description, QA reopen is incorrect.

For example, QA only describes the problem in the create Portlet. Later, when verifying the bug, QA found that the developer only fixed the issue in the create Portlet, And the search Portlet had the same issue but was not fixed, so the bug was reopened.

The developer said, "No, QA, you have not mentioned the search Portlet issue. This bug should not be reopen. You should introduce a new search Portlet bug ."

This idea is wrong for the following reasons:

1) do not rush to say that reopen is incorrect. First, check whether the bug in the search Portlet has nothing to do with the bug in the create Portlet. If it does not matter, patiently explain to QA why a new bug should be proposed.
2) but no matter how this happens, our developers also have problems. They do not understand that fixing bugs is not a headache. First, we need to find the cause of the Bug, analyze the potential impact of the cause of the bug, and finally completely fix the bug. In addition, a bug has a working principle. When you find a bug in a place, the chance of a bug around you is usually high. Therefore, we must do more tests around this bug.
3) What you don't understand is that only high standards and strict requirements can motivate you to develop faster and better.
4) this kind of work mentality also has problems. If you are wrong, you may be wrong. Do not justify your mistakes too much. Know your own mistakes, where the mistakes are, and then you can make improvements next time. Therefore, we need to adjust our mentality in a timely manner.

Misunderstanding 9: When you go to work, you can browse the technical website to learn new technologies.

We have no objection to the team members learning new knowledge. However, it should be on the premise that the task of the current day has been completed. We will also encourage you if the research content is related to our work.

For example, to improve the efficiency of a fix bug, we need to confirm that a bug that cannot be reproduced cannot exceed 2 hours at most. After talking about this rule in the morning, we found that a team member confirmed two bugs that could not be re-installed, and then went online to learn new technologies.

Misunderstanding of Team Leader

Misunderstanding 1: There is no difference between handling customer problems and handling general development tasks

Some team leaders or feature owners believe that, just like handling customer problems and general development tasks, they can write the code and complete ut.

For example, when a team member processes Andrew D and requires the filter service function to be added, the code is reported to PM as the task is completed. He ignored Andrew's request for a demo on the IST site.

Therefore, we not only need to test on the QA and development sites, but also need to update and deploy the relevant code and configuration (emse script) on the IST site) to verify that Andrew can see this new feature without any configuration. After finally passing the verification on the IST site, you also need to reply to Andrew by email to inform him that the problem has been resolved.

Misunderstanding 2: If the owner has a problem after the task is assigned, he will come to me, but I am very busy and have no time to find him.

The leader has no knowledge of all feature resources under his jurisdiction, and can foresee the possible risks before being assigned to the team members, inform the owner in advance to prevent risks or closely observe whether the owner can discover and avoid risks. If a problem occurs, we need to help the team members identify the cause of the problem and learn and improve their abilities and skills.

You need to communicate with the team members at ordinary times. Do not mistakenly think that it is okay if the team members don't ask me.

For example, if hikelee is working on the expression of the dynamic Web service feature, the bulk address and alter ID mask feature are assigned to the two members, the feature status is rarely asked and checked in the middle. As a result, both feature and feature have a problem.

Misunderstanding 3: A feature owner can be a good employee with a long working life.

The feature owner is not the one who has a good working attitude, has a long working life, or wants to be the feature owner. The essence of this problem is that the use of human resources requires equivalent power. For example, some people do things seriously, but the object-oriented analysis and design capabilities are weak, so they cannot arrange for them to do the analysis and design work. Some people have strong analytical capabilities, however, if you do things less often than half a week, you cannot arrange team leaders if you do things and communication skills are poor.

Skills

1. timely reply

People who seek help in a timely manner can give a good impression and reduce unnecessary troubles.

For example, once lucky sent an email asking all team leaders to help her check the gap between FRD, FSD, and DSD. After the result email is sent, only hikelee replied to her email and told her to complete the task as soon as possible. Afterwards, luky publicly praised hikelee for its good behavior habits.

Winter did not feel how important it is to reply emails to him in time before urging and checking the document task completion. It was not until he took charge of this task that no one replied to his email that he realized how important it was to reply to the email in a timely manner. This is not only a matter of courtesy, but also reduces communication costs.

In addition, timely reply to emails can eliminate the sender's concerns and avoid unnecessary troubles. Andrew D once asked me to add a filter service function for him to show it to the customer. At that time, I was too busy to reply to him immediately. We were discussing solution, impact, and loee. Four days later, he began to complain to my leaders that I did not accept his request. It can be seen how important it is to reply to emails in a timely manner.

2. eliminate or reduce unnecessary wait and rework

Our team leader should learn to discover and summarize the aspects and situations in which our team members may cause unnecessary wait and rework. Case by case teaches them to actively communicate, prioritize and improve work efficiency.

Gradually establish and improve existing systems and processes, and record our processes and experiences in wiki.

The following are some examples:

Example 1: If no one on the scene can make a final shot when discussing a problem, the problem should be immediately stopped after the problem is clarified. Find an award from a person with arbitration qualifications, rather than endless debate.

Example 2: In the past few days, many people are waiting to enter the bug fix plan and bug completion status in VSS. It is not the best way to wait for others to check in or always remember to check whether it is possible.

At this point, we can first send an email to the supervisor's bug fix Saul, CC to PM and our team members, and notify all relevant personnel as soon as possible. Then update the bug tracking sheet in a relatively idle time.

3. provide opportunities to train the team members' Presentation Skills

We should provide more opportunities to train our team members' presentation skills. For example, ask the team members to explain DSD, make a demo, and prepare some training for you.

However, we should inform you in advance to make full preparations. So as not to achieve the effect, it also makes the team members feel that we are trying to make them difficult.

4. If you want to ask for help, you must consider the problem from the standpoint of the other party.

For example, there is a feature of the ASI table share drop down of Abu Dhabi recently. Jerry Lu believes that the current solution is not good, and requires the Code completed by Rol-back and the new approach in the current version.

After careful analysis and comparison, I found that Jerry Lu's solution is indeed much better than the current solution. However, because it is close to release and the amount of reconstruction code changes is relatively large, it is best to postpone the code to the next release.

To persuade Jerry Lu to agree with my point of view, I first thought about what problems he might ask. If he doesn't agree with his main concerns, what information does he need to know to persuade others?

With these questions and prepared answers, I found Jerry Lu at night. Tell him what are the disadvantages of the old solution and where the new solution is good. Jerry said that is why he decided to abandon the old solution. Then I told him what we need to do according to the new solution. At this time, Jerry realized that there is a great risk of code change, but he worried that the old solution would not meet the customer's needs if he did not follow the new solution, this function must be provided in 6.7.0. I told him that the old solution can also meet the most basic requirements of customers.

Upon hearing this, Jerry said he had agreed to postpone, but he still had to find a way to persuade Andrew D. I told him, don't worry, we have a way to delete the old solution code in subsequent versions, and we can automatically switch the old solution to the new solution. In this way, I helped Jerry find the right reason to persuade Andrew D.