An easy mistake for a Technical Project Manager

An easy mistake for a Technical Project Manager

A technical project manager can easily make the following mistake: when assigning tasks to members for self-thinking simple problems, technical details are introduced and the simplicity of the problems is revealed.

For example, the project manager x needs to change a string on the page when receiving a new requirement from the customer. So I immediately called member A. "This requirement only needs to be changed to the corresponding page string. It takes 5 minutes to complete. Please change it ". Regardless of whether the problem is really simple, the first problem is that X obfuscated the line between the project manager and the developer. The specific implementation details are the work of developers, and the Project Manager does not need to care about it. Even if developers do not know how to implement it, it is also the work of the Technical Manager. In addition, "5 minutes to get done" is often a harm to developers. The most common result is that after member A goes down, the problem is not that simple. It is not only necessary to modify the strings in the page file, but also involves modifying a field in the database. What is more troublesome, after the modification, the unit test is red. It took the last day to solve the problem within five minutes.

Project managers generally do not participate in the specific coding work. The conclusion that "a problem is very simple" in the current project can be obtained based on previous development experience may not be repeated. Therefore, it is best for the project manager not to mention the technical details, and the assignment task is OK. For example, "At present, a new requirement is received, and the customer requests to change a string on a page. You can analyze and solve the problem. The problem is urgent. I believe you can finish it as soon as possible. "First, describe the requirements clearly, and then describe the urgency. The rest can be safely and boldly handed over to the developers.

A good project manager must always be clear about his/her responsibilities. If, for various reasons, the project manager is also a technical manager and has to participate in the specific coding implementation, you must always be clear about your role change. After assigning the task, you can refer to the technical details of the pipeline: "This problem is urgent. Based on my past experience, you need to modify a corresponding page. You can modify it to see if it can be done as soon as possible. "This example is too simple. The following are basically nonsense. When talking about technical details, the project manager, who is also a technical manager, is not a good choice unless others are not familiar with the details.

Some project managers may argue that it is easier to describe the problem, so that employees do not need to sharpen their work. If an employee does not work for a long time, the 5-minute task can be completed by one day, it is likely that the entire team has encountered a problem. What needs to be improved is the code review, rewards and punishments, and other systems. Too many topics are involved in team building.

End with an old saying: when a project manager does something, there is nothing.