编辑导语：在日常生活中，我们往往会接触到一些大中型系统，虽然其使用频率较低，但是却与我们的生活息息相关。那么，对于产品经理来说，这样的大中型系统应该如何去构建呢？本文作者结合实际工作经验，以电力系统为例，为我们总结了最基础的、需要掌握的要素都有哪些，并且对于大中型系统构建中所涉及的各个流程和工作配合进行了阐述。
在我们使用的互联网产品中，除了日常使用较多的电商、支付、娱乐等产品外，还有一部分产品给我们提供日常服务的产品，比较常见：电力、燃气、社保、12360等相关政府提供服务的基础系统。
这些系统日常中使用频率很低，如果需要使用也是通过支付宝或者微信提供第三方入口可以直接进入，完成自己需要办理业务和服务。虽然其使用率低，但是作为国民经济发展一部分是不可或缺的。
本文将以电力系统为例，主要为电力指挥系统、电能质量配电系统等（具体可查看百度百科解释），在对于这种大中型系统构建中所涉及的需求、项目、开发、人员配置等互相交流学，主要是面向内部系统，文章中不会有任何资料透露。
首先：从项目的组成人员角色来开始，每个名称根据不同项目组会有不同、一些会叫做需求、业务、或者是产品，但是不管叫什么名称，工作的基本内容一样，就是需求收集进行整理。同时产出相关的需求方案，开会沟通和相关人员不断进行细节方面沟通，并且组织需求评审，跟踪一下对应的项目进度。
当然，项目组如果有项目经理这部分就可以交给项目经理了，自己则能全部负责产品层面的工作，像是产品基础的细节像是需求评审、收集需求、出需求方案等将不在这里展开。
接着简单说一下对于大中型项目的人员会根据不同的小组进行配置，一个项目可能四五十个小组进行负责，不同小组开发、测试、产品、项目经理、这是人员标准配置。
其次：公用人员角色就是UI设计，他们是单独的部门人一般也不会很多，像是运营、风控、审计、安全等这些都会根据不同的项目组进行统一配置。
还有一部分人员第三方提供服务的人员，如果项目涉及硬件部分每一个厂会有一个对应的负责人，他们也是必不可少的，那么简单的人员就是这些，整体的人员配置情况需要根据不同项目组进行编制。
最后：很多人不怎么喜欢的沟通、开会，日常不是开会就是在开会的路上。一天早上九十点开始到晚上七八点中，会议不断，各种会议需要进行参与，不参与你可能后面就不知道进度。
也许有一天突然找你要东西而你不知道情况，为了更好的避坑，所以开会还是要参与，主要会集中在项目的开始，工作日一般是前三天，密集的会议会不间断。
这里就是考察产品经理对于项目的紧急程度、合理性等安排统筹，将自己手头上面事情能够在最短时间内进行整理并且安排到具体实施人员，主要的就是开发人员，提前安排会保证产品的人身安全，不然后面突击给开发任务，他们会原地爆炸。
大中型系统的涉及人员多、涉及业务复杂，所以开始前将对应人员和负责业务进行熟悉就好，但是也需要准备好对应的人员临时更换人员，换一个小白，同时加上自己也是个小白，对于工作就不好推进，要尽量避免这种情况。
万一遇上这种情况，那么只能自己快速熟悉业务，对于人员众多的大中型项目需要很多项目组进行配合，需要注意不同项目组之间可能对于系统会有交集。这时候需要提前沟通好负责任务，最好是对应功能细化，不然后面就是和稀泥，搞得这个项目进度延迟，很糟糕。
接着对不熟悉大中型项目，需要快速的了解一些专业名词，整个项目有一些通用的名词，这些名词第一次听到就需要了解，不然就像听到加密的电报一样。有些可能是专业名词缩写，有些是整个系统中人员默认的简称，不管是哪种，只要是听到你想不明白就问相关人员词语解释，这样会保证你能听懂项目组在说什么。
同时专业性较强的大中型项目需要去了解相关业务的逻辑，这些业务逻辑和市场上的业务完全不一样，之前积累的互联网经验换到这种传统大中型系统中一点用处没有，这就需要有一定学习能力。
以上就是构建大中型系统最基础的、需要掌握的要素，简单总结就是：
- 专业名词需要了解
- 多和不同项目组人员沟通
- 开会要积极参与
- 和开发沟通要到位
- 任务安排要细
这些都是产品或者需求基本具备能力和水平，介绍完了项目组和人员的情况接下就是大中型系统的介绍。
一、多个系统组合
一个大中型系统可能拆分N多系统同时由多个系统进行组合，可见政企在便民服务中投入是不低的。
如果只是单纯的了解一个系统是远远不够，需要同时了解三个或者五个系统，这些系统也一样都是大中型系统，可能A系统中a功能和B系统中d功能之间有着联系，也有可能数据是一样或者数据库表相互关联，后期需求会面临的是需要构建一个F系统，需要在已有的大中型系统进行拆分组合。
这样就需要产品或者需求对于其他系统有一定了解，做好前期准备的工作，在项目开始时面对问题会有一定的了解，同时对于开发的提出问题能够有很好的应对之策。
大中型系统的复杂程度其实在与多个系统功能相互关联，多个功能穿插，其中最关键就是数据的问题，数据问题需要和不同的系统进行比对，不管是产品还是需求都会面临自己写sql校验数据准确性，以及对应的数据表结构要自己去了解。
这些问题如果自己当初设计的就需要在接到不合理的需求时尽可能设计的合理，如果不是自己进行设计就需要首先进行业务的了解和熟悉，进而对于数据库的表进行查看，保证开发有问题时能够及时解决，因为开发会是临时抽调过来，他们不了解具体业务和数据，这些需要产品和需求自己进行了解。
二、业务层级功能深
大中型系统在构建时候因涉及的人员较多、业务复杂会构建很深的层级，在每一个层级功能下面会挂着七八个相关子功能系统，同时这些子系统中数据来源会是其他几个系统数据库中提取数据。
对于这种层级很深的情况，就不要去看任何需求文档和测试环境系统，最好是正式环境和测试一起看，同时需要相关开发人员多沟通，整理自己在使用中遇到的问题和不明白的地方，集中时间进行沟通。
很多细小的功能在大功能模块下起到主要作用，同时这种功能会是很常用功能，有一些功能使用频率不会很高，往往是这些不高的功能后期会展开二期、三期等。
对于大中型系统来说，实用性是较为关注的，相对UI界面设计这些则是关注点较低，这就是为什么会在一个菜单下面挂着七八个子功能，同时扩展会在子功能中不定期修改、增加、删除字段信息。
可能一个功能中的表单会在不同版本中出现好几个，乍一看已经改变了，能够加个字段解决问题就不会让需求或者是产品在业务层面修改，这也是开发和产品共同默认的默契。
三、庞大的架构
大中型系统会由三个和五个系统构成，所以整体架构是一部分，单个系统架构是一部分，这两部分架构构成一个整体系统。
不管是后期的维护还是开始新构建，都需要将这两个架构整理明白，搞清楚业务的整体方向，这也是前期比较耗费精力的部分，需要不断进行调整和沟通，需求方案调整次数会多。在整体架构中经过已经报备之后后期不会进行改动，在功能上面也需要根据相关资料贴合。
大中型系统会有两种存在：一种是完全新开始构建；另一种是已经整体已经完成构建。
先来说新开始构建，需要在较短时间内将整体业务的系统部署到测试环境，同时进行演示，这里会在演示环节进行修改和增加不少，很多大型项目就是从一个测试环境demo开始往里增加功能需求，修改之前的需求进行构建，这里不过多解释相信很多有经验产品自然会懂。
另一种已经存在就是从前面的描述开始进行后半部分，那就是不断的修改和调整功能，增加大功能模块和小功能模块需要根据这个已经改过不知道合不合适的架构上面进行扩展，所以对于整体架构进行整体重构基本上不会出现。
四、维护更新
维护和更新的主要重点则是数据部分，对于功能在业务层面没有大问题将基本上不会进行修改和更新。一个大中型项目在开始时就会分为简单两个步骤，第一步就是业务功能构建，第二部分就是数据。
在确定业务功能之后就会开始数据治理部分，后期对于每一个数据要达到一定的标准值，数据问题主要是新系统和老系统进行数据比对，在一定时间内数据没有误差，就可以完成项目的交付，但是还是要留一部分时间的过渡期。后期维护更新主要侧重点是数据治理部分，对于业务层面的修改调整基本上不会有很多。
构建大中型系统需要的前期准备基本上就是以上内容，下一篇文章将介绍具体实施部分。