研发管理常用定律

angern · 发表于 2021-10-12 13:42

EDA365欢迎您登录！

您需要登录才可以下载或查看，没有帐号？注册

x

管理学上有很多您听说过或没有听说过的定律，这些定律虽然看上去很简单易懂，但看完之后联系实际不得不让人佩服第一个提出这些定律的大师们的睿智。有些定律对本人也是启发良多，引导着日常工作的方方面面。本文从研发管理学的角度出发，谈谈对一些定律的理解和思考：
一. 帕金森定律
定律描述：帕金森定律强调，一份工作所需要的资源与工作本身并没有太大的关系，一件事情被膨胀出来的重要性和复杂性，与完成这件事情的时间成正比。如果一件事情给你5天能够完成，那给你10天去做，你也会在第10天才能完成，这就像我们小时候放暑假要做暑假作业，很多小伙伴会在假期快结束时才开始突击一下，这样的话不管假期是两个月还是一个月结果实际上是一样的，所以帕金森定律又被称为学生定律。有时候时间太多反而使你懒散、缺乏原动力、效率低，可能还会大幅度降低效力。
理解思考：对帕金森定律定律而言，我觉得从两方面入手：
首先就是要让信息透明化，任何时间相关的问题都需要在每天暴露出来。这方面敏捷思想为我们提供了很多有效的思路和实践，如每日的站立会议、短周期的迭代、Story的细粒度分解、持续构建和集成等都能促进研发过程的可视化。
另一方面，在项目和研发的计划上，最好能做到先紧后松，尽量把缓冲保留在项目最后，确保过程在时间上的收敛性，这实际上和项目管理学中的关键链管理思路是类似的。
二. 康威定律
定律描述：康威定律说的是“设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构”，让四个人开发编译器，你就会得到四个（4-pass）编译器，也就是说产品必然是其组织沟通结构的缩影。
理解思考：康威定律无非在告诉我们研发人员间的高效面对面的沟通对于好的产品和设计是至关重要的，实际开发过程中需要确保高效的团队沟通模式：
确保信息透明。这点同样可以参考敏捷领域的一些做法，只有信息透明才能确保团队成员处在同一认知水平上，才能有效沟通。
建立有效的沟通管理机制。关于沟通管理可参考我的博客《沟通管理--关于信息的有效传递和维护》，这里不再展开。
进行团队建设。在我的另一篇博客《如何成为一名研发主管--关于个人、过程、工具和团队》也提到过康威定律，之所以在讲研发主管培训的时候会提到这个定律，是因为研发主管作为基层的管理人员，他们的做事风格和模式很大程度上影响着团队的沟通效果，所以确保研发主管们都能充分理解这个定律也是很有必要的。
三. 布鲁克斯定律
定律描述：相信很多从事研发管理工作的同行都读过图灵奖得主布鲁克斯（Brooks）的那本经典著作《人月神话》，这本书里就提到了这条定律：往进度落后的项目中投入更多的人手往往使进度更加落后。原因在于新人进来后的所必需经历的学习曲线。
理解思考：关于布鲁克斯定律，个人认为是真理，但我们可以通过以下几个方面对其进行弱化：
进行过程资产建设。过程资产建设可以是团队级别的也可以是组织级别的，涉及知识管理平台、共享库等多个方面的内容。尤其对于研发过程而言，隐形知识价值巨大，如果能把这些隐形知识显性化，对降低新人的学习曲线是有很大促进作用的。
阶段性研发。如果能把一个大的研发过程拆分成小的阶段，然后每个阶段过程有明确的输入输出，则一个阶段过程的结束和开始就是新人加入团队的最好时机，因为他们面对的通常是一个新的开始，大家可以都处在相对统一的工作平台上。
四. 手表定律
定律描述：手表定理是指一个人有一只表时，可以很明确知道现在是几点钟，当他同时拥有两只表时，如果这两只表的时间不一样的话，他就不知道现在到底是几点了。关于手表定理的表现形式，在实际研发过程中并不少见，如你的领导可能会直接跳过你去找你下面的一个开发人员做这个，但在你眼里可能这一安排不一定合适，然后你就会跟他讲做那个，这样这个开发人员就不知道到底是要做哪个了。
理解思考：手表定律的背后是团队组织结构管理，解决问题的思路也是梳理人员的管理方式和沟通结构。对于几十个人的团队而言，确立梯队式管理的机制是必要的，普通的研发人员将通过他的研发主管进行工作的安排和协调，而研发主管再作为对外接口处理来自项目、运营团队等的请求，这样就避免了项目经理直接找某某研发人员处理某件事情的情况，提高研发人员自身的开发任务管理能力。
五. 木桶定律
定律描述：木桶定律是讲一只水桶能装多少水，这完全取决于它最短的那块木板。这就是说任何一个组织，可能面临的一个共同问题，即构成组织的各个部分往往是优劣不齐的，而劣势部分往往决定整个组织的水平。这在软件行业也是同样，一个产品是否能被用户所广泛接受，往往可能就是因为缺乏经验的UED在不经意间在把界面上的一个按钮放在不合适的位置而已。
理解思考：对很多国内的软件公司、尤其是小公司普遍存在的一个现象就是重技术而轻管理，认为只要技术人员水平高、代码写得好，做出来的东西就一定好，这个认识是个误区。一个产品是否成功取决于很多因素，除了技术还有产品、项目、运营、市场等，这些环节的有效协作才能真正做到所谓的“面向用户、以提高用户体验为宗旨”等产品化策略。个人认为可以参考IPD中所提到的建立跨职能工作小组，建立端到端的全流程意识等方式进行改进。
六. 墨菲定律
定律描述：墨菲定律指的是事情往往会向你所想到的不好的方向发展，只要有这个可能性。这条定律与上面讲到的”帕金森定律”以及激励理论方面的”彼得原理”合称为二十世纪管理学三大定律，在技术界也很有名，因为它道出了一个铁的事实：技术风险能够由可能性变为突发性的事实。
理解思考：关于墨菲定律，个人在研发管理过程中有几点体会：
不能忽视小概率/偶发事件。在研发过程中有时候会出现一些所谓的诡异问题，即指那些有时候会发生、有时候又很正常，但一旦发生往往造成系统级错误的问题。对这些问题我们必须重视，如果一时半伙搞不定，一定要通过Tickct系统或研发日志等方式把它记下来，然后不断的去尝试和发掘。实际上软件研发或者说写代码这件事情是很死的，问题会发生就一定有它的原因，本身就不存在什么诡异性之说，只是我们暂时不知道而已。
从错误中汲取经验教训。如果我们不幸被“墨菲击中“了，那这次也没办法，但我们不希望还有下一次，也就是说我们要进行经验总结。5个why、鱼骨图等根本原因分析工具，回顾会议等工作流程都是需要引入到日程研发过程中并定期/不定期的进行分析和总结。