Discussion on the project management of Software (II.)

The previous article assorted said that the problem of software projects, this article said yards of the farmers themselves. Recently things have been relatively busy, did not have time to update, until just see the company code in a colleague in the header file in a function and a function of the. cc file to achieve the same function, even the code is exactly the same, but this friend to arbitrarily increase the code of repetition, is no language. Feeling the occasion, forcing me to throw this article out tonight. Last time commented that the management of software is not to be inhuman, but instead, should be more humane. My personal understanding is that the project itself design, implementation, and testing should minimize the reliance on human subjective factors, for the management of developers, it must be humane. Okay, no nonsense, start.
As a manager, if a thing (big to a function, small to a bug) did not do well, then what should we look at? For example, the problem mentioned above, a software engineer, ignoring the existing code, directly add a implementation function exactly the same or even the same code function, what do we do? Just call him over and scold him? Out of the question, direct opening remark car face blame, absolutely will not solve the problem.
    I thought, we should first think two questions, is he can not do well? Or does he want to do it? Some people will say, I go, so simple things, how can not do well, must not want to do well, but also with what to think. In fact, when we take this matter to a large project to see, there are various possibilities, which is what we want to be human-friendly place. When a person can not do things well, there are two possibilities, the first is that there is no time to do well. When the project is very urgent, the customer is waiting, the boss has been urging, even the order is in that project, the software engineer under the pressure is actually very large, for fear that because of their own impact on the company's sales, so in the rapid completion of the project and intense testing, many people are not in the mood to see the existing code, Such a simple thing, just write one, hurriedly the task to complete the absolute occupy his highest priority. If the manager who is afraid of the head, casually promised to sell or even customers, did not carefully consider the workload (forgive him, because if the developer is important in the eyes of the project, then his eyes is how to turn the project into profit), then this situation should be frequent, especially in small companies, this situation is more common. If this is the case, it is unrealistic to think about the manager's own reflection. Another possibility that one cannot do things well is the lack of skills. There is a very good saying that five years of work experience can not be used with a skill for five years. At work, many people feel that they are progressing very quickly at the beginning, but the more they get acquainted with the work environment, the less progress, or even stagnation, of the code. Do the work at hand, and step by step to complete the task. But very few people to carefully look at their previous code where the writing is not good, those problems are poorly thought out, there are those methods too stupid, and they have not for these bad places to learn, now there is no better way to achieve, and few companies will continue to train staff, increase staff skills, is the staff more efficient completion of the task. As a manager, if the employees themselves do not learn, it is more often to organize a number of learning and exchange training, so that senior engineers talk about their project design, talk about their code used in the algorithm, design patterns, communication mechanisms, as well as the problems encountered, and so on, these are very helpful to the growth of junior engineer. Therefore, when a person can not do things well, managers should first reflect on whether they are not enough to estimate the amount of task, set goals too hasty. Second, you should reflect on the level of the team is not a long time to stay at a certain level, which reminds you of your brother training. Of course, as a yard, but also to have a growing heart, willing to constantly learn some new things, read books, review the algorithm, so as to dry five years have five years of work experience, rather than an experience with five years. Think about it, what a sad thing it is to have an experience for five years.
What if it's not the guy who can't do it, but he doesn't want to do it? Some people say to expel him, all TM do not want to dry, keep also useless. In fact, this point can be divided into two points of view. The first is that external factors make him do not want to do well, such as the company's requirements for the project itself is not high, and the team, we all do so, do not do too seriously and do not use, the leader can not see, who dry more quickly who pay more, too strict for their own requirements are not what good. As a code farmer, for writing code is a conscience live, I have experience, the QA mix is actually not difficult, but to each point is done very well, the difficulty is very high. In this case, the manager should be in time to detect those who usually work hard to write code but the person in time to find them to talk, to see if they have neglected a lot of people poured in the mind of the code, while looking at the project is too low standards. A simple example, for the same task, you ask two different people, how long can you finish? Two people are likely to give a large gap in time, do not judge a person to grind time with you, and to ask more, you say that the standard is done? Most likely you'll hear one person say, complete all the functions, and construct the test for each function point pass these tests, consider the possible exception boundary conditions and deal with them, while the other person is talking about writing the code. This is when the company does not have a uniform requirement that everyone has a different definition of the standard to be done. Through these, in fact, we can also better understand a person, please cherish those who give the first answer to the yards of farmers. I don't want to do it. Another external cause is that, with leadership contradictions, such as leadership like brainstorming, employees like thoughtful, then there will be leaders feel that employees do not work, and employees feel that the leadership of a little brain is not the case. If the leader is thoughtful, and the staff brainstorm, then the leadership will feel that the staff impetuous a little bit, and the staff feel that leadership is hard to become a big deal. At this point, as a manager, first of all should be found in their own style inconsistent with those employees, and pay attention to their relationship, because after all, you are the leader, you need to figure out how to control people, and he is more in the consideration of the project. If the contradiction deepens, it is easy for employees to leave. There are a lot of small problems, all need the attention of managers, we must try to understand the use of people. I believe that we have all seen some employees because they can not engage in their favorite areas or their own areas of expertise to leave the situation. In fact, these are the problems of managers themselves.
Another possibility of not doing well is the internal cause of the employee itself, which is actually two factors. The first is not high on their own, at the same time the company does not have a high standard, then the staff's own inertia will make his goal to complete the task, rather than do a good job. I have seen some people write their own code after the function of throwing directly to the QA test, measure the problem to repair, no problem. I have also seen, some people in the beginning to write code began to think of their own function how to measure, where to test, with what method to test, those places may have functional problems, those places have abnormal situation did not handle, those places may have performance problems, he put these one by one are recorded, will be handed over to QA, Use your own sample to ensure that all functions are correct, and that all the places you have taken into account are basically fine, and then to QA, so that they can help themselves to measure the problems they may not have thought of. For such employees, a rigorous process and requirements can solve the problem. The second internal cause is the employee's attitude is not good. There are people in this world to work as everything, someone to work as a means of eating life, some people really just want to do a little job to get some wages, usually over point of their own truly, there are serious in the company are doing their own things, look at the novel, on the Internet, things to do do, and then continue their lives. This part of the people we really can not afford to hurt, if you are very concerned about the team's feeling of struggle together, and you have a very big gas field, may wish to talk to him, changed his heart changed his attitude. Or you do not care about the team to fight together, we squarely very good. Otherwise, the early scattered, for everyone is good.
In a blink of an eye and so much more wordy. About the software project management first write so much. Originally intended to train, svn,branch,release, testing, bug management, and so on, are written, but also feel too details. This is the first time, if necessary, to write later.

Discussion on the project management of Software (II.)