1. 敏捷开发平台简介

红迅JSAAS敏捷开发平台是广州红迅软件有限公司面向合作伙伴以及有IT运维团队中大型企业提供新一代的企业级的数据IT一体化的业务管理平台工具，它基于流行的JAVA开源技术上构建，扩展容易，学习成本低，可快速构建企业的一体业务管理中心，即满足企业以下的管理需要。

1. 统一主数据管理

2. 统一业务单据管理

3. 统一业务流程管理

4. 统一组织架构管理

5. 统一数据门户

6. 统一数据移动审批

7. 统一数据报表管理

8. 统一业务运营管理

9. 统一知识文档

10. 统一对外协同

11. 统一对内协同

它将是您的企业在移动互联网下实现对企业的运营数据管控的得力助手。

适合应用场景

1. 需要打通内部各系统，实现内部统一业务审批如EIP系统

2. 建立全新的业务管理系统，如Oa，客户关系管理，合同管理，项目管理，成本控制管理

3. 需要与ERP打通进行所有业务单据的审批，如销售订单、采购订单、合同订单审批，
   同时可在移动端、微信单进行同步审批及消息推送。

4. 需要与用友NC、U8、U9、金蝶、顶捷等ERP进行数据单据整合，并且需要流程统一管控。

5. 需要类似零售行业，实现与内部业务与外部供应商信息联动业务协同处理

6. 需要实现类似政府公文的业务管理

7. 需要有一块快速自定义的平台框架适应企业或单位的业务变化

8. 需要构建企业内部的ERP系统

适合企业或单位

1. 已有团队，需要建立企业内部平台运营

2. 尚未有团队，需要全新建立企业IT运营团队

3. 有新的信息化系统需求，含中大型国企

4. 有开发小团队，尚未有成熟的开发平台

5. 有业务项目，需要快速交付

采用红迅快速开发平台，可保证企业类的系统信息化的项目可按时按质交付，保证可观收益。

快速开发平台包括：

2. 应用框架技术

红迅JSAAS敏捷开发平台采用流行Spring轻量级框架，并且结合大量成熟的开源框架，满足企业级的开发与运营的需要。

1. Spring Core核心容器

2. Spring  MVC 4

3. Spring AOP

4. Spring Security

5. Groovy动态脚本语言

6. MiniUI前端JS框架

7. Jquery javascrip库

8. JPA、MyBatis Or JDBC数据持久层框架

9. Maven版本控制

10. Log4j Java XML API

11. Scheduling Quartz定时任务

12. Alfresco Activiti 5

开源技术框架详细介绍

JSAAS平台框架使用开源技术汇总
后端框架
1	Spring基础框架	spring-security-core 3.2.3 RELEASE
2		spring-security-web
3		spring-webmvc 4.1.2 RELEASE
4		spring-jdbc 4.1.2 RELEASE
5		spring-core 4.1.2 RELEASE
6		spring-orm 4.1.2 RELEASE
7		spring-jms 4.1.2 RELEASE
8	ORM框架-Hibernate JPA	hibernate-entitymanager 4.3.6 Final/hibernate-jpa-2.1.api
9	ORM框架-MyBatis	mybatis-spring 1.2.2
10		mybatis 3.28
11	任务调度	quartz 2.2.2
12	消息管理	Apache Active MQ 5.10
13	流程引擎	activiti-engine 5.18
14		activiti-spring 5.18
15		activiti-modeler
16	Office文件读写POI	poi 3.10.1
17	报表引擎	Jasper Report 6.2
18	缓存读写	redis 2.9.0或memcached 1.5
19	JSON序列化	fastjson 1.2.32/json-lib 2.4
20	邮件引擎	javamail 1.4.4
21	XML读写	dom4j 1.6.1
22	模板引擎	freemark 2.3.18
23	JSP标签库	JSTL 1.2
24	规则与动态脚本引擎	groovy 2.3.0
25	日志库	log4j 1.2.15 slf4j 1.7.5
26	Http客户端	Httpclient
27	数据库连接池	druid 1.0.26
28	其他工具类	apache commons-dbuils 1.4 ,common-io 2.4,commons-lang 2.6等
前台库
1	JQuery	jquery-1.6.11
2	MiniUI组件	mini-ui 3.7
3	Ueditor	1.4.3
4	CodeMirror代码编辑器
5	echart	3.7.1
手机端
1	Vue 2.0x/YDUI Touch

 

3.业务功能定制与在线配置

平台提供简单易用的并且功能强大的代码生成器配合开发人员来进行功能开发，以保证用户基于平台上快速构建所需的功能。满足您在不同的业务场景下的数据展示与应用的开发需要，实现真正上的业务的运营需求。

3.1. 代码生成器生成多层架构代码

1. 支持不同层次的代码分层，让开发人员分工合作。

2. 支持对外配置化的Restful WebService的配置你化需要

3. 支持不同的数据库，如MySql,Oracle,SqlServer,Db2或国产的关系数据库

4. 支持多种不同的客户端，如PAD，PHONE，PC

3.2. 在线的主数据及单据维护管理

系统提供在线的主数据单据配置，用户可在平台上通过大量使用不同的组件及数据类型，可映射至系统平台中，实现对主数据的可视化配置及管理，如下所示，在线配置项目的基本信息及其维护管理界面，同时手机端与微信端同样也可以实现这些数据的查询与管理。

主数据维护管理

系统允许开发人员或业务管理人员实现对以上的多种主数据的管理，可配置以下系统功能：

1. 配置子系统

2. 配置菜单

3. 配置功能按钮

4. 配置打印报表

5. 配置移动端数据

6. 配置数据权限

7. 配置子系统、菜单、按钮的权限

3.3. 多种系统风格的支持

系统支持多种风格的子系统、菜单、功能列表的数据展示风格，可满足企业对UI的美观要求

高雅风格

平民风格

经典风格

3.4. 子系统与功能菜单在线配置

平台提供多个子系统统一集中管理，支持不同的功能面板配置，支持菜单下的功能按钮的配置与管理，让您的应用像积木一样，越建越好，并且越来越协同。

 

4.灵活组织架构管理

平台提供了灵活的组织架管理，可支持通过API直接从外部组织架构获得人员与部门数据来实现业务，也支持从其他组织架构源，如HR用户中心，AD或LDAP组织架构中心获得用户数据。JSAAS平台同时也提供了灵活强大的用户组织架构构建数据工具，可以满足企业的各种复杂的业务架构的运营需要。它通过组、用户、关系三大组织架构要素来支持组织的复杂运算。如默认中系统支持以下特性：

1. 系统支持不同类型的机构，如平台可以给企业内部组织，外部供应商，经销商组织协同使用。

2. 支持自定义的不同用户组，如部门、角色、岗位、职务、项目、销售区域等

3. 支持自定义用户的多种业务关系，如汇报、上下级、销售汇总关系等

4. 支持用户与组的多种关系定义：如主负责人，汇报关系人，部门领导等。

【组织架构管理】

角色授权

1. 平台提供全面的功能权限管理，包括访问页面、数据、资源权限，有效满足不同企业、单位对数据权限的不同要求。

2. 提供基于角色控制，可控制访问资源页面、功能按钮，过滤不同部门、不同分公司、不同组织的业务数据。

5. 业务单据管理

每个企业在运营过程中都会有不同的业务单据数据，需要进行录入、流转、归档、决策分析等。JSAAS敏捷开发平台是一个强大的单据管理平台中心，它提供了大量的可视化及编程式的工具，支持业务运营人员设计与部署满足企业运营需要的数据处理流程。

5.1.表单的可视化设计工具

表单的中的设计工具支持丰富的控件，可用于不同的应用场景下使用表单，支持可视化的工单配置，也支持编程式的工单配置管理。编程式的工单可保证能实现复杂的表单数据展示。 表单工具支持大量的常用数据展示控件，如：

• 支持的控件类型有：

• 文本控件

• 复选控件

• 复选列表控件

• 单选择列表控件

• 下拉列表控件

• 日期控件

• 月份控件

• 时间控件

• 编辑型按钮控件

• 按钮控件

• 自定义查级联查询控件

• 多行文本控件

• 富文件控件

• Office控件

• 下拉树控件

• 自定义查询对话框控件

• 用户选择控件

• 部门选择控件

• 组织架构选择控件

• 子表控件

• 图片上传控件

• 附件上传控件

• 组框控件

• 日期相减控件

• 金额大小转换控件

• 子表数据统计控件

• 条件展示的div

• 隐藏域字段控件

• 审批意见控件

• 审批历史展示控件

业务表单方案

通过绑定表单方案及对表单的数据处理，可提供灵活的在PC端与手机端展示的建单功能。如：

5.2.单据数据列表设计工具

平台提供强大的数据列表生成功能，可以实现数据的普通列表展示，导航分类列表展示，树型数据展示。业务人员仅需要学会SQL语法，通过以下单据数据列表的工具，配置数据源、列表展示的表头、查询的字段、功能按钮及表单代码编辑。通过配置完成后，其可以展示以下的功能界面：

工具配置过程：

1.自定义SQL定义数据

2. 自定表头

3.自定义功能按钮

4.自定义查询条件

5. 一键生成PC端与手机端源代码及界面

同时也支持多种数据展示风格，如下左右导航树数据展示：

同时支持志生成列表的功能同时兼容手机端录入数据的界面，保证PC与手机功能一致。

红迅的业务单据满足实现企业级的单据应用的需求，它能满足：

• 单据管理功能配置化及授权访问

• 单据数据权限控制的控制访问

• 单据按钮权限控制访问

• 单据的数据的导入与导出

• 单据的多种打印模板

• 单据的流程配置及审批

• 单据的统计报表制作

• 单据流程的业务分析与管理

6.BPMN2中国式流程支持

JSAAS平台支持非常强大的流程服务，特别是中国特色的流程审批服务，包括：

• 流程串行、并行审批

• 子流程的审批

• 流程版本变更

• 流程的自由流程

• 流程的人员变更处理

• 流程任务的分发与汇总

• 流程定义的会签

• 流程的催办

• 流程超时跳过

• 流程的工作日历

• 流程表单的在线配置

• 流程分支的配置处理

• 流程的组架构整合

• 流程表单的权限配置控制

• 流程消息通知

• 流程的回退与追回

• 流程的抄送与阅读控制

• 流程表单的模板打印等

多种流程开发工具集的支持

流程在线定义、表单自定义配置、查询设计、列表设计、表单方案设计、流程方案设计、组织架构设计、数据字典、选择对话框设计、数据源设计、流水号设计、流程授权设计等，可以满足各种流程的业务扩展需求。

流程在线定义

平台整合Activiti Modeler Designer,支持丰富的BPMN2的元素语法，可描述简单与复杂的流程业务需求，为企业、机关单位制作完善的业务流程提供了完好的支持，结合平台本身的表单与流程解决方案工具，让流程业务落地变得简单。

流程方案配置

提供组装流程业务的解决方案的管理，把流程定义、审批人员、流程表单、审批时的事件及交互脚本调用等组装起来，实现真正意义上的BPMN的流程业务规则。如审批时，执行写入其他数据库的操作。支持各种事件的脚本交互处理；同时可让平台扮演流程管理中心，支持第三方平台的流程应用调用。

 

待办任务处理

任务干预

提供用户多种途径对正在运行的流程实例进行干预处理，防止流程人为出错后，系统有效提供手段进行人工纠正。

7.手机审批

通过在手机端进行模板配置，无需要进行功能开发，即可实现手机上进行待办处理，大大方便企业的管理人员。

8.报表管理

平台提供流行的在线报表管理功能，客户可线下进行报表设计，设计完成后，上传配置即可在线报表查看，并可配置于公司首页、部门首页或个人的首页、菜单等，展示风格可根据报表模板来定，同时实现在线报表展示及导出。

上传后的报表展示

9. 基础服务支持

邮件服务

1. 平台整合开源的邮件服务器，邮件服务器可独立部署也可嵌入式部署，但邮件量比较大时，建议分开部署处理，平台可以在线收发邮件，邮件可为内部邮件、也可为外部邮件。

2. 邮件账号合并系统中的人员管理的账号，有效实现一号统一，邮件密码可与系统登录的密码不一致也可一致

文件附件管理

1. 平台中大量的文件、附件、图片均需要进行统一的管理，系统对每个账号的附件上传的文件的类型、大小、访问安全提出严格的控制

2. 提供文件全文索引管理，有效提高附件的搜索速度

支持在线的文档预览

内部消息通知管理

平台提供内部的短消息的收发处理，可有效在系统内进行消息的通知。结合后面外围的即时消息，可有效实现消息的即时收发。

短信消息管理

1. 平台整合流行第三方短信网关，通过发送短信XML至网关，以达到有效给相应的人员推送短信消息

2. 平台整合腾讯的信鸽云推送，可有效实现免费的消息推送

微信公众号

平台提供不同的微信开发管理功能，包括订阅号、微信公众号、企业号的菜单自定义、消息自动回复、企业公告等功能，为现在的企业的微营销带来便捷的体验。

企业微信

平台实现了企业微信的账号及用户组织架构同步，为流程的消息通知开通实时的企业微信通知服务。

数据交互处理

平台提供方便的数据映射及接口开放的功能处理，通过JSON\XML\JMS\WebService等数据格式有效实现数据接口处理。

自定义PORTAL

支持栏目模板自定义，支持门户布局配置，支持不同风格的部门、单位、个人的首页门配置。

其他基础功能工具

如菜单管理、数据字典管理、系统参数管理、系统访问日志管理、系统流程号管理，数据源管理，自定义SQL管理，任务调度管理，平台的工作日历，系统开发文档管理等。

10.SAAS功能的支持

平台可根据参数配置,是否打开SAAS的功能支持，一旦打开，即支持同一套应用同时提供给多个租户使用，默认采用以下的第二种方式SAAS的应用支持

支持多企业在线注册及使用

11.如需了解深层的技术与项目交流,请联系:

• QQ: 1361783075

编辑导读：产品经理作为产品的“父母”，每天要做的事情又多又杂，很多人会觉得一些事情应该是项目经理应该做的，而不是产品经理的工作。本文作者对此发表了自己的一些看法，与你分享。

多位读者看了我的文章“一份完整PRD的八要素”后，在后台留言这是项目管理，不是产品经理该干的，是不是混淆了产品经理和项目经理？

所以，我认为有必要厘清项目经理和产品经理两者的关系。

文章将分成3部分：

产品经理需要会项目管理吗？（会不会）产品经理需要亲自干项目管理的事吗？（要不要）项目管理的关键点是什么？（怎么干）附：以下是上周文中提到的PRD需要的8要素：

一、产品经理需要会项目管理吗？

在菩提之前的文章“产品经理需要的3项核心能力”中，菩提认为产品经理需要的3项核心能力分别是商业洞察、产品规划与设计、项目管理。

渔歌的观点和菩提完全一致，项目管理是产品经理必备的核心能力之一。产品经理是对产品结果负责的人，而项目管理影响产品质量、产品进度，所以当然要懂，甚至擅长。

产品经理是为产品操碎了心的那个人，人称产品他妈或产品他爸，比如出了bug，交互不连贯，少了指标解释，或者指标解释中有个错别字，或者竞品有新的苗头，大部人第一时间会找产品经理，炮弹式几联问产品经理：“什么情况？为什么？你怎么想的？怎么解决？什么时候解决？”。

面对这种几联问，产品经理如果不能对项目管理做到心中有数，必然无法接招。总不能总回复业务老板、产品老板、技术老板：“我不是很清楚，待我了解后再向大家汇报。”这种措辞只能用1-2次，用多了，大家都知道找产品经理无用，就不会再找产品经理，要么直接找知道的人，要么把产品经理换了。

所以，产品经理的生存环境的确不太友好，甚至为了一个小小的功能，要心系天下、心系市场、心系交互、心系技术、心系业务、心系老板，花式哄着大家开心，还要让大家保质保量，不出幺蛾子。愁煞产品宝宝了。

渔歌认识的产品经理们大多有为了产品熬白了头发，熬出了中年人的土肥圆的经历。

有的产品经理梦里都在写PRD，写着写着兴奋了，就真的醒了，深更半夜起床一气呵成把PRD写完，第二天一早可开心的跑到公司，神采飞扬的跟开发GG们说，昨天大家提到的问题有解决方案了，来来，咱们一起看下。

有的产品经理梦里说着梦话，“你们别吵吵，不就是这事是前端干，还是后端干嘛？从技术架构上该谁干？你们谁愿意干？就这么点事，吵来吵去，代码都写好了，能不能省点心啊。”然后一声深深的哀叹。家里人听到这梦话，觉得好笑又心疼。

有的产品经理坐着公交车，脑子里一直翻转着产品那些事，毫无知觉的坐过站，等回过神了，直嚷着“我勒个趣”，然后一溜烟赶紧下车，再打个车原路返回。

有两产品经理深夜12点下班，结伴一起回公司边上的出租房，讨论着最新的市场环境变化，公司策略变化，公司人事变化带来的影响，左一句右一句：“对，就应该这么干。不对，他想的不对。”仿佛他俩可以指挥整个世界。

这背后每件事情都广义上的项目管理，项目管理即是无形的存在，也是有形的存在，不是发个项目进度邮件，开个项目启动会才是项目管理。

所以，渔歌认为：产品经理必须会项目管理，擅长项目管理。

二、产品经理需要亲自干项目管理的事吗？

其实，文章第一部分已经很明确，产品经理毫无疑问要干产品经理的事，事无巨细，只是项目管理有很多种方式和手段，这和每家公司的岗位配备、人员能力&性格，都有很大关系。

如果企业没有配备专门的项目管理团队，产品经理就需要身兼项目管理的职责。

如果企业配备了专门的项目管理团队，那产品经理和项目管理经理是相互助力，一起拿结果的合作关系。产品经理并不能把项目管理的工作完全甩出去，因为产品经理对结果负责，但凡对结果有可能造成影响的过程都需要知晓，必要的时候去影响这个过程。

在大公司、大项目或者讲求规范的公司，可能会配备专人负责项目管理。但：

从项目管理的职责上看，项目管理很多时候只是对项目进度负责，比如什么时候上线？各方资源有没问题？如果有风险，如何暴露风险并化解风险。从项目管理的数量上看，项目经理往往同时负责多个项目，对多个项目统筹管理，不是对特定产品负责。从项目管理的专业上看，很少有项目经理能对产品本身提出建设性意见，或者主动发现产品问题，项目经理更多是提出明确的时间节点要求和资源配置，然后听取各方反馈，再整理成项目管理的结论。所以，产品经理是项目经理的重要输入，项目经理是产品经理的重要助力。

虽然很可能也有一些内部矛盾或斗争，会在项目经理和产品经理之间爆发。但如果企业在良性发展的阶段，项目管理经理和产品经理以合作关系为主。

三、项目管理的关键点是什么？

菩提在关于“项目管理的要诀”一文中讲述了项目管理的目标、原则、常用方法，渔歌认同菩提的观点，所以只简单摘要菩提的观点，有兴趣的可查看文章详情：

项目管理的目标：

项目管理的目标：分基线目标和高阶目标，基线目标是为了保证短期产出，高阶目标是为了个人长线的口碑。

基线目标：保证项目质量、项目进度。项目质量、项目进度是项目管理的双因子。高阶目标：与各方建立良好的合作关系，奔向同一个目标。项目管理不只是单一项目导向下，保证单一项目的成功，更是围绕项目成员的长期合作关系的培养。项目管理的原则：

团结一切可以团结的力量。小步迭代，快速奔跑。确定的先做，不确定的先放一放。项目管理的常用方法：

制定详细&责任到人的项目计划给自己找个靠谱的技术负责人。必要情况下，建立项目日会、周会机制。必要时，采用逆向管理机制-反串讲。项目review不可少最后，这些都只是渔歌的所见、所闻、所思，也可能不对。

大家的产品和项目管理的实际工作是什么样的呢?欢迎留言告诉渔歌。

#专栏作家#

11年经验的某大厂产品经理，专注产品和大数据。

本文原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于 CC0 协议

编辑导语：中台在这几年争议很多，很多企业都开始打造自己的中台服务，但是有些打造出来不仅用处不大，还劳民伤财；其实中台也是要看公司的各个方面，最终决定要不要做中台；本文作者分享了关于没有匹配的研发组织，如何实现高效的产品研发，我们一起来看一下。

最近阿里一系列的组织架构调整，随之而来对阿里拆中台等相关解读的文章又尘嚣直上，再加上中台这几年的发展，大家对中台充满了争议，中台死亡论也成了一股暗流。

有人把它捧到天上，又有人把它甩到茅房；我认为中台概念现在没有可以丈量的标准，一千个人就有一千个中台的模样，有的人运用中台提升了组织的运行效率；有的人建中台却劳民伤财最后失败告终，中台没有错，只是用的人用错了而已。

很多传统企业数字化转型，太过强调中台的平台属性却忽视了更为重要的组织属性，一个不能变革组织的中台建设是注定要失败的；因为所有事情的执行者是人，没有匹配的组织架构，没有合适的岗位人员，相应的事情就很难执行。

一、从大秦帝国看中台

最近大秦赋在热播中，“及至始皇，奋六世之余烈，振长策而御宇内，吞二周而亡诸侯，履至尊而制六合，执敲扑而鞭笞天下，威振四海。”看的我们也是心潮澎湃，激昂壮烈。

回顾那段历史，我一直在思考，为什么是秦国一统天下，结束五百年的诸侯之争，为什么秦朝短短十几年就走上覆灭之路，它对后世中国带来哪些影响呢？它对我们的工作有什么指导启示吗？

和春秋战国时期的周王朝相比，秦制的本质是实行中央集权的郡县制，撤销了诸侯国，有人说秦制就是大中台，书同文、车同轨，其实就是one id；这么说也是有一定道理的，中台的本质就是由过去分散式的前台应用独立建设转变为统一建设，以达到更好的能力积累和复用。

但有人把秦二世亡国类比中台的死亡，这就有点牵强了。

秦朝灭亡从表面上来看是秦二世的昏庸无道，实行暴政，本质上更多是秦朝中央集权的政治改革过于激进，对过去的分封体制是一种颠覆，对于法家思想的过度执念，这样的改革只有像秦始皇这样雄才大略的帝王才能hold住；如果再给秦始皇更多的时间，也许秦朝就不至于二世灭亡。所以汉朝初期采用了郡县制和分封制结合的模式，循序渐进的进行改革，直到汉武帝平定七国叛乱，最终实现中央集权在后世中国的深远影响。

书同文、车同轨其实就是中台要建立统一的标准、规范，这对于组织的协同，对于能力的复用都有帮助；按道理这对于企业管理来说，或者对于研发来说，都是一件好事情，为什么却有那么多人中伤中台呢？

我认为中台的建设中，始终存在着管控与自主，稳定与创新等矛盾，这就需要强大的组织领导力，能打破原有的组织关系，不怕动某些人的利益才能完成。

很多中台失败的案例大多数是只有变革之心，却无变革之力。

拓展阅读：

向左还是向右？中台建设才不止这点纠结事

半年中台实践的思考：落地中台，贵在其神，活用其形

二、合理的研发组织是基础

中台架构一般是一些具备大型复杂生态系统的大公司在自主的前台和统一的后台寻求平衡的结果；对于大部分小公司来说，中台架构离我们还是比较远，所以我一直强调，对于中台架构要重其神而轻其行。

中台架构的成功的基础是中台组织的建立和保障，对于研发来说，一个合理的研发组织也是高效研发的基础。

笔者早几年负责一个互联网产品的技术团队，这是一个创业阶段的小团队，整个技术团队也就十几个人，业务也相对来说比较单一；所以组织架构相对来说就比较简单，分成了后端Java开发团队和APP开发团队，平时以产品迭代为主，偶尔也协调资源做一些和客户有关或者运营活动有关的项目。

此时职能团队是实线管理团队，而项目因为存在可变化性，是临时的虚线团队。

随着业务发展，前台出现两个业务团队的时候，两个业务团队为了更好的让技术团队服务业务团队，开始要求拆分技术团队到业务单元，以便更好的和业务绩效挂钩。

如果该项目业务稳定、资源充足，可以独立成更有自主性的项目团队，否则还是按照虚线的项目团队作为过渡。当时我们就过早的拆分了团队，不可避免的部门墙也导致了在一些新项目时资源协同性很差的问题；好在我还是作为公司的技术总监来统筹技术管理，这个影响还不是很大；所以小团队不要过早拆分，否则资源本身不充足的基础上，又更加难以利用！

一项新的业务，要尽量用现有的功能团队先进行项目初期的开发或者孵化，等项目上线或者成熟后，转由专门支持该项目的效率团队完成后续的迭代升级；所以最终形成如下图的研发组织，有侧重业务线，有侧重功能线。

为了便于更好的协同和技术体系的统一，CTO或者技术委员会将在技术管理中起到重要的作用。

在一个自我演化的团队，只要保证CTO或者技术委员会的统筹和统一的技术管理的作用，技术团队的拆分、裂变都是有序的，技术体系的统一，技术规范的统一，开发流程的一致都能得到有效的维护。

2019年初，我开始负责一个TO B业务的科技公司的整体研发，很不幸的是，之前的技术管理做得很不好，表现在存在5个事业部，研发分散在事业部，且技术路线不统一，光主流的后端开发语言就涵盖Java，net和PHP三种；所以后续业务整合、研发统一的过程中，系统和技术的整合也是一件非常头疼的事情；当时尝试了中台化的解决方案，以期通过中台架构实现柔性化的统一。

既然说到中台的柔性，我想对于当前阿里拆中台的猜测表达一下自己的想法，也许阿里是年底正常的架构调整，也许是有人说的中台强管控对于前台应用的制约；如果真是这个原因，我想这和我对中台的理解不同，中台不能做强管控的中台，而是要做柔性的中台，改革是一个循序渐进的过程。

另外，有人把阿里前台创新的不足归结于中台的制约，我认为也是比较牵强的；中台不是创新的方向标，它只是创新的加速器，创新是靠的企业文化和管理机制；如果建了中台就能让企业具备创新的能力，这无异于是对中台的不切实际的过高期望。

另外，对于自运营的互联网应用研发的企业和对外实现客户交付的偏软件应用研发的企业，对于研发组织的建设依然会有很大的不同。

互联网企业重运营，所以产品的迭代，对日常运营的支持就会更加的频繁，适合在前台建立全职能的研发团队，以提供更紧密的支持；而交付型的软件企业重销售，前台更侧重产品销售和项目交付，所以更倾向研发统一管理，让专业的人做专业的事，同时更能有效的利用进行技术积累和复用，提升产品研发的效率。

今年我们在部分领域实行了项目带产品的策略，但是由于研发既负责项目交付，又承担产品迭代，在资源紧缺的情况下，两边可能都会耽误，项目交付不能保证，产品研发也不顺畅。

这算是一次小小的教训，如何改变呢？如果团队规模较大，要把项目交付团队和研发团队做一个分离，各司其责，相互协同又不要相互影响。

对于TO B的企业，我们需要从能力线、产品线以及项目线上来建设技术团队，通过CTO或技术委员会保持在跨组织的技术管理，以保证技术战略、技术规范、开发流程的有效统一。

三、不可忽视的康威定律

很多老板看到中台架构很好也请来供应商帮着搞，但是就是搞不好，就感觉阿里宣传的中台是不是吹牛逼。

其实阿里的中台也不是一帆风顺的，没有组织的变革，没有自上而下的强力推动，也是寸步难行。

在钟华的《企业IT架构转型之道》一书中，他形象的给我们展现了，承接中台架构的业务组织–共享业务事业部的发展史，又一次告诉我们IT架构和组织架构密不可分的关系，这就是有名的“康威定律”！

康威定律是马尔文·康威1967提出的：“设计系统的架构受制于产生这些设计的组织的沟通结构。”

通俗的来讲：产品必然是其（人员）组织沟通结构的缩影。

更直白的说，你想要什么样的系统，就搭建什么样的团队。

如果你的团队分成前端团队，Java后台开发团队，DBA团队，运维团队，你的系统就会长成下面的样子：

相反，如果你的系统是按照业务边界划分的，大家按照一个业务目标去把自己的模块做出小系统，小产品的话，你的大系统就会长成下面的样子，即微服务的架构。

架构不仅仅需要技术，在大公司尤其需要政治，所谓的架构的政治；所以康威定律一定是要熟悉并合理使用的第一定律，想想那些大公司的产品形态和他们的组织关系，就会发现这么有趣的联系。

所以一些传统企业想要数字化转型，如果还是依托传统的信息部这样的后台组织去搞，十有八九很难成功，需要一个全新的数字化部门大胆的改革。

同样作为产品研发，我们如果既要降本增效，又想保持创新，没有合理的匹配的研发组织，那也只是一场梦而已。

#专栏作家#

经历程序员、技术Leader、产品经理、研发Leader等多种岗位。关注医疗，早教领域，擅长企业IT架构及互联网产品架构。

本文原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

作者 / 谭丽平

来源 / 盒饭财经（ID：daxiongfan）

战略需要与组织架构相匹配，不平凡的2020年，大厂都是如何调整组织架构的。

时值年底，很多互联网大企都开始了新一轮的组织架构调整。12月11日，阿里巴巴发布新一轮组织架构调整，调整主要针对核心电商业务和本地生活服务；12月14日，京东零售集团完成了新一轮组织架构调整；12月18日，美团公布了公司新一轮组织调整......

这一幕又让人想起组织架构调整浪潮席卷的2018年。2020年，旧世界在下沉，新世界在上升，大厂调整组织架构背后又透露出哪些信号？

盒饭财经（ID：daxiongfan）梳理了各家互联网大厂有关组织架构调整的新动态，一图在手，天下你有。

01 进攻与求稳

截止目前，除了腾讯自2018年918变革后没有改变以外，绝大多数互联网大厂大都已经至少经历了一轮调整。

2020年各大互联网企业组织架构调整表，制图盒饭财经

从时间来看，调整大多集中在年前、年中和年末。

调整最多的是常常被认为落后的百度，1月8日，百度升级AI体系。原来AIG(AI技术平台体系)、TG(基础技术体系)、ACG(百度智能云事业群组)整体整合为“百度人工智能体系”(AI Group、缩写为AIG)。新AIG包含技术中台群组(TPG)和智能云事业群组(ACG)两大群组，继续由百度CTO王海峰负责。

2020年3月13日，百度再度围绕对云业务进行架构调整，CTO王海峰发内部邮件称，百度智能云的云计算、智能金融、智能客服、渠道生态等业务的负责人直接向王海峰汇报，尹世明、张志琦将另作安排。

百度表示，这次组织架构调整是内部资源优化整合。从2019年起进行的一系列调整显示智能云战略地位一直在升级。

2019年9月2日，李彦宏发出全员内部信，宣布进一步升级“云+AI”战略，百度智能云与CTO体系高效融合，要用更高效的方式发挥AI优势。2018年12月18日，百度内部智能云事业部升级为智能云事业群组，同时承载人工智能toB业务和云业务，这是百度智能云此轮调整的关键起点。

组织架构的变化，需要从历史沿革中寻找规律，2017年陆奇的加入，百度迎来“决胜AI时代”，直接将部分与人工智能无关的业务被边缘化。并对组织架构前后进行了多次调整，而后形成了六大事业群平行的基本架构。然而，2018年5月，陆奇离开百度，百度的转型和调整止步。它错过了移动互联网时代，虽然陆奇作为“关键先生”也未发挥关键作用，但是，他的策略并没有被完全推翻，百度希望希望通过李彦宏版的“智能云”扳回一城。

阿里、京东、美团、滴滴、字节、小米、快手等大厂也已经进行了组织架构调整。

从调整方式来看，它们普遍整合了相关业务并将核心的部门升级事业部门为事业群，这种组织方法以部门、产品组为单位，有其边界简明和利于快速尝试的优点。

比如，京东升级零售企业业务事业部升级为京东零售企业业务事业群，继续由宋春正负责，向徐雷汇报。此外，据36氪报道，主攻下沉市场的京喜也完成新一轮调整，由事业部直接升级为京喜事业群。

为了追赶社区团购业务短板，京东通过架构调整以快速响应。它成立了单独的社区团购事业部，整合了京东原有的社区团购业务。新成立的社区团购事业部、原京东零售集团大商超全渠道事业群旗下新通路事业部以及1号店业务均全部整合进京喜事业群。据媒体报道，京东内部员工透露，该调整没有发布任何内部邮件，“只是开了一个面向集团的宣讲会，主题则是‘挖人’”。与美团、拼多多类似，京东目前也在挖掘各部门精兵强将组建社区团购团队，并由刘强东亲自带队。

除此之外，8月，京东物流CEO王振辉通过全员信宣布，京东物流将进行使命愿景、组织架构和品牌形象三大升级，以更年轻、更科技、更开放的形象开启下一个征程。

王振辉表示，京东物流使命将升级为“技术驱动，引领全球高效流通和可持续发展”，愿景将升级为“成为全球最值得信赖的供应链基础设施服务商”；组织架构将升级为“梦想787”：即全国7大区域、8个前台和7个中后台；品牌形象将更新为“JDL”，其中JD即京东，是京东物流发展的根源和价值观指引，L是Logistics（物流），也是Lead（引领）、Link（链接）、Less（简洁）和Love（爱）。

12月10日，媒体报道，滴滴正式开启新一轮架构调整。其中，整合两轮车、代驾、跑腿、货运等业务成立城市运输与服务事业群，任命付强担任新事业群CEO兼事业群安委会主任，直接向程维汇报。

除了进攻性动作，通过组织架构调整，大厂也正在求稳。

12月11日，阿里淘宝天猫总裁蒋凡发出全员公开信，宣布已针对核心“电商业务”和阿里本地生活服务公司进行了新一轮组织架构调整。此次调整主要针对核心电商业务和本地生活多个高管职位作出调整。

图片来源于无冕财经

这两次调整均由上述两大业务的负责人（蒋凡和王磊）发布内部信告知全员，而非阿里巴巴董事局主席兼 CEO 张勇发布。这意味着，备受外界关注的蒋凡和王磊仍留在原位，均未发生调动。此次调整的重点是，天猫此前不同行业有不同负责人，现在统一归杨光负责；搜索合并进产品，才加入阿里一年的汤兴权责扩大；阿里妈妈原先归蒋凡直接管理，现在归刘博负责。淘系三员大将位置更为稳固，分别是杨光、汤兴、刘博。

本地生活公司组织架构调整后，事业群和事业部调整后都有一号位，打法更会聚焦。此外，本年度阿里本地生活也将与支付宝有更强的联合，利用流量变现。

阿里以善于调整组织架构著称，往往每年都要进行几轮调整，今年，调整姗姗来迟，且只是局部布局；腾讯经历过2018年的大调整之后，再未有新的变动；百度虽然动作频频，但发力点依旧聚焦“AI+云”。相较之下，小米上市后一年内调整了7次，12月，新成立三个互联网一级部门；滴滴频频整合升级网约车、出租车、橙心优选等；快手也在不断调整中，直面自己的困难。

02 对抗熵增

熵增过程是一个自发的由有序向无序发展的过程，对大厂而言，组织架构调整是为对抗熵增。

一般来说，影响组织架构的设置和调整的因素大都包括：企业战略、业务发展、发展阶段、管控模式、组织规模、组织文化、外部环境等。

比如，2016年5月，小米进行了创办以来最大规模的人事调整。那一年，小米手机销量大幅下滑，全年出货量大跌36%，甚至一度跌出全球前五，狂飙突进后，小米暴露出诸多问题。

为重振小米，雷军将原先负责研发和供应链的周光平调离，亲自负责研发和供应链，渠道方面则由林斌大规模开展线下店，发力印度市场。经历一年蛰伏，小米触底反弹。2017年7月，雷军在公开信中称二季度手机单季出货量为2316万台，创下历史最高纪录，2017年小米又接连发布了小米6、MIX2等产品。

自此，小米经常就持续进行组织架构和人员的调整，上市后的一年内进行了7次调整，在2020年的第三季度，时隔4年重回全球手机出货量第三。

雷军在接受媒体采访时曾表示，早期的小米有点像游击队或者特战队，但今天（2018年）小米营收过千亿、员工近两万，就必须要从‘游击队’变成正规军、集团军。未来团队还会继续扩大，建设不好组织体系就是风险管控远远不足，“这事关企业的生死存亡”。

快手也正在加快变革以避免增长降速。

今年5月，快手发布内部信宣布组织架构调整，主要涉及商业化、运营、产品等多个核心部门。具体组织架构调整为：原运营负责人马宏彬将与原商业化负责人严强调换岗位；原产品负责人之一徐欣，将调任负责用户体验中心；原产品负责人之一王剑伟，将收拢产品和直播业务汇报线，成为产品最高负责人。

对此，快手直言，组织架构调整有多方面考量。目前行业竞争非常激烈，快手每个干部都需要有更加丰富和多元的业务经验；希望通过干部个人的经验积累，使得团队之间的协作变得更加顺畅；通过架构调整，也能看到每个干部更多发展的可能性；希望加强干部团队对于用户价值和客户价值的重视。

12月，快手进行了年内的第二次调整，撤销 2019 届经营管理委员会，并宣布新一届的名单。可见，2020年的短视频风口也正对快手内部组织结构进行着考验，如何在频频调整中找准定位，是快手接下来需要做的。

从小米和快手的例子来看，当企业发展到一定阶段，如果不进行变革，将会进入不协调的发展。雷军曾说，组织架构调整是一个渐进的过程，哪有一劳永逸、一步到位的组织调整。未来 2 年内，小米肯定还会陆续进行一系列调整和优化。

海尔张瑞敏曾提出“没有成功的企业，只有时代的企业”。

企业要变革加速的时代背景下，保持持续的竞争力，组织架构的设置与调整要随政治、经济、技术、行业、竞争对手等外部环境的变化而变化。企业组织结构调整除了满足公司的战略要求，还包括适应外界环境的变化。

以阿里为例，无论是在电商领域，还是本地生活领域，2020年都让阿里感受到了新增的压力。从今年电商行业整体发展态势来看，虽然阿里系电商依然是国内最大龙头，可竞争对手拼多多、京东变阵，抖音和快手从侧翼发动进攻，在本地生活服务领域，又继续受到美团加深服务半径的进攻。

除此之外，因反垄断法及蚂蚁上市延期影响，其舆论环境也大不比往年，特别是到年末，应对风险，对阿里可能是比创造新增长更重要的话题。

北京大学国家发展研究院BiMBA商学院院长陈春花表示，“今天我们的环境发生了根本性的变化，即使是阿里、腾讯、京东这样的互联网巨头，都不得不调整自己的组织结构。”陈春花认为，今天的企业组织一定是动态的，组织一定要变得越来越网络化。

创业之初，往往追求针尖扎破天，进入成熟期，很多公司更追求横向扩张，进入无限的游戏，这也是反垄断提上议程的原因之一。

虽然受到疫情，以及中美关系影响，但短期的逆流，不会影响全球化的大趋势。大厂依然在为国际业务积极布局，另一方面，也是国内赛道拥挤，希望能享受海外增长的红利。今年年初，京东全球售和京东国际物流合并，成立欧美业务部，之后欧美业务部又与东南亚业务部合并，成立了京东业务部。

全面负责国际业务部负责人的闫小兵2012年加入京东，2018年初的架构调整中，闫小兵出任3C电子及消费品零售事业群总裁，同时兼任京东集团高级副总裁。后在年中大调整中，其他两大事业群总裁王笑松和胡胜利纷纷被调整，而闫小兵依然受到重用。

根据员工透露，在国际业务调整后，京东的国际业务分成了跨境、商物流和本地站三个团队，三个团队均向闫小兵汇报。

今年对国际业务的调整，加上闫小兵担任京东国际业务部负责人，可见京东已经对国际业务展开新一轮布局。

除此之外，今年3月，字节跳动组织变动，张利东担任字节跳动（中国）董事长，作为中国职能总负责人，抖音CEO张楠将担任字节跳动（中国）CEO，作为中国业务总负责人两人向张一鸣汇报。而张一鸣则领导公司全球战略和发展，更专注于长期重大课题的探索和战略思考，包括全球化企业管理研究，企业社会责任，以及教育等新业务方向。

此外，今年7月，报道称，有消息人士向其透露，字节跳动目前有意在海外设立一个新总部或者建立一个独立领导的TikTok管理委员会。

今年，社区团购是最热的赛道之一，拼多多、滴滴、美团、阿里等火药味十足，也向此方向排兵布阵。

除了前文写到的刘强东亲自下场带队打社区团购一仗，滴滴在9月下旬，也推出了橙心优选。在人员调整中，滴滴多次将网约车精锐部队调至橙心优选项目，可见滴滴对于这一新业务的重视程度，此前程维曾表示对橙心优选的投入不设上限，“全力拿下市场第一名”。

在新一轮组织变革中，流行的中台模式，正面临全新挑战。

纵向来看，互联网巨头这几年组织调整都逐步围绕打造前台、中台和后台的管控模式。前台重在围绕客户和需求整合资源，快速响应和满足客户需求，为客户持续创造和提升价值；中台为前台业务运营和创新提供通用专业能力共享平台，实现专业化、系统化、组件化、开放化；后台为整个公司提供基础管理、职能服务支持、和风险管控等，旨在实现专业化支持与服务的能力。

中台为阿里最先提出，如今此趋势似乎正在发生改变。

2015年，张勇推出“大中台、小前台”战略。最初希望打造统一技术架构、产品支撑体系、数据共享平台、安全体系等等。把整个组织“横”过来，支撑上面多种多样的业务形态。之后，在2018年，成为了百度、美团、京东、滴滴等大厂相继使用的战略。

不过，近期有消息传出张勇在阿里内网发布文章表示，他对目前阿里的中台并不满意，认为现在阿里的业务发展太慢，要把中台变薄，变得敏捷和快速。

阿里的一位中台架构师透露，“现在是要求我们把最抽象的部分留在中台，这样中台就剩下很薄的一层，通过这几年沉淀下来的通用能力来提高效率，可以大大减少人力，释放出来的人去前台做个性化的改造。”

那么，中台过后，下一个“中台战略”在哪里？

Podman 使用传统的 fork/exec 模型（相对于客户端/服务器模型）来运行容器。

在进入本文的主要主题 Podman 和容器之前，我需要了解一点 Linux 审计功能的技术。

什么是审计？
Linux 内核有一个有趣的安全功能，叫做审计。它允许管理员在系统上监视安全事件，并将它们记录到audit.log 中，该文件可以本地存储或远程存储在另一台机器上，以防止黑客试图掩盖他的踪迹。

/etc/shadow 文件是一个经常要监控的安全文件，因为向其添加记录可能允许攻击者获得对系统的访问权限。管理员想知道是否有任何进程修改了该文件，你可以通过执行以下命令来执行此操作：

auditctl -w /etc/shadow

现在让我们看看当我修改了 /etc/shadow 文件会发生什么：

touch /etc/shadow

ausearch -f /etc/shadow -i -ts recent

type=PROCTITLE msg=audit(10/10/2018 09:46:03.042:4108) : proctitle=touch /etc/shadow type=SYSCALL msg=audit(10/10/2018 09:46:03.042:4108) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb17f6704 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=2712 pid=3727 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=3 comm=touch exe=/usr/bin/touch subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)`
审计记录中有很多信息，但我重点注意到它记录了 root 修改了 /etc/shadow 文件，并且该进程的审计 UID（auid）的所有者是 dwalsh。

内核修改了这个文件了么？

跟踪登录 UID
登录 UID（loginuid），存储在 /proc/self/loginuid 中，它是系统上每个进程的 proc 结构的一部分。该字段只能设置一次；设置后，内核将不允许任何进程重置它。

当我登录系统时，登录程序会为我的登录过程设置 loginuid 字段。

我（dwalsh）的 UID 是 3267。

$ cat /proc/self/loginuid
3267
现在，即使我变成了 root，我的登录 UID 仍将保持不变。

$ sudo cat /proc/self/loginuid
3267
请注意，从初始登录过程 fork 并 exec 的每个进程都会自动继承 loginuid。这就是内核知道登录的人是 dwalsh 的方式。

容器
现在让我们来看看容器。

sudo podman run fedora cat /proc/self/loginuid
3267
甚至容器进程也保留了我的 loginuid。 现在让我们用 Docker 试试。

sudo docker run fedora cat /proc/self/loginuid
4294967295
为什么不一样？
Podman 对于容器使用传统的 fork/exec 模型，因此容器进程是 Podman 进程的后代。Docker 使用客户端/服务器模型。我执行的 docker 命令是 Docker 客户端工具，它通过客户端/服务器操作与 Docker 守护进程通信。然后 Docker 守护程序创建容器并处理 stdin/stdout 与 Docker 客户端工具的通信。

进程的默认 loginuid（在设置 loginuid 之前）是 4294967295（LCTT 译注：232 - 1）。由于容器是 Docker 守护程序的后代，而 Docker 守护程序是 init 系统的子代，所以，我们看到 systemd、Docker 守护程序和容器进程全部具有相同的 loginuid：4294967295，审计系统视其为未设置审计 UID。

cat /proc/1/loginuid
4294967295
怎么会被滥用？
让我们来看看如果 Docker 启动的容器进程修改 /etc/shadow 文件会发生什么。

$ sudo docker run --privileged -v /:/host fedora touch /host/etc/shadow
$ sudo ausearch -f /etc/shadow -i type=PROCTITLE msg=audit(10/10/2018 10:27:20.055:4569) : proctitle=/usr/bin/coreutils --coreutils-prog-shebang=touch /usr/bin/touch /host/etc/shadow type=SYSCALL msg=audit(10/10/2018 10:27:20.055:4569) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7ffdb6973f50 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=11863 pid=11882 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=touch exe=/usr/bin/coreutils subj=system_u:system_r:spc_t:s0 key=(null)
在 Docker 情形中，auid 是未设置的（4294967295）；这意味着安全人员可能知道有进程修改了 /etc/shadow 文件但身份丢失了。

如果该攻击者随后删除了 Docker 容器，那么在系统上谁修改 /etc/shadow 文件将没有任何跟踪信息。

现在让我们看看相同的场景在 Podman 下的情况。

$ sudo podman run --privileged -v /:/host fedora touch /host/etc/shadow
$ sudo ausearch -f /etc/shadow -i type=PROCTITLE msg=audit(10/10/2018 10:23:41.659:4530) : proctitle=/usr/bin/coreutils --coreutils-prog-shebang=touch /usr/bin/touch /host/etc/shadow type=SYSCALL msg=audit(10/10/2018 10:23:41.659:4530) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7fffdffd0f34 a2=O_WRONLY|O_CREAT|O_NOCTTY| O_NONBLOCK a3=0x1b6 items=2 ppid=11671 pid=11683 auid=dwalsh uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=3 comm=touch exe=/usr/bin/coreutils subj=unconfined_u:system_r:spc_t:s0 key=(null)
由于它使用传统的 fork/exec 方式，因此 Podman 正确记录了所有内容。

这只是观察 /etc/shadow 文件的一个简单示例，但审计系统对于观察系统上的进程非常有用。使用 fork/exec 容器运行时（而不是客户端/服务器容器运行时）来启动容器允许你通过审计日志记录保持更好的安全性。

最后的想法
在启动容器时，与客户端/服务器模型相比，fork/exec 模型还有许多其他不错的功能。例如，systemd 功能包括：

SD_NOTIFY：如果将 Podman 命令放入 systemd 单元文件中，容器进程可以通过 Podman 返回通知，表明服务已准备好接收任务。这是在客户端/服务器模式下无法完成的事情。
套接字激活：你可以将连接的套接字从 systemd 传递到 Podman，并传递到容器进程以便使用它们。这在客户端/服务器模型中是不可能的。
在我看来，其最好的功能是作为非 root 用户运行 Podman 和容器。这意味着你永远不会在宿主机上授予用户 root 权限，而在客户端/服务器模型中（如 Docker 使用的），你必须打开以 root 身份运行的特权守护程序的套接字来启动容器。在那里，你将受到守护程序中实现的安全机制与宿主机操作系统中实现的安全机制的支配 —— 这是一个危险的主张。

via: https://opensource.com/article/18/10/podman-more-secure-way-run-containers

作者：Daniel J Walsh 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出