探讨政企信息化建设的需求变化、实施单位的响应策略现状及建议，分析政企单位信息化建设思想的演变，以及在信息化技术快速发展的背景下，如何构建合理的项目团队，进行技术迭代和业务系统迭代。
账号虽很早就注册了，但博客却没写过，很多时候是想写写但却不知从何下手，近端时间领导让整理下关于开发型项目实施的想法，在此，将整理的内容存放此一份，也算是一个备份。
目录
本文是在个人有限的知识、思路、能力等基础上对目前信息化企业对软件类项目实施和持续发展的一点想法，其中可能出现观点错误、思路偏移、想法天真等等，敬请批评指正。
从上世纪到现在，信息化从开始蜗牛般速度蹒跚前行，到今日日新月异般的极速发展，可以说类目繁多的新技术、新产品在一日间出现与发布。
从个人对国内信息化企业的了解，国内信息化发展大体分为三个层次：互联网企业信息化、传统的信息化企业的信息化、政企单位的信息化。
互联网企业，也包括部分新兴的小微科技企业，典型的如BATJ、华为等，是国内信息化发展的领头羊，主要从企业本身产品信息化发展为基点，基于世界开源产品为基础横向发展综合业务，逐步构建企业内部的信息化产品体系，推向市场并为其他企业单位提供基础信息化服务，客户是世间的人类个体或企业；
传统的信息化企业，以互联网企业产品、开源产品结合的方式发展企业的信息化技术水平，主要是从事传统信息化建设的企业，多以项目为起点，逐步迭代出行业产品，或通过项目的短平快维持企业本身的发展，客户主要是国家政企单位，承建国家政企单位软硬件信息化建设项目，也是国家政企单位信息化建设的重要力量，典型的如国内的中软、东软、东华等。
国家政企单位，主要是国家单位、国营企业、事业单位或国有独资的公司等。为了单位信息化建设和发展，单位内成立科技部门，也会成立国有独资的科技公司或三产形式的科技公司，信息化技术水平处于最低层次。国家政企单位通过单位内的国有独资的科技公司或三产形式的科技公司对本单位的信息化发展进行规划、设计、建设。然而，结合国家政企单位的信息化技术水平的实际情况，一般会将信息化项目建设任务移交给国内独资的科技公司或三产形式的科技公司，这些科技公司依据信息化建设的简繁难易程度选择自建、或与传统的信息化企业进行外包或合作等模式开展。
综上，就信息化技术发展水平而言，互联网企业 > 传统的信息化企业 > 国家政企单位依次减弱。
从上世纪末信息化发展开始说起，开发语言主要有VB、C、C++、Java、汇编、Dephi、PB、C#等，信息化系统以C/S架构、单点应用居多。瀑布模型、手工编码、人工手工测试、LoadRunner压测结合方式开展系统建设实施，版本管理有VSS、SVN、SubVersion。以政企项目为例，一个数据库、N个客户端应用支撑起整个业务系统，后续增加了数据库的负载、异地备份等。
本世纪初，B/S架构信息化系统逐步增多，项目建设也从传统的瀑布模型向螺旋迭代模型发展，期间敏捷开发思想（测试驱动、小步迭代、结对编程等等）也开始盛行和落地实践，但直到近两年DevOps思想出现，结合敏捷开源产品（如：Scrum），得以将项目管理、敏捷开发、代码管理、测试、持续集成、持续交付等集成到一起。
近十年内，信息化系统涉及的各方面都在独自的迭代发展，版本管理出现了去中心化的Git，测试出现了自动化测试、移动应用测试、界面型应用测试等，Java方面技术产品在解决实际开发中的问题中也从早期Servlet、Spring、Struts1、ibatis、Hibernate、ESB迭代发展到Struts2、SpringMVC、MyBatis、SpringBoot、SpringCloud等。
上述仅仅对上世纪末本世纪初的信息化发展极其简单的一个描述，描述的不细也不全面，如：终端（移动端、TV、智能设备等）、大数据、物联网、云计算、区块链、自动化、包括前后端模板引擎、代码生成器等等都未提及到。
总之，信息化技术在快读地向更加智能、更加综合、更加全面的方向发展，无论最终产品、最终用户，还是软件开发过程中的开发、测试、实施等。
政企信息化随着信息化技术的综合发展，尤其互联网的快速发展，政企信息化发展需求和建设思想也在发生着变化。
起初，各单位为了提高本单位的信息化发展和建设，各自为政，独自建设，琳琅满目的政企信息化系统落地生根，无规划、无标准、无共享等等，后称之为“烟囱式”建设。
之后，为了规范标准、数据共享、统筹管理等，各行业国家政企单位开始统一规划，进行集中式系统建设。由国家统建，地方实施。此时主要是实现单一系统的统一建设，采用单一系统+分级数据库形式，数据库为1+N模式，一个国家中心数据库、N个区域中心数据库，数据库中数据进行定时同步。
当前，任何国家政企单位从国家到地方的逐级单位内，都存在着很多的业务系统，诸多业务系统间大多是无通信、无共享（虽然通过ESB+WebService可以实现业务系统间数据共享，但WebService的开发比目前微服务较为复杂和麻烦，同时政企单位并未对所有的业务系统链接到ESB），每个系统独立登录，独立使用，如此，业务系统越多，单位内具体的系统使用人员的工作强度就越大，同时因其他业务系统的数据无共享而无法获取，不得不人为地将不同业务的分析情况综合一起，进行人工关联和分析。为了解决现状，统一门户、统一认证、单点登录、统一平台等等越来越多地被政企单位提上日程，结合目前大数据、云计算、物联网等等互联网的发展，政企单位对系统的使用易用性、兼容性、容错性、自动化、智能化等也提出了更高的要求，同时建设需求越来越多，需求变化越来越快，比如：单位内不同业务关联针对不用维度、不同深度、不同颗粒度的分析研究，有时也会出现无法预测的分析需求。
政企单位项目实施单位通常为中标的民营企业，包括本单位的三产公司。更多时候是本单位三产公司和传统的信息化企业合作实施模式，部分是传统的信息化企业或本单位的三产公司独立实施模式。
在项目实施中，由于信息化技术能力上通常是本单位的独资科技公司比本单位的三产公司弱，三产公司比传统的信息化企业弱，传统的信息化企业比互联网公司弱，于是，在具体实施中会出现本单位的三产公司外包给传统的信息化企业，传统的信息化企业或自己开发、或外包给互联网小微企业、或和互联网小微企业共同开发，在逐层的外包或合作过程中，传统的信息化企业和互联网小微企业从中获取的利润微薄。为什么传统的信息化企业获利微薄呢？因为传统的信息化企业在不具备开发型项目实施中核心技术时则会外包至互联网小微企业，部分时候翻被互联网小微企业以核心技术抬高外包总价，传统的信息化企业中间利差就很小了，进而会出现传统的信息化企业项目很多但利润很少。
针对传统的信息化企业，部分项目在实施中迭代出了相关的产品，进而以单一产品抢占市场；部分项目在实施中无提炼迭代，后续类似项目中基本从零开始，进而项目维持在微薄利润，甚至亏损情况。其中的原由个人认为有：
- 政企单位的信息化建设思想受到互联网发展的侵染，对信息化建设的业务要求和技术要求越来越难、越来越高。
- 传统的信息化企业在无持续的技术积累、迭代的情况下逐步无法满足政企单位的信息化建设的要求，无奈只能团队疲于应对或和互联网小微企业合作。
- 政企单位的信息化建设跟随国家发展规划的步伐，时间紧任务重，在具体信息化建设中传统的信息化企业无成熟或相对成熟的技术模型时会疲于奔命式地堆砌出一个无规划无架构无设计的信息系统，但内部却杂乱而不稳固。
如此也就无从进行所谓的提炼迭代，进而演变出恶性循环。
面对如此困境，个人的一点建议是：
- 构建结构合理的项目团队（仅指开发团队）：核心成员、骨干成员、普通成员。
- 核心成员：
- 主要有经验丰富、技术能力强的人员组成。
- 骨干成员：
- 主要是有一定经验、技术能力较强、业务理解能力强的人员组成。
- 普通成员：
- 主要是有一点经验或无经验、技术能力一般的人员组成。
2.统筹规划、合理分工
- 核心成员：
- 主要协助项目经理、需求调研人员等进行业务架构、技术架构、底层技术编码，不涉及具体的业务实现。
- 具体完成项目技术选型、系统主体架构、支撑业务流转的基础架构的实现，包括公共、通用型的功能抽取封装等。
- 骨干成员：
- 主要基于核心成员的技术架构、业务架构、底层封装的服务进行主要业务实现。
- 具体完成项目核心、主要业务的编码实现。
- 普通成员：
- 主要骨干成员的主要业务代码，实现简单的业务功能。
- 具体完成简单业务功能的实现，可能是使用代码生成器、基于底层封装好的功能包进行简要功能开发。
3.技术迭代、逐级提升
项目团队各成员保持持续性地成长是对项目实施最好的技术保障，如何保障团队成员的持续性地成长，需要明确各层级成员的目标和成长内容，包括分配对应的时间。个人建议如下：
- 核心成员：
- 成长目标：提升自身业务、技术架构能力，知识广度和深度、思考力，眼界等。
- 提升源：开源项目源码研究、书籍、视频、技术论坛或社区、技术线上或线下活动等。
- 提升方式：自学，部分可以报学习班等。通常如果涉及到的技术较为前沿则无相关学习班而只能自学。
- 骨干成员：
- 成长目标：核心成员所具备的能力。
- 提升源：书籍、视频、核心成员开发的项目架构。
- 提升方式：自学，项目组内训等。
- 普通成员：
- 成长目标：骨干成员所具备的能力。
- 提升源：书籍、视频、骨干成员的主要业务模块设计和实现。
- 提升方式：自学、项目组内训等。
4.业务系统迭代
在项目实施中，对业务系统持续迭代，提取不同行业间通用的公共模块、同行业内通过的公共模块，为后续项目提供更多的复用。
以上是仅仅是个人的一点不成熟的认识和思考，错误或不足之处敬请批评指正。
扫一扫
18
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
