主持人：
徐锋-Keylink创始合伙人/资深IT产品咨询顾问
嘉 宾：
张逸-DaoCloud应用现代化首席顾问
茹炳晟-腾讯 Tech Lead / 腾讯研究院特约研究员
钱勇-惟客数据副总裁&产品技术委员会主席
姚冬-华为云应用平台部首席技术架构师
— 1 —
数字化转型时代研发的方向
主持人徐锋：
数字化转型时代背景下，经常听到一句话叫做“IT人太会造词了”，就是不断的编一个新的词，去装老的酒。20多年前我毕业投身所在的时代叫信息化时代，很多人问信息化的时代和数字化的时代是同一个东西，还是只换了一个词呢？大家是怎么看这个问题的？
张逸：
我非常同意主持人刚才说的，IT人特别会造词儿，因为不造词儿怎么挣钱呐。我个人理解数字化和信息化有点像现在的信息化从互联网的Web1.0升级到2.0，然后到3.0，未来我们还有一个更大的词儿——元宇宙。对数字化的定义，我个人很难说出它和信息化的差别，我只是说我对数字化的理解。第一个，我认为数字化的一个特征可以称为万物互联，因为它连接的态势，连接的对象比原来我们信息化连接的对象要多很多。第二个，我认为叫数字智能，因为连接了之后会产生很多智能，还有很多数据，那这些数据怎么把它变废为宝？在信息化时代，因为它的规模，它的算力，它的基础设施还很难达到，它的人工智能的相关算法也很难达到，现在应该是有这么一个基础了，所以我们可以赋能给它提升数字智能。第三个，我认为叫极致体验，比如我们传统的信息化，大多数体验就是Web端的网页，再加上后来的移动，但现在他的方法和输入的介质，以及使用的体验方式都有很大的变化，未来我们也会看到它会有VR，会变得更加的成熟。
钱勇：
我确实在这个领域做的比较久了，之前在用友工作的时候经历了企业信息化的过程。我们当时做信息化最大的痛点之一，就是数据采集。比如说财务凭证、ERP物料怎么录到系统等等，这些都是很难解决的问题。所以信息化时代更多是把企业内部的基于业财管理的一些核心流程转移到了系统里面，转移到了线上，然后我可以针对这些高质量的、高密度的数据做一些简要的BI分析和洞察。但是数字化时代最大的变化就是物理世界和数字世界之间的连接变得更便捷，我们可以通过RFID、条码、二维码，以及各种传感器等数字化的手段把数据上传到系统。所以你可以看到，在工业界的工业互联网，就是让所有的生产设备上云；能源互联网，就是全国所有的电能、风能、石油、天然气等能源节点建立起来的分布式网络 ；然后还有产业互联网，企业间和产业间的生意和研产供销的协同。所以，我理解的数字化就是物理世界的东西，在数字世界里有一个镜像，基于这个镜像就会产生大量的各种各样的数据。通过对这些数据的洞察和分析，包括通过各种算法的赋能，它能够给企业的经营，以及我们生活各个方面的一些场景，带来完全不一样的体验，我觉得这个是非常大的一个变化。
主持人徐锋：
我经常跟很多CIO朋友一起聊，发现数字化时代最大的变化是手上钱多了，老板给的钱越来越多，但是同时被骂的声音也越来越多，钱花哪了？这个有的时候很苦，说是要花那么多钱，但是又问我花哪了，所以这就有一个非常有意思的话题，在数字化时代，企业应该把研发的投资投到哪里？
钱勇：
这个问题我觉得几个方面来回答，首先就是要明确投资目的，IT投资的目的是什么？我觉得任何一个不同的行业，或者企业在生命周期的不同阶段，IT投资的策略都是不同的。刚才其实炳晟老师也在讲，如果是初创期，你就做战术性研发是没有问题的，而且你所有的投资都要面临你的业务如何能够低成本的、快速的、大规模的创造价值，活下去是你第一要做的事情。但是如果是一个头部的领先企业，那么你可能会做一些前瞻性的技术投资和研究，我觉得这个可能会有所不同。其次，基于我自己过去实践的经验和观点来说，我觉得任何一个技术投资、产品投资，或者数字化项目投资，它的回报周期不应该超过18个月。也就是说如果这个项目没有在18个月之内，创造显著的或者能够被管理层认可的价值，我会认为这个项目在前期立项阶段，或者执行的路径和方法阶段可能是有问题的。因为任何一件事情，我觉得正回报还是比较重要的，我们不能说这件事情是一个很长期的、很久远的才能够创造价值，我觉得对于CIO来说，要审慎评估长短期的价值输出，或者评估你在IT投资上的整体发展路径；什么是短期内的正反馈，什么是要关注的长期反馈。但我认为现在技术发展也比较快，我们也很难去预测未来五年到十年而做更好的技术准备，那索性我们不如把时间看得更近一点，但是要保持它的可演进的能力；就像刚才炳晟老师讲的，软件是长出来的，它不是规划出来的，如果是规划出来的我们可以预先做一些投资，但长出来的就是要随着技术的发展、市场的发展、业务的发展以及公司对价值诉求的发展，去演进你的产品。还有另外一个观点，无论是技术的投资，还是技术的选型，还是项目的上马，不是我们认为好的或者大家都认为好的就一定是好的，而适用的才是好的，能满足你当下业务需要的就是最好的。
数字化转型时代研发投资的重点方向和指导原则是什么？
主持人徐锋：
有一个观点非常认同，炳晟老师在刚才分享的时候讲，说“软件架构”和建筑架构不应该是同一个词，我也非常认同这个观点，把软件架构师类比为建筑架构师是说小了，其实应该类比于城市的规划师。因为每个城市的变化，才是我们软件最好的隐喻。所以这个时候，就会提到一个很尖锐的问题，刚才钱老师也提到了“18个月就应该见效”，那么ROI就成了一个非常重要的评估点，那么怎么提高我们IT投入的ROI呢？因为现在研发越来越贵，这个成本越来越高，随便养一个小的团队，可能就是一个巨大的投入，那么在这个时候，ROI的提升就可能成为一个关注的非常多的话题，这些方面大家有什么样的一些建议或者看法？
茹炳晟：
投入这一块其实本质上来讲，投入了多少就取决于你的回报或者你的预期回报有多少，换句话说就是做这件事值还是不值。那这个问题就转变成你对问题的一个提炼和把握，简单来讲就是所有的投入都是由问题来驱动，我当下的问题是什么，或者说我中期要解决的问题是什么？长期要解决的问题是什么？这就决定了你投入的一个配置，其实本质上是为了去解决这些问题，但我其实也看到一个不太好的现象，18个月其实在是站在管理层来讲，可能认为是一个回报能够容忍的最长时限，但实际上，从很多基础能力的建设来讲，18个月其实是不够的。但是我们如果把18个月放在应用层业务交互层，那18个月这个周期并不长，如果18个月业务还跑不出来，基本上是要做调整的，策略方向要做调整，但是一些底层能力，一些核心的底座能力的打造，18个月可能刚刚行。这就是为什么你可以看到好多以Google这种硅谷为代表的企业，他其实很多的投入是不计成本的，说白了就是两年、三年、五年这样的一个中长期技术投入，它是要经过好几次曲线上升的。所以说还是我们这个问题怎么去定义，我的理解如果面向业务，我们可能就是以18个月维度，以短平快，换句话说是在ROI跟我的投入以及我的一个长远收入之间找一个合适的平衡点，解决当下的问题。当下是业务的问题、快速交付的问题，就解决当下快速交付的问题，如果当下是质量问题，我就解决质量、流程的问题。但如果我面向的是一种中长期的核心竞争力的建设，那ROI可能就不那么重要了。像Google去投大数据，去做三驾马车，做那些底层的东西的时候，他根本就不考虑成本，他去做那些真正带来对软件行业带来极端变化的这些系统时从来没有去考虑收入，他考虑的是改变人类，做一些改变世界的事情，在考虑这个事情的过程当中，他获得了巨额的收入，这就是一种很长期的投资。
张逸：
其实刚才炳晟老师说的这个区别还是看大厂小厂，大厂有钱所以他比较任性，当然从某种角度来说，确实他是有规划，因为这种规划，他会看到技术一定在发展。刚才钱老师说的18个月，我想也是从摩尔定律得到的一个启发，所以他的技术发展一定是向上的，对于一些大厂来说，他不去投入足够的研发经费，就很难保持它的先进性，但对小厂来说呢，他可能对ROI的这个值衡量会更多，因为他经不起啊！我有一个合作伙伴，他们是把ROI做了一个可视化，就是我做每一件事情，我能产生的ROI把它尽可能的去可视化出来，他做的是类似于RPA的这种方式，就是数字机器人，我引入一个数字机器人和传统不采用数字机器人的做法，能产生多少ROI，这个是可以在一定程度上做量化的，当然他的量化是需要有一个公式去计算，然后也在不断的调整，但对老板来说，这个数据只要有很明显上升，他就很happy，当然这个数据的真实性、可靠性、准确性是需要去探索的。
姚冬：
我觉得其实18个月的话，他实际上是一个刻度，而不是一个绝对的东西。像腾讯、华为这样的企业可能维度会更大一些，因为它要看一个中长期的东西。初创的企业可能未必，这个维度就会变成几个月。另外一点是，其实你真正的投入，应该把80%投入到20%的长期有效的事情上面去，然后拿一些小东西来去撬动。举个例子，因为我是做研发效能的，通常来说我不会去讲说一定要去上一个什么样的工具，比如需求管理工具，前期在初创的时候用一些简易的工具可能效果会更好，之后的话真的说这个东西靠谱了，然后我们再去上平台。
— 2 —
这个世界没有银弹，研发管理方法的意义与创新
数字化转型的时代，是向IT要经营能力的一个时代，而不仅仅是一个管理能力的时代。
主持人徐锋：
过去信息化只是一个内部能力的信息化，而数字化时代，IT已经成为了绝大多数企业获得新的商业竞争力的一种来源。所以这个时候，IT从过去的成本中心，可能慢慢的需要去考虑更多的ROI，这个ROI可能会有长期的，也可能会有短期的，因为这些技术的领先，有可能是另外一个领域的。比如刚才茹老师所讲的谷歌不计投入，我补充一下我的观点，它跟投资圈的玩法是一样的，同时投20个项目，只要有一个成功了，那么所有的成本就已经回来了。它的ROI并不是从单个项目去看到，而是一个组合。所以IT团队、研发团队的ROI意识要能够真正的为未来商业的竞争力提升服务。我经常听到我的圈里在聊一个话题，叫做数字化转型的时代，是向IT要经营能力的一个时代，而不仅仅是一个管理能力的时代。那么研发也就受到了更多的挑战，研发团队越来越多，也越来越多元，对于研发管理就变成了一个更加复杂的话题。后来大家都开始提敏态，敏捷的方法创精益，吴博士也在大量的推行敏态，但我们会发现这几年，有一个很远古的东西回来了，那就是IPD，但我觉得它也非常的重。那么在此过程中，大家会觉得在这样的一个新的数字化转型时代，研发管理应该采用什么样的方法更合理？
姚冬：
首先我觉得IPD不是谁都适用，如果要划一个维度的话，我觉得至少上千人甚至上万人的研发团队才适用。之前有企业跟我聊说想要做IPD，是一家人工智能的企业，差不多三五百人，我觉得是不适合。上IPD会有一些资源、前提条件的要求，至少你的层面、团队规模达到要求后，再往上去做这种规模化，规模化之后才有可能IPD。在华为IPD裹挟了很多东西，比如说研发的IPD只是其中一块，还会包含比如说供应链、进销存等等，所有这些东西都包含在IPD里，所以IPD它的Level 1至少分了十几个域，Level 2一直可以拆解到三级、四级这些东西，所以一直拆解下去的话，其实不是每一个企业都能够承受得了的。即便在华为，其实在不同的业务线，使用的研发流程也是不一样的，比如说像我们传统的交换机，业务属性决定部署频度，不可能是每周或者每天上线多次，因为人家是有时间要求的。比如说云服务所有的这些机房等等这些全是自主可控的，所以我的研发工程师就可以自主上线了。电信领域是完全不一样的，所以其实在华为内部的话，会有无数种的研发的流程和模式，实际上是匹配自己的业务属性、技术属性和团队的成熟度的。
ToB领域敏捷和IPD怎样擦出价值火花？
钱勇：
谈谈我的理解，因为我们也在用IPD，但是可能跟姚老师谈的IPD不是一个IPD，我们是用了IPD理念和思维方式方法，把它做到了最简化IPD，我们是叫MVP级的端到端的IPD，然后在我们的研发组织当中落地。这个跟刚才谈到的ROI话题之间是有关联的，如果我们的研发组织是完全的技术愿景驱动型的，大家更追求技术的先进性，更追求软件工程的这种顺滑的程度，能够双流合一。但是对于一些初创公司和高速成长阶段的公司，我们觉得商业化跟市场需求的接轨，可能比研发的效率提升的重要性稍微高那么一点。这时候我们去做工程效能也好，还是做后面的商业化也好，还是在前面的立项阶段就控制也好，总之就要做到“恰如其分”。这个所谓的恰如其分，就是如果你前面的商业设计错了，你的业务需求偏了，你后面的效能多高都没有意义；就是在“正确的做事”和“做正确的事“之间要找到平衡点，而这个平衡点，我认为IPD里面有一些思想，可以让研发能够理解商业的需求是什么，商业的价值是什么，我为什么要做这件事儿，做这件事儿对我的回报周期是多久，我的投产是什么样子的。有了这种思维，研发会知道我干的这件事情对公司来说意味着什么，如果我的一个迭代延期对公司来说意味着什么？因为我们可能每一个排期和每一个商业计划之间都是严丝合缝设计好的。所以在这个过程当中，我觉得很多很复杂的思想、方法或者工具，你只要理解它的精髓，然后在你的组织体量的流程里面把它引用进来，用最简单的方式能够为你所用就挺好的。
云原生时代的研发管理方法是否可以超越敏捷，满足敏态业务需求？
张逸：
在云原生时代，我们都在追求轻量级的、快速孵化的一些应用，但是相反，它的一套方法论反而会越来越复杂，然后用这套复杂方法去满足更大规模的、更复杂的软件IT系统，所以研发管理还是应该根据我们项目的情况、团队的情况、组织的情况、投资的情况来做判断，但我个人的感受是希望尽可能的把一些可以用工具去做的事儿让工具去完成，像腾讯现在也有跟效能相关的案例，我认为把很多工作交给工具去做，可以把重复的工作减少，这样就可以减少浪费。工具和人不一样，它是铁面无私的，你必须得通过这个方式去做，因为做管理最难的就是我们要管人，这是我觉得最重要的一点。所以首先第一个就要工具化去解决我们的研发管理。第二个，就是要用可视化，就是我们在管理的时候要看到很多指标，通过这些指标来说服管理者，因为我们在管理的时候，最大的阻力往往真的是管理者，因为管理者他没有认识到这些。第三个就是文化和组织结构，在云原生时代也好，在数字化时代也好，真的是要调整的。很多传统的企业还是停留在早期的传统的，甚至于都不是科技管理，也不是IT管理的那种模式下，这种模式下CTO在推进数字化转型的时候，最大的阻力有两个，一个是技术，因为技术太落后了，你根本没办法去符合云原生的要求，但是人家美国的国防部把战斗机都搬在Kubernetes上面，所以其实技术的手段还是可以做的。最大的挑战是人，要做这件事儿，关于流程的审批和资金的预算都要花很长时间，等到你花这么长时间，其实很多时机的窗口就错过了。
主持人徐锋：
在整个研发管理里面，即使是非常远古、存在很多年的东西，它仍然会有一些关键的思想，直到今天都是正确的。在研发的管理中，应该去借鉴各种的管理思想，然后去重构自己的关键的业务流程，就比如说姚老师提到的IPD是一个很重的流程，但是到钱老师这，可能就把这个流程进行了一个简化，张老师提到了这个可能还需要有更多的关键方法、关键工具来支撑。这样的一个过程中，应该根据产品的方向，企业的特征、规模去找到最合适的管理方法。所以，我们相信在未来研发管理仍然会百花齐放。很多年前有个好朋友做CMI之后，去做研发管理的工具。我不看好，到今天的确也做得不怎么好，原因很简单，因为给IT人做IT工具，这是一个最难的事情。为什么呢？IT人一看就说，“这玩意我花点时间也能做出来，比你做的还好”。但是，恰好IT人也是最不会用的。以前我们讲哪个行业的信息化水平最差？很遗憾的发现，IT行业的信息化最差。为什么呢？就是最不屑用工具去帮助我们去提高这样的能力。我觉得刚才张老师提的特别棒，希望能够在整个行业里面重视，对自己生产软件的这些东西进行工具化，它其实可能会带来很多的好处。
— 3 —
研发效能的价值与方法
降本增效的大环境下，如何评估研发这个“吞金怪兽”的效能？
主持人徐锋：
数字化转型时代，研发组织被业务部门诟病最多的是“聊什么聊,去年还有两个需求没做完”。他们会觉得研发这个“吞金怪兽”，投了很多的钱，投了很多的人，但是产出总是不如预期的那么快，所以总是会被提到一个效能的问题。刚才，茹老师在演讲的时候，也特别提到降本增效，这“本”，第一项想到的就是“裁员”。很简单，如果您是个老板，打开财务报表一看，这个是最容易干掉的固定成本。所以它是一个非常容易被想到的过程，但是，研发的能效的确在未来可能会越来越重要，那么关于能效这样的一个问题，有哪些具体的策略方法呢？
姚冬：
“效能”或者“能效”，是两个词。“效”依然是两个词，一个是“效果”，一个“效率”。“效果”是最后的业务指标；“效率”就比如我们有业务的ROI、客户的满意度、复购率等等。“效率”实际上是我们如何更快速的、高质量的去交付东西，但质量其实在前面那块也会有，因为客户能够感受到的质量，包括可用性，友好性等等。“能”实际上是一个“能力”，这个能力决定了是否可以去高效的、可持续的做某件事情，它更多的是在可持续性上面，整体的度量大致会分这几个层面。那么研发应该投入到什么地方？效能应该怎么去做？其实无非就是人和工具、人和机器，自动化和人工如何去拆分，所以基本上所有的这些都可以让机器来做，因为比如说Code Review，到底哪些东西是需要人去做Code Review的，在做Code Review之前，机器应该干什么样的事情。比如像代码扫描，就可以完全把90%以上的这些东西扫完了，人就只去看那10-20%最关键的业务逻辑，大架构师没必要去看代码风格这个东西，包括像测试、部署等等这些，比如DevOps里面工程这一侧的东西，全都是通过工具来去保证它的高效、一致性、可持续、高质量。人工解放出来后，就可以去干那些机器干不了的事情。
张逸：
我认为研发效能是非常的重要，但是在实际的过程中，又会有一些无奈，一些害怕，因为我们之前给一个客户去推广研发效能，希望能提升他的效率。通过效能发现问题的时候，要去做归因分析，去找真正的原因，才好解决你的效能。讲了很多之后，最后他概括一句话“你讲的模型都很好，你怎么给我定义出KPI？”他就把KPI和绩效开始挂钩了。这个时候就变成对研发人员提交的频次、bug率、流动时间等等，最后成为你拿奖金的一部分。非常讽刺的是，我们在给客户讲研发效能的时候，第一我就说研发效能不是KPI考核，我们对研发效能的定义，不要把它直观的和KPI的绩效去画一个等号。
主持人徐锋：
对于一个知识创造性的行业，提高效能很重要的一件事情是在自己的管理思路上要有革新，不能带着这种非常传统的从现代工厂留下来的KPI的逻辑去考核，可能会对效能的提升有适得其反的作用。
张逸：
以数据驱动的方式，比如代码的提交率，如果把代码的提交率作为一个KPI的指标，我们就不断的提交。如果把缺陷率拿来作为我们的评估指标，那我就少开发功能。总会有一些方法去提升KPI，但是它并没有真正提升研发效能。我们管理层在做研发效能的时候，我觉得研发效能应该会有一个成熟级，可能对KPI的追求应该属于一个成熟级比较低的，但可能在推广的过程中，它也许是一个必然的过程，但绝对不是我们的最终目标，这可能炳晟老师会更精通这一块儿。
茹炳晟：
我理解的研发效能在落地的过程就是三件事情：1、最佳实践2、工具3、度量。但是很多人的想法是先要度量，有了度量之后，发现哪里做得好，哪里做的不好，再去引导出一些好的实践，再通过工具把这些实践落地，但实际上这个方法其实是偏的。因为首先你度量上的数据是什么，比如你的流动时间先要有完整的定义。你要有这些度量指标的定义，就必须要有流程，流程是干净的、清晰的基础上，度量指标才能被定义，然后才能通过度量指标来发现问题。所以在整个过程当中，我认为应该是先有实践，然后把一些实践沉淀到工具，用工具实现自动化，让工程师关注在应该关注的事情上。如果一个团队想零成本实现研发效能提升，只要做一件事情，保证工程师的连续工作时长，不要打断他，不要让他开会，效率一定就上去很多。有了这些实践之后，落到工具里面，工具就会把度量的数据自动产生，这个数据准确性问题就解决了，而且是零成本自动产生数据，而且数据的真实性问题也解决了。基于这些数据，再对它进行分析和洞察，然后再来指导实践，而且这些数据绝对不是用来考核的，如果用来考核就完蛋了，刚才张老师也说了用来考核就变成了，你要什么我就给你什么。有一个笑话大家可以听听，一个度量指标说要找女朋友，要求是大眼睛，大嘴巴、热爱运动、水上运动、水下运动都能搞得很溜，因为喜欢户外。后来系统推荐了一个东西给他，是青蛙，都符合要求的。所以度量指标可以达到，但是最终的目标不一定能够达到。所以很多时候我们应该是由目标出发，再来决定你要度量什么，也就是说有实践，然后有工具，然后度量是一个副产品。这个副产品可以提高我们的最佳实践的提炼，用系统思考的方向来讲，形成一个最佳循环，形成一个增强回路，这样才是一个正确的方法。
主持人徐锋：
所以不是用度量去找最佳实践，是用度量去分析问题，然后根据问题去找到提升的方向在哪里，点在哪里。为了保证度量的真实性、科学性，其实它本质上不应该是一个管理工具，它应该是一个自我诊断和自我观测的一个模式。
技术债务的偿还也是要“恰如其分”的。
主持人徐锋：
当你真正背负着技术债务的时候，怎么去做，有什么建议呢？
茹老师在分享的时候提到技术债务是一个不好的东西。他最后有一个例子，讲到业务先行的时候，技术债务可以先背负，觉得应该把它调整一下。技术债务就好像贷款买房买车是一样的，债务其实是有两面性的，有好的一面。任何一个产品的代码里面其实都是有债务的，中国有句老话叫“水至清无大鱼”，我觉得未必特别适合，但举债前行是有必要去做的，你不能无意识的做。在技术债务的划分里有一个矩阵四象限，有意的还是无意的，是谨慎的还是鲁莽的。你要去判定，如果是有益的，并且也是对于你的战略业务需求是重要的，就可以举债前行。回到刚才徐老师讲的就是怎么去清理维护，其实技术债务不仅存在代码里头，其实在整个研发的过程中，比如说你的需求、设计、架构、代码、流水线的东西、测试用例、测试数据、一直到部署上线之后的一个配置等等都会有。所以不能只看代码里面的东西，真正清理的时候一个原则是非必要不去清理，清理是比较耗时，而且要想一想清理真正能给你带来什么东西。新增的一定要把控好，原有的就是帮助你去修改，增长的时候就开始运行。
茹炳晟：
债务分好多种形式，设计的、代码的、编程的、还有组织的，是有优先级的。我认为设计债务在这里面是最重的一个。如果设计债务在一开始弄不好，后面所有的东西都会呈几百倍、几十倍的增长。设计债务在一开始的时候，可能花一点点小精力，后面就会爽很多。它是投资，你值得花一点钱。
张逸：
首先技术债是不可避免的，一定会出现。但“技术债务”这个词本身就表达了“还的越晚，利息越高”。我非常同意设计的债是一定要还的，关键是它在不断的延伸，我们的软件也会越来越多，代码也会越来越多，那到时候设计债务没有及时的偿还，它的利息比例可能就比别的债的利息比例要高很多。我们软件行业现在因为疫情时代特别的困难，好多失业的人员。头几天，我们听同事讲了一个消息，就是深圳的某一位人员，欠房贷400多万，那400多万要怎么还，失业了怎么办？实际上就是你原来在过去的那个点，你对未来期望很高，因为我很厉害，所以我能挣很多钱，所以愿意去偿还这么大的债务。但是随着债务越来越高，然后在某一个风险点暴露的时候，你可能还债就会非常的困难。其实天天在说技术债务，但真的没看到多少公司把技术债务放到一个很重要的一个地位。我们现在就是把技术债可视化出来，我们在项目里面有一个技术债不断维护的一个技术债雷达，我们把技术债也分类，然后用一个雷达图把它可视化出来，每次回顾会议的时候，都要去过一下这个技术债，然后去看这些技术债还有哪些，因为我们的技术债其实就是to do list，我们会把这些技术债分配给对应的owner去尝试去解决。我当时的承担的一个技术债，就是编译自动化运行的速度太慢，所以我们要做并行的去跑这个自动化测试，当时背负着这个债，然后我们还有一个专门做偿还技术债务的团队。第二个是刚刚提到的“恰如其分”，其实技术债的偿还也是要恰如其分的，因为你要衡量成本和收益。我翻译的一本书叫《恰如其分的软件架构》讲的风险驱动设计，先从风险去识别，这些风险都是技术债，也可以叫Technical Debt Driven Design，提前去发现在未来可能会出现的技术债。然后我们把这些技术债放到我们的风险列表里面去，尝试给出解决方案。另外还有一点，小债务有时候要及时还，我们看到很多代码重构，什么是重构？很多时候是重写，因为你小代码重构没做，后来就只有重写。当然有一些设计靠重构是做不到的，但是为后面的改进提供更多可能性。你在写代码的时候，就像你在画一幅油画，画完之后你再退两步看一看这个油画美不美，有没有问题，有没有瑕疵。写代码也是这样的。你写完了可以提交，提交之后退两步，站在一个读者的角度来看代码的可读性、可重用性、可拓展性，然后及时的去重构。
钱勇：
技术债的问题，我的想法是在关键环节，比如设计环节可以多做一些论证。我们通常都是会叫上整个架构组的同事反复去论证一下，因为我觉得特别关键的环节的设计很重要，因为如果后面返工可能会影响很大。另外，我们也会引入一些业务的人，因为很多技术债是业务债导致的。当年业务提了这样一个需求，但刚一上线，需求就变了，逻辑完全是反的，所以那个设计就废止了。新的需求是基于原来的架构继续演进？还是再重新建一个？这个时候对技术人员来说可能就是一个选择。当工期很紧的时候，可能就在上面改，改了之后他就会形成各种各样的技术债务。所以我觉得很多事情的解决，可能都是系统来看，不是从单点看。包括刚才说的效能，以及我们谈到的技术债，我觉得要善用四个驱动力，第一是业务驱动，首先做对的事儿；第二是工具驱动，有很多方法和工具能够让整个软件工程更高效；第三是数据驱动，就是可以度量和可视化；第四其实是研发效能中最关键的，就是工程文化驱动，我对代码的质量、对攻克技术难关是否带有我自己的意愿和情怀。如果团队能够把这几个东西叠加在一起，可能会解决的更好。
主持人徐锋：
我对今天上午的对话环节做一个简单的回顾。在最开始的时候，我们提到了数字化转型时代的研发要求，我觉得几位专家，都提到了一个词叫ROI，研发开始理解业务ROI，我认为是数字化转型时代里面非常重要的一个转变。
第二部分我们聊到，这个世界没有银弹，没有哪个方法是可以解决所有研发问题的，所以不管IPD、敏捷、还是云原生，背后的关键管理思想，关键的管理流程，应该根据我们的实际情况，例如研发人数、产品方向等因素去做适度的匹配。
第三部分我们聊到，对于效能来讲，其实可以马上去行动的，就是尽量去释放研发人员的有效研发时间，减少他们在管理成本上的投入。积极的用度量的方法，找到可以改进的问题，不断的去持续改进，不要太早的去想用考核考出能效。我认为研发的团队要形成激发自学习、自进步的组织，并且要善于用工具。关于技术债务的这个部分，我觉得姚冬老师给了一个非常重要的提示，敢于举良性的债务，因为这是发展的需要。我始终觉得不应该有技术洁癖，因为在很多的时候，业务是有窗口期的，所以要敢于举债。我们的人生也如此，敢于良性的举债，实际上是会获得更美好的明天。其实我们要识别的是恶性的债务，需要有这样的一个意识去找到这些债，你知道你今天在举债。我觉得张老师和茹老师都提到一个东西，叫设计这样的一个债务。
我觉得这几年敏捷下来，部分团队带来的一个错误的认知，过于要求快以后，在设计这部分的“停下来”、“慢一点”、“想清楚”的东西并没有，导致了非常多我们本来可以避免的债。那么每位老师都提到了“恰如其分”，我始终觉得这是中国文化博大精深之处。在西方翻译过来的恰如其分，如果我翻译的话，就可以用中国的词叫“中庸”。所谓的“中庸”，叫“不偏不倚”，恰好在这个位置上。我是一个对中国文化非常自信的人，我不太关注于西方，很多人说所有理论回归到头是德鲁克，我觉得很多的理论从德鲁克回到头是老庄，是韩非。什么叫“中庸”，什么叫“不偏不倚”，我觉得大家可以带着这样的话题，带着这样的疑问，去看看他们是如何去解读“恰如其分”。
END
点这里↓↓↓记得关注标星哦~
