Recently, I have started to take on some projects, so let's talk about project management-related matters. I have been in the industry for 13 years and have gradually encountered various project management styles. The basic point is that no single project management method can solve all problems; adjustments must be made according to the team itself.

Speaking of software projects, the general process is similar to the diagram below.

During the implementation of software projects, we often encounter these types of people:

Product Manager

For internet companies, the product manager is a very important role. A good product manager can create products that users love, while a poor product manager may lead the team into various demand reworks and significant resource waste.

However, the entry threshold for product managers is low, but doing the job well is exceptionally difficult. After all, in this era, anyone can claim to be a product manager, unlike technical roles, which require actual coding skills.

In most cases, product managers communicate requirements directly, which leads to a problem: for business personnel/product managers, their requirement is that users should be able to log into the system. But for developers, they want to know the implementation details, the more detailed, the better. For example, submitting via username and password, whether the username is a phone number, how many characters the password can have, what to prompt if the user cannot be found, what to prompt if the password is incorrect, etc.

However, a poor product manager can only state that their requirement is for users to log into the system. For developers, they want to know the implementation details, the more detailed, the better. For example, whether the username is a phone number or something else, how many characters the password can have, what to prompt if the user cannot be found, what to prompt if the password is incorrect, and if external login is involved, how to differentiate permissions between the system and the account, etc.

This leads to a very surreal situation where the product manager does not know what to supplement; they feel they have explained clearly enough. Developers also cannot cover all these situations, and every time they encounter requirements, they always find a bunch of logical issues, making it impossible to move forward.

An even more frightening situation is that there will be pressure from the boss regarding project expectations, which leads to a large number of unclear requirements being forced into the development phase to ensure rapid iteration.

Then, the second tragedy of the project occurs: requirement changes.

This is also the most criticized area, causing the most conflict between product managers and developers. In my years of experience, I have seen many excellent product managers who provide detailed background and descriptions of requirements, along with various rule tables and flowcharts. You can tell they are very dedicated to their products.

However, I find that many developers think these tasks are very simple, just writing some text and making some diagrams, and they feel they can do it too, lacking any sense of respect. When I create my own products, the most time-consuming part is not the development but the product design. I continuously pay for my lack of experience, and I may end up creating a feature that few people use.

Back to the topic, why do developers hate requirement changes so much? I believe the problem lies in the inconsistent understanding between both parties. For product managers, they may think that making these changes is very simple. But for developers, it can be a significant issue.

For example, if we are working on an H5 activity in WeChat and suddenly someone says we need to add background music that plays continuously. If this was not mentioned at the beginning, then for the sake of development efficiency, you might directly use backend rendering, as this avoids having to write a separate API interface.

However, when the webpage redirects, the music will inevitably be interrupted. Although there are ways to solve this, such as embedding an iframe or switching to a single-page application, introducing a new implementation will disrupt the already completed functionality. It's like having laid a solid foundation and then going back to alter it, and assessing the potential impacts is genuinely difficult, even for developers themselves.

Yet, this feature seems simple to the average person, as other pages have similar functionalities. It is easy to judge that it is a failure of the developer's ability if they cannot handle such a simple feature.

I have seen some excellent product managers who take the time to understand technical implementation solutions and communicate their thoughts with developers, so they can consider these aspects during the initial design phase.

Architects and Coders

So, once we enter the development phase, does that mean the project is problem-free?

This is where the architect comes into play. Some readers may not fully understand what architects primarily do. In fact, an architect is just a general term; more often, they are the project's designer. This person could be the team's technical manager, a core developer, or a technical expert—simply put, they are the ones laying the foundation for the project.

A good architect will choose suitable technical solutions based on the current project situation. This situation may include but is not limited to the following points: project cycle, project goals, resource availability, target audience, etc. They will consider technical feasibility, concurrency, demand expansion, and so on. Essentially, they will choose the currently optimal solution from multiple dimensions.

However, a poor architect can ruin the entire project. A good architect will refactor, while a poor architect will rewrite (of course, there are exceptions; I have also seen cases where rewriting significantly improved both performance and development efficiency without affecting the project's expected outcomes).

So, here comes the "rewriter." Faced with the project, they will point out what is wrong here and what problems exist, leading to various issues. As long as they rewrite, everything is no longer a problem.

But more often than not, the rewriter cannot explain why these problems exist; they focus more on the historical developers rather than the specific reasons that caused the issues, giving everyone the impression that they are not targeting anyone specifically, but in their eyes, everyone else is subpar. Another situation is that the rewriter cannot understand the previous developer's code but is too proud to ask for help, so rewriting becomes the only option.

From my current experience, most who demand a rewrite from the start end up with a final product of lower quality than the original. Setting aside human issues, many historical legacy reasons are unknown to the new developers, and they often overlook these problems during the rewriting process, leading to a decline in product quality.

After discussing the rewriter, let's talk about the "wheel maker." The wheel maker enjoys creating wheels and, like the rewriter, has a mysterious confidence, always feeling that the existing solutions, frameworks, and languages in the project are inadequate and problematic. They believe they can create something superior. They share the same issue as the rewriter, lacking an understanding of existing requirements or that their wheel cannot meet current needs, focusing more on satisfying their own requirements.

Finally, we come to the architect. As the name suggests, the architect is the one who builds the architecture. Architects love to discuss concurrency, performance, and architecture. How do we understand this?

I have seen many project builders who, despite working on a new project with little traffic, design the system for high concurrency (of course, in most cases, the designed system cannot withstand high concurrency), and then spend ten times the resources and time designing a complex and difficult-to-expand system.

I have witnessed cases where a microservice was specifically designed for a single table's CRUD operations, and I have seen a new project requiring 6-7 services to complete a single interface process.

Another type is the self-deprecating coder. This type of developer is accurately described as a copy-paste worker. They are novice-level rewriters who only consider completing the current functionality through copy-pasting and modifying. When requirements change, the complexity of adjustments increases exponentially. When they reach a point where adjustments are impossible, they evolve into rewriters, going all-in to start over.

Testing

Once the project has avoided these major issues, can it be completed smoothly?

Testing is a very important position in the project process and serves as the final checkpoint for project quality. After all the pitfalls created by the previous individuals, what if the project is delayed? In discussions, to ensure the project can go live smoothly, testing time is compressed. What? There isn't enough testing time? Then let's do a collective test.

Many people believe that testing is not important and is a role that anyone can do. Like product managers, good testers have a very high threshold.

But the reality is that most testers cannot even describe the problems clearly, just like most product managers cannot articulate the requirements. Some traditional projects do not even have testing, believing that there will be no bugs once developed.

In my career, I have encountered some testers who repeatedly communicate about problem descriptions, and the extremely high communication costs can drive one to the brink of collapse. Usually, their descriptions state that there is a bug here, but they do not provide reproduction steps, account environments, screenshots, etc., requiring repeated confirmations. Some cannot even clarify the requirements and describe what they consider unreasonable as bugs.

Most testers cannot even write out the test users for verification. For example, if the product needs to implement a login function using a phone number, their test cases are always the same as the product requirements, rather than various test cases for validation.

Finally, it’s unclear how to determine if the verification has passed, and then it went live, ultimately leading to users discovering many issues.

Project Manager

In many cases, the project manager may be concurrently held by a technical manager or a product manager. In some larger companies I have worked for, there are dedicated project managers.

At this stage of the project, the project manager will jump out and say that everyone present is incompetent, then list everyone's faults as mentioned above. However, most project managers can only become a tool for asking about timelines; they do not participate in the project and only occasionally ask if things are going well. They compress the timeline, saying it will go live tomorrow. They cannot know where the current issues are stuck, and everyone in the project ignores them.

When there are problems in the project, it is always A has a problem, B has a problem, C has a problem, but there is never a time when there are no problems. Yet they cannot provide a clear plan, such as what the team needs to accomplish today, what work is completed this week, and when the dependencies with other teams will be coordinated, etc.

Conclusion

The complexity of the software development process is far greater than the human factors I mentioned above, such as waterfall development and agile development, the use of efficient project management tools, project process optimization, and so on.

In my professional experience, I have gone through countless projects, and we have done some of the things mentioned above to varying degrees. However, I have found that good teams are also forged through collaboration, as everyone’s personality, experience, and abilities are different. Mistakes will inevitably happen, but the rapid pace of internet development shortens the time for team collaboration, and quick architectural adjustments deprive teams of the time needed to gel, harming one project after another.

This is also why there are both the "strivers" and the "slackers"; in essence, they are the same, both expressing to the outside world that they are working hard for long hours, so it must not be their fault. One exhausts themselves, while the other drags themselves along (after all, they have to wait for their leader to leave work before they can leave).

Or, everyone has discovered the silver bullet in the software development process, which is the 996 and 007 work culture.

I am Lu Canwei, a technician with 13 years of experience, who has been a technical leader in several companies and is also a full-stack developer. I am currently taking on some project development work, so if you are interested, feel free to discuss.