|
“事不过二”原则的另一层含义，是“同样的错误不能犯第二次”。每次故障之后，Casestudy都必须进行深刻的总结复盘，对故障原因进行5Why分析，给出明确可执行的To Do List。每次季度总结会，大家自我反省问题所在，在下个季度必须有所改善，不能再犯类似的错误。孔子云：“不迁怒，不贰过”，在错误中反思与成长，才能让我们成为更优秀的人。 原则七：设计优先“设计优先”这条原则，相对来说更加具体一些。之所以单列一项，是因为架构设计太重要了。 Uncle Bob曾说过： “软件架构的目标，是为了让构建与维护系统的所需人力资源最小化。” 架构设计，并不仅仅关系到系统的质量，还关乎团队的效能问题。很多团队也有明文规定，开发周期在3pd以上的项目必须有设计文档，开发周期在5pd以上的项目必须有设计评审。在具体的执行过程中，由于各种原因，设计往往并不能达到预期的效果。 究其原因，有的是因为项目周期紧，来不及设计的足够详细。有的是因为RD主观上认为项目比较简单，设计草草了事。 无数事实证明，忽略了前期设计，往往会导致后续开发周期被大幅拉长，给项目带来了很大的Delay风险。而且最可怕的是，不当的设计会给项目带来巨大的后期维护成本，我们不得不腾出时间，专门进行项目的优化与重构。 因此，无论什么时候都要记住“设计优先”这一原则。磨刀不误砍柴工，前期良好的设计，会给项目开发以及后期维护带来极大的收益。 “设计优先”这一原则，要求写别人看得懂的设计，我们了解一个系统最直接的途径就是结合设计文档与代码。在实际工作中，很多同学的设计文档让大家看得一头雾水，通篇下来，看不出系统整体的设计思路。 其实，设计的过程是一种智力上的创造，我们更希望它能成为个人与集体智慧的结晶。 如何才能让我们的设计变得通俗易懂？ 我个人认为，设计应该尽量使用比较合理的逻辑，进而把设计中的一些点组织起来。比如：可以使用从抽象到具体，由总到分的结构来组织材料。在设计过程中，要以需求为出发点，通过合理的抽象把问题简化，讲清楚各个模块之间的关系，再详细分述模块的实现细节。 做完设计之后，可以发给比较资深的RD或者PM审阅一下，根据他们的反馈再进行完善。好的设计，一定是逻辑清晰易懂、细节落地可执行的。 原则八：P/PC平衡“P/PC平衡”原则，即产出与产能平衡原则。伊索寓言中讲述了一个《生金蛋的鹅》的故事，产出好比“金蛋”，产能好比“会下金蛋的鹅”。“重蛋轻鹅”的人，最终可能连产蛋的资产都保不住；“重鹅轻蛋”的人，最终可能会被饿死。产出与产能必须平衡，才能达到真正的高效能。 为了让大家更清晰的了解这一原则，本文举两个例子： 从系统的角度看，每一个系统都是通过持续不断地叠加功能，来实现其产出，而系统的产能是通过系统架构的可扩展性、稳定性等一系列特性来表征。为了达到产出与产能的平衡，需要在不断支持业务需求的过程中，持续进行技术架构层面的优化。 如果一味地做业务需求，经过一定的时间，系统会越来越慢，最终影响业务的稳定性。反之，一个没有任何业务产出的系统，最终会消亡。 再从RD的角度来看这个问题，RD通过做需求来给公司创造价值，实现自己的产出。而RD的产能是指技术能力、软素质、身体健康状况，有这些资本后，我们才能进行持续的产出。在日常工作中，我发现很多RD往往只重视产出。他们也在很努力地做项目，但是每一个项目所使用的方法，还是沿用自己先前一贯的思路。最终，不仅项目做得一般，还会抱怨自己得不到任何成长。 这就是P/PC不平衡的体现，如果能在做项目的过程中，通过学习总结持续提升自己的技术能力和软素质，并将其应用于项目实施交付中，相信一定会取得双赢的结果。 “P/PC平衡”原则还适用于很多其他的领域，例如：团队、家庭等，我本人也非常推崇这一原则。希望大家也能将其作为自身的一项基本原则，努力寻找到产出与产能的平衡点。 原则九：善于提问“善于提问”，首先要勤于提问。求知欲源于好奇心，是人类的一种本能。在工作中要养成勤于提问的好习惯，不懂就问，不要因为自己一时懒惰或者碍于情面，就放弃提问的机会。当遇到不同的观点时，也要礼貌地问出来。波克定理告诉我们，只有在争辩中，才可能诞生最好的主意和最好的决定。 （责任编辑：晨鸿） |
