我们应该如何在商业上建设台湾

原标题:商业上的台湾建设应该做些什么？

对作者来说，由于公司的业务和产品特点，在台湾是非常必要的。因此，在中国大陆和台湾的实践中，笔者总结和分享了如何建设一个中国大陆和台湾的企业。

这个冬天，外面的寒冷让人不寒而栗；产品经理，一个有强烈生存欲望的生物，不仅需要考虑如何度过严冬，还需要帮助老板降低成本，提高效率，以度过严冬的互联网。中国大陆和台湾可能是一个不错的选择。

一、为什么选择中国？

我负责的产品是订单调度管理平台，涵盖计划、商品、订单、审批、执行、文档生命周期管理等模块。它是一种操作管理产品，具有混合产品线和冗余模块，以及各种配置和规则。

面对新业务的出现和变化，它超出了现有产品的承载能力。

有许多产品线和不同的产品逻辑。至于产品，很难在全球范围内掌握——。如果一个产品需要调整和优化，很容易产生产品遗漏或产品设计漏洞，导致生产问题。

此外，对于开发测试，由于新业务的产生，通用产品计划会反复开发测试，这不仅会造成开发资源的严重浪费，还会大大增加后期产品运行和维护的压力。

因此，随着越来越多的商业场景的发展，开发建设越来越多，产品管理变得越来越臃肿。

因此，优化订单管理平台结构，创新产品管理方法迫在眉睫！

此时，我们会慢慢思考，我们将如何看待订单调度管理平台？我们设定了几个主要方向:

中国台湾解决方案已经慢慢进入我们的产品愿景。什么是中国台湾？简而言之，它是一个企业级的能力重用平台。专业上，它是一种结合互联网技术和行业特点的企业结构，将企业的核心能力与共享服务中心相结合，形成企业快速、低成本进行业务创新的“大、中、小前台”组织和业务机制。

那我们为什么要选择中国？

能力沉淀：

自2018年以来，虽然互联网投资资本的趋势并没有下降，但投资热已经有所收敛，资本流动不再盲目“追风”，更加理性和集中。

资本主要集中在头部，尾部的一些初创企业甚至没有收到任何新的投资。

资本是利润驱动的。当整体经济形势不是很好的时候，可用的钱就少了，钱就不那么容易赚，也更容易花。有必要节约成本，降低各成本中心的成本，找到节省开发、人力和产品成本的方法，甚至从员工福利开始。出国已成为“去新马泰(马群新街口、冯路、泰国)的一日游”。

然而，产品层面的中国-台湾架构受到科技公司的高度追捧，因为它可以显著提高人均效率。

快速响应：

公司的规模已经发展到一定程度，现有的传统系统架构肯定无法支持业务的规模和复杂性。对于新业务，企业级系统会不断调整。不稳定的系统将导致系统巨大的使用风险。如何确保系统的稳定性和可用性是产品需要考虑的问题。

此外，当业务发展非常广泛时，还应该考虑产品的另一个问题，即如何积累和输出产品的能力，通过有效的产品管理和设计，使平台的各种能力(功能/产品)能够被快速重用和组合，以支持业务的更快探索和发展。

稳定输出：

在互联网出现的前十年，企业发展迅速，无偿积累互联网产品和系统开发资源，建造了许多烟囱。然而，在过去的两年里，这种研发方法只有很少的商业价值和利益。——一些产品线的建设成本很高，但业务已经崩溃，导致开发资源的极大浪费。

例如，产品部门有几十个开发团队，他们每年只能处理数百个需求。研发团队每天必须加班到晚上9点左右。作为一名产品经理，他们每年必须召开数百次会议，只有在每天18336000次会议之后，他们才能认真撰写文档并进行产品设计，这几乎与研发的下班时间相同。

但是即使每个人都这么努力工作，产品部门的需求周期仍然非常长，整天都有来自业务部门的抱怨。一年后，创新成果并不多，对新业务的反应速度仍然很慢。

因此，中国台湾建筑摆脱了“烟囱”系统建设模式带来的各种发展桎梏，通过统一的公共技术模块进行服务分离。当再次需要服务时，通过接口调用来完成，从而避免了重复的车轮构建，延长了研发周期。

模块化管理：

还有烟囱产品。如果一个企业有很多格式和复杂的场景，企业的后台产品往往不能支持前台快速、创新地响应用户的需求。后台更关心解决企业管理效率问题，而中层能很好地解决前台创新问题。

虽然大多数企业已经有了后台，但是要么前台根本不能使用，要么不容易使用，要么变化速度跟不上前台的节奏。前台需要变革和创新，而中间办公室需要稳定和稳定。依靠现有的产品结构，这个问题似乎不能很好地解决。

因此，企业有必要建立一个稳定可靠的中间平台系统，拥有一个能够快速迭代、美观的前平台系统。

资本角度：

在过去的两年里，这项业务发展迅速。商业环境变得越来越复杂。短暂、平稳、快速的业务创新和不断的错误是为了节约成本。

我必须在这里提到，supercell Company ——可以通过组建一个拥有2到5名员工和不超过7名员工的独立开发团队来参与新游戏的开发。如果游戏不受用户欢迎，——可以迅速放弃产品，用最少的资源再试一次，不断创新和反复试验。然而，这是公司资源的最大节约。中国电信可以支持他们这样做。

规划调整：

此外，随着用户增长红利的逐渐消失，互联网市场变得饱和，市场开始挖掘用户的存量。用户在选择应用程序时变得更加理性，互联网产品也从野蛮增长转变为精细操作——

人们躺在树下摘水果的日子一去不复返了。通过开发几个系统，这种产品不容易取胜。我们必须认真制定产品计划，一步一步降低产品成本，但我们仍然必须承担更多的责任，也就是说，马吃得更少，还必须做得更好，做得更多。

2。如何成为中国电视台？

面对订单调度管理平台，他现在是一个整体，基本上没有前端和后端部门。产品线从收据开始到收据结束，由产品经理负责。产品线似乎非常清晰，在现有规模下是完美的，可扩展性差。如果我们将前端、中间和后端分开，哪些产品是前端，哪些是中间端？我们中国台湾的性质是什么？

从产品线的角度来看，大致可以分为几个产品线:采购线、退货线和转移线。

以采购为例。只要一个产品经理负责采购相关事宜，这就是产品线责任制。该方案在业务逻辑简单、场景单一的情况下非常有用。

然而，随着商业的发展，各种各样的小产品(售前、售中、购中)出现了。因为不同

此外，每个产品线都将涉及用户操作页面。不同的产品经理会设计不同的产品功能，因为他们的风格不同。同一平台下的不同模块将给用户带来不同的用户体验。通常会有业务需求:作为一个产品经理，你所做的和由产品经理设计的页面一样好。多么尴尬的要求！

从现有架构来看，订单调度管理平台的产品线管理是按照产品线模块进行纵向分析和划分的。我们应该更换什么结构模块来切割前、中、后三个阶段？

至于中国，有几种类型的中国-台湾:数据-台湾，商业-台湾，组织-台湾和技术-台湾。从产品设计和使用的角度来看，订单调度管理平台本身就是一个为现有业务需求实现信息管理的业务系统。因此，我们应该构建一个属于企业台湾的平台，即:

基于抽象复用、结构理性和统一业务管理的视角，通过业务逻辑适度抽象和灵活的复用功能设计，抽象、复用和汇聚产品管理方案，构建企业级的功能获取平台。

拆分前、中、后舞台

研发模式：

刚开始接触前、中、后舞台。前台的印象停留在前端的概念上，这是页面和后台逻辑之间的区别。

因此，我们的团队分裂了。一个团队负责页面，所有与页面相关的都属于前台产品。然后后台负责复杂的业务逻辑。在这种划分之后，矛盾立即突出了——

作为一种业务需求。页面的前台产品图、前台产品编写的逻辑和前台产品不是用户界面体验部门。

为了满足同样的需求，企业和产品都被愚弄了。最初，一个可以由一个产品处理的产品计划需要投入两到三个人力资源，这不仅没有节省劳动力，而且浪费了资源。

因此，这绝对行不通！

在与技术沟通之后，经过进一步的探索，我们能不能按照技术系统的细分来做？

订单计划系统有两个技术系统。系统甲负责预测计划，系统乙负责文件执行。

这样，前台产品负责系统A，中间的前台产品负责系统B。最好从产品需求开始。

但奇怪的是，有些前台产品需要调整系统B的逻辑，而中国和台湾的产品有时会与系统A相联系，因此产品之间的矛盾已经解决，技术矛盾也越来越突出，这也不是很好。

后来有了新的变化，因为系统A通常负责预测计划，系统B负责文档执行。然后我们将根据产品类型进行划分。前端产品负责需求方，而不管页面或逻辑如何。无论页面或逻辑如何，文档执行都要对中国台湾产品负责。这样，技术矛盾也就解决了。

然而，在我看来，这也不是很好。——不能解决快速业务发展和缓慢系统响应之间的矛盾以及重复浪费资源的问题。

随着对中国和台湾的深入了解以及建筑师的交流和研究，中国和台湾逐渐获得了更深层次的认识和理解，即——

前台是一个小的商业场景。中国和台湾通过派遣各种资源为前台部门和前台业务服务。中国和台湾需要做的是抽象、沉淀和整合背景资源，将其打包成便于前台使用的可重用和可共享的核心能力，并将背景资源的易用性简化到前台。

事实上，在这个过程中，对现有的商业场景进行了分析。对于现有的零售场景，商店和中央仓库下有各种商业场景(售前、无人货架、生鲜和家居)，包括超市、便利店、高端商店，规模不是很大。

此外，公司正处于探索阶段。对于一个商业模式，比如bento模式，可能需要一个月的短时间才能上线进行试点，半个月后

慢慢地，经过痛苦的分裂期以及前台和中间桌之间的磨合，我对中间桌的理解逐渐变得清晰。企业级产品管理需要稳定性和快速响应。稳定和反应是两件矛盾的事情。中间的桌子就是这样一个矛盾的变速箱，匹配前台(车轮)和后台(发动机)之间的速度矛盾，达到最佳传动比，提高发动机效率，降低油耗。

因此，我们的细分不是简单的系统、页面和文档类型的区别，而是小企业场景和抽象能力沉淀的划分。在小场景中也有一般的逻辑。然后，我们将在产品管理中将其沉淀到资源整合和打包的中央平台，以提供稳定的输出，并将其转化为前台友好且可重用的核心能力。我们的前台是各种小型产品场景下的前端系统。它们就像用户联系，是企业和用户之间最直接的联系。

小场景产品快速迭代上线，而中国和台湾则不断抽象沉淀，从而解决前台和后台的失速问题，帮助企业不断提高用户响应。

3。我们做了什么？

从业务抽象到领域建模，再到架构设计，逐步构建一个订单调度管理系统的中台产品管理模式。作为中国和台湾的产物，从0到1的中国和台湾建设应该从本质上保持中国和台湾的思想。我们做了以下事情:

Business Abstraction

结合当前的业务情况，比较和分析各种场景条目、文档管理和文档信息流，设计业务蓝图和抽象业务元素，隐藏业务细节和抽象业务对象。

在抽象过程中，中国和台湾的产品就像工程图的建模一样。过一会儿，我会缩小公共工程图纸的范围，看看整栋房子看起来好不好，再看看整幅画，看看整体效果是否在控制之中。过一会儿，我将不得不放大，看看细节是否画到位，看看房子的结构在每个细节上是否合理。

因此，业务的抽象必须站在产品架构和控制以及计划产品管理的某个层次上。落在产品功能设计上，足以设计易于使用的功能和出色的交互体验。

中央台湾核心产品模块规划

经过业务调查和分析，基于前一阶段的主题领域输出，技术架构师根据中心的多重划分标准规划产品模块。从业务管理和产品管理的角度，总结了总体架构设计。在覆盖所有现有业务场景的基础上，整个产品架构易于扩展和组合，并且可以支持动态扩展、精确监控和其他目标。

抽象与集成实现，建立最小产品模块

产品功能设计是在产品模块规划的指导下，从上到下，从粗到精的抽象过程。它主要将业务抽象结果转换成产品管理方案(主要由业务场景和业务流程组成)。通过设置最小产品模块，实现了产品的模块化设计，通过将所有最小产品功能模块像积木一样快速组合在一起，可以实现业务能力输出。

一旦确定了中国和台湾的总体思路，产品经理就可以自由地独立推进中国和台湾的建设。

product management segmentation and delivery

将组装好的产品分为前部、中部和后部。总体思路和详细设计完成后，是产品管理的灰度切换和交付，这只是输出商业价值的开始。通过经营管理，商务中心和台湾不断沉淀和发展，能力将逐步增强和拓展，模式将逐步调整和完善。

事实上，中台计划解决了现有企业遇到的矛盾和问题，但在实施过程中，中台并不是一个完美的计划，在这个过程中，也感受到了中台产品管理的弊端。

中国和台湾产品的知名度越来越高

尽管中国大陆和台湾隐藏在前台业务场景的背后，但它们也会收到业务需求报告。然而，对于业务优先级调度，我们有两种主要的需求类型:中国和台湾建设将自行解决需求和业务需求。然而，每次安排资源时，不确定性都会非常大。有可能由于业务需求紧迫，中国和台湾无法安排对中国和台湾建设的需求，导致错过了中国和台湾一体化的最佳时期，进而做出可能需要更多资源的改变和调整。

因此，中国大陆和台湾的需求非常不稳定，但毕竟我们是一个面向业务的产品平台，无法将这两种需求提升到同一个维度进行优先排序。然而，中国和台湾的产品必须为一些中国和台湾的基础设施节省一些资源。

前期建设资源占用量大，短期内没有明显的商业价值产出。

对于订单调度管理平台，中国-台湾的前期建设需要两个月的人力和自然资源来满足每一个需求。整个改造后，基本上可以做几十个大项目。因为没有业务价值输出，业务同事也无法理解，所以资源占用很大，而且相互矛盾。产品经理必须能够承受压力并量化价值指数。随着公司的发展，中台的价值和利益将逐渐显现。

4。“中国-台湾经验总结”我认为中国-台湾产品应该这样做:“弱水3000，我只拿一瓢水”。虽然有3000个弱水，但中国台湾产品的经理可以拿一瓢水。我认为这很适合对中国台湾产品的旧词进行新的解释。总结自己的经验，并与大家分享:“中国和台湾产品必须保持实力，随时做一些基本、重要和不紧急的事情。

因为互联网公司多年来一直相信“只有快速但不被打破”,所以团队在制定优先级时倾向于做那些具有最明显商业价值的事情。许多重要和非紧急的任务被推后，再也没有被提及。

但是对中国台湾产品团队——有不同的要求。中台产品必须保持实力，始终做一些基本的、重要的、非紧急的事情。

许多企业的信息化建设部门停留在业务支持层面。看来甲乙双方作为以业务为导向的产品部门，提出了当前的业务需求，并以项目为基础管理产品工作。企业不会过多考虑系统的整体结构。它已经完成了一个烟囱项目，也就是说，这个项目已经完成，并被投入另一个项目。

作为中国和台湾的产品经理，他不仅要考虑业务的需求，还要在项目过程中不断整合基础产品管理，通过项目的力量一点一点地改善中国和台湾的建设。

应尽快抽象出具有明显共性的功能模块。

订单管理调度平台属于B端产品。许多产品具有明显的共性，可以尽快抽象出来。

这样，在系统架构构建的初始阶段就可以做出正确的设计方案，这不会增加太多的研发工作量，并且会使系统将来的扩展更加容易。如果平台建造到一定程度，在分裂前、分裂期间和分裂后，调整水平井涌结构确实需要很大的努力。

适度抽象商业逻辑，不要对未来想太多。

在中国和台湾产品设计的早期阶段，没有必要为未来不确定的事情提前做太多的布局。业务逻辑的适度抽象和灵活的重用功能设计就足够了，因为它们很可能在将来不会被使用，但会导致过度设计、开发资源的浪费，甚至使系统架构看起来非常奇怪。

业务价值和面向需求系统的抽象迭代

没有明确的好处和价值。强制采用中台概念设计会在业务中造成混乱和恐慌，并可能对业务的正常运营造成不利影响。在最初阶段，某种程度的非理性是可以容忍的。然而，中国台湾的产品管理必须体现业务需求，并能量化业务价值