业务交付、质量、架构他们之间的关系到底是什么？

        最近赶了一次研发规划，整体把一直以来做的事情总结了一下，做的好的、待改进的和将要建设的。匆忙进行交了作业，结果反馈也自己的预期比较一致，也是最近一直在思考的问题：建设项比较多，他们之间的关系是什么，改进项对产品和人员能力提升的支撑粒度如何？

        结合反馈和最近自己的思考，做了初步梳理：

1）业务的持续交付是重中之重，包含短期交付与长期交付；

2）研发改进的最终目的是：持续交付有价值的东西。持续-关注的是长期，交付是最终目的，有价值是最重要的方向指引。

3）在此基础之上，重点要是要聚焦于“人”，一切的一切都是人来完成的，人的成长、人的诉求、人的感受都要持续关注。

        之前把改进项按研发、架构、质量分开来划分，分人来跟踪改进，这样最大的问题就是不聚焦，单点的改进组合起来无法形成整体的能力提升。需要按照部门的重点任务来聚焦业务模块（或某项能力），来识别瓶颈问题，做模块级改进（或叫端到端改进）。

        再说一下质量，其实质量是衡量交付的最直接的标准，它无处不在。所以他会贯穿所有职能，某些专项可以单独质量团队承接，但更大的改进还是产品、开发、测试、自动化全职能共同建设的。所以还是要聚焦年度交付内容、端到端交付核心指标项来做系统改进。

        再聊聊架构，一般架构的演进及优化可以是由质量推到出来、也可以有交付能力来推到出来、也可以有技术驱动产品的思路来推到出来，不过对于成熟度未到量化级时，往往都是前两种。这样一来，在研发规划时，就会有一些切入点及重点的把控了。