序
这本书拿到了第21届的Jolt大奖，相当于软件设计的书籍届最有分量的奖项。不过，这几年由于经费问题，奖项取消了，也已经不再评选有分量的计算机书籍了。
灯塔的作用在于照亮前路，它的存在大家习以为常，可是有一天它不再发光的时候，黑漆漆的前路，不由得让人心生迷茫。
这本书呆在我书柜里不止5年了，我很惭愧。Better late than never。我还是很认真的看完这本好书，这是一本软件工程类的书籍，讲的是一种叫做持续交付的过程模式，它的最大好处就在于把开发、交付与运维有机的结合在一起了。
甲方是干什么的
前些天，一张幽默的贴图火遍了朋友圈。这个漫画，无疑就是我做甲方的工作写照，不晓得大家笑过之后，又进一步去思考，到底出了什么问题？
第一张图，我们的身份是甲方，嗯，没错。
第三张图，东西什么时候要，也没错，现在要。或许有人会说，你看，这么说不科学吧，我承认，的确不太科学，但是它合理！
一共三张图的连幅漫画，能出问题的只有第二张。甲方说，我们要什么，可是下面回答不知道！我想这就是我认为当下信息化行业最大的问题所在，需求工程做的一塌糊涂！作为厂家，竟然没有能力完成需求调研，并作出一个合理的需求文档，这难道不是问题吗？
大部分的厂家竟然装傻说不知道给架构设计看的需求文档和给用户看的需求文档是不一样的，更甚者，连文档编撰人，修改日期与版本，在提交文档的时候都没有出现的。
大家都不高兴
如果说隔行如隔山难以理解我说的话，我打一个更容易懂的比方，装修。我家要装修，我有一个预算，请了一个装修队，让他装修成北欧风格的样子，首先这个装修队得知道北欧风格是什么风格，有什么元素，在卧室，大厅，厨房有什么用的范例，然后根据我家的情况，出一个效果图，大家同意就开始干。
现在呢，这个装修队说，北欧风格我知道，请问要插座么？要布线么？你说要啊，这这这都要，他就立马干，可是忽然发现要拉网线了，又挖开暗槽，时间过了一个月，发现灯可以亮，插座也通电了，他就说可以验收了吧？WTF，这就是你交货的北欧风格，那个灯是北欧范的么，我落地灯放哪？那个海螺型材塑钢窗，怎么个北欧风，于是他说，老板这不是你说要的吗？可我们也干了一个月的活啊。灯也不是不能亮，电也通了，你凑活用啦。
这就是做什么却不知道的厂家，一而再再而三接到项目，然后又一再再而三交付给用户的情况，导致搞信息化的人三天两头要去救火，解决系统故障，用系统的人抱怨连连，花了这么多钱，效果怎么如此的差？不然，你看看你身边各种需要你使用公共服务时候需要打开的app与系统，看看有哪一个你是满意的？从医院的挂号系统，到办理出入境的公安系统，到查个公积金、社保金，你是满意的多还是不满意的多。
到底甲方是干什么的？
这个问题，我还真的想了很久。以前我们说，甲方就是市场里买菜的，看到哪家满意就一手给钱一手交货。在信息化项目中，尤其是在广州的信息化项目管理规定与财政制度管理规定下的甲方到底是怎么样的？我现在总结一下：
- 用钱必须立项做计划，支付必须合乎规定，尤其是合同与财政管理的规定；
- 信息化项目必须要有监理，按照广州的要求完成各种过程文档，不过这种角色只是走个过场，根本不发挥作用。
- 负责配合厂家整理需求，把关技术路线与设计架构，控制项目的时间与资金风险，配合实施系统与上线，完成系统验收，负责系统运维
前两条，是所有单位的人都必须遵循的必须按照财政的规定来用钱，以及按照业务的指导单位下发的规定工作。但是第三条，就是各个业务部门工作人员需要的独有的业务能力。
如果只看第三的话，这个项目的甲方，还是真的是去市场买菜，看好了就买，定下来就送货上门折磨简单吗？从软件工程的角度来说，这样的甲方，与厂家的项目经理与产品经理的重合度有多高？
最后我想问，如果想做好这份工作还需要什么样的业务能力？不能因为我们是甲方，我们可以推卸责任说，我们技术不行，开发能力不行，所以厂家说什么就是什么。
业务能力
在国内，在政府机关做信息化是个很边缘的角色。
- 业务部门觉得，你们就是修修机器，搞搞网络的，其他你们什么都不懂。
- 厂家的开发工程师觉得，你们就是没水平，有水平能开发架构的人才，早tmd都去企业干了，怎么会呆在这个工资卑微的岗位上。
不过，我不是这么认为的！
现在的工作，哪有不用信息化的，信息化做得越好，表现出的业务能力就越出色，而且往后会越来越重要！最近国家推出政策说，从小开始培训AI小能手，于此我只能冷笑一声，然后看看有没有办培训班的可能。
甲方不是市场上买菜的大爷
我认为，政府机关的甲方角色，绝不是市场上买菜的大爷，而是饭店里掌勺的大厨，市场采购回来后还要加工端给业务部门（顾客），顾客说好还是好。
从另外一个角度来看，政府机关的信息化与互联网行业非常的相似，面对着用户总多的需求，采购也好，自主研发也好，系统上线绝不是为信息化工作画上句号，而是信息化运维工作的开始，能够如何服务好系统上线后的各个用户，就称为了本阶段最重要的部分。然而，大家并没有明确的意识到这个情况，偏低的运维经费，救火一般的扎在系统的各个BUG中，根本没有足够的时间去了解业务部门的想法，进而对系统如何挺高业务的工作效率提出更多合理的改进。
这就是持续交付！术语就是DevOps。简单的解释，就是系统不断的都在建设与运维的过程中，面对来自业务最新的需求，能够安全与保质保量的在最短的时间内上线。而不是面对来自开发商总多的推诿：
- 这个架构不支持
- 这个功能需要重新设计
- 之前没说，现在设计起来费用很大
即便开发商阳奉阴违的拍拍胸脯说，你说的话我懂的，我让他们夜以继日的加班，最后给你一个不太可用的版本，最后还说“这不是你说的吗？”
我受够了这样的日子，从当前开始，我决定，从我接手的项目开始，全面实施持续集成，重新调整一套符合政府机关行业信息化现状，并且可落地的软件开发与运维过程模式。
2+3的新体系
基于持续集成的政府机关软件开发的成熟度模型体系，这是我对这个工作的学术定义吧。犹记得学IT软件项目管理那一会，懵懂的知道，用了很多办法项目的成功率也就从20%几升到40%几，不能有一劳永逸的妙招。以前不懂什么是项目干系人，嗯，现在我懂了，因为我就是啊。
两个平台
基于支撑业务系统的技术体系平台与基于项目管理的技术体系平台
基于支撑业务系统的技术体系平台：采用开源的框架架构起用户认证、数据库管理、统一文件管理、日志管理与微服务管理。
开发语言仅限于：java、.Net、Python、C++、PHP基于项目管理的技术体系平台（DevOps）：采用Docker的虚拟化技术来作为基础，完成配置管理（项目和各种配置），自动化测试技术（上线标准测试脚本），项目的过程文档的管理（方便运维与成熟度评分）。
一套DEVOPS闭环流程
立项：完成系统模型的定义（内容发布系统，实时聊天系统，工作流及协同工作系统等等），可参考的几个开源系统（通过向业务部门部署开源系统测试并探索用户需求），完成政务信息化系统UI设计标准
采购：通过在招投标方案中写明系统模型及模型规范、开源模型方案（体系必须选择其中一种）、用户需求搜集确认规范、政务信息化系统UI设计标准、项目管理奖惩制度、信息化的日志规范、代码开发规范、系统安全规范、系统备份策略与规范
实施：合同签订后，采用场景式用户需求探索并为每一个需求进行用户确认，确定持续集成的第一原初版本，如果系统后台一律采用docker的方式来交付与部署，所有的项目环节都用项目管理系统记录
验收：聘请第三验收测评公司来做验收测试与符合性验收测试，撰写测试脚本，如果第一次测试不通过，后续重新测评的费用由厂家支付；必须提交源码以及开发调试集成环境；必须提交一键安装包
运维：接入系统运维的大平台，交由年度运维集成公司来做日常的服务器与定期的脚本运行测试，及时发现服务器的风险点与测试脚本对应的系统风险点。
一个关键技术：采用过程清单管理
对不同的系统模型，采用针对本模型的功能点验收清单，清单上有未完成的工作，不能进入下一个步骤。
一个反馈沟通机制：构建成熟度模型为项目与厂家评分
项目分阶段对开发商的开发能力与系统能力进行评分，定期与兄弟单位共享成熟度与评分结果，构建软件开发的白名单与黑名单。
结语
千里之行，始于足下。一切需要我们努力的事情，都有一个不容易的开始，但愿这个苦扰了我好些年的事情，能够在今后的5年里有所改善，看来容易，落地难，要能形成长效机制更难。