将软件项目中长期加班看做风险

比眉伴天荒 2022-04-15 00:07 234阅读 0赞

看到一篇博文，一位项目经理谈到软件bug和长时间工作的关系，他认为推迟下班不仅浪费时间，还可能完全适得其反.在他的项目管理中将长时间工作当作风险来控制。

他认为应当设定工作时间限制，更长的工作时间会产生更多严重的BUG，程序员在疲惫，压力大的情况下非常容易引入错误。

通常情况下团队是被一些不起眼的小问题拖下水，在不知不觉中工作量就增加了。这时人们就会花费更多的时间来处理这些额外的工作，但不幸的是会有更多的错误发生，不断重复和循环。

提出的防范措施是在指定计划时设置一些缓冲区，是小问题不会增加整个项目进度。同时把超长时间工作看做风险处理，仔细辨别工作之间的关联性，使项目应当舒畅有序的进行。

从这篇文章中可得到两点经验：

1）加班不是良药反而有可能是毒药。在项目管理中应当把它看做是一种风险而不是荣耀。

2）千里之堤毁于蚁穴。不要忽略小问题，项目管理中明确定义好范围，不要觉得事情小就模棱两可。最后积少成多造成项目失控。

原文内容如下：

A Project Manager's View of Long Hours

The comments thread on my recent work-life balance post and Nicoleandmaggie's recent post about productivity have me thinking about the extent to which my experience as a project manager informs my opinions about work hours and work-life balance. The answer is: a lot.  
  
As a project manager, I view long hours by my team (and, by extension, by myself) as both a risk and a failure.  
  
Long hours are a risk because of the issues I discuss in my work limit post. To put it simply, longer hours correlate strongly with more mistakes. I primarily manage software and other technology projects, and I would argue that mistakes (in the form of bugs) can be the biggest risk to those projects. They are certainly one of the hardest risks to manage. There is no point in the project at which we can consider ourselves past the risk caused by bugs, and there is almost no limit to the schedule and budget damage they can do. At any point, we might uncover a new bug. Most bugs are easily tracked down and resolved. But some are hard to find, and I have seen projects put months behind schedule by particularly nasty ones.  
  
I firmly believe that an exhausted, over-stressed programmer is much more likely to make a mistake that introduces a bug than a well-rested, happy one. I know, I know. You're different. You can work long hours and stay productive! I have worked with many, many people in my 10+ years as a project manager. A lot of them thought they were the exception to the work limit rule. None were. I have never worked with anyone whose work quality didn't drop off as the hours crept up over extended periods of time.  
  
The only exception I've seen to the work limit rule is a partial one: if you have two sets of tasks that are significantly different from each other, sometimes one can serve as a "refresher" for the other. This probably works best if one of the two sets of tasks is fairly mindless, but I've seen it work for two sets of "intense" tasks, too, if they are sufficiently different. So, if you have to both write code and produce status reports, time spent filling in the status reports may help refresh you to write more code. I don't think it refreshes you anywhere near as much as going to a movie or going home and playing with your kids would, though.  
  
I've actually been thinking about this "two types of tasks" effect quite a bit, in relationship to writing and my job. Writing uses a very different set of skills than my day job, and I do, in fact, find that it "refreshes" me for my work. However, writing is seen as work by a lot of people, and rightfully so. So when I put in a 40-45 hour work week and another 5-10 hours writing, am I really working a 45-55 hour week? I don't think so, because for me, writing is a hobby. It is not what I depend on to feed my family or pay our bills. I might set deadlines and goals for myself (and I do!) but there is no real pressure on me. If a blog post sucks and no one likes it, no big deal. If I decide I'd rather catch up on the episodes of Sherlock we have recorded than write a new post, so what? Still, this potential issue is one of the things I'm cognizant of as I think about doing more and more formal types of writing. I can't let it start contributing to my work limit, because I use all of that on my day job. So I'm proceeding carefully.  
  
Anyway, because I believe strongly that all people have work limits, that working past these limits leads to an increase in errors, and that those errors have the potential to delay or otherwise hurt my project, I think of long hours as a risk to be avoided. Incidentally, I'm not the only one who thinks this. And, while I've written primarily about software projects, I think other types of work have the same issues. In fact, the most spectacular demonstration of this effect I've ever seen was on a science project at a biotech company. A project needed a certain amount of purified protein by a given date, in order to supply crucial assays. Protein production was laborious and time-consuming, for both the usual reasons and more specialized reasons that I cannot discuss. A prep came ready for purification late in the day, and a lab tech was pressured by his boss to stay late and start the purification going. This lab tech was chronically overworked, partly because he had a bit of a hero complex, but mostly because his boss was a jerk and/or was clueless about how to actually manage. He was well past his work limit, and had been for weeks, possibly months. But he stayed late, and started the prep. When the rest of the team came in the next morning, they discovered that he'd put the prep on the wrong column, and essentially destroyed it. Meanwhile, the team that made the source material had to move on to another project or risk missing a contractual deadline worth hundreds of thousands of dollars, and therefore couldn't produce more protein for this project right away. When all was said and done, the first project took an approximately three month delay because of this one mistake.  
  
Now, that is an extreme example. But I actually think the more usual case is worse. Usually, small errors just get absorbed by the team, silently adding to the workload, and putting everyone under more stress. They might start working longer hours to deal with the extra work, and then more mistakes happen, and the cycle repeats. Before you know it, the project is three weeks behind schedule and you have no idea why. Ask yourself: is this sort of delay a risk you need to take?  
  
One of the key parts of a project manager's job is the management of risk. We think about likely issues and try to put controls in place to eliminate them or at least mitigate the damage they can do. I think long hours are a risk, and luckily, there is a fairly straightforward mitigation: proper planning. When I am planning out a project (or set of projects using the same resources), I do so with the assumption that everyone is working their usual 40 hour work week- or less for the part time contractors. I plan in buffer ("slop", or to use the fancy term "risk reserve") so that little issues do not immediately send us into long hours mode. I carefully identify dependent tasks, so that unforeseen dependencies do not bounce us into long hours mode. I try to think of other potential risks and manage those. In short, I do everything I can to make sure that my team has the time and money it needs to complete the work without resorting to insane hours. While the project is running, I keep an eye on all of these things, and I actively manage communications both within my team and with other stakeholders, all with a goal of keeping us on schedule, under budget, and out of long hours mode.  
  
Of course, I can't control for the work habits of my team members. For instance, a chronic procrastinator will often bump him or herself into long hours mode. But, as a project manager, I can recognize this work trait and try to set up intermediate deadlines so that this behavior doesn't spill over onto the rest of the team.  
  
So when something happens, and my team ends up working long hours for more than the crunch in the last couple of weeks before release? I consider that a failure. I missed something or misplanned something, because otherwise, the extra hours would not be needed. I try to figure out what went wrong and learn from it, so that I can do a better job on future projects.  
  
All of this means that I do not view people who routinely work long hours as heroes, or a standard by which we should all measure ourselves.If they are doing it to themselves, I think they are risks to their projects and I try to keep them off projects I run. If they are working the hours because they "have" to, I think they have crappy managers. Why would anyone aspire to either condition?