当你成为一个技术团队的管理者时，就会经常会被老板问到，研发的价值在哪里？如何让研发的价值更大？现在的研发团队和行业内相比效率/能力/水平怎么样？如此种种……
每个公司每个技术团队的管理者都有自己的逻辑来回答这个问题，因为这是带团队的核心逻辑之一，且各有缘法。
今天这篇文章不是想准确的回答这个问题，也不是标准答案，只是这些问题最近引发的一些个人思考。
先抛两个公式：
公式一：研发的价值 = (业务价值 + 技术价值) – 非正常成本 – 正常成本
公式二：研发的价值 = 单位有效时间内产出的价值 × 有效时间 – 非正常成本 – 正常成本
这是简化的研发的价值模型，可以作为理解研发价值创造的基础框架。实际应用中可能还需要进一步的细化和调整，因为价值的计算可能远比这两个公式复杂。
总体来看，让价值更大在于攻守，如何攻，如何守，攻就是提高产出价值，守就是减少成本。
在攻的方面，提高产出价值包括提高业务价值和技术价值。我们都知道业务需求是做不完的，如何在做不完的业务需求里面产出更大的价值， 关键点在于业务需求本身的价值和业务价值生效的时间，将具有更大价值的业务需求更快的上线是提高研发侧业务价值的主体逻辑。当然，需求上线后可能还有 bug 之类的，这个我们作为守的那部分来聊。
提高业务价值
提高业务价值的主体逻辑包括两层意思，一个是更大价值的业务需求，另一个是更快的上线。
更大价值的业务需求我理解为做重要的事情，实际上是我们对于事项的一个优先级排序。对于重要的事情分两个阶段，一个是确定事项前的判断，一个是事项确定后的判断，确定前的判断有以下要点：
-
战略和期望：这是一个前期非常重要的判断项，公司层面的战略、技术长期规划，老板对这个组织的期望等等 -
业务影响和目标价值：直白的说，看这些事项对业务目标的达成情况的影响，对收入增长的影响，对于 NPS 这些的影响等等 -
第三方约束和风险：比如已经签了合同的，有截止时间要求的，比如一些严格的技术风险，或者稳定性的问题等等
基于以上这些我们有了一个对事情的判断，但是当这些事情过滤后对于一个管理者来说，还需要做的一个重要性的判断是资源。
资源是最后一个项，是一个相对后期的项，看我们在人力、时间，财务资源上投入多少，这个是过程态中我们要持续看的，根据这些来看我们个人和团队的精力如何分配等。资源需求较大的事项，即使重要性较高，也可能因为资源的限制而需要降低优先级。
在明确了事项的优先级后，下一步就是更快的上线了，更快的上线从研发管理的角度可以分为三个层面，研发流程、工程系统、团队协作和沟通。
-
研发流程：
-
精简流程：优化开发到上线的流程，减少不必要的步骤，以加快从需求到部署的时间。可以有一个系统来看每个流程阶段的时间花费，如果没有系统用表格顶一下也行。具体落地指标可以看平均需求交付周期、每流程交付时间等 -
敏捷实践：采用敏捷方法论，如 Scrum 或 Kanban，以小批量、快速迭代的方式推进项目。在实际落地过程中可以以需求吞吐量、平均需求交付周期、每需求人力成本等。
-
-
工程系统：
-
系统工程化建设：投资于自动化测试、持续集成（CI）、持续部署（CD）等工程系统，以提高开发和部署效率。 -
技术架构优化：根据业务需求，对技术架构进行持续优化，确保其支持快速增长和变化，并降低长期维护成本。
-
-
团队协作和沟通：
-
跨部门协作：促进开发、运维、产品和其他相关部门之间的沟通，确保需求的快速流转和问题的及时解决。 -
沟通机制：建立高效的沟通机制，包括定期会议、即时通讯工具和项目管理软件，确保信息流通畅通。 -
团队授权：赋予团队更大的决策权，使得团队能够快速作出决策，而不必每一项都上报等待批准。
-
以上是业务价值，将具有更大价值的业务需求更快的上线是核心逻辑。
提高技术价值
对于技术价值而言，逻辑略有不同，技术价值在将更大价值的技术更快的上线的基础上， 需要坚定不移的持续投入和有规划的稳步建设。
持续投入是指在资源方面，特别是人力资源方面，需要在业务需求紧张的情况下保障技术需求的投入资源占比。
有规划的稳定建设是指在保障系统稳定的前提下，有规划的对技术架构进行优化，明确技术发展路线图，按照既定的规划逐步实施技术改造和优化，确保每一步都有明确的目标和时间表。
提高有效时间内的价值
从公式二：单位有效时间内产出的价值 × 有效时间 来看，要提高研发价值，需要提高单位有效时间内产出的价值以及提升有效时间。那么如何提高单位有效时间内产出的价值？
一个是从业务层面，将具有更大价值的业务需求更快的上线，另一个从人的层面，提高单兵能力，因为研发最终是要落在人身上，强化单兵能力，对于提升整个团队的有效时间内的产出有极大地促进作用，单兵能力的高低能决定团队总体效能的高低。
至于提升有效时间，从研发管理角度来看一个是以机制形式保障研发的开发投入时间，如研发静默时间，在静默时间不允许插入非写代码相关的事项；
另一方面是以目标为导向，推动团队集中精力专注于某个目标的达成，如小黑屋之类的，当然，其本质上是延长工作时间，也就在一定程度上提升了有效时间，此法慎用，除非文化本来如此，能留下来的是能接受这种文化的人。
以上是攻的角度，也就是提高产出价值来思考，从守的角度来看，更多提就是减少成本，这里主要是减少非正常成本。
减少非正常成本
非正常成本是指在生产和运营过程中由于管理不善、技术失败、人为疏忽或外部因素导致的超出正常开支的成本。这些成本通常不是生产或提供服务的必需开支，而是由于各种非计划事件造成的损失，可以以某种方式减少或规避。
这里的非正常成本我的理解包括以下的部分：
1. 项目延期和需求变更
项目延期和需求变更会导致增加额外的人力成本，延迟了需求的上线时间，可能导致业务损失或风险发生。我们一般可以通过更精细的项目管理来减少延期，通过正式的变更控制流程，评估变更的必要性和影响，以控制变更带来的成本。
2. 技术难题
当在项目过程中遇到了预料之外的技术挑战和难题，可能会导致项目停滞，以至研发团队无法按时完成项目，需要额外的研发投入或影响产品需求计划等。
我们一般在项目开始前对技术难题进行充分调研和风险评估，如果是在项目中遇到了，快速协调资源解决，甚至是请外部的专家来解决，从内部来看，提升现有团队人才梯队，提升团队成员能力，让成为技术难题的项越来越少是更优的解决方案。
3. 产品缺陷
产品缺陷我们通常称之为线上 BUG，当一个线上 BUG 出现后就会有一个流程串起一批人来解决，这个成本比在更前置的开发阶段或测试阶段发现并解决的成本更高，甚至会影响到用户的使用和口碑。
我们一般是通过代码审核、自动化测试、生死用例、showcase 等各种流程和机制来保障和提升产品的质量，同时对于已经出现的问题，使用缺陷管理系统，确保所有缺陷被记录、跟踪并及时处理。
4. 过度设计
过度设计是指在开发过程中投入的工作远超过解决问题所需的程度，这通常体现在过于复杂的系统设计、不必要的功能，或过早优化的代码上。涉及到开发、维护和产品质量三方面，这种过度设计会导致更多的开发和测试时间，更复杂的维护工作，以及可能降低的产品质量。
在设计时尽量遵循 KISS（Keep It Simple, Stupid） 原则 ，避免不必要的复杂性。
5. 历史债务
技术债务是指由于短期内的快速开发和决策，而在长期内需要支付的额外工作。例如，为了赶项目进度，团队可能会选择快速但不完美的解决方案，而不是花费更多时间来寻找更好的解决方案。
为了解决技术债务，可能需要进行代码重构或重新设计系统，这将带来额外的开发和测试时间。此外，技术债务可能会降低开发团队的生产力，例如，如果代码质量低，团队可能需要花费更多的时间来理解代码、修复错误和添加新功能。
我们一般是要将历史债务管理起来，识别和记录技术债务，并制定计划逐步解决，同时在新项目中避免产生新的技术债务。
6. 线上故障
线上事故对于任何技术团队来说都是一种非常严重的非正常成本。
这类事故可能会对用户产生直接的影响，包括用户体验降低、数据丢失、服务中断等。这不仅可能导致用户对产品或服务的信心降低，甚至可能导致用户流失。此外，严重的时候，线上事故还会导致公司的资产损失。
为此，我们需要建立全面的监控系统，及时发现并响应线上故障，同时制定灾备计划和故障恢复策略，以减少故障影响，并对每次故障进行事后分析，总结教训并采取预防措施避免未来的重复。
在我们的研发过程中，持续的减少以上的非正常成本是提升整体研发价值的守的逻辑。
除此之外，我们还需要考虑整体系统的复杂度，用持续优化对抗世界的不确定性。
康康说：老板要的无非是「人少活好效率高」
换句话说是成本低质量高产出多，而质量高也是为了成本低，只不过和人少的成本相比是不一样的成本。
老板看的还是 ROI