Who is suitable for reading this article?
1. Project Manager
2. Technicians who want to improve the status quo of the team
3. Students who study software engineering feel that it is a piece of paper
If you don't think software project management is an art of managing people, read an article I just accidentally collected, " The Story of an Agile Coach Stopping a Deviated Train "
As we all know, software development is inseparable from technology, but it is also inseparable from management. Although this is just a simple sentence, different people have different understandings of it, some people focus on "technology", and some people put it on "management". Of course, such judgments are completely invalid. First of all, both are necessary. Moreover, the proportion of technology and management caused by the specific details of different projects is not the same. Therefore, we can only create our software according to local conditions. , to create one myth after another.
Not sure how you learned about software project management? Here are a few scenarios that I think are possible.
1. University textbooks, many computer majors in colleges must take a course in software engineering, among which the software project management has been ostentatious. Of course, as far as I know, students often complete their studies without knowing anything, so this course brings them far less significance than production practice.
2. University textbooks, (repeated? NO) The management departments of many universities also offer the same courses. Of course, their focus is project management, but they also involve some software project management items.
3. IT manager, maybe you know some IT managers, they always tell you all kinds of stories about their teams, maybe you don't necessarily hear the words "software project management", but you can definitely match him with this approach No.
4. Programmer, maybe your friend is in the software industry, so they also have various accounts of what happened to their team.
5. Books, of course, this is obvious, because the software industry is a huge market, and many scholars are involved in it. Considerable actual situation tells us that this kind of books usually rely on some realistic scenarios to describe.
……
No more enumerating.
What kind of knowledge is software project management?
Software project management, in its essence, is a management, and it should be described as a responsibility to manage the collaborative work of software personnel.
The characteristics of modern software indicate that the development of a successful software will not be, or at least not usually, done by a single person, but by a software team collaboratively. How to organize and coordinate software teams to develop software in an orderly and effective manner is a great responsibility of software project management. We have reason to believe that a team without good software project management cannot efficiently adapt to the competition in the modern software industry. Therefore, the importance of software project management has always been regarded as a vital component in software engineering and has been included in the required courses for project managers.
It is often heard that large companies/foreign companies have an effective management team. People from large companies are popular because their management experience can bring about an improvement in the productivity of the new company, or Said that this layer of "managerability" will become the gold plated in their dreams.
Software project management is not the technology of managing technology, but the art of managing people.
Tell me about some examples of how some foreign companies work. The software department of a well-known wholly foreign-owned multinational company accepts the company's software business in mainland China and completes more than 70% of domestic projects. Their work and life are under a clear division of labor. After undertaking the project, they complete the software project requirements, design, production R&D, testing and other tasks in sequence. The period includes various processes starting from the project review. The time to complete these preliminary work occupies more than 60% of the entire software project development time, and then the code writing begins. Of course, the design is definitely not perfect, and the modification during the period is also around the main road, which is inseparable. Only after rigorous testing can the final software product be obtained. These also coincide with the proportional allocations mentioned in many software project management books we have obtained.
What about the domestic situation? We can say that the number of software companies is uneven, and the size is even more surprising. I can't kill everyone with one blow, but I believe many companies are always like this: After the project manager got the project, he began to think about how to start the design of the software, so he quickly convened a team to set up the database first, and then also wrote a A word document that can still be used with a scroll bar, attracted his subordinates, and began to explain the various modules of this project to them. The subsequent work can be imagined, which is to enter coding. The project will soon be settled in VSS, and the ××× project requirement document can also be found on it.
What about time? Overseas companies may have been writing documents within a month of the project, resulting in programmers not knowing whether they should be called clerks. The mainland team, programmers, with the enthusiasm of sacrificing for the software, started day and night. Code life, write their favorite code, not documentation.
A month has passed, the overseas company has finally started the coding process, and the mainland team may have finished writing most of the modules. (Many project managers in China are also involved in the coding work themselves, and they are also indispensable figures) The project managers began to check the results one by one. The project managers are still a bit older, so they began to communicate with their subordinates.
Why is this page so ugly? Don't you find it ugly? You won't... So, change.
This function doesn't seem right. I should have told you very clearly last time, why did you forget? ... so, change.
It's okay to do this, but don't you feel uncomfortable using it here, here, here? So, change.
This, you can refer to what I made ×××, we try not to use pictures now, you can’t be the same as the last project, we can change it, I have already changed it, you should change it like this, (refuting : Didn't you say you should do this before), that's what the leader meant, wouldn't it be more direct to use words instead? (Retort: But it was said before that it would not work like this), you still listen to me and change it to this! So, change.
This, it's not very good to do this, don't you think it's inconvenient, and the technology is so complicated, separate, why are you still using the previous XX style, isn't this ** style approach very useful? Why not? So, change.
……
The programmer has been wondering, I have been thinking about this for a long time, if I were to be the customer, it would feel good, at least better than the ××, hey, but I have to change it, anyway, the money is calculated according to the time...
Depending on the number of modifications to be made, such modifications may take longer or shorter periods of time. But a new problem came again. When the programmer took the modified program to hand over, the project manager began to give pointers. Of course, there were still problems left over and forgotten during the period. Of course, it was often changed due to modification. New problems are introduced. So: don't you use this thing yourself? how so! It's going to be back to work! (Retort: I didn't change this just now...￥...%&#) Of course, we still have to change it. If we go deeper, there are still many problems, which were seen through the project manager's "pursuit of perfection" vision, so the whole process went through again The construction that lasted for more than half a month was successfully completed, but there were various problems that were unknown and introduced everywhere.
Maybe you would say refactoring when changing the project, and then use testing to ensure automatic verification, and then..., but the existing framework may not be the fertile soil for growing vegetables at all, and the existing team has no so-called testing at all. technology is guaranteed.
From the above examples, I roughly select the following types:
user experience
The project may be moving closer to the advertisement of "good user experience" and talk about it, but in fact these "user experience" are only subjective judgments of some people. Of course, in beauty, everyone has the right to express their opinions. , but not everyone can make the final decision.
Specifications
The content that is not expressly stipulated has the hidden danger of death without proof, resulting in wrongful convictions, and the root cause of many other problems. Because it has been emphasized that it is the art of managing people, and people are actors with thoughts and subjective initiative. People who are confused by "unjust, false and wrongful convictions" may develop a psychology of fear or rejection. This kind of psychology is not harmonious for the art of managing people, but drinking water and thinking about the source, who caused the problem? Does it all come down to the project manager? Not really, but more specifically because of lack of rigour in management strategy.
technological change
Effective team communication is an essential part of team management, and the above cases obviously fail to communicate effectively, or it can also be understood as a result of non-standardization of specifications.
At this point, the overseas team has begun to enter the annual travel plan, and the domestic team, if there is no new project, is accepting the opinions of users. Of course, it is conceivable that the change is inevitable, of course, the possibility of the overseas team returning to work It's not no, but the problem is that their products have reached "agreement" with users in advance (because users may also be confused by the software team in the demand stage, they don't know whether the decided plan is the effect of the product, but this way Compared with the latter, the success rate is generally much higher...) As for the mainland team, if the requirements are done amateurishly, problems will appear in a large number of business logic and user experience links, and the impact of this will affect the entire project. are fatal. The cost of the project becomes inestimable, and one day the user is dissatisfied, everything has to be started from scratch, and all the mistakes are made in the "what-if" at the beginning. The Continental team always assumes that their needs and implementation are so easy for users, and Continental users are often the type of submissive (inexperienced and knowledgeable, coupled with the possibility of long-term partnerships, so they are more able to "Adapting" to that bad experience), and the mainland team thinks that their users are "no opinion", so they are becoming more and more arrogant and arrogant... Of course, this is by no means most software companies, But at least I believe part of it.
Continental team
The current team is exhausted.
The project manager thinks that his subordinates are all waste, and he can't do a little thing well (on the contrary, what he does is so beautiful, he is complacent...)
Subordinates: Hey, everything has been changed again. The arrogant type is angry. What you do is also called user experience. It is backward; the submissive type, hey, pay more attention next time (start to distort your subjective judgment and start to be cautious. acting on future projects)
Relationships: The otherwise harmonious office has developed a separation.
It's no wonder that people say that foreigners think relatively simple, while Chinese people think too complicated. In this way, social factors are the root cause of this complex relationship, and this unfavorable communication has become a dissonance in the team. And the art of Guan Ren will appear lifeless when it encounters such a note.
foreign team
Since the documentation is well done, when there is a problem, open the document and convince the person who knows it. Responsibility will not be shied away. (Remember that Carnegie said that ordinary people will not or no one is willing to admit that they are wrong. Even if they do, they do not think so 100%... Then why should we introduce such an environment to nourish such bacteria? What about growth? Since we can use black and white to get rid of this boring interpersonal factor...)
Documentation is also conducive to project acceptance. When users are dissatisfied with the products they get, they need to pay for improvements. The mainland team has no advantage in this regard, and can only be told that you did something wrong.
Therefore, in software project management, documentation can be used as a solution to solve important factors such as software team communication and specification.
At this time, you may be able to hear the voice of the project manager of the mainland team. Now, where does our team have so much time to do these efforts, can those documents be used as buttons to produce effects? can not? We want programs, not documentation! Furthermore, who will write these so-called documents? I am the only one who understands the needs. Do you want to exhaust me? Also, such a big system is not difficult at all, so why write those?
Since these questions have been raised, there must be a reason for their existence. It is true that small teams need to pay risks to complete such tasks.
First of all, project managers are reluctant to write, because many impatient people are impatient to write what they call formal, but are they actually formal? In fact, they are subtly changing the way we work, and improving the construction process of programs from one side, so that it does not grow up twisted. Maybe the previous rules about time allocation don't work for your team, but documentation always solves your current problems more or less.
Furthermore, to solve the problem of document granularity. I have heard from friends that their company's documents are detailed to a granularity of 100px × 200px, and the length, width and height of each visible part are strictly designed. In addition, the code design is refined to the method body. Of course, this is not what I recommend, and I have nothing to recommend to you, because there has never been and should not be an answer to this question. You have to work out a project that matches your granularity according to your team, down to the method body. This approach may cause many existing software teams to go crazy.
Finally, emphasize the role of documentation in improving interpersonal relationships. This aspect of the problem is the most dangerous and terrifying. It affects your mood, your work, and even your physical and mental health (don't be mad at yourself or mad at others...). Human psychology is the most complex part of the entire software project management. A good team is not a team that emphasizes team spirit with team members, but a team that can inspire people's strongest team spirit. are not comparable.
If your team is still communicating verbally, if your team is still arguing over pure specification issues other than business domain logic, if your team is still in the throes of changing code, try the method, I can't guarantee that it will work, but don't bother to try it.