In the actual software development process, many project management personnel may have the first headache in China, that is, the team members are not enthusiastic about their work and are not invested enough.
There may be many causes of this problem, such:
One of the possible reasons is people.
Assuming that everyone consciously abides by the rules in the workplace, the management difficulty is relatively low. However, in many cases, team members may lack some basic consensus. For many people, the basic idea may be:
Working is just a way to make a living. I don't know where to be tomorrow? This leads to a lack of sense of belonging and initiative among team members.
The second possible cause is the environment.
China's software industry is in the downstream of the entire industrial chain. Outsourcing and system integration are the themes of the software industry. This background makes a lot of work boring. Just as Microsoft cannot outsource the kernel, many times the outsourcing is often repetitive and interesting.
The third reason may be the Enterprise.
Some enterprises have no long-term plans to equate employees with tools.
There are still some advantages for cause 1 and cause 2. If the real cause is cause 3, it is not something that can be solved at the project level. Maybe a better way is to change the company.
At a specific point in time and in a specific social environment, some realities can only be accepted, but it is difficult for individuals to change their power, such as the industrial environment. At this time, the most important thing for individuals is their choice.
Everyone has the right to choose a company and work for themselves. If they find that their choice is inappropriate, they can give up.
However, after the selection, it is just a shame or pity, it must be wrong, the result can only be a waste of youth.
Therefore, if the cause is one or two, the manager's first responsibility is to let everyone recognize their choices. Next, you can start your work by referring to the spells mentioned by Han Feizi.
Rules are rules agreed to by everyone. The key point here is that everyone must agree. After the agreement is made, the rule is actually a commitment between team members.
Surgery is a temporary response. Such as criticism, punishment, or encouragement. Criticism and punishment of such things should be based on law, and those who undoubtedly violate their commitments should be criticized.
The trend is more subtle, so I won't talk about it here.
While doing the above, do not forget the basic principle of management: sincerely stick to the win-win philosophy.
Efforts should be made to plan personal development prospects and help individuals grow practically.
At the same time, two things must not be done:
The first is simply using the great policy or letting yourself flow.
A simple description of the great policy is that you will be fined immediately if you do not do anything or do not do well. There may naturally be many penalty methods, such as lowering the rating and criticizing them.
In the short term, this is almost the only way to achieve quick results, but in fact it is at the cost of long-term benefits. In this way, the efficiency is reduced, and the elimination of the advantages and the disadvantages (opposite to the survival of the fittest) is almost an inevitable result.
On the contrary, the other extreme is laissez-faire, trying to maintain the air. In this way, the atmosphere of the team is still acceptable, but there is no fighting power. In normal times, the team tends to be scattered and will not start from the details. As a result, it will become a big problem. At the same time, the personnel did not grow. In the long term, the dual interests of individuals and companies will eventually be damaged.
Second, try to use numbers to measure individuals. The cost and effect are completely out of proportion.
In traditional industries, there seems to be a piece-rate wage statement. People who prefer quantitative management tend to try to use numbers to directly measure team members. This is not completely feasible, but it is dangerous for software development. As mentioned above, as a software set of concepts and logic, its measurements are very vague.
For example=Scale/Work hours to measure individuals andUseCodeIf a row is used as a measurement unit, exceptions may occur. For example, when the same function is completed, the number of lines of good code may be less than the number of lines of code with a lower quality. If the time consumption is the same, it appears that, on the contrary, the productivity of excellent code is low.
However, with productivity,BugRate indicators are used to measure people. The danger lies not only in the inaccuracy of numbers. However, once these numbers are associated with personal interests, the inaccuracy of these numbers may be magnified, resulting in greater inequality. Code lines, working hours, and evenBugAn individual can have a very large impact on the implementation of these key metrics, which is usually difficult to be excluded as a factor that interferes with data.