01 | 效能模型：如何系统地理解研发效能？
该思维导图由 AI 生成，仅供参考
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了研发效能在软件开发领域的重要性，并提出了提高研发效能的关键因素。文章首先从讨论996工作制引申出对研发效能的探讨，强调了长期加班对效率和质量的负面影响。随后，以硅谷知名公司为例，阐述了高效能对业务成功的重要性，并探讨了软件开发领域的创新和工具的不断更新对研发效能的影响。作者还提出了研发效能的模型，从优化流程、团队工程实践、个人工程实践以及文化与管理等四个方面来提高研发效能。通过对软件开发的本质特点进行探讨，建立了一个研发效能的模型，为读者提供了深入了解团队研发效能的全面视角。整体而言，本文通过深入探讨软件开发的本质特点和研发效能模型，为读者提供了提高团队研发效能的重要思路和方法。
《研发效率破局之道》，新⼈⾸单¥59
全部留言(41)
- 最新
- 精选
Jxin
1.个人无所谓加班，入门晚，学习和勤勉已经养成习惯。但无脑的做业务需求的加班我是拒绝的，因为业务需求干大半年后，再无脑做成长太有限。而重构核心业务逻辑，重构项目分层，梳理业务图谱，写自动化脚本。为这些将来能节省时间的方面去加班去投资时间，我是很乐意的。 2.遗憾的是，你前面加班，把时间投在提高效能上，而后面自己效率上去没加班，引起了领导反感；或则帮团队成员都提高了效能，但也拉高了标准，导致大家单位时间要干的事更多了，最后还是只能加班苟延残喘。 3.遗憾的是，公司兴奋加班熬夜才是尽职尽责。 4.只有我加班投在效能上的时间，后期节省的时间我能自由支配，那么去投资才会有较强的意愿，项目研发才能越来越高效。作者回复: https://github.com/svenstaro/genact 了解一下？😎
2019-08-23318
小树苗关于研发效能模型，听了还是很有感触的。 首先关于MVP，就有一个很大的困扰，MVP很依赖产品经理对产品的定义，产品经理往往害怕一些细小功能点的有无会伤害产品和业务，总想第一个版本上去就是完美的，结果就导致新产品第一个版本就是个大家伙，交付周期就会很长，夜长梦多，接着就是需求变更，其他高优先级需求插入，结果就是交付周期极其的长，大家又要加班，恶性循环。而产品经理定义需求能否按照MVP的原则来，也依赖于组织文化。 另一方面，在建设效能工具的时候，流程方面往往是好搞的，因为很多工具流程可以借鉴，这是属于冰山外露的那一部分，但是团队工程实践，个人工程实践却需要花大力气去搞，比如构建时间的缩短，就需要精雕细琢去研究如何做到足够短。往往我们有了漂亮了流程，但是流程各个环节却耗时很长，而是否舍得花成本去解决这些隐藏在流程背后的问题，又依赖于组织文化。作者回复: > ...总想第一个版本上去就是完美的... 那就是没有真正理解精益开发，精益创业，没有理解MVP。如果有条件的话，可以想办法提高公司成员对MVP的理解。 > ...流程各个环节却耗时很长...是否舍得花成本去解决这些隐藏在流程背后的问题，又依赖于组织文化... 👍 还有领导的意识。
2019-08-2314
罗小布1. 用记事本编码和用IDE编码，谁的效率高? 2. 用微信文件传来传去和云端协同办公，比如石墨文档，谁的效率高？ 3 . 工作期间，单屏幕工作和分多屏幕，谁的效率高？ 工具本来就是未来提升效率，解决问题的，选择好的工具也是非常重要作者回复: 同意同意。我个人一直对工具比较执着。花了很多时间在上面 ：） 不过使用工具也有一个合适度的问题。我曾经就花了太多时间去做不成熟的优化（premature optimization)。一般premature optimization是指架构方面的，但是实际上在使用工具上也一样。我现在的实用工具原则是：留意平时工作，在重复比较多的工作部分，花一些时间去找工具进行优化。随时注意投入产出的比较。
2019-08-2311
李双是效能低才导致加班，还是加班导致效能低？作者回复: 这是一个很好的考虑问题的角度。我觉得这是一个恶性循环： 1. 加班之后发现有一些效果 2. 较多地使用加班 3. 加班导致性效能降低。产品质量下降 4. 为了赶上进度，提高产出，又觉得加班是一个办法，回到步骤2
2019-08-23510
囧囧冰淇淋1.为何国内公司会支持用996工作模式？弊端是什么？ 目前国内比较多的三种工作时长：965，966，996。前者大部分是国企，后者则是私营，最后者则是绝少数私营。996暴露出绝大部分公司效率低下，只有通过加长员工的工作时间弥补，但这个弥补绝大部分时候适得其反，员工不理解，磨洋工，最后损失的还是公司。 作为员工我们要怎么办？ 作为老板我们又要怎么办呢？ 2.关注研发效能，工作效能？ 作者针对员工，又是软件类工作者，提出了提升个人和团队研发效能的思考和可行性，这部分是我非常向往的，谁不希望早点完成早点回家？谁不希望干好拿到更高的薪水？ 研发效能：团队能够持续为用户产生有效价值的效率，包括有效性、效率和可持续性三方面。简单说，就是开发者是否能够长期即快又准地产生用户价值。 虽然我不是软件工作者，但可以模仿作者对这些的思路，重新组合下运用到我的工作上。 作者提出有效性、效率和可持续性三方面。有效性应该是开发的产品能解决多少问题，如果只解决了部分那就打个折扣一类。效率指多少员工花了多少时间开发出了这个产品。可持续性应该有两个方面，一个是开发出的产品是否能不断迭代更新，另一个则是如何把这个方法高效率的传给新同事（如果员工流动，这方法没传下去，公司岂不是又倒血霉重新来？） 有效性：0-10 效率：0-100% 持续性：0-10 有效性X效率X可持续性=用户价值 20个开发团队搞出30多个服务和五种语言的例子： 有效性（4分）*效率（100%）*持续性（4分）=16 3.研发活动的本质 只有深入研发活动的本质，才能提高效能，只有深入了解运营工作的本质，才能提高运营效率。作者从原则和应用场景入手，把研发本质以一条流水线的形式展示，那运营的原则和应用场景是什么？是否也能以一条流水线的形式展示？ 作为一个运营，对店铺最终的营业额负责，运营是否能长期稳定准确的寻找到新的热卖产品，并使其尽可能多的卖出。这似乎贯穿了产品部，营销，页面设计，客服部。 平常的公司：运营认为春季每个月上40款，每个星期有10款可以上新，既可以吸引新客户也能满足老顾客。产品部看看店铺热卖的款，80%找相似的，另外的部分试试新风格。定下后，营销和页面设计开始商量拍摄、新款页面和推广图，客服部同时开始培训新款特点等。作者回复: 你的学习态度真是很赞！！ > 有效性：0-10 效率：0-100% 持续性：0-10 > 有效性X效率X可持续性=用户价值 这个部分的计算公式很好！不过权重要根据情况调节 > 20个开发团队搞出30多个服务和五种语言的例子： > 有效性（4分）*效率（100%）*持续性（4分）=16 在后面微服务多到难以维护的时候，这三个数字应该跟接近 有效性（不确定，应该不会太高）*效率（50%，因为做不快了）*持续性（4分）
2019-08-256
寒光研发效能的提升，对团队成员的技能要求应该是什么样的呢？对于国内某些大厂，还是倾向于自上而下，层层分解。这样，最后真正写代码的，可能就是些初级技能的开发者，他们是有非常量化的代码指标的，实现功能已经不错了，还让他们有创造性，要求太苛刻了。不管怎么批判，这就是现实，如何突破？因为我们不可能要求团队的成员都具备硅谷的水平，在这些国内的现状下，我们的突破点在哪里呢？作者回复: 我建议作为管理者，应该在做业务目标的同时有一些技术目标。提高团队的效能就是技术目标中的一种。当然很可能需要说服更上一层领导，让他了解并支持技术目标。 不一定需要成员有大的创造性。一开始更重要的可能是主动性。可以从绩效等方面鼓励帮团队提高效能的行为。
2019-08-2336
xiaozhi239文章写得真好。我目前也在负责团队内部的效能提升（G家），从你的分享里收获了很多。同时也在打算近期回国，关于国内程序员的开发环境和工作环境也希望有机会能尽自己所能帮忙改善作者回复: 希望能对你后面回国工作有一些帮助。如果想更多讨论可以加我微信jungejason
2020-08-173
yu公司目前屬於小團隊，十幾來人，部分人士效率特別差，即使引進了自動化測試，自動部署，在撰寫商業邏輯面依然是非常緩慢。經由分析原因可能如下： 1. 項目需求不明確 2. 開發人員對於流程不熟悉 3. 開發人員寧願埋頭苦幹也不願意討論 改進方法 1. 加強每個功能與項目的編碼，明確需求 2. 要求開發人員熟悉流程 除此之外，老師有什麼更好的建議嗎作者回复: > 部分人士效率特別差 这些人员背景如何？没有经验的新人吗？还是有经验但是效率不好？
2019-08-2333
DZZ老师好，我们公司今年从很上层开始强推研效考核，各种指标直接和KPI之类挂钩。这种方式给我们很多人的感觉就是形式主义，各种造数据。而没有真正去提高一个需求从业务端提出到IT端上线的效能。需求质量不高，团队加班严重，又需要去造各类研效数据。这样的流程太令人感到不合理又不爽，却又因为KPI不得不做。我现在负责团队的这个研效流程的管理，每天都在和需求各个阶段的时间节点斗争，哪天该找业务内审，哪天又该技术评审，哪天又要需求宣讲，哪天又有开发，测试，上线……一个版本接着一个，根本没有喘气的时间。一旦有点紧急需求，时间点对不上了，就得压缩某个阶段的时间。在整个阶段有很多方面的问题: 业务方也不会准时提出需求进行需求的分析，挤占后续阶段的时间。 SA(和业务对接的技术人员）需求分析落地需求质量不高，需求文档经常是一句话。 开发测试人员大部分是外包人员，没有很强的技术或责任心，水平参差不齐，稍微复杂一点的根本不放心给资历浅的。 由于前面各问题，上线后又有各种问题需要修复。 再加上前面的集团推动所谓的研效提升，又造成每个版本都这样不停的恶性循环，现在持续了快一年这样的节奏，感觉人都快拖垮了。 不知道有没有什么样的办法n作者回复: 很抱歉听到你们处于这种不理想的环境。 总的技术负责人对这个懂不懂，另外在公司又没有发言权？
2020-10-0922
ylw66老师说的非常好，但是在一个大型公司，即便高层有远见卓识，推进到每个项目上，可能只能在项目层面推进团队工程实践和优化流程。即便一个项目搞好了，但是项目与项目之间的沟通仍然存在较大问题，而且项目与项目之间的研发模型、效能模型又都不一样，这在国外如何解决呢作者回复: 这正是软件研发的灵活性导致的。我觉得主要的解决办法是 1. 了解方法论的本质，根据不同团队特点找到不同具体实践。2. 找到共性全公司推广。 在硅谷这边大概也是这样做的。
2020-04-082
