把一个App作为一个整体来看,架构的优化会涉及到这个App当中的任意一个模块。优化的工作也必然涉及到了人力的问题和资源的协同。架构的优化工作在人力的安排上主要有两种方式,1)一种是有专门的团队来对接架构优化的工作,2)另外一种呢,是有几个人明确架构,优化方案和目标,推进在团队当中不同的方向进行落地。

  • 第一种方式通常使用专项的方式来推进架构的优化,在这个过程当中不同的角色都有相关的人员参与,并提前确认。 整个架构优化的过程当中,时间维度较短牵扯的精力较少,并且团队当中的相关人员对于目标比较一致。在推进的过程当中,相关资源的变化的概率较低,协统的成本相对要小一些。
  • 第二种方式也会以确定的目标去推进,与第一种方式的不同在于相关资源的投入是不确定的,时间节点也是在一定的范围内的。因为没有确定的资源的投入,对于架构优化的工作的人力与版本需求迭代中的人力存在优先级的问题。

研发人力投入充足,有可能存在测试的人力不足,测试的人力有支持也会存在研发人力不足的情况。最终这些人力资源的投入决定做哪些事情,还是看事情的重要和紧急的程度。即使是这个能力已经确认了,在某一个时间点上线也会因为高优的需求而停止。

这一部分的机制与团队的研发模式有一定的关系,不论基于在什么样的大背景下,架构优化的工作通常被定义为重要但不紧急。和正常的研发流程一样,该做的事情一样也不会少。 反而会因为架构优化的影响面,而需要多做一些额外的资源投入。

如果把参与产品需求迭代的研发和测试人员的工作调整,让他们来做技术架构的优化工作,那么对于流程和工作方式,有一些是不符合他们之前的工作习惯的,这些工作的内容需要提前确认并明确对应的时间。甚至需要帮他们去采集一些工作的详细内容,以确定每一个任务都是被认真的以架构的思维思考过。

举个例子,在需求迭代的过程当中,研发人员交付的是基于需求的实现功能,测试人员需要根据需求进行测试以确定研发人员交付的功能质量是否过关。 而架构的优化部分需求是影响该App中的大部分业务,架构的调整相关业务也会受到影响.

研发人员在确认架构优化的技术实现方案的同时,也需要确认不同的业务方基于技术架构优化方案之上的接入的方案,对于测试人员来说,回归的测试点就不限于某一个具体的业务线,而是基于本次架构的优化受影响的所有相关业务。

这些资源及时间节点的依赖是需要单独确认,以最终的依赖关系,与目标相关的角色,一同协调资源、时间及明确关键路径,这样才有可能架构优化的工作产出并符合预期,否则将会出现失控的情况。

或许你会想我是架构师,这件事情,我只要确定好技术方案就可以了。客观的来讲,如果你只负责这个技术方案的输出,那么这个技术方案能如期落地的可能性就会比较小。因为没有谁比你更了解这个整体的技术方案,也没有谁比你更清楚,哪个节点对于完成目标是起到了关键的作用。

只有把所有的任务拆解清楚并明确负责人,这一步骤完成了,资源和时间的节点也就基本上就确定了。架构优化的相关同学对于业务和架构需要的理解要优于其他同学,项目执行的过程中才有可能是有条理的。