In Hangzhou in 2010, when spring is like four seasons, Brother Liu, the project manager, and Sister Yang, the company's human resources manager, sat down to drink tea by the West Lake again. Brother Liu was appointed as the project manager half a year ago, and took over the management of the company's strategic product V3.0 halfway through.
"These guys have fooled me again!" Brother Liu seemed to have some trouble at work.
"That's it," he continued, "the March release plan explicitly calls for the release of the core component of the Report Center, which engineers and customers have been looking forward to! I broke my promise and didn't submit it on time! Now, the testing tasks have to be re-adjusted, and the personnel training plan and version release plan have also been affected, the boys should have brought it up earlier, so that I have time to find a way to remedy the failure of their work!"
"Yes Didn't they encounter some technical difficulties, or some recent unexpected tasks affected their work? You also know that there must be a reason for this to happen, and some situations must be excusable!" Sister Yang said, "As far as I know, the work performance and personnel quality of your project team members are the best in all projects in the company!" Sister Yang knows that although Brother Liu has a hot temper, he has always been concerned with matters, not the kind of A person who will report and look for opportunities to find trouble.
"Fuck!" Brother Liu said with a smile, "In order to ensure the smooth development of this task, I arranged for special personnel, gave them enough time, and even added another 20% to their estimated development time. Flexibility time! During this period, there was no downsizing in the project team, and any insurmountable obstacles encountered are pure nonsense! I also once doubted whether they encountered technical difficulties, and they did not propose to me that they needed technical research departments at first. I cooperated, and I didn't ask for technical support in the process of promotion! When I ask them now, I only say that I don't understand the technical problem, and I don't understand it, and they also say that the technical problem will always be solved." As the
saying goes, "No Have you ever eaten pork but never seen a pig run?" As a human resources manager of a software company, Sister Yang often communicates with software engineers in the company, and she still has a certain understanding of software development. In her opinion: the software industry The difference is that it is impossible for software developers to completely stick to their promises, and most software projects in companies and even in the industry are lagging behind.
"Sister Yang, I admit that this perception is common in the industry, including many of our customers who acquiesce that our schedule is delayed, and companies like Microsoft also have accidents that change their release plans again and again! But this perception It's wrong in general, and dangerous. Because it will help those who don't pay attention to commitment to make excuses, and it will fundamentally stimulate a lot of unprofessional behavior, such as lack of rigor in developing development plans, ignoring task risk analysis, etc.
" Well, let me ask you, what excuses do people generally have for not being able to complete tasks on time? What do you think of these excuses, and how should you deal with them?" Sister Yang also wants to know that developers are always unable to complete their commitments on time. What insight does Brother Liu have on this phenomenon?
Brother Liu was lost in thought, thinking about how to answer Sister Yang's question.
"To answer this question, I think I should explain several misunderstandings that software developers have in their understanding of the behavior of committing." Brother Liu began to answer Sister Yang's question.
"The first thing a software developer doesn't say is that my promise isn't FedEx's 'mission to do it', I'm just 'do my best'. One manifestation is that everyone likes to set a series of preconditions, It is convenient to use as a talisman when the promise cannot be fulfilled later.” Sister Yang has a deep understanding of this point, because she has participated in several project summary meetings in the company in the past, and those who failed to complete the task usually have to spit out how they did it. He has tried his best, he thinks that he should be exempted if he tried his best, and he should be forgiven even if he fails to complete the task. Brother Liu continued, "I think commitment has two aspects, first, I am willing, and second, I can. There is no commitment without will, but without ability, commitment is still false. So when developers make commitments to me I think they not only have the will but also the ability to complete the task, they should complete the task without exception, otherwise they should not make a commitment."
Sister Yang nodded, "You mentioned it last time when I had tea with me. In your opinion, the development of a software project is composed of a series of tasks. To undertake a task is to make a commitment. In your team, a commitment is regarded as a contract. Once a commitment is made, it must be unswervingly executed without any reason. Because If the promise is not fulfilled, the credit will be lost, and if the accumulation reaches a certain level, the customer will also be lost!”
"There will be a second unspecified thing for software developers. I promise to come up with this thing at that time, but I don't guarantee that this thing will be easy to use. For example, last month, Brother Xiaowu promised to use it within a week. After writing the custom tool for the ticket format, the tool was submitted by the deadline. However, there are many bugs in the code, and it will take another week to fix these bugs. Then we found that the existing design needs to add a controlled development tool to the auxiliary development tool. It increases the workload of developers, and it is extremely inconvenient for implementers. It takes several weeks to correct these design defects. All the later work based on this tool has to stop and wait.”
Brother Liu stopped. , took a sip of tea, and continued, "The root of this problem is that I and he did not agree on what needs to be delivered when due. He thinks it is just a piece of code, and what I hope to get is a well-designed, developed and debugged. Releasable tool. If I argue with him about how many defects are acceptable, then I'm in trouble, because you know the definition of defects and the number of defects are related to the use case of the engineer, the expertise of the tester, etc. I think To avoid this from happening, it is necessary to clearly put forward detailed requirements specifications involving specific quality indicators in the process of reaching a consensus."
"Next, I will talk about how ordinary software developers fool project managers! In my opinion, in this industry, , there are three of the most common excuses!"
"The first, 'I was interrupted by many unplanned things.' For example, an urgent need from a client, a sudden task arranged by the leader. Who is this? The problem? It is nothing more than a natural and man-made disaster. If it is a natural disaster, such as building a house and encountering rain, this situation requires the person who made the promise not to make a promise based on the situation that everything went well. Reflected in project management, it is to reserve a certain margin when making a task development plan. If it is a man-made disaster, then it is obvious that he did not pay attention to his commitment to me, because he gave priority to other things, then I am sorry, the commitment was not made by me , but he made it, in the absence of prior communication, he was making an assertion."
"Second, 'This job is harder than I thought.' Who's problem is that? Note that it's not me, he's the one who estimates the difficulty of the task. Don't do it if he's not sure if it can be done. Commitment, if you don't fully understand the difficulty of the task and make an estimate, you shouldn't make a commitment. Frankly speaking, the above problems are all unprofessional performance!"
"Wait, there is a problem!" Sister Yang interrupted, " I remember that the project team would discuss and formulate the development plan to clarify the overall plan and detailed arrangement of tasks, and check and adjust regularly. Why do these accidents you mentioned happen?"
"You asked a good question! Haha, practice makes perfect. Come on!" Brother Liu gave Sister Yang a thumbs up, "Many project managers take a similar approach, and the classic project management theory suggests us! However, a real problem is trying to get every detail of the plan to work. It is difficult to know everything clearly. What is certain is that it is difficult for project managers to organize all dependencies. Project managers who have compiled similar charts have realized that there will always be things that you fail to list during the project execution process. The new tasks that have been planned are inserted into it. Therefore, these complex diagram networks like spider webs may not be a problem to complete the compilation, but it is extremely painful and difficult to keep them updated and coordinated with the actual situation of the project. Later, it is likely to become a decoration for framing the project team and coping with CMMI, ISO and other inspections!"
"We know that in project management theory, there are many tools and techniques for making schedule plans, such as critical path method CPM, plan review technology. PERT, PDM, etc. These methods and techniques can help us identify critical tasks or high-priority activities in the task queue, so that we can understand how the progress will be affected if there is a problem with one of the links. Therefore, we usually focus on the critical path, but not on the delay behavior on the critical path, which is often ignored or not detected in time. Personally, this latter behavior is precisely the reason why many projects encounter trouble, because every project team has The priority of a task and activity will change, for example, depending on how long the task is delayed, the troubles encountered by the project team are usually caused by the accumulation of delays in many links over time, and quantitative changes lead to qualitative changes!”
"The last reason that is often used is, 'So-and-so did not complete his task on time, which affected my work', where so-and-so may be a member of the project team or a third-party subcontractor involved in the project For example, a client we implemented some time ago, in the development of the PACS interface, due to the communication problem between the company, the hospital and the manufacturer, our interface developer waited for a week. This situation does exist, but it can be avoided. , the task-bearer should communicate with the relevant units and personnel about the time arrangement before submitting the plan, and guarantee it in the form of a fax or similar contract. Therefore, when this happens, I think the person who reported the plan and made the commitment should take responsibility for it. It 's your responsibility!"
"Brother Liu! If you do this, I'm worried that everyone's estimates of the task will become quite conservative, and make sure that his commitment to you is guaranteed by drought and flood. But this will make you tidy up the entire schedule. It is found that the time required to complete the project will be N times as expected, and you may not be able to explain it to the boss!"
"Yes, this is indeed a problem! There are several possible solutions that I can think of!"
"First , to measure the rationality of the planned use of resources! For extremely conservative estimates, it must be like squeezing water in a sponge. I think it is more feasible to use expert estimates or industry data as a reference. When jointly determining this data, We want to give developers a difficulty of picking bananas from monkeys, which means that developers need to work a little harder according to this plan, such as working overtime. There is an extended problem here. Many developers say that their tasks have been completed 80% of the time. %, when I hear this, I think the project managers are skeptical, because it is difficult to give supporting evidence for how 80% came out. In many cases, it is his personal subjective estimation, or purely for Cheat QA or meet the project manager's expectations."
"Second, many developers estimate progress based on their most optimistic estimates of completing the task, which is not a schedule, I think it is wishful thinking, such a project is doomed before it starts. Failed. When the overall time is limited, it is more appropriate to cancel some excessive project tasks early, the so-called project scope control, to ensure that limited resources are prioritized for critical tasks.”
"Finally, I don't think the reason most software development projects are delayed is not because of the delay in the R&D phase, after all, the real investment in this work can only occupy a small part of the whole process, and these work basically within our company. It's mechanical. More of the reason for delays in development projects is that the plan is not well implemented, and R&D becomes the scapegoat. Because everyone seems to be more comfortable with the idea that things are screwed up in the R&D stage, in fact, the developers Often complained that due to product engineer's work delay or poor analysis products delaying development, but also to ensure back-end testing time, many tasks are delivered in a hurry, and development quality cannot be guaranteed. Therefore, it is necessary to strengthen planning in links other than R&D Control, which requires me to be ready to communicate with my boss and other department managers as soon as possible."
Postscript:
Most software development projects have relatively aggressive plans and schedules. There are very few projects that don't try something new, be it a new technology or a new management idea. Management always completes the project in the shortest possible time, but the risk element of the project is everywhere. Many developers have experience in participating in failed projects. Some people find that the project has fallen behind schedule as soon as they join the project, and have to work overtime to speed up the progress painfully. Therefore, as soon as many new projects are proposed, the team begins to wonder: what trouble will we encounter this time?
It is very important to overcome this "dreaded" emotion, so members in this state are less productive. Holding some team building activities, such as dinner parties, karaoke is not the answer. A more feasible way is to integrate the opinions of various team members, formulate a reasonable plan, and discuss with them in the various sub-teams. In many discussions about successful meetings, we have stated that it is basically useless to pull the entire team into the conference room and explain the plan to them with PPT, because the details and practices that affect the plan are generally the details and practices. It is more effective for people to discuss in a small area together, because in this environment, everyone's enthusiasm for speaking will be higher, and the time is more relaxed, which is conducive to fully discussing all issues. At the end of each small team meeting, the project manager needs to confirm whether each participant has clearly defined the tasks they need to undertake. It is not enough for the team leader to understand, because the work is completed by everyone. If someone thinks your plan is flawed, ask him to elaborate on his ideas. If you still can't come to an agreement, you'll want to consider making a decision whether you should let him continue with the program with everyone. Because, "undertaking a task" really means a commitment to each other.
One thing that still needs to be reminded of project managers: do not try to force others to make commitments that you want but are unrealistic in their eyes. Others may succumb to your pressure to make a commitment, but if it is not fulfilled in the end, it will be you, the entire team, and even the entire company that will suffer. The commitment of the task is more reasonable in the case of mutual compromise between the manager and the developer.
Finally, it is important to emphasize that paying attention to commitment is the basis for building a trusting relationship between teams! We always want to work in a high-trust environment that makes us subconsciously trusted teammates