消息模块几乎每个产品都会拥有，而消息模块的设计是一个产品成长过程中必备的一个环节。特别是针对高频业务消息的分发，消息模块是业务模块的中间件，与不同的第三方、业务系统联动，保证企业核心业务流程的正常运转。本文以消息中台的思路设计方案，最终落地消息中心方案，以消息收发为基础应用，为不同业务线提供支撑。
当我们的团队集中度在一个产品时，我们的消息系统其实可以做到很简单，简单来说，核心目的是为了在适当的时间以合理的内容告知用户他应该知道的消息。
如果将消息独立一个系统，那么消息本身不存在应用价值，但是在业务线中，与其他业务流程进行组合，那么一个消息的价值可能就是一个量级的转化。
那么在一家成熟的企业来说，一个产品远远是无法支撑庞大的商业模式，所以想要提升自身的发展，无过于开源和节流。
开源即展示新的业务线，拓展新的产品线，都是一家企业打开了新挑战，对未来是存满不确定性的。而节流则对资源的合理利用，梳理现有业务流，剔除重复资源，减少重复劳动力。
那么在整合消息相关资源时，我们会发现最直观的问题：不同的产品线消息模块重复建设，从效率层面来看，本身可以通过一条流程走完的消息流，6以多分支的方式，各自做各自的工作，形成了应用资源和开发资源的浪费。
由于每个产品线的消息模块都是一个自成一体的系统，所以在业务人员或开发人员来说，都是一件头痛的事情，因为团队同时要对多套系统进行维护。
那么我们要如何通过一个消息中台来分发不同业务线的消息呢？下面笔者将详细分享自己对于消息中心从0到1的设计经验（以下内容数据方面有一定的模糊处理，仅供参考）
一、业务背景
1、业务调研
想要对消息业务有所了解，我们需要先找到一个突破点，即日常工作职责中必须用到消息的职能部门。我们要对业务进行调研更多是对于一个流程、一套闭环工作进行了解，如果是需求调研更多是为了解决一个点的问题，而我们现在要对于整个流程进行了解和整理。
业务调研的流程，首先是要明确为什么要做，原始驱动力是什么？然后明确我们最终的目标，然后以目标反推哪些人与之相关。
知道要去找哪些人后，我们要先提前把问题想好，避免大眼瞪小眼的尴尬。把你不了解的、不熟悉的都记录下来，通过深入访谈或者会议进行沟通，访谈时采用提示引导法。通过你的问题引出他的想法以及问题。然后梳理不同角色的调研结果，通过结果总结分析问题。
前期调研方式和调研问题决定了我们后续对于消息中台的定义和设计，所以这里一定要仔细分别调研时的会谈价值，分析时同时要基于企业不同产品线考虑，尽可能做到多角度分析比对。
同样，如果你对消息没有概念，对系统没有认知，只是知道这套系统具体功能是做什么的，这样是远远不够的。你需要对外进行调研，我们可以适当进行竞品调研，这里可以推荐大家几个消息平台作为学习参考，这里仅介绍国外产品，国内的产品大家搜索引擎找一下都可以找到。
One Signal：OneSignal: High Volume Mobile and Web Push Notifications
VWO：：VWO - Application
AirShip：Airship
由于很多人确实没有对消息触达和架构这块并没有经验，而且也没有做过开发工作，所以是需要多学习一下竞品的流程与模式。当然，学习参考并不代表抄袭，因为别人有的你也抄不来，抄过来了也不代表适合你。但是我们做任何一个产品的时候都要保持敬畏之心，对竞品了解是最基础的。你可能会认为：人家做都也不怎么样呀，都没有上市。但我要告诉你，当你在了解其他产品时，有一条底层逻辑要谨记，任何一个消息推送类产品只要存在市场上，那肯定有它所具备的优势。
除了对外调研，内部的调研同样不可缺少，这里可以提供大家几个方向问题，帮助大家在调研消息业务时，进行业务方面的了解。
请麻烦描述一下目前我们的消息推送全流程是如何实现的，与哪些第三方渠道对接？
目前业务方面对于消息的主动触达方式有哪些？频率如何？有没有遇到什么问题？
你们在使用公众号推送/邮箱推送/App Push/站内信推送时是如何进行推送渠道的筛选的？不同的渠道对应的是哪些业务场景？
目前我们的消息业务是否可以满足现有应用场景和客户群体，对于更多有助于公司业务提升的场景中，我们有哪些不足点可以进行优化？
在没有消息渠道触达客户时，我们目前是如何与客户进行沟通的？沟通的结果如何？是否有相关的数据支撑呢？
通过几个常规性的问题，帮助我们了解最基础的业务流程，即使你对公司现有对业务流程非常熟悉了，我建议你也需要走一遍业务沟通，因为我们其实带着问题的同时，并不是说只需要知道这么几个问题，而且通过非常规的提示引导法将我们的沟通对象进入思考状态，让对方逐步把细节阐述出来，然后我们从细节开始分解核心进行梳理。
2、业务背景
在调研过后，我们对基础业务有来一定的了解，对消息的闭环流程同样也做到来略知一二，那么我们要开始梳理整个业务背景。
整体业务背景是你做这件事最原始的论点，而业务数据就是你的论据。以数据结合背景阐述我们即将要做的事情。
首先我们要明确消息是用来做什么的，在实际的业务场景中，消息分对内与对外两大类型。
内部消息属于单独在我们不同业务系统里进行分发，我们需要将不同的消息分发给对应岗位的小伙伴。
对外消息是产品与用户沟通对话的方式，外部消息有很多不同类型，但是最终目的是一致的，都是为了触达用户，让用户及时收到节点信息。
例如电商平台最常见的订单退款情况，当发生订单退款时，公司内部应由哪个职能部门去处理，我们应该将这类消息告知该部门下的哪个小伙伴。
当专门处理退款的小伙伴解決这个问题后，如果拒绝退款的情况下，我们要第一时间告知我们的客户，让用户知道自己的订单已经处理完毕，处理后通知的效率也影响用户对产品的好感。
比如Apple的订单取消邮件通知，只要你收到了邮件，打开了邮件，对方的数据就会同步接受，从数据中知道了你看到了这个消息。
如果订单正常处理，同意了退款，那么该订单退款业务扭转到了财务部门。同样，财务部门相关小伙伴也需要收到消息，及时告知，及时处理对其审核，同样处理完成后，也需要对外给予用户不同类型的消息通知。
那么到这里我们已经了解消息对于产品业务的重要性，那么为什么我们要推出消息中心呢？
例如我们公司目前处于快速发展阶段，由于公司业务线正在快速拓展，不同的产品线也正在逐步增加，与此同时，不同的产品线均需要通过消息模块来触达客户。
原来我们均以功能的概念在设计，那么业务资源和开发资源会存在大量的重复消耗，而且在维护方面也存在诸多问题，同时需要维护多套系统业务。
为了适应公司的业务发展以及未来不同场景下的消息应用，我们将引入中心概念，以中台作为业务定义，推出新的消息中心。拆解模块之间的职能，解决重复造轮子，反复改问题的现象。同时将不同的消息渠道整合，为不同的业务线提供不同场景的应用支撑。
用几句话概况一下目前现状，问题概况以及实际影响，最终推出消息中心，在阐述背景时，尽量要结合企业目前的战略计划，比如目前企业的不同业务线都在中心化推送业务发展，那么我们这叫顺势而为。反之就需要从其他角度切入，说出最恰当的理由来支撑团队做这件事。
3、问题原因与数据
消息应用背景明确后，那么我们需要论证，但是口说无凭，当当靠你的嘴巴很多情况下无法说服团队成员。那么你就要抛出一些与业务方更贴切、更实际的问题。比如为什么现阶段我们要做消息中心？
产品营销体系已搭建完成，缺乏统一触达渠道，无法及时触达用户；
不同业务系统的消息通知能力独立分散，对不同业务系统的消息无法管控；
消息数据价值未被挖掘，消息相关数据仍然未掌握在平台，无法通过消息数据优化质量；
这些问题看上去都很重要，我们对问题也要进行简单拆分，问题分两类，一类属于未来预测型问题，另外一类属于资源合理型问题。
未来预测型问题，就是要把以后发展中会遇到的问题前置，将可见的问题抛出，这类情况更适合高速发展期的企业，比如产品营销体系目前已搭建完成。我们的运营会通过营销活动来提升客户活跃度。
当我们举行一场圣诞节活动时，一场大型活动对不同价值的客户有不同的营销策略，那么在活动开始前，我们会通过邮件通知客户。
比如我们分发了20万张优惠券，20万张优惠券分发后，均以邮件通知和短信通知触达，如果没有及时的数据反馈，那么最终我们无法知道这10万封邮件最终会有多少的打开率与点击率。而10万封短信会被多少用户拦截拒绝亦或者打开。
平台触达用户的消息是很容易体现活动效果或推广效果，通过最终的效果反推未来的客户营销策略，如缺失了这部分的一体化消息，会影响用户后续的消息关注度。
就像这封Quora的邮件，消息反馈的设计可以整理为三个角度：首屏数据、内容数据、整体数据。单单通过一封邮件内容，推送给几十万个用户即可获得到海量的用户数据，从中我们可以分析出不同类型用户的喜好，对此我们可以从数据进行优化，满足用户的需求。
那么资源合理型问题更适合想要进行节流方向的产品方向，直接从现有的案例来引导，目的在于建立消息资源的重要性。
例如目前我们企业整体还没有属于自己的消息平台，营销邮件和营销短信都是通过第三方来进行发送。而由于业务的快速发展，单单邮件就需要发出2000万封左右，在不计算人工成本的情况下，每月第三方的消息推送工具费用达到$50000，对于企业自身来说，这就是一种资源的浪费。
从简单的一句话中，我们就知道这个问题的影响面以及价值，而这些数据都需要通过实际与业务、销售、运营进行调研得出，通过实际的数据集合反馈问题。
在整个业务背景中，我们不仅在前期调研数据，了解实际问题。而且我们要抛出企业现阶段的问题，问题不多但是要尖锐，特别是价值敏感性人群会对这部分问题特别感冒。结合企业战略为方向进行取舍。
二、方案目标
1、方案目标
怎么理解方案的目标？方案目标即最终要达到的目的。在设计目标时，尽可能与企业目前战略目标一致。正如任正非说的“力出一孔，利出一孔”，战略聚焦是公司有组织能力的体现。
任何一套业务都要与战略保持一致，当然，战略目标也在变化，唯一不变都就是变化，所以我们也要适应变化，比如我们现阶段都战略目标是为了实现市场占有率达到20%，而目前市场占有率只有10%，如何从消息中心层面帮助整个企业提升效益，这就是我们要做的。
我们目标设计时，需要考虑三个核心；
1、可落地性强；
2、可预期设计；
3、基于现有数据设计；
一句话来概况就是这个目标要高且完成率要尽可能高，这里的目标仅仅指的是长期目标，长期可实现的目标作为消息中心的方案目标。
2、整体架构方案
在了解方案背景以及实际问题后，我们就需要抛出方案。而方案中最核心的就是架构，消息中心架构代表了整个方案组合内容，往往架构代表整个骨架，而这个骨架已囊括了未来我们大多数设计和应用场景。
这里我们要抛出的是整体的业务架构，至于后面的功能架构和技术架构不需要在此处体现。
消息中心整体由App Push服务、系统通知服务、微信推送服务、短信服务、邮件服务、浏览器推送服务、聊天室系统、工单系统、内部消息系统九个基础模块支撑
以上仅仅是笔者在设计消息时，公司目前的消息相关业务架构以及未来设计，不同的产品业务肯定会有更多更加灵活的组合方式。
这九大基础模块中，每个消息都对应不同的场景，比如
App push：针对现有A产品线的服务支撑，通过定期定向定量的推送促进客户打开率以及活跃度，同时B产品线以及C产品线的App正在进行构建中，后期同样也可以支撑这两条产品线。
微信推送服务：截止2020年底，目前国内微信拥有11亿多用户量，而针对国内业务我们除了短信服务触达，微信推送目前是主流渠道之一，而且微信推送包括小程序推送和公众号推送，这两类几乎不需要成本，对于国内用户多触达率更高。虽然微信推送会有内容方面的限制，但是我们的推送大部分都是基于与用户的互动业务消息，是用户愿意主动接受的消息。
同样，我们在设计消息架构的时候，必须要考虑的是消息的重叠度，即A类消息与B类消息的触达场景重叠度。
比如我们设计A类消息时，必须要考虑这类消息推送的频率以及人群，这是这类消息的价值点，避免重叠度是为了最大程度降低公司重复资源以及对同类客户的打扰。因为过于频繁的打扰客户，不仅会降低品牌好感度，甚至客户会拒收或者屏蔽平台的任何消息。
那么九大服务用来为不同的产品线作为服务支撑，包括项目A和项目B，产品A和产品B，CRM系统、MPC系统......
简单来说，消息中心为不同业务应用平台提供消息系统的支撑，帮助不同业务系统完成基础消息的闭环流程。
不同的消息对于不同的业务线有哪些具体效益，我们可以举例说明，比如产品A是一个国外SaaS电商平台，那么针对国外的用户群体，我们调研了A、B两类客户群体。
通过分析这两类客户群体，我们发现行为模式中有一些共通点。由于互联网发展周期原因，目前仍处于PC互联网时代后期。
PC互联网时代中邮件是主要通讯方式，所以我们针对这类用户的通知，特别是偏向业务相关、营销相关的通知会以邮件为核心，作为高频触达的手段，有效与我们的客户进行双向的沟通。
而另外一方面，PC中必然包括了浏览器，而Chrome长期占据国外浏览器市场的近70%，几乎达到了垄断的地位。
所以针对这类客户触达，我们会首先考虑用浏览器推送进行重要业务消息的通知。由于这类通知是单向的通知，无法与客户进行双向沟通渠道，所以这类消息我们会降低发送频率，提升推送质量，保证有效触达。
同样，我们也考虑到浏览器市场的丰富多样性，所以根据2019年某市场分析数据，处于第二位的火狐浏览器以及Edge浏览器各占据近10%，所以后续我们也会根据最终触达效果考虑增加不同浏览器的推送。
后期我们会将以上九大基础服务产生的业务数据进行整合，以消息类型纬度对数据进行分析，通过企业内数据中心反馈的数据，对最终的推送效果进行二次、三次优化。
消息的优化肯定是基于大量的数据，而不同的公司业务线不同，数据来源也会不一样，比如我们的数据是全部来源于数据中心，由数据中心进行初步的数据清洗，然后我们负责通过接口进行调用、查看、汇总。如果没有数据中心，那么大部分消息数据会存储在消息中心，由于消息中心进行数据的汇总整理；
最终我们会通过消息数据来优化触达率、点击率、打开率、转化率、停留时长等等，实现对消息的内容、频次、人群精准推送。
三、方案拆分
1、阶段拆分
方案的阶段拆分是一件极为痛苦的事情，因为实际上你的方案要做的是一个大方向的事情，但是在阶段拆分时，你要开始细化，细化到每一阶段应该完成什么。
在这里，根据消息中心的目标，我们拆解成三个阶段：
产品打磨期：确定产品PMF（Product Market Fit 产品市场匹配度）帮助我们快速调整产品方向。最终验证产品开发与应用的设计是否成立可用。
产品发展期：通过消息结合业务系统挖掘客户价值，通过不断放大客户价值，组合不同职能团队，将消息体系进一步完善，做到精细化运营客户。
产品迭代期：通过市场反馈形成关键数据指标，倒推产品提升核心漏斗数据，提升每个业务数据指标，降低每个流程的断点率与流失率。
那么我们将三个大阶段继续拆分，拆分成不同的版本，比如第一阶段的产品打磨期，我们将会拆解成几个大版本，每个大版本再拆解成3-5个不同的小版本；
我们在设计版本迭代时，根据现阶段的目标不同可以酌情进行调整，但是便于我们的任务可执行可落地，我们必须进行多次拆解。
产品规划中内容有一定删减（仅供参考）
每个阶段都应该有对应都阶段性目标，这里需要再次说明都是，每个阶段性目标都要以大版本迭代为核心。
以小版本进行迭代有很多优势，比如我们可以增加阶段性产出价值，并且同时降低试错的成本，不断通过内部使用进行迭代，特别是首个版本上线后，除了主线外，我们还需要另外有一个快速更新对版本，这里笔者称之为快速版本。
快速版本是为了解决大版本之间存在的问题，并且保证系统在稳定的线上环境时可以正常处理业务，保障业务之间的抗风险能力。以快速版本作为产品快速迭代形式更新，既能减少每个小版本之间的摩擦又可以提高整体产品的质量。
2、版本拆分规划
首个版本其实是最简单的，因为我们的目标是最明确的，做基建，打地基。首个版本我们要明确在有目标且只有一个目标的大前提下进行拆分。
将每个小版本的需求通过表格的形式罗列起来，通过表格你可以清晰的看到在某个版本计划下，我们应该做哪个模块下的哪些需求功能，这些需求的优先级如何。
那么对应的需求功能具体可以实现什么，预期完成时间是什么时候，具体有谁来做。最终技术实现时间预估在什么时候，这些信息内容都可以通过表格一目了然。
当然，这些表格里面的内容除了你自己看，也需要定时定期的更新，因为你自己要根据表格里面的内容对自己未来一段时间的工作进行规划排期。而我们的老大可能也需要看到你的进度，那么你的这张表就是你的预期产出时间以及未来的时间点。
首先要明确解决的问题，完成该目标后，我们可以解决什么问题。例如我们v0.11版本要完成消息中心整体架构的搭建，并完成对产品A业务系统的整体消息支撑。
由于产品A属于面向世界的产品，所以不仅仅是针对国内的客户，更多是触达到国外客户，所以我们会把现有的邮件服务迁移到消息中心，集中一个中心对外出口推送邮件。
如果只有一套邮件服务，其实这个问题还好解决，那么如果我们有多套业务，如何解决这个问题？事实上，如果你对消息了解，你就应该知道一种推送方式其实有多种形式可以接入。
比如第三方邮件平台服务、自建邮件服务、邮件代发服务...那么如何选择？结论是：根据自身业务应用场景选择，在设计消息模块时最忌惮“拍脑袋”行为。每一步都要为未来都应用考虑，且每一步都会造成企业成本，如果一步做错，后续会影响整条业务线的消息。
所以当你不知道如何选择的时候，我们可以先把自己的方向列好，然后把每个方向的市场优劣势都曝光出来，尽量在优劣势中进行判断。但是这里极有可能会被自己都主观判断和认知所影响，所以在完成整理后，可以与同事、小伙伴探讨几分钟。
最终从几个方案中选择最合适的，这里不管是邮件服务，还是App push、浏览器推送...都是有不同的解决方案的，作为产品人应该学会找到所有的方案然后从中挑选对于不同产品下的最佳应用方案。
在确定方案后，接下来就要明确方案核心流程，方案核心流程必须要有多个角色，因为一个中心肯定会给予多个业务系统做支撑，所以我们的核心业务流程要保持一致
如上图，这里我们可以拿着一个客户触发业务节点，这么一个基础的场景，把整个方案的基础逻辑阐述清除。具体描述比如
我们通过客户端触发业务节点，然后不同的业务系统会接受到客户端传递的参数，然后业务系统由自身去组装业务节点的参数，通过不同的参数发送到消息中心。消息中心接到相关指令后，进行基础的校验，校验通过后开始对消息类型进行判断，比如刚刚所说的邮件服务，邮件需要走第三方的通道，所以我们需要组装第三方需要的参数，然后通过第三方消息平台发送，第三方会返回发送的结果给我们。然后我们对数据进行最终对存储与校验。那么最终消息会由第三方发送给我们的客户端，完成消息的触达。
核心业务流程其实很简单，但是对于不懂相关业务的小伙伴来说可能会有些勉强，所以我们需要用简单易懂的文字帮助不同认知阶级的人理解。
基于核心业务流程理解后，我们也需要有更具体抽象的当前阶段的规划业务流程，比如说我们的邮件是怎么发送怎么创建的？我们的浏览器推送是如何发送如何创建的？
细化到一个业务流是如何执行的，那么你需要把具体这个业务流是如何走通整理出来，有一套完整的闭环，从消息的创建到消息的编辑。
在实现流程闭环时，我们始终要记得本阶段、本版本下我们的任务是什么，不需要做太多优化、美化的任务。
如果当前阶段我们只是完成消息的触达，那么我们的核心任务就是如何把这个目标实现。因为我们在规划时候无法做到十全十美，肯定会有一些细节是没想到的，所以我们就需要用一个个小版本堆积起来，然后做到统一处理。
对于当前版本规划已经明确后，我们这一阶段对任务就完成了，以上工作需要细心梳理，每个细节都可能成为你方案被失败打回重塑的理由。
3、原型设计
以上我们完成了消息中心近60%的工作，那么剩下40%就需要你在原型中体现，我们就要着手拆解原型，对原型进行优化设计。
设计原型前，我们需要先与前端沟通，了解一下我们前端的技术栈有哪些，比如你们公司前端目前的前端技术架构采用Ant-design（比较常见的Ant-design、Layui、element），那么你可以去网上找一下对应的UI框架元件库。
大部分设计架构在网上都是可以找到Axure的元件库，可以之间载入到Axure使用，好处就是你的前端很很容易可以看懂你需要的模块，减少重复的工作量。
在原型设计中，我们落实到每个细节，方案要大而广，具有前瞻性视角。原型要小而细，落实到每个细微之处。
笔者采用的是Ant-design，比如在消息列表页面，左侧是简单的logo、一级菜单和二级菜单，右侧是核心消息列表（功能页面），这种架构在多数国内的管理结构中都是比较合理的。另外需要注意的是，即使是在有框架的情况下，请不要发挥你天马行空的想象力，因为我们是内部使用效率优先，要学会适度适应每个人的接受能力，每个人的认知水平不足，如果你的原型设计过于“华丽”，有一定可能会降低入手门槛。
如果我们采用元件库做原型基础设计，那么我推荐你加上交互，比如我们的列表页面有一个失效按钮，是为了防止消息的异常情况下进行拦截，那么这种高危操作是需要进行二次确认的，所以我们点失效的时候，就要出现对应的提示内容，需要我们输入失效的原因。
在设计时，同样我们也会考虑在负面操作时，对【确认】按钮进行失焦处理，将焦点集中在【取消】按钮，这样会一定程度上引起操作人的二次思考，降低出错几率，
原型中除了基本的交互，还有具体的开发说明，当然，这点可以后置补充。
多数情况下，我们一开始不需要对细节进行补充，在技术评审的时候需要补充相关的细节，需要注意的是，我们在做一个消息中心（任何一个模块）时，我们都要对细节把控到位。
只要是在工作环境中，开发说明决定最终你与技术后期沟通的频率，但是作为开发出生的笔者，在国内工作时经常会看到某些产品人的说明是这样的
图片来自网络
从产品的角度可能没错，但是从开发的角度来说，心里不禁感叹：这是个啥？
如果你真的是在一家正规公司上班，有正规的团队，正在带领团队从0到1设计产品时，请按照标准的开发说明进行标准，包括每个字段的长度、校验格式等等。
举个例子，比如这是我们的消息推送页面，那么我们这里有8个地方需要说明（内容已经过一定删减）。
针对这8个数据，我们要进行统一说明，每个说明点可以将你可以想到的内容以及需要注意的点都进行简单的细致的描述。
具体的说明格式其实并没有一个标准，每个人都有自己不一样的习惯，比如我们是有数据字典，所以我们会有相应都数据编号。然后对应都数据字段的说明，都会放在数据说明，相应的交互说明也需要写入。
如果你在设计初版系统时，你不一定需要按照笔者这样做，因为笔者这样做也不一定是对的，仅仅是因为笔者自己也是一位独立开发者，曾经也在团队协作中深受其害，所以对说明要求会略多。但是我们的目标是一致的，都是为了提高团队效率，降低沟通成本。所以你需要把每个细节都说明清楚，这都是你未来与开发沟通，甚至讨论争论的原因。
原型部分网上的文章众多，笔者就不一一赘述，万变不离其宗，事就是这么个事，基于方案架构和流程的前提下，只要你把这个事说清楚了，你不管是用Axure、墨刀还是Word、Photoshop，我相信都是可以达到完成原型设计的目标。
四、总结反思
1、听取意见
当你完成整个消息中心的设计后，请谨记，要听取他人意见。学会聆听，因为完成这件事其实并不难，因为你在网上也可以找到很多细节可借鉴，但是你借鉴的不一定适合团队。所以你可以与主管、老大讨论，听取意见。
因为消息中心是需要长期与多部门、多产品协调沟通的，如果你一开始在做的时候就没有与其他人多讨论，那么后期由于业务拓展，很有可能整体架构很容易被推翻重构。
当然，关于团队的意见，笔者也有个题外话。笔者在这个阶段经常会发现身边的小伙伴会存在两个极端，要么从来不听取他人的意见，即使听了也不改，改了心里也是不服气的。要么对别人的话言听计从，几乎不需要自己思考，别人说啥就啥，别人说要改什么，他立即按冀索图解决某件事。
这两者都不能解决问题，前者很容易积累情绪，造成团队分裂。后者很容易长期变成“工具人”，有些人说，工具人有啥不好的，不需要思考也挺不错的。但是往往到了35岁以后，往往会有焦虑围绕着这些人，因为这些人在过往的工作中并没有学到什么，没有建立自身知识储备。
2、结语
对于消息中心来说，根据实际业务线的丰富度，相应应用场景也会更加复杂，所以我们在设计消息的落地场景时，对于不同场景的适用性挑战也会增大。但殊途同归，基于整个企业战略去做更多思考，总归会让价值落地。
笔者也在不断的复盘和总结中完成这一次整体架构的设计，当然，这仅仅只是开启，因为我们目前也仅仅完成了第一版的产品设计工作。基于现有规划的未来，肯定还会遇到更多的难题，但这也是身为产品的乐趣之一，希望能与正在看这篇文章的你共同成长。