浅谈软件开发定律系列之帕金森定律（Parkinson’s Law）

原文地址 http://eilfei2000.blog.51cto.com/2956473/718353

 

 

浅谈软件开发定律系列之帕金森定律（Parkinson’s Law）

2011-11-18 18:12:11

标签： 拖延  项目时间  项目管理  冗余

原创作品，允许转载，转载时请务必以超链接形式标明文章  原始出处 、作者信息和本声明。否则将追究法律责任。 http://eilfei2000.blog.51cto.com/2956473/718353

    帕金森定律（Parkinson’s Law）–“工作总是用完所有可利用的时间（Work expands to fill the time available）”，这意味着容易达到的目标将使员工工作上变得松懈
–如果你给自己安排了充裕的时间从事一项工作，你会放慢你的节奏以便用掉所有分配的时间。

反思：
–1如何规避帕金森定律？
–2如果整个项目有20%的缓冲时间，你会如何分配这20%的缓冲？

 定律解析

    这个道理很类似大学时代，总是拖到最后几天去学习，然后匆忙应试的道理——这个道理害苦了很多大学生，让他们有一种错觉，养成凡事随意放弃的坏习惯。

    临考试前的突击，然后老师随意的放大家通过考试，让很多大学生盲目自信，认为学习也不过如此，自己的自学能力非常牛，三天的突击就能考到70分，如果随便学学，花上两个星期的时间，想必拿奖学金不成问题。然后就盲目自信，对任何事情都盲目乐观和冲动，同时，遇到问题又随意放弃。

    话题转回来，在工作中也是这样。如果本来能一天做完的事情，如果你安排两天，那么肯定拖到两天才能做完。如果时间太过宽松，也不会提前完成——提前完成会安排其他的任务。
   （跑下题：所以研发体系的基层、中层才必须要懂技术，否则落实任务都会出问题）

 

    一个类似的，关于预留提前量的例子：
    学校开大会，校长要求上午8点全校师生集合，然后系主任为了保障8点能搞定，就下达通知，要求7：30各班集合。班主任为了保障7:30能集合完毕，就给班长说7点在操场集合……最后，班长给全班通知：早上6:30在操场集合。

关于项目时间的把握，有两种经典图形：

 

客户：10天
↑↓
老板：8天
↑↓
经理：6天
↑↓
主管：4天
↑↓
员工：3天

 

    一种和学校召集大会类似，客户要求10天完成，老板为了给自己留缓冲时间，就给经理说8天，经理为了给自己留缓冲时间就给主管说4天搞定，主管也留了自己的缓冲时间，就给员工说3天搞定——然后，员工就花了3天时间，搞了一个错误百出的东西，大家逐层邀功，最后客户本来能拿到一个8天周期完成的，质量较好的东西，结果实际拿到的是3天周期的，质量较差的东西。

    同样的图形，还有可能是反例：
    一件事情，员工说自己能3天搞定，进行汇报，然后主管怕事情搞不定，留了富余量，上报给经理说4天能搞定；经理继续留缓冲，上报老板说8天；老板给客户说10天——然后，员工就花了3天时间，大家逐层邀功，最后客户还是花10天，得到了一个3天质量的东西。

 

问题解答

–1如何规避帕金森定律？
–2如果整个项目有20%的缓冲时间，你会如何分配这20%的缓冲？

 

    如果一个运作了几年的团队，一直使用这种提前量方式，对团队的效率影响是致命的。你的项目经理给你落实任务，说的言之决绝，但是你心里有数，项目经理给的项目计划肯定有很多水分，他说的deadline不是真的。你按部就班的做事情，最后搞不定，项目经理会触发项目延期。

    这种节奏下，大家对承诺，项目计划，项目进度看的都很随意，执行力非常低。而且员工越来越油滑，有百害而无一利。 

    那么，如何才能真正的协商项目时间呢？

     只在一个点设置冗余时间！

    比如只在老板哪里，客户要求10天，最后就下达为8天，同时团队明确这实际就是deadline，无延期的可能性。或者就在经理环节……只在唯一的环节统一冗余即可。
但是这种模式，对项目时间，成员对时间的重视度要达成一致。整体来说，这种团队本身的成熟度要足够高。上下一心，才能做事情。

 

    如果，项目最后有20%的富余时间，应该放在那里？----时间怎么用，仁者见仁智者见智。在《番茄工作法》一书中，作者将工作时长切分为最小的时间元为25分钟。也遇到类似的例子，如果一件事情专心投入，结果25分钟之内完成了，剩余的时间怎么办？答案是：过度学习!再回顾一下所做的或重复一下所学的，看看刚才的工作是否可以改进，或总结新的结论。

    个人工作管理和团队工作管理有相似之处，所以如果真的项目剩余了20%的富余时间，个人意见是，宁愿项目做完后，大家写总结，文档归档，或者版本发布后，做最后的回归测试，同时重构代码，剩余时间不要放在项目过程中使用。拖延对大家没有任何好处。

本文出自 “柳记” 博客，请务必保留此出处http://eilfei2000.blog.51cto.com/2956473/718353