敏态项目和稳态项目_什么是敏态和稳态业务

最近有很多小伙伴咨询关于敏态项目和稳态项目的问题，小编结合多年的经验整理出来一些什么是敏态和稳态业务对应的资料，分享给大家。

测试敏捷化 vs 敏捷测试

本文首发于网站【 林子的空间 】

大家可能关注到双态IT联盟前一阵发布了一个 测试敏捷化成熟度评估模型 ，不断有小伙伴问到我关于这个成熟度评估的问题，我发现大家很自然地把这个跟敏捷测试成熟度画上了等号，不过这不是Thoughtworks开发的，我也不是很清楚。为此，我特地进行了一番调研，希望我这篇文章的解读能解答大伙大部分的疑问。

我们先尝试从字面意思来理解一下，对于以下两个术语大家都比较熟悉：

这两个例子，相信大家都能理解没有问题。关于测试敏捷化，类似地，从字面意思可以这样理解：

那么，“敏捷的测试”是否等同于“敏捷测试”呢？从字面意思来看，似乎是等同的。但事实如何，需要对两者有深入的理解才可以下定论。

为了更好地解释，有必要先介绍什么是敏态与稳态。

在数字化转型时代，企业一方面需要适应数字化时代快速变化的市场需求，另一方面需要保持关键业务的安全可靠和稳定性，传统的IT需要同时适应这两种业务形态，面临很大的挑战。为了应对这种挑战，Gartner公司提出 双模IT（Bimodal IT） 的理念：

传统企业数字化转型的常规做法是可预见性的业务使用传统瀑布式开发，称之为 稳态 ；探索性的业务使用敏捷开发，称之为 敏态 。Thoughtworks洞见安辉的文章 《敏捷转型中的敏态与稳态》 对此有比较详细的介绍。

当然，稳态和敏态的这种做法在业界也存在争议。Thoughtworks数字化专家肖然在文章 《数字化时代的科技双模，双模IT成为过去式》 中指出：

尽管如此，传统企业转型过程中，基本都会长期经历敏态和稳态共存的阶段，对转型有着积极的意义。从长远来看，最终还是需要转型到组织级的敏捷，实现真正的全流程端到端敏捷的。

关于敏捷测试，引用Wikipedia的两段话：

从Wikipedia的定义可以看到：

同时，Thoughtworks的资深QA们基于多年敏捷团队开发实践经验提炼出的 敏捷测试宣言 ，非常清晰的表述了敏捷测试的价值观：

敏捷测试是 基于敏捷价值观“快速高效地交付更大的价值”这个目标 ，所开展的所有质量相关活动，是从团队的角度去思考如何实现这个目标，而不再是以测试这个活动/角色的角度出发，不能简单地理解为“敏捷的测试”或“敏捷地测试”。

关于敏捷测试的更多详细内容，欢迎参考刘冉老师的 《Thoughtworks的敏捷测试》 文章和我的 《敏捷测试》系列 文章。

测试敏捷化这个概念来自于双态IT联盟发布的 《测试敏捷化白皮书》 （以下简称“白皮书”），这里直接引用该白皮书中的内容来解释测试敏捷化。

从前面引用的内容来看，测试敏捷化是将测试作为 独立主体 ，从测试的角度出发来考虑优化和改进。

基于白皮书的内容，双态IT联盟还发布了相应的成熟度评估模型，这个成熟度评估也是 基于测试的几个维度 进行的：

到此，我们可以比较清晰地看到测试敏捷化是围绕测试在解决问题，考虑的更多是测试价值的体现。

了解了概念，再来从背景、目标、主体、关注点和适用范围这几个维度集中对比一下测试敏捷化与敏捷测试：

从上表我们不难看出测试敏捷化与敏捷测试具备较大差异：

敏捷测试是产生于敏捷软件开发模式，在这种新型开发模式下需要考虑如何满足质量保障的需求，自然而然产生了敏捷测试。敏捷测试是遵循敏捷价值观的，其目标也是跟敏捷开发一致，那就是快速高效地交付更大的价值。

测试敏捷化则是在数字化转型过程中敏稳两态共存的情形下，传统IT稳态模式的测试团队面临转型挑战，旨在帮助测试团队实现转型。因此，测试敏捷化的目标主要是为了体现测试的价值，提升测试团队的敏捷能力。

为了实现目标，敏捷测试以全功能的敏捷开发团队为主体，关注软件开发全生命周期的质量相关活动。敏捷测试不再是以测试这个检验环节/活动为主，不会强调某个独立角色，而是要求团队整体为质量负责，实现测试左移、持续测试和测试右移，快速获取反馈，从而真正实现软件产品的质量内建。

而测试敏捷化是以测试作为独立主体，以测试的角度出发考虑优化改进，主要关注点包括测试需求、测试计划、测试设计、测试执行等测试过程，以及环境、数据、技术、工具等测试的支撑。

如上面数字化转型示意图所示：

敏捷测试产生于敏捷开发模式，必然适用于纯敏态的开发团队。同时，敏捷测试的一些方法和实践，也可以被稳态团队所借鉴并适当采用。

测试敏捷化由于背景、目标、主体和关注点都不同于敏捷测试，是不宜用于敏态开发环境的，只适用于稳态环境。

数字化转型的确给传统测试团队带来很大的挑战，一方面要配合敏态团队实现测试开发融合，另一方面还要面临稳态测试如何优化改进的问题。

测试敏捷化虽然在一定程度上帮助转型中的稳态测试团队，但是不能从根本上帮助转型的实现。另外，前面提到敏稳双态共存模式不过是转型中的一个过渡阶段，是否要为这种过渡时期的稳态模式投入较多精力，请深思而前行。

测试要实现转型以适应敏捷开发模式，不能只是测试人员的转型、也不能只是测试工作方式的转型，只有改变文化理念和认知方式、调整组织架构和沟通方式、优化流程和策略、采用有利于快速反馈的工具与实践，按照由内而外的“道”-“法”-“术”-“器”方向实现彻底的转型，才有可能实现真正的敏捷测试。这个内容我在文章 《数字化转型背景下的测试转型》 里有非常详细的介绍，请移步阅读。

敏捷测试不是“敏捷的测试”，也不是“敏捷地测试”，而测试敏捷化是“敏捷地测试”，两者不等同。

由于测试敏捷化的背景、目标、主体和关注点都不同于敏捷测试，是不宜用于敏捷开发模式的，只适用于传统企业的稳态模式，也不能帮助稳态团队实现敏捷转型。而敏态、稳态共存本身就是数字化转型的过渡阶段的产物，因此在稳态测试团队采用也需要谨慎前行。

传统测试的真正敏捷转型需要遵循“道”-“法”-“术”-“器”方向、实现由内而外的转变才能实现。

超融合软件解决方案可以适用哪些场景？

首先，软件方案和一体机方案如何选择？

如果 IT 规模比较大，会涉及到当下或未来使用多个服务器品牌的可以考虑购买超融合软件产品自行构建方案；

服务器用量较大，具有议价能力的，也可以考虑通过购买方案降低整体的方案成本；

对于虚拟化、硬件等运维能力强的客户可以使用软件方案，但对于运维能力不强的客户建议一体机方案以便降低维护和服务支持的复杂度。

其次，超融合可以适用于哪些场景？

具体可以参考Gartner 在其报告《Critical Capabilities for Hyperconverged Infrastructure》。里面提到了超融合的 6 大适用场景与 11 个评估关键点。

Consolidated：以降低 TCO 为目标的不同层级 IT 设施整合的数据中心超融合项目。

Business-Critical：用于承载类似 ERP 等关键业务，并用于提升可靠性与可扩展性的超融合相关项目。

Cloud：用于承载基于私有云设计的新型应用或重新设计的核心应用。

Edge：支持和 IoT 设备接口，并基于边缘计算相关应用、微服务的超融合相关项目。

ROBO：被远程管理的非主数据中心，亦可用于作为 IoT / 边缘计算的桥接基础架构。

VDI：VDI 架构可通过 LAN/WAN 的方式，通过远程显示协议访问，通过超融合简化部署而受益。

以上 Gartner 定义的六大场景包含重要信息：

超融合最早被广泛的应用的场景以 VDI 和 ROBO 为主，即使是生产环境，也用于非核心生产系统，但时至今日， 超融合已经完全覆盖了传统架构中块存储覆盖的所有的领域，甚至包含企业级核心应用。

超融合作为私有云的重要基础，同样成为超融合的一个重要应用场景。

目前热点的边缘计算和物联网领域，也成为超融合的一个重要应用场景。

如何做好项目进度管理？

题主提到了项目集、项目经理和工具这三个关键词。其实涉及到专业的项目管理，还需要结合具体的场景，比如主要是敏捷还是瀑布管理，是否是金融体系内的“稳态” “敏态”的双模管理等等。不考虑场景因素，单从项目管理工具来看，这种复杂场景需要怎样的产品，能支撑起完整的项目流程。

先来看看企业研发管理的经典流程：

项目经理从开始就贯穿整个业务的始终，其中的协调工作量之大，过程之艰辛可想而之。

根据Gartner的2019项目和项目组合管理魔力象限，在决定什么对企业的业务最有利时，以下能力是必不可少的：

项目需求管理

项目规划和管理

时间管理

资源管理

资源容量规划

项目组合管理

项目协作

项目管理

报表服务

安全和用户管理

集成

可用性

这也是ONES研发管理工具覆盖的能力。为了能够做到真正有效的项目管理，我们来看看ONES日常坚持的项目管理原则和工具的使用。

一、合理规划项目进度

根据项目特点和具体情境，选择合适的进度计划。对于需求范围明确、变化可控，稳定性价值高于灵活性的项目，可以适用瀑布开发方法，制定详细的进度计划、严格执行；而需求尚不具体且范围多变导致的延期，往往需要保持项目计划设计的灵活性，可以借助甘特图、工时管理、项目资源方法和工具，合理规划项目进度。

1. 科学预估、管理工时；合理拆解需求，制定里程碑计划，完成任务拆分；各层级工时预估结论、整体排期计划公示、也可以通过周会制度，随时同步项目的推进过程，一旦发现有延期风险，要及时地应对，避免风险堆积

2. 有效评估和管理项目资源：面对资源冲突、过度分配和临时性调动问题，通过项目任务、和项目成员工时报表、资源饱和度统计，了解各项目资源投入情况。优先级更高的需求、领导临时安排插入的影响可追溯，平衡整体资源

二、规范和控制需求变更

项目需求变更原因多种多样，无论是客户发起、还是公司/团队内部原因所致，正确的认识变更，管理相关方预期，规范变更流程，控制变更范围，跟进变更后需求状态和进度影响范围…都有助于降低项目延期风险、控制延期影响。

1. 统一对项目目标的认知：对项目整体目标、重要任务优先级达成一致的前提下，分析需求变更的背景和内外部原因，按照既定的优先级和资源情况理性沟通

2. 规范需求变更流程：结合具体业务场景，确定严格和正式的需求变更工作流程，防止随意、不必要的需求变更导致的进度延误

3. 评估变更后影响、更新进度：对需求变更导致的返工任务量、资源浪费情况等影响评估和记录，并按照最新的需求规划更新进度计划

三、制定更高效的沟通方法

项目沟通贯穿信息从搜集、管理、流通、执行、最终反馈的全流程。伴随项目复杂程度提升和团队规模扩大，高效的沟通除了传统集中办公、会议、周报等制度之外，也可以借助更多的工具和方法。

1.可视化工具：如看板、燃尽图等，帮助团队所有成员直观了解项目进度情况，任务背景状态、负责人、已完成项和剩余工时等一目了然、清晰可见

2. 在线的团队知识库：共享项目计划和文件，文档资源及时共享，帮助不同角色职能快速找到答案和可用经验

3. 项目沟通流程规范和会议制度：尤其是跨团队沟通的流程和规范，团队所有成员都按照统一的标准和规范执行，降低沟通成本

4. 营造团队合作的良好氛围：多多促进成员之间的日常交流让他们更亲近，从而在工作中更容易合作

当然，如果你用的是国外软件例如Jira这样的项目管理工具想迁移到更好用的ONES也没问题：）

ONES Project支持从 Jira 导入数据，数据范围包括但不限于：

导入用户、用户组和 Jira 系统配置；

导入项目配置，包括 issue type、workflow、field config、权限配置、通知配置；

导入任务数据，包括属性和属性值、迭代、评论等信息。

这个功能可以让之前使用过 Jira 的团队和企业将数据平滑迁移至 ONES，不需要再进行繁复的手动数据输入，即可开启高效研发之旅。

Jira 导ONES 总共分三步！

导出Jira — 导入ONES— 开心的使用！

1. 从 Jira 导出数据包

在 Jira 左边栏主菜单 Jira Settings (设置) System (系统) Backup manager (备用管理器) Creat backup for cloud (创建云备份) Download cloud backup (下载云备份)

2. 将数据包上传到 ONES

管理员在 ONES 主菜单 团队配置中心 从 Jira 导入数据 开始导入 上传数据文件，此过程将会持续 30 分钟左右，在完成导入后将会邮件形式通知管理员。

成功的项目都是相似的，失败的项目却各有各的原因。作为一款优秀的研发项目管理工具，我们接下来会持续为大家分享项目管理中的那些坑和国内外各类项目管理经验，希望我们一起向阳生长！

数字化运营管控是如何提升管理透明及效率的！

全文摘自《数字蝶变：企业数字化转型之道》电子工业出版社出版/赵兴峰著

运营是国内企业发明的词汇，也是国内互联网企业为了推广而创造的一种模式。笔者虽然没有在国外互联网企业工作的经历，但咨询过国外互联网企业，包括谷歌、微软、Facebook、Twitter和爱彼迎，这些企业都没有运营（Operation）部门。而国内的阿里巴巴、百度、京东、腾讯都有运营岗位，这里的运营更多强调的是联通营销和销售，实现线下或者实际转化的环节。在一定意义上运营连接了产品和技术，实现了互联网网站或者app的用户经营。

传统企业组织中可能没有运营岗位，此时，运营是指整个企业的团队管理和组织管理，包括组织的绩效管控、团队的绩效管理，以及整个企业管理活动效率的提升。除对营销和销售环节重点管控外，也需要对整个组织的效率进行有效监控，所以必须建立一套指标体系进行跟踪管理。

运营管理效率是一家企业执行力的体现，是将战略目标在组织层面进行分解，然后逐步落实并实现的过程。国内的企业经过一轮执行力和领导力的洗礼，多数企业比较强调结果的重要性，随着“请给我结果”“以结果为导向”“用结果说话”等各种执行力培训和执行力文化的熏陶，越来越多的企业强调结果的重要性，忽略了过程管理的重要性，把过程中的管理和控制交给团队完成，发挥团队或者个人的创造力，确保结果达成。

不能评价说强调结果是错的，但是过程管理也是非常重要的。同样，不同的团队实现的过程不同，其耗费的企业资源和花费的时间不同，这是过程差异造成的。如果效率不高，方法不当，为了达成目标，越努力的员工对企业造成的损害就越大。很多人会反对这种观点，认为这种观点太绝对，毕竟很多企业还是需要努力工作的员工，而不是需要非常聪明的员工。有些执行力“专家”也强调“认真第一，聪明第二”或者说“速度第一，完美第二”。这些不是不对，而是在数字智能时代，企业应该用更多数字化的分析提升理性决策，而不是让员工凭借一腔热血拼命努力。

在笔者服务的一家企业中，有几个新人非常努力，每天通过打电话接触200个以上客户，但是因为沟通技巧很差，销售能力弱，成交转化率不高。但是，他们非常勤奋，非常努力。这些客户电话都是企业通过百度推广后转化到企业网站上并留下的联系方式。每一个留下电话都是有兴趣的客户，这些客户成交转化率对企业来讲尤其重要。因为百度推广需要花费企业的营销费用，一个留下电话的客户线索的平均营销获客成本都在500元以上，如果销售团队不能有效转化，就会浪费前期的营销推广费用。

这几个新人每天接触200个以上的客户，每个客户的线索成本为500元，每天这几个销售人员接触的200个客户都花费了近10万元的营销推广费用，如果不能有效转化，就会浪费企业的资源。企业的平均转化率为15%左右，而这几个新人的平均转化率不足5%。如果平均获客成本是3000元，那么这几个新人的获客成本则达到1.5万元。他们越努力，给企业造成的损失就越大。精细化运营强调的不是越努力越好，而是需要更加有效地努力，这就要求企业加强过程管理，把握每一个运营环节。

企业数据化管理的升级路线如图4-5所示。

图4-5 企业数据化管理的升级路线

行政部门的工作也都是可以量化的，但需要采集数据并建立指标体系，对运营的各个环节进行数据化和指标化，让所有运营活动都用数据表征，这样企业就能够精细化运营管理的各个环节，提升过程管控的力度和粒度，提高管理的精细化程度。

每一项运营管理活动都是企业投入的成本和费用。站在老板的角度，员工的每一项活动都是企业的费用，所以必须量化企业的投入，然后用指标表征每个活动的投入产出效率。在梳理运营管理活动指标时，从企业经营绩效的角度考虑，一般包括五大类指标，即规模指标（数量）、速度指标（增长）、效率指标、效益指标和风险控制指标（见图4-6）。

图4-6 经营和管理中的数据指标

规模指标是对数量的统计，在运营管理中必须量化员工的行为，每天做多少事情，接触多少客户，发送多少封邮件，给多少个客户回复电话，每天实际工作多长时间等，这些都是量化的指标，可定义为规模指标。运营活动首先必须保证有足够的量，这样才能有足够的产出。

速度指标也是成长性指标，除了保证规模、数量，还需要在这些数量上不断增长。增长是一家企业管理效率的核心指标。没有一家企业不存在管理问题，当企业的规模不增长时，很多管理问题就会暴露出来。增长是解决几乎所有管理问题的良药。一家企业要想持续发展，必须有足够快的增长速度指标，如果企业连续3年不增长，则基本就会倒闭。

效率指标是指投入与产出之间的比值。投入都是为了产出，如果企业投入100万元做广告，带来1000万元的销售额，那么广告的投入产出效率就是1∶10，营销费用率就是10%。如果投入10个人，带来1000万元的产值，那么人均产值就是100万元，如果人均工资是10万元，那么投入工资的产出效率就是投入1元产出10元，人工成本率也是10%。这些都是效率指标，效率决定企业是否能够以更低的成本产生更高的产出。在同一个市场上，企业间的竞争就是比效率，效率高的企业会战胜效率低的企业。

效益指标是指企业经营管理活动的净产出。投入100元，产出110元，净利润就是10元。效益是产出和投入之间的差。效益高低决定了企业是否有足够的收益，也决定企业是否有足够的资源再次投入。

风险控制指标经常被管理者忽略。风险控制包括经营风险、管理风险、组织风险、法律风险、市场风险、技术风险等。如果一家企业的资产负债率过高，则有较高的经营风险，一旦盈利性差，就不能支付利息导致亏损。如果管理团队不稳定，则会有管理风险。如果组织有被竞争对手猎取或者被投资者收买的风险，则组织的稳定性就变差。企业经营的业务受法律法规的约束，有违规行为会带来法律风险；市场风险包括竞争对手、潜在进入者及替代产品的风险。如果替代产品的生产成本大幅度降低，则企业的市场风险就会加剧。技术风险则比较容易理解，产品的更新换代及技术创新应用都有可能导致本企业产品失去竞争力，或者失去市场。

通过指标监控企业所有的运营管理活动，一旦出现较大变动则要具体分析相关情况，随时管控运营过程，确保企业稳健和持续发展。

目前，外部环境的变化越来越快，消费者的消费习惯正在发生剧烈变化，B2B的业务也在发生巨大变化，客户的采购行为和采购方式也是日新月异，数字化的趋势正在渗透到每一个行业。如果企业无法快速适应这个变化，就会面临各种危机，企业组织必须敏捷应对。

上文提到“感知—响应”模型。在“感知—响应”模型中提到了一个“感知—响应”周期的概念。通过一个周期的感知响应，能够掌握一次知识的迭代，企业对外部环境的认知就能够迭代升级一次。一家企业每天重复各种经营和管理活动，如果在每次经营管理活动决策过程中都进行迭代，不断升级认知，不断提高经营和管理决策的精准性，并且随着外部环境的变化随时调整自己的方法和方案，企业就是敏捷组织。如果在这个过程中不能迭代，或者迭代太慢，那么这个组织对外部环境变化的响应就是迟钝的。

在运营管控流程中引入敏捷管理的概念，就是希望所有的企业管理者在做管理决策的过程中用数据说话，而不是用经验说话。不是经验不对，而是经验仅仅是过去数据的积累，在自己大脑中形成的知识，随着外部环境发生巨大变化，这些知识就会过时，就需要运用现在的数据和信息重新思考决策，从而使企业经营管理活动中的决策能够随时应对新的场景和变化。

数字智能时代要求企业组织响应外部环境变化的频次越来越高，所以每个月一次的月度经营分析会议已经无法适应新环境的要求。在大数据时代，企业必须要建立一套数据感知响应系统，通过即时的数据采集、数据分析及决策，实现即时响应，并在快速迭代中形成应对外部环境的最佳策略。

为了适应这个需求，领先的企业都在尝试新的组织变革，包括阿里巴巴等互联网企业、华为等研发制造型企业，以及其他传统的零售和连锁服务型企业。它们通过信息系统打通各个环节，建立一个数据中台，为前端提供即时的数据分析和决策支持，为后端服务提供数据上的服务。

企业通过建立数据中台，将信息系统中的数据进行汇集、清洗和加工，为业务部门提供数据服务。数据中台所发挥的作用是数据治理、数据管理、数据汇集、数据开发、数据分发及数据应用服务。数据治理包括数据的清洗加工，建立数据标准，形成高质量数据资产目录，为数据开发提供集中的数据仓库。而数据管理功能则包括数据监管、数据动态存储和处理，数据安全，数据资产使用的集中管控，以及数据共享机制的建立。数据汇集则包括数据的提取，一般采用ETL（Extract，Transfer，Load）的方式从信息系统中提取数据，并以一种具有关联关系的中间表建立数据之间的业务逻辑，从而保证数据不是孤立的，而是具有各种“血缘关系”的数据集。数据开发是为了满足数据应用将数据开发成数据报表、数据图表或者数据模型，这些成为数据中台上的数据产品，类似于阿里巴巴平台上的生意参谋或者店铺管家一样的数据服务。数据分发则是在其他信息系统需要调用数据时提供加工清洗过的高质量的数据，并按照一定的规则为其他信息系统提供数据集，包括主数据的管理与分发、数据表的管理与分发等。而数据应用则是在业务部门的业务需求基础上提供的服务，如果销售部门希望能够对客户进行画像处理，那么数据应用就针对客户信息和客户行为相关的数据进行处理，提供一个具有标签的客户信息表给业务部门使用。数据应用服务还包括数据接口，通过API的方式为其他应用提供数据，通过基于字段和数据表的授权使用。

企业在数据资产管理上建立数据中台之后，在组织中就可以设立业务中台，从而为前台的营销和销售部门提供基于数据的决策支持服务。强大的中台能够大幅度提升前台响应客户需求的敏捷性。

“三台组织”的概念示意图如图4-7所示。

图4-7 “三台组织”的概念示意图

不同企业的业务形态不同，“三台组织”的设计也会有所不同。例如，采购，如果企业采购的是标准化的物料、原料或者配件，没有太多个性化的产品或者定制化的原材料和配件，基本都是标准件、标准化的产品，如钢材、水泥、石油、标准化工原料，其市场供应充足，是完全市场化的采购行为，此时采购响应度不是影响组织响应度的关键，在这种情况下采购部门可以被放到后台。但是，如果前端的采购有特殊性，采购的物料需要定制化，有一定的采购周期，甚至有一定的垄断性，与供应商的合作有一定战略合作性，必须结成伙伴才能有更好的采购响应度，此时的采购就需要被纳入前台管理，利用数据中台服务，为采购部门提供更加精准、及时和高效的服务，确保在整个供应链管理上不会拖后腿，保证整个供应链的敏捷性。

企业利益和个人利益不一致是正常现象，这必然会导致个人在处理企业问题的过程中或多或少都会因为考虑个人私利而出现与企业利益不一致的现象。首先，必须承认这是正常现象。如果没有这种现象，那么企业基本不需要管理，企业里每一个人都像老板那样处理事情，企业一定有更高效的产出。所以，企业中一定会有大量的“灰色地带”需要监控，即使是没有任何权利的一线员工也有偷懒的时候。

数据是企业经营和管理活动的记录。如果数据记录无所不包，企业就能够精细化地监控所有的行为和活动，能够精准地分析各种活动的效率，能够知道哪个环节出现问题导致流程不畅、效率不高、效果不好。这是一种理想情况，企业管理越精细，员工就越能将自己的行为与企业的利益绑定到一起。

笔者第一份工作在宝洁，进入之后就是两个月的新员工入职培训。在这两个月的培训中，笔者感触最深的就是“在宝洁，没有记录下来的事情就没有发生过”。后来在其他外资企业工作时，笔者也看到过这种类似的要求，所有的经营管理活动，只要可能都要在系统中记录，而且这些记录都可以拿出来进行数据分析，以便有效地优化管理。这种习惯在国内企业中是比较少见的，国内的企业比较强调个人能力，喜欢空降高层管理者，更看重高层管理者曾经在某一个行业成功运作过一个产品、一个品牌或者一个项目，希望他过去的成功能够在本企业继续成功运作。而多数的外资企业则不同，它们更强调系统的强大、组织的强大，而不是依赖个人的强大。组织的强大和系统的强大来自系统自身的优化，而这种优化需要在不同代的管理者之间进行传承，这种传承能造就一个强大的组织。其实很多知识的沉淀是从数据中总结规律的积累，因为企业会投放很多次广告，不断监控广告的效果，所以应该更加清楚地知道如何投放广告才能有更好的效果。如果不能把数据记录在系统中，则只会是在这个岗位的人掌握这个规律，他离开了，新来的人就不知道如何投放广告才会有更好的效果，还需要重新摸索一遍。这些知识源自数据分析，沉淀在企业系统中，要形成可传承的经营管理诀窍，这样的组织才会在发展中越来越强大。

如果没有数据记录和数据分析所形成的知识沉淀，就容易存在浑水摸鱼的现象。笔者听过这样一个故事，李××是企业的销售经理，在最初做销售时，一次给客户报价，企业要求的底价是95元/件，李××给客户报价96元/件，而对方的采购经理还价98元/件。李××当时懵了，因为他第一次见到还价还有提高价格的，还以为对方听错了价格，再次确认，对方还价还是98元/件。后来有人告诉李××，中间差价是这个采购经理的回扣。李××可以向企业报以95元/件的价格成交，中间每件商品3元的差价他拿1元，采购经理拿2元，这样李××既可以完成销售任务还有回扣，采购经理能够采购到商品还有回扣，企业也能够按照底价卖出，看似四方都得利了，其实这就是很多企业在经营管理中的“灰色地带”，或者称为监管不到的地带。这种问题如果经常出现，就会让公司的整个管理机制变得非常混乱。同时，因为这些事情让双方的利益绑定在一起，他们的关系非常紧密，其他的业务员就无法切入。很多企业的采购经理到了另外一家企业之后，会继续沿用原来的供应商，而把之前的供应商取消；很多销售经理换了工作，也会把客户带走，这背后的逻辑就是利益的绑定。

没有数据记录，没有即时的数据采集，没有线上报价和线下监督机制，就无法暴露这些问题。现在多数交易是通过线上完成的，减少了中间人的参与。没有了人为的参与，这些利益截留就没有了空间，这样很多企业的管理就会正规化，交易成本就会下降，而且更加容易维护客户关系，不会因为销售经理的更换而流失客户，也不会因为采购经理的离岗而流失优质供应商。

当然，变革是痛苦的，因为这种新的模式必然损害一些人的利益，受到一些人的阻挠，因为数据化管理必然带来“阳光化”的治理。企业老板在推动变革时也可以看到，谁在阻挠，谁可能就是既得利益者，他们担心因为数据化管理之后的“阳光化”，导致个人利益受到损害，他们会找各种各样的借口阻挠数据化的应用。

“阳光是最好的防腐剂，而路灯是最好的警察”。如果一家企业想整治不正之风，让数据化管理发挥作用即可。

随着数据技术的应用，企业管理的沟通方式也在发生变化。过去在科层制组织下，员工既不能越级汇报，也不能越级管理，从而确保每个层级都发挥自己的决策和管理作用。但是随着社交媒体在企业组织管理中的应用，原有的组织形态正在逐步被打破。

在科层制组织下，组织的分工是按照专业和能力进行的，不同的专业领域被分配在不同的科或者部门，财务负责财务方面的工作，人力资源负责人力资源的工作，生产负责生产的工作等，不同部门是按照专业分工的。而层级则是按照能力分工的，能力强大的做高层，能力中等的是中层，能力差的在基层。这种科层制在最初的组织设计上发挥了专业和能力，使每个人都能够找到自己的位置，最大限度地发挥员工的专业和能力。但是，这种组织形态也牺牲了组织决策的效率性。在传统工业时代，重视专业能力而忽视决策效率这种组织形态没有太大的问题，因为所有的企业都是稳步管理的，是一个稳态的市场，在几十年内行业甚至都不会发生太大的变化。

但是到了互联网时代，这种组织形态制约了决策的及时性，禁锢了组织的敏捷性。所以，以谷歌为代表的互联网企业提出了围绕产品和服务的蜂巢式组织，就是基于一个产品或者服务，建立产品经理专门负责该产品或者该互联网服务，然后在这个产品或者互联网服务上配置对应的专业需求的人才，包括财务、人力资源、前端开发、后端运维、营销和销售职能，所有这些职能都由产品经理负责，所以建立了财务BP、人力BP、技术BP等。这种模式在互联网企业中非常普及，国内的腾讯、阿里巴巴、百度等前期也都采用这种模式提高决策的效率。在这种模式下，企业“短、平、快”地决策，考评机制也做了对应的调整，从原来基于业绩指标的KPI（KeyPerformanceIndicator，关键业绩指标）的考评评价体系转变为基于短期目标的OKR（ObjectiveandKeyResults）考评体系。稳态组织的KPI逐步被敏态的基于目标达成的考评机制所取代。

数据技术驱动的组织形态变革可参考图2-11。

图2-11 数据技术驱动的“跨界打劫”现象

随着互联网创新应用和数据技术的崛起，外部环境变化越来越快，这就要求企业更加敏捷地响应外部环境变化。为了响应客户的一个需求或者一个投诉，为了一个客户的招/投标、一个工程项目的方案，组织内部直接拉起一个“群”（可以使用QQ、微信、钉钉，也可以使用企业内部的聊天工具），这个群里有高层管理者，也有基层员工，群里的汇报关系不再是层级汇报，而是跨部门、跨层级，甚至跨越了企业组织的边界，把合作伙伴拉到群里一起沟通。这样企业就有了一个临时响应客户诉求的新的临时组织，组织成员在这个群里进行沟通和汇报，研讨方案，及时响应，及时决策。当这个客户的诉求消失时，或者项目结束时，这个群就会被“解散”。我们将这种临时组织称为临时的“军团”，这个“军团”的成立仅仅是为了一场小小的“战役”，这场“战役”结束，“军团”解散，重组成另外的“军团”，从而应对其他“军团”战斗。

“军团制”体系对组织的弹性要求更高。这与稳定的劳动关系形成了落差：为了保证团队的稳定性，企业与员工必须有符合劳动法的劳动关系，必须是雇佣制下的稳态关系，这与敏态的“军团”组织形成对立。一场“战役”结束，有可能下一场“战役”还没有到来，人员又恢复到稳态的科层制组织关系中，而没有战斗时，人员闲置，组织承担了太多的人工成本。当组织战役大小不一，任务、项目或者工程所需要的人力不同时，更是一个巨大的挑战。所以，未来的组织将趋向敏态的、松散的组织关系，有更多的人可以以战略合作伙伴的形式参与企业的“战役”中，当“战役”结束时，组织解散，没有劳动关系的制约，企业可以以更低的成本，个人也可以参与另外一个组织的“战斗”中。所以，员工社会化的组织更像是这种“军团制”的模式。企业组织形态发生变化，企业的组织模式也会发生变化，组织与人的关系也将发生变化，越来越多的人成为自由职业人。

滴滴专车司机是独立的个人，与滴滴没有直接的雇佣关系。当一个消费者的出行订单在平台上生成时，滴滴派遣最近的司机接单，并完成这个订单。这个订单结束，滴滴与司机的合作关系也暂时结束，滴滴司机继续在平台上等待接单，完成下一个“任务”。这种基于任务模式的组织是未来组织的主要形态。

敏态化的组织不仅要打破层级结构，还要打破组织的边界，开始跨越组织边界进行用工，这就需要更多的战略合作伙伴参与整个组织的“任务”中。虽然这对一些相对较为复杂、技术含量要求较高的工种的可实现性具有挑战，但随着组织形态日趋敏态化，企业组织逐步成为一个生态，越来越多的人成为生态中的一员。

从组织建设的视角看待这个问题，企业的人力资源部除了有稳定的企业员工，还要建设一个人才生态圈，能够在企业有临时重大需求时获得临时的“雇佣兵”参与作战，同时可以用生态组织的方式扩大企业的“作战能力”。宝洁在研发上一直领先于竞争对手，其战略合作模式就是将企业的产品创新交给一个平台，这个平台上有大学教授，也有技术人员，还有在校的研究生。宝洁将技术难题放到平台上，平台上的专家、学生和技术人员就可以“接单”，攻破难题后根据知识产权采购的模式，宝洁回购这些技术专利或者知识产权。在研发创新不成功的情况下，宝洁不需要支付费用，同时宝洁会提供一定的费用作为研究支出，平台上的专家和技术人员都可以自主申请。通过这个平台，宝洁打破了企业原有的组织形态，用生态伙伴的方式吸引更多人为自己提供技术创新。现在宝洁每年的技术创新几乎有三分之一都来自这种方式。

感谢您阅读本篇对敏态项目和稳态项目的详细介绍，如果你对什么是敏态和稳态业务还不够了解，想进一步学习关于敏态项目和稳态项目的知识，可以在本站首页搜索你想知道的！