From programmer to Project Manager (6): Programmer's Station-perfectionism is also a mistake

The pursuit of perfection is a valuable spirit, and perfectionism has always been regarded as an excellent character. But in the project, perfectionism is also a mistake, though it is a "beautiful mistake". The project is balanced, the need is qualified, not excellent, 70 points, not 100 points!

1. A polarizing programmer

I believe that in many people's eyes, programmers are meticulous work, the code is carefully carved, the pursuit of excellence. Look, they sit in front of the computer is big half a day, if not the pursuit of perfect person, who can sit like this bench?

But as far as I can see, in the "pursuit of perfection" This problem, the programmer is actually a serious polarization. Some programmers do have a high demand for their code, and when programming, they pay great attention to the rigor of logic, the high efficiency of running, the elegance of code, and the refactoring and optimization of code. They are like a neat and tidy countryside old too, all day broom does not leave hand, where to see the code that is not pleasing to the eye, will change to where, if let him to maintain a system, most will eventually let him the whole system of code all reconstruct or rewrite again. They are truly perfectionists.

There are also some people who write code that seems just to accomplish the task. They are responsible for their functions, lack of planning and design process, think of where to write where, finally press F5, compile through, oh yes! They don't even want to click on the button they created, even more do not enter a phone number in the text box of a social security number to test it, the most important thing is to finally get to the manager, as for the number of hidden problems in the code, and then again. It reminds me of the programmer tribal chief Joel, who wrote a program that "looks like a dog's breakfast, so long as the dog can eat it, why spend the money to make the food smell and taste?" "We can even imagine that their computer screen is not covered with dust, the keyboard is not stuffed with hair and food crumbs, computer desktop icons are not as colorful jigsaw puzzles, people dazzling."

The latter category of programmers seems to have an absolute advantage in number, and for a project manager who is not good at controlling project quality, their code will eventually become a nightmare for the project. Once the system has been put into operation, the worms will emerge like alien creatures from the American horror film, flowing from the nostrils, mouth and ear seams.

The second kind of programmer low standard low requirements, casual approach, it is easy to be identified as a bad tendency, and perfectionism is not so, because we have been taught to pursue perfection since childhood, perfectionism is generally considered to be a good character, is the goal that everyone should pursue.

Although perfectionism sounds good, it is not suitable for projects because the goal of the project is to complete the project with the least amount of cost, to satisfy the parties, rather than to create a flawless product that proves the ability of the individual or the company. It is clear that perfectionism is better suited to the cultivation of individual abilities, or to a scientific study without a deadline, and that perfectionism is also a mistake in a project, albeit a "beautiful mistake".

Perfectionists and casual people, both programmers are not the best candidates for the project, they happen to be the two opposite extreme, if they are responsible for the project, it is estimated to be like a seesaw, either under the ground, or into the sky. But the project can not afford such a toss, the project needs to have a balance of ability, they are very good grasp the pursuit of the perfect "degree", so that the software function to meet the needs of customers, but not to spend too much energy. Unfortunately, this kind of programmer is not many, because the degree of grasp for programmers, is really not an easy thing.

2. Perfect not equal to 100 points of quality

The perfection in the programmer's mind is not the same as the perfection in the project manager's heart, because the two centers of attention are different. Programmers focus on their own software features themselves, and strive to achieve the best quality software products, so the programmer's perfect is actually the perfect quality.

The project manager in the eyes, see is the whole project, including quality, progress, cost, scope, risk and other aspects, need to balance, spend the least cost, with the least time, to meet the satisfaction of all parties, to achieve project acceptance, this is perfect. Pure product Quality First-class, and progress delays, cost overruns, which is obviously not a perfect project.

In fact, modern quality management theory generally believes that quality is not the higher the better. In fact, the market has proved countless times. Many people have called Microsoft's products rotten, and Steve Jobs was said to have cursed windows as a piece of crap, but Microsoft later became the dominant software industry.

ISO9000 's authoritative definition of quality is: the degree to which a set of intrinsic characteristics satisfies the requirements. See, it is satisfying, not exceeding, which is very important. No less, less, but not much, more is wasted. What we need is not a 100-point quality, not even a first-class quality, but a quality that meets the requirements.

In project management, there is a noun called "gold-plated", that is, after the product to meet customer requirements, and then do some additional work, so that the product more perfect, to further enhance customer satisfaction, which in the pmbok is a clearly prohibited behavior. Software quality of 100 points, in the project is not only a huge waste, and almost an unreachable goal, will only overwhelm the project, and finally into a disaster situation.

3. Eligibility is perfect

The pursuit of perfection itself is not wrong, but if the rise to perfectionism, always to do the best, but not necessarily in line with the local conditions at the time limit. A "most" word will kill the dead, because "there is no best, only better", if blindly pursue better, the result may be like the monster in tar pits, can not extricate themselves. In such an era of efficiency, perfectionism is more likely to lead to the loss of opportunity. Therefore, to maintain the pursuit of perfect heart, but also know the balance, do not fall into the trap of extreme perfectionism.

To be perfect not perfectionism, is essentially a matter of degree, the project should be balanced and avoid extremes. People who have studied project management theory know that there is an "iron triangle" in project management, that is, under the constraints of a certain project scope, the cost, schedule and quality constitute the three endpoints of the triangle, in order to keep the triangular area unchanged, any change of the end point will cause the synchronization change of the other or two endpoints. The Iron triangle is essentially a relationship of balance and restraint, and perfectionism, which simply emphasizes quality and ignores other factors, is obviously an extreme act.

What is the "degree" of quality in the project? In fact, "qualified" two words. Qualification means being recognized, but not at the cost of achieving good. Is it perfect for customer recognition, leadership pleasure, and employee ease? Can say that the project is not the best, only qualified, qualified is perfect.

4. "70-point doctrine"

From childhood teachers and books on education we want to pursue perfection, test to test 100 points, 90 points are too low, that 70 points still get hand?

In fact, 70 points is not low, to know that the slogan of the university students now is "60 points long live, more than a penny wasted, less a cent void." Of course, this slogan is easily criticized as a non-enterprising, but all things exist there is a reasonable side, "60 Long live" is a reason.

In terms of learning, I am advocating perfectionism, the premise is that learning is a personal interest, useful, practical things, we can most of the university curriculum, basically the opposite. Classes, exams, nothing more than to hang the branch, successfully get diplomas and degree certificates. In this case, long live 60 points is easy to understand. Why do you want to test 100 points, save time, can be used to learn their own more interesting things.

To some extent, doing a project is also a test: there are test content (project scope), test time (schedule), and pass line (quality requirements and acceptance criteria). If the passing line of the project is indicated by a score, it is also 60 points, since 60 points is enough, why did the fruit put forward the "70-point doctrine"? Actually very simple, because to want to just test 60 points, it is too difficult, not good will get a failure. So I put forward the "70-point Doctrine", a neo-doctrine that transcends perfectionism, striving to strike a balance between passing and perfection.

If the project is divided into 70 goals, the appropriate buffer, you can do it easily, easier to control. 70 points means that has reached the customer acceptance requirements, has been able to put into normal use, but there may be some minor impact of the bug, the individual page efficiency needs to be improved, individual operation is not very handy, system extensibility, code organization and so further optimization ... These imperfect places, let them stay there, after all, customers have already felt that they have reached the goal, why bother themselves with their own, not to reach 100 points? Early acceptance, early collection of money, this is the kingly! Eat only 7 points full, the project is only 70 points, "70 points long live"!

From programmer to Project Manager (6): Programmer's Station-perfectionism is also a mistake