技术管理理论篇1——墨菲定理

国人的管理经验大都来自于自己的感悟和摸索，因此产生了一种莫大的高深感觉，曰只可意会不可言传；而在西方世界看来，管理是需要以理论为指导经常锻炼而进行修习而来的，用理论指导，辅助于各种常规手段，逐步提升自己的管理力，在西方的管理学看来并不神奇，到底孰对孰错，就让我来实践实践吧。

理论篇之墨菲定理

来自百度百科的介绍：墨菲定律由爱德华·墨菲（Edward A. Murphy）在1949年提出，亦称墨菲法则、墨菲定理。
原文为：如果有两种或两种以上的方式去做某件事情，而其中一种选择方式将导致灾难，则必定有人会做出这种选择。

简单的理解是：如果事情有变坏的可能，不管这种可能性有多小，它总会发生。

字面意思看起来，是一种悲观看法，如果有坏事情的可能，则这种可能出现的几率就非常大。总结下来有四个方面：

1. 任何事都没有表面看起来那么简单；
2. 所有的事都会比你预计的时间长；
3. 会出错的事总会出错；
4. 如果你担心某种情况发生，那么它就更有可能发生。

墨菲定理在项目管理中的表现

在一个敏捷开发的迭代内，如果有任何不同以往的新需求出现，则迭代加班或延期的可能性就会大大提升。因为产生问题的可能性非常符合墨菲定理。

1. 新的需求没有表面看起来那么简单；
2. 新的需求在实现时比你预期的时间长；
3. 新的需求总是总容易出错的；
4. 我非常担心新需求会影响进度，那么它就更有可能影响进度。

惨痛的教训还是蛮多的，在团队管理中心，一个不小心就会发生类似的问题。在询问队友原因时，总会归结为下列原因：

• 新需求提的不够详细；
• 新需求在拆分时没有拆的更细
• 新需求在拆分任务时，拆分的过细，导致参与人过多，责任不够清晰
• 新需求没有按照api进行计划
• 界面改动过多，想要重构下，突然发现UI的改动工作量太大了
• 管理太粗，导致发现问题的时候太晚；
• 做起来很简单，就是需求改动太多；
• 等等等等

墨菲定理重在预警

我个人的理解，墨菲定理恰恰提醒了我们风险所在。一旦你意识到项目管理中可能会有某些变动导致项目交付的波动时，那就需要记起墨菲定理。是的，其中必有隐情，元芳，你怎么看？

常言道：常在河边走，怎能不湿鞋！别想偷懒让它自然发展去，到最后必然是无法收拾的局面。管理管理，有管才能有理。

• 重视小概率的事件
  千里之堤，溃于蚁穴。一些小问题不一定都自己处理，我们可以交给队友处理，不过事后别忘了查看结果。在每个可能点上都做好了检查，那这些小概率的事情，才能消灭掉。当然在软件项目管理中，要善于利用工具，有许多自动化的工具，例如：Jenkins、GitLab、Shell等，或自研的运维、测试工具等，利用好这些工具，可以消灭许多经常犯的低级错误。

• 做好各种预案
  重要的事情，做好Plan B计划，甚至Plan C计划，这样在发生故障的时候，可以从容面对，迅速切换计划，避免更大的损失。

• 善于总结和变化
  失败并不可怕，如果我们能善于总结经验和教训，也许能很快摸索出一套符合自己当下团队技术能力的合适方案。时移世易，因时而变，不因循守旧才能更好的带领团队奔向成功！

总结

人生不如意事，十常八九。老祖先虽然没有提出墨菲定理，然而世界之道理基本是相通的。如果我们把完美当成一种非常艰难的形态，那我们看待自己遇到的的人或事的时候，可能会更从容淡定一些。遇到美的事情，我们可以举杯庆祝；遇到坏的事情，我们也可以淡定处之。 无怪乎，《史记》有云，顺,不妄喜；逆,不惶馁；安,不奢逸；危,不惊惧；胸有惊雷而面如平湖者,可拜上将军！