【架构优化过程思考】如何降低隐性的资源投入

在软件的研发生命周期中，一部分工作是显性的，可以明确资源的投入；也有一部分工作是隐性，资源的投入是后知的不可明确的。

对于显性的资源投入，团队可达成共识，每位参与研发过程的人员基本上都要有在对应的节点投入精力。在时间的评估时较容易想到并提前预留时间而进行相关工作的开展，常见的如需求理解、方案设计及评审，规划及计划、研发及测试等工作。

对于隐性的资源投入，在团队中与具体的研发人员所处的业务方向，研发方式、流程规范、以及协同方式均有关。这部分的工作在研发的过程是被忽略掉的，是动态产生的，没有办法明确的工作。常见的如日常的目标对齐，沟通，协同，bug修复，汇报等工作。

对比显性的资源投入，隐性的资源投入存在着不确定性，这些不确性的工作的人力投入也是不确定的，在团队中也是没有符合大部人员的预期的。故这部分的资源投入，拿到一个明确的收益的成本就要高于显示的资源的投入。下面的内容中，我分别以目标对齐、沟通成本、协同依赖、研发质量、维护成本及向上汇报这六个节点中说一下涉及到的隐性的资源投入及转换为显性资源投入的方法。

• 目标对齐：目标的对齐过程同样也会存在隐性的资源投入，架构优化的过程是自顶向下的推进，目标容易达成统一。而当是同一个产品线中，业务方来推进内部的架构优化，对于横向的影响及支持或者需要获得团队高阶人员的支持，则需要较明确的理由把事情说清楚，并获得支持。这个过程并不投个需求，让对方实现这么简单。而是方案设计的合理性，问题修改的必要性，资源投入支持成本等等，这些信息在研发的早期均是需要进行评估的，大部分研发的工程师还没有养成这样的习惯，虽然相关的工作已经进行了评估，但是还处于被动对齐目标的状态，这时相关工作的资源投入，就是隐性的，没有公开的。而当把相关的信息进行公开及对齐，这部分的工作就变成了显性的。当架构优化的工作变为其它的研发类需求，目标对齐可公开同样也有着必要性。
• 沟通成本：沟通成本是研发过程中常见的成本之一，沟通是整个协同过程中必要的手段。每位研发人员的沟通方式也会有所不同，对于沟通的有效性也会产生影响。主要存在以下几个方面，第一沟通的目标不明确：不清楚沟通要形成什么样的结论，需要确定什么样的决策支持；第二沟通的内容准备不充分：沟通的过程准备的内容不足会导致沟通无效，需要再次确认相关事项发起新的沟通；第三没有找对人：典型的如关键决策人员没有参加沟通，相关人员也没有参加沟通，这就意味着关键信息的缺失。以上三点都会存在一次沟通无效的可能需要发起再次的沟通，同时当一位研发人员并行的事项较多，大部分是横向协同的工作。自然沟通的工作就会占用大部分的研发时间，这时研发人员应该考虑的是否为角色所应该承担的工作了。
• 协同依赖：协同是团队中常见的工作，在研发的过程当中存在同一个目标，由多个实现方共同完成的情况，实现方之间存在着先后的依赖，最终目标的完成是依赖于整个目标之中的所有节点的完成，缺一不可。对于研发人员来讲，负责的任务的研发，当有依赖协同方时，只有相关的任务都完成，所负责的事项才算是完成，这个过程因不确定的外因变化导致的资源投入是隐性的。而对于负责人角色的研发人员来讲，他对于协同方的资源的投入，完成时间和优先级都存在着不确定性，需要进行推与目标达成共识，虽说是关于资源的协同成本，同样也是隐性的资源投入，不确定的因素同样也会来自于内因。只有把内因的不确定性及外因的不确定性都明确了，最终的协同关系才有可能确定，按照预期完成相关的节点。
• 研发质量：研发质量同样也是隐性成本之一，在整个研发生命周期过程当中，个人投入的研发时间是有限的，当一位研发人员，把资源投入在修复质量的问题时，必然会降低在其他研发过程的节点的资源的投入。代码质量问题，主要分为两类

• 一类为线下的问题，线下问题是指在当期的功能需求迭代的过程之中，研发所产生的代码质量问题，这一类的问题主要在测试阶段产生，是被动的解决问题。被动解决问题的过程，当后续缺少跟进、总结及优化，超出行业的均值，同样也是隐性的资源的投入。
• 一类为线上的问题。线上问题是指版本迭代完成，产品交付给用户使用时出现了问题。这一类的问题需要占用当期正在研发的功能的时间进行修复。同样也是隐性的资源投入。

质量问题影响的因素较多，应该按照团队性的行为，或者是个人性的行为进行合理的分阶段的优化。

• 维护成本：分为两部分

• 自维护的代码：这维护的代码的印象成分，主要来自于两个方面一个方面没讲个有线条的架构合理性，另一方面为研发人员对于业务的理解程度。架构的合理性决定研发过程的代码的复杂程度，影响研发人员对于业务的理解程度，特别是对于新同学，当整体的架构不够合理，拆分的不够，模块之间的职责不清晰，这时业务的维护成本就会偏高，代码的修改成本和带来的风险就会变大。同样架构简单、模块的边界清晰、研发人员的理解成本就会降低、修改代码的过程影响范围就会降低，带来的风险也就会降低。
• 需要支持的代码：同一个业务，在不同的产品中（app）复用，复用的方案会影响长期的维护成本，既要考虑业务升级单次/长期同步的成本，也需要看升级适配/差异化定制的成本，同时也还有多产品线之间的沟通联调的成本。对于横向协同需要长期支持的代码研发，边界的界定是优先明确的工作，只有边界清晰了，才可进行协同方案的定制，以组件化、标准化的方式进行长期的协同，有效的规避因多条线并行目标不统一而带来的沟通、协同、技术支持、等隐性的资源投入。

• 向上汇报：严格地讲向上汇报的工作，应该算是显性的资源投入，资源的投入必然需要有收益及产出，在团队中整个团队的资源投入，产生的收益，必然要需要有一个向上汇报的渠道，进行资源的投入及收益的总结，明确资源投入的价值。例行性地向上汇应当算作显性的资源投入。而不确定时间周期、不确定汇报对象及不确定的汇报内容对于汇报内容的梳理者的确是工作量的叠加，也是隐性资源的投入，对于这部分的工作，应该做成例行化标准化，