业务驱动和快速迭代(8.1)

在前面几篇产品规划的文章里面已经谈到过，今年我们整体的产品研发将围绕微服务+DevOps来展开，而里面有两个重要的产品研发，一个就是DevOps支撑平台，一个就是API网关。整个两个产品构建完整的支撑微服务架构开发平台支撑体系。

即在传统企业IT架构转型过程中可以看到几个关键点的变化：

1. 传统的单体应用-》独立自治的多个微服务模块

2. 传统的PaaS平台+ESB服务总线基础-》DevOps+容器化PaaS+API网关

简单来说就是你要做好IT架构的微服务化，中台化转型，那么你支撑平台这件事情也得跟上，平台提供共性能力支撑和能力开放，支持多个微服务模块持续集成和交付。在后期监控运维还得配合DevOps理念跟上，形成要给完整的IT生命周期闭环管理。

在进行API网关和DevOps支撑平台研发的时候，自己一直在思考两个重点，就是业务驱动和快速迭代，即基于实际的业务使用场景来思考和提炼产品应该具备哪些功能，实际的功能优先级是如何的。而业务场景驱动里面最重要的就是最终的用户角色分析，不同的用户角色实际的问题和需求是如何的。

拿API网关来说，不论是SpringCLoud框架里面的Zuul微服务网关，还是类似Kong，Orange等开源API网关产品，最早可能只是一个具备代理和路由转发，具备基本的安全，流控能力的网关引擎，连基本的管理界面都没有，到现在类似Kong已经形成了基本的管理前台界面，能够方面的进行API注册接入，各类插件模块的配置和添加，但是最终的使用者是谁呢？

我们分析类似Kong网关产品最终的使用者是偏业务系统本身的开发人员的，而不是面向统一的业务系统集成商或平台能力提供商的。先不说类似我们当前集成平台实施中提供的各种服务接入，服务订购等自服务流程，就连最基本的业务系统视角的功能也很难独立提供。

即业务系统开发人员是没法上这个管理平台的，那么如果业务系统需要查看注册接入了哪些服务，配置了哪些规则，具体服务调用实例和日志信息的时候，都无法提供这些能力，都需要进行定制化开发。而恰好这些当前开源API网关产品的痛点，可能就是定制化要给API网关的管理平台产品的优点。

也就是说当前API网关产品更多是面向已有微服务架构体系内的API能力对外开放需求来做的，而不是基于微服务架构体系里面多个业务系统，开发厂商间接口协同思路来做的。因此要将API网关产品转变为一个具备多系统集成能力的集成类产品，中间还有很多工作要做。

还有，一个大的业务系统按微服务架构思路招标，比如一个供应链系统，招标的时候即按微服务模块划分思路拆分为了招投标管理，采购管理，供应商管理三个独立的技术标，后续三个开发商中标，每个开发商开发时候都采用微服务架构，比如招投标管理里面会继续拆分微多个微服务模块，而这个时候我们看到就存在两类接口集成问题，在实际协同上需要采用不同的集成策略来处理。

1. 招投标内部多个微服务组件间接口集成：同一厂商，采用服务注册和配置中心即可，不需要网关

2. 招投标和采购管理两个大子系统间集成：不同厂商，需要采用API网关来完成集成和协同

而这些就是实际我们面对的业务场景，集成场景需要这样来做，当你真正做到现场的实施项目的时候，这些关键需求自然会碰到。但是你如果完全是研发驱动，脱离市场和一线客户需求，那么最终产品将出现很多关键功能性缺失。

那么当你无法在前期通过需求调研或竞品分析各种方式采集到完整的用户需求，并整理为产品需求的时候，你需要考虑的就是基于敏捷开发思路下的产品快速迭代。

而快速迭代本身又有两个重点

1. 短周期：必须是短周期，1周到4周，短周期目的就是真正让进度可视，可见，可验证。

2. 可使用：可使用是一个关键点，即迭代发布的版本一定是可以发到现场让用户真正开始使用的版本。

任何迭代版本的发布，是否可用必须是一个关键的衡量敏捷项目管理和迭代质量的指标。举个例子来说，我们准备1个月发布V1.0初始迭代版本，但是发布后发现这个版本根本用不起来，我们又陆续发布了1.1，1.2，1.3三个小版本才真正用起来，而这三个小版本的发布可能又用了2个月的时间。也就是说你的产品真正用户开始使用，真正开始支撑业务用了3个月的时间。那么这种形式主义上的迭代没有任何意义。

通过迭代的方式是让你进一步的收集需求和优化改进，但是一定不是关键需求就缺失导致产品根本无法使用。如果一个迭代版本无法使用，那么发布到现场本身也没有任何意义。

冠以敏捷而抛弃过程并导致混乱，太强调沟通而无法基础工件交付，开起来很美好的短周期产品发布但是却是一个无法真正用起来的半成品，这些都是伪敏捷的自欺欺人做法。