IT瘾产品推荐

创业避坑指南：哈佛研讨会揭示“如何让产品被人真正需要”

Fri, 19 Dec 2025 14:02:16 CST

如果给正准备辞职创业的朋友推荐一个视频，你会推荐哪个？

我一定会推荐哈佛大学两年前发布的这场研讨会。这绝对是一期你在踏上创业之路前，必须看完的内容。

主讲人 Michael Michael，波士顿风投公司 Underscore VC 的创始合伙人。十几岁创办第一家软件公司，做了 21 年创业者，又做了 18 年投资人，经手的公司创造了数十亿美元价值。

不管你是正在琢磨创业想法，还是产品已经上线，又或者只是好奇为什么有些产品能卖爆，这场一个半小时的研讨会都值得你收藏起来反复品味。

Michael在开头就指出了一个非常残酷的现象：创业公司失败的原因有很多，资金断裂、团队内讧、市场变化…… 但排名第一的死因，不是钱不够，不是人不行，而是你压根没在解决一个真问题。

说白了，你做的东西，根本没人想买。

他有一句话非常关键：如果你觉得你的客户是所有人，那你基本上已经注定失败了。

Michael在这期研讨会里提出了一套非常完整的框架，从怎么定义你的客户，到怎么评估你的方案，再到怎么让用户觉得非买不可。

如果你真的能够完全吃透这期内容，那么你在创业这条路上一定可以比其他人走得更远。

搞清楚你的产品到底是做给谁的？

绝大多数创业者都会犯同一个错误，就是在去找投资人或者导师的时候，上来第一句话就是：我有一个绝妙的idea。

在Michael看来，想法这东西，是最廉价的。因为想法遍地都是，它本身是免费的，不值钱。

想法，只有在能够「解决某个具体问题」的时候，才有意义。

所以这个研讨会做的第一件事，不是教你怎么把产品做得多吸引人或者多牛逼，而是让你回答一个看起来特别简单的问题—— 你的产品到底是做给谁的？

真正能答好这个问题的人，少之又少。

研讨会上有个来自哈萨克斯坦的创业者分享了她的项目，是一个帮助贫困儿童获得数字设备的非营利组织。

Michael问她：你的目标用户是谁？她给出了非常具体地描述：是哈萨克斯坦偏远地区和边缘化社区的儿童，他们缺乏基本的数字素养，也没有电脑和设备。

Michael说，这就对了。

「想要把产品卖给全世界，这个目标对任何公司来说都太大了，即便是世界上最大的那些公司，也会把目标客户切得非常细。」

另一个团队在提交自己的商业计划时就犯了这个错误。他们做的是一个信贷比价平台，帮助用户找到利率更低的贷款产品。

产品逻辑很清楚，但问题在于，他们压根没说这个产品是给谁用的。是给刚毕业的年轻人？还是给有房贷压力的中年家庭？还是给小微企业主？

每一类人群的需求完全不同，你触达他们的渠道也不一样，你跟他们说话的方式更不一样。

不知道客户是谁，就不知道怎么找到他们，就不知道怎么打动他们。而这，是创业最基本的生存法则。

区分用户和客户

这里有一个很多人会搞混的概念，就是用户和客户。

用户是实际使用你产品的人，客户是为你产品付钱的人。有时候这两者是同一个人，有时候不是。

比如，很多SaaS软件的用户可能是一线员工，但客户是IT部门的负责人或者公司老板。

当用户和客户不是同一个人的时候，你需要的是，同时满足两种价值主张。用户需要感受到产品确实好用、有价值，愿意持续使用；客户需要看到投资回报，愿意持续付费。

Michael用了一个词叫pull，就是拉力。你需要用户产生拉力，主动要求使用你的产品。只有用户在用，客户才会愿意买单。

但光有用户用还不够，你还得让客户看到付费是值得的。

你必须保证两边都得照顾到，少了哪边都不行。

理解需求的层次

Michael把需求分成两个维度：一个维度是显性还是隐性，另一个维度是关键还是愿望性的。

最理想的需求是blatant and critical，就是显性且关键的。用户自己很清楚有这个问题，而且这个问题不解决会严重影响他们的工作或生活。

比如，你的牙疼得睡不着觉，这就是显性且关键的需求，你不需要有人来说服你去看牙医。

最难做的需求是latent and aspirational，就是隐性且愿望性的。用户自己没意识到有这个问题，或者意识到了但觉得不紧急、不重要。

比如，你告诉一个中年人他应该开始理财了。他可能心里知道这事重要，但总觉得以后再说也行。这种需求要转化成购买行为，难度是很大的。

所以如果你的产品解决的是一个显性且关键的痛点，用户的购买动力天然就强。如果你的产品解决的是一个隐性且愿望性的需求，你就得花大量精力去教育市场、唤醒需求。

计算收益痛苦比

这个概念非常重要，但很多人做产品的时候，其实完全没考虑过。

「收益痛苦比」的意思是，你的产品给用户带来的好处，必须远远超过他们为此付出的代价。

很多人做产品的时候只想着自己的东西多好多好，却忘了用户要使用你的产品需要经历什么：他要找到你，他要试用你，他要学习怎么用你，他要把数据迁移过来，他要说服他的同事和老板接受这个改变……

所有这些，都是痛苦。

而且不光是显性的痛苦，还有一种东西叫惰性。人天生就不喜欢改变，哪怕现有的方案不够好，他也会想，将就着用呗，反正也没那么糟。

所以Michael说，如果你想让用户真的动起来，你的产品带来的好处不能只是稍微好一点，而是要好十倍。对，十倍。因为只有十倍的提升，才能抵消那些看得见和看不见的转换成本，才能让用户觉得这件事值得折腾。

找到你的差异化

最后一个问题：凭什么是你？市场上可能有很多方案在解决类似的问题，用户为什么要选你而不是别人？

这就需要你想清楚自己的独特价值是什么，你提供了什么别人给不了的东西，或者你在某个维度上做到了别人做不到的程度。

说了这么多，其实价值主张核心就是一个词：清晰。

你要清晰地知道自己在服务谁，你要清晰地理解他们的痛点是什么，你要清晰地说明你的方案为什么能解决这个痛点，你要清晰地展示这个方案能带来多大的好处。

Michael在最后说了一句话：如果你自己都不能清楚地解释你在解决什么问题，那你为什么要做这件事？

想清楚你到底要做什么，比做什么都重要。

2026年如何开发软件产品

Mon, 01 Dec 2025 09:10:30 CST

1. 2026年后，纯粹的前端、后端、算法、策略岗位会越来越少，活得滋润的都是那种“左手敲代码、右手会让AI干活”的全能构建者。我问了十几个还在一线带团队的大牛，他们现在招人第一条要求就是：你能不能用AI把开发速度干到以前3倍？别再死磕手写一切了，学会借力才是王道

2. 版本控制不会Git的，2026年连面试都不用去了。SVN？那是上古神器，提了别人只会笑你。代码必须上GitHub，Gitee只适合放一些不能见光的小项目。最重要的安全常识：凡是能把你账户搞爆的东西（API Key、私钥、数据库密码），全部写进.gitignore，永远别犯低级错误，不然分分钟被人薅羊毛

3. 云服务器直接选最新版的Ubuntu LTS，Windows Server除非你想天天跟环境配置打架。想省事到极致？前端项目直接丢Vercel，免费额度够用一辈子，git push一下全自动构建部署，10秒上线，爽得飞起。很多百万用户量的独立开发产品到现在还在用Vercel免费版，真的香

4. 域名必须是自己的，越短越好记越好。别再用一堆乱七八糟的 http://github.io二级域名了，看起来就廉价。像wquguru这种个人品牌，直接买个短域名，所有产品都挂在子域名下面，用户一看到就知道是“老王家出的东西”，信任感直接拉满。我现在看到好的短域名就跟抢茅台一样下手

5. 部署必须Docker化，不接受反驳。以前最常见的扯皮就是“在我电脑上能跑”，现在直接给别人一个docker-compose.yml，谁都能一键跑起来。参考我自己的项目结构： https://github.com/wquguru/llm-council-zenmux… ，根目录干干净净，所有服务都能单独起，别人拿过去改两行就能用

6. 前端铁打的组合：Next.js + Tailwind + Shadcn UI。为啥？因为所有大模型在这套技术栈上训练的数据最多，让Claude Code帮你写组件，90%的情况下直接能用，改两行就完美。想用React + AntD也可以，但你会发现AI吐出来的代码永远差一口气。Python党想快速出demo就Streamlit，但只准做内部工具

7. 后端新手直接上FastAPI，老鸟随便你用啥。逻辑不复杂的全栈项目，直接用Next.js的API Routes就够了，全程TypeScript一门语言吃天下，上下文切换成本为零。性能真到瓶颈了再去搞NestJS、Go、Rust，到那时候你已经有钱请人了

8. 项目文件夹要让人看懂，更要让AI看懂。根目录建议这样分：frontend、backend、agents、docs，再加两个神仙文件夹：.spec（放所有规范和决策记录）+.chat（把跟AI的关键对话直接cp进去）。下次你或者别人让AI接手维护，它直接就能看懂前因后果，效率直接起飞

9. 做AI Agent千万别先摸LangChain，那东西就是黑盒子中的黑盒子，调试到崩溃。直接上官方SDK：OpenAI SDK、Claude SDK，代码量少20倍，Token省30%，还100%可控。我现在所有新Agent项目全部原生SDK，调试速度快到飞起

10. 数据库+认证直接Supabase一把梭，开源的Firebase，免费额度离谱地高，后端代码能少写80%。缓存用Upstash，Serverless Redis，跟Vercel无缝打通。一个月几块钱就能扛住几十万日活，独立开发者闭眼冲就对了。省下来的钱和时间拿去喝奶茶不好吗？

分红型ETF：挑选红利类产品的6个要点（03.03）

Tue, 04 Mar 2025 18:19:07 CST

最近有很多朋友在后台询问，如何挑选红利指数产品？

今天正好发布的《分红型ETF》专栏，简要的说明一下挑选思路，下述方式也适用于大部分指数产品。

本文第二部分，分享了《20个A、H股标杆型红利ETF产品》，建议收藏。

一、挑选红利类产品的6个要点

1、关注指数加权方式

红利因子是红利类指数最关键的因子，指数成份股常以股息率倒数排序，以股息率高低加权。这就决定了，股息率越高的成份股，其权重越高，对指数的影响也就越大。

指数每隔一段时间会被动调整样本，剔除股息率降低的成份股，纳入更高股息率的成份股，从而被动实现“高抛低吸”，红利类指数适合长持的基础来源于此。

部分红利不以股息率加权，那它只能算“红利加强”而非核心规则，如深证红利算“深证基本面40红利加强版”，它成长性高于其他红利，但因为市值加权，走势与红利大相径庭，不能看作防守型队员。

因此，请记住股息率加权是红利的核心基础。

2、关注样本与行业的限制

受红利因子特性影响，各指数成份股所属行业一般处于较成熟阶段，会有不少强周期行业。受突击分红、临时分红、超比例分红等因素的影响，可能会存在“股息率”陷阱。

因此，不同指数可能会增加一定的限制，提升指数的分散度。比如：单样本权重<10%、单行业权重<30%等等，类似的限制能有效降低行业集中度。

在特定周期，也可能因为类似的限制，导致跑不过其他指数。这便是均衡所付出的代价，选择时要理解编制策略，而不是只看收益率。

所以，如果为了避免行业暴露风险，请关注样本限制。

3、关注指数的策略空间

策略指数号称“聪明指数”，这个聪明来源于指数特定的选样规则，从而超越市场基准指数。但任何的策略，都会有一定的空间限制，应当从分布市场、因子数量、样本数量等角度考量。

1）市场分布宽窄：比如上证红利（又称“红利指数”），市场最老的红利类指数，其市场仅限于上交所上市企业，小于分布沪深两市的中证红利。

2）因子数量多寡：比如中证红利低波，在红利因子的基础上，增加了低波动因子。它先以股息率倒序，再以波动率正序，挑选股息率较高、波动率较低的样本。虽然作用很明显，但会降低策略空间。

3）样本数量多寡：比如上证红利50个样本，中证红利100个样本，从聚焦的角度上红在特定周期可能表现更好，但中长期看，适当的样本数量能降低风险。

不同的市场分布、因子数量、样本数量，会决定指数不同的策略空间和不同的分散度。选择集中，还是选择分散，这得看个人的选择和风格。

61一般建议，既然是指数化投资，选择相对更宽的指数，能降低不必要的风险。

4、关注指数调样比例和周期

1）调样比例：适度的调样比例，是维持指数相对平稳的关键。一般指数都有一定的调样比例限制，比如5%、10%、20%等。

但也有指数不限制调样比例，比如中证红利质量在调样时，完全不限制调样的比例。每一次调样动辄50%、60%的样本被跟换，虽然指数历史数据表现较好，但想基于历史数据去判断估值就比较难。

2）调样周期：受成份股风格影响，红利类指数的调样周期较长，一般在半年到一年左右，不过红利低波100是按季度调样。

不同的调样周期，会影响指数高抛低吸的有效性，这个度怎么把握没有准确答案。但从历史数据来看，半年是一个不错的周期。频次太低，影响效率。频次太高，也会增加磨损成本。

5、关注指数有没有加强策略

红利类指数其实也在不断的进化，比如2013年修正成为股息率加权，2022年大幅加强红利因子的要求。

在经历了2022年的流动性危机后，中证红利要求成份股市值规模低于100亿的样本，其权重不高于0.5%，增加了流动性限制。

大部分红利也增加了分红的连续性与合理性的限制。如中证红利要求连续三年现金分红，并且过去三年股息率支付率和过去一年股息率支付均大于0小于1，不分不行，分太多也不行。

港股在这个方面走在了更前面，如恒生港股通高股息率低波指数，在股息率的有效性上，做了很大工作，当成份股股息率大于7%时，要求复查其有效性。

再比如标普港股通低波红利指数，增加了行业均衡策略、基本面因子（考量经营现金流为正），从根本上提升成份股分红来源的有效性。

6、选好指数后，怎么选产品？

基于上述规则，我相信大部分朋友，应该理解如何挑选适红利类指数。后续，便是挑选同一指数下的不同产品。

一些关键的指数，基金公司们或多或少都会发行产品跟踪，比如年前特别火的中证A500，跟踪产品多如过江之鲫，那该如何选择？

1）费率为先：首选费率较低的产品，这个是核心规则。目前市场常见费率是0.5%+0.1%，低费率是0.15%+0.05%，差距不小，这会影响中长期收益率。

2）规模合适或较大：在A股有打新收益，处于1.5-5亿规模的产品，有可能获得较高超额，比如之前的中证红利ETF，获得了极为可观的超额。

如果有交易需求或是港股产品，可以选择规模较大的产品，从而满足流动性需求。

3）跟踪紧密度：看产品能否尽可能的靠近“全收益指数”的收益率，越接近越好，超越就更为难得。

4）是否分红：这是见仁见智的一件事，但站在红利类产品的角度，稳定分红的利大于弊，这也是61发布《分红型ETF》专栏的缘由。

5）管理人口碑：产品各有策略，跟踪各有好歹，管理人很关键。尽量选择口碑好、经营稳健、信息透明、关注用户建议的公司产品。

二、20个A、H股标杆型红利ETF产品

看了上述内容，相信你对红利类产品的选择，已经有了一个相对准确的认知。第二部分就是基于上述逻辑，整理了A、H股常见的20个红利类ETF产品，方便大家选择和判断。

1、A、H股分红型、低费率ETF

1）本期增加了标普港股通低波红利指数，其跟踪产品港股红利指数ETF是港股规模最大的产品，指数特色也很明显，故纳入。

2）本期剔除宽基指数部分，以后看情况再判断是否纳入。

2、各产品2025年度分红月度跟踪表

截至2025年2月底，表内共有7个产品实施过分红，其中红利港股ETF分红3次，红利国企ETF、港股红利ETF基金分红各两次。不过，红利港股ETF规模下滑，目前不足1亿，注意规模风险。

三、“61”全市场估值仪表盘

四、“61”指数基金估值表（0341期）

==================

很多人问过一个：为何某一个产品的分红率，到不了估值表内的股息率水平？

其实这是两个概念：

1、指数股息率：是指成份股分红部分加权计算所得，是指成份股分到基金的部分。

2、基金分红率：分红部分回到基金后，管理人有可能不分，继续买入成份股（分红再投入了）；或者基于分红约定，按规则分一部分（如红利指数的90%）出来，剩余的部分也会继续买入。

因为基金管理有日常损耗，即便100%分出来，基金的分红率往往也会低于指数的股息率。这便是文初提到的，要注意基金费率的核心原因，再进一步就是关注基金管理中的其他费用，这一点以前的文章也有详细介绍。

==================

数据整理不易，还望多多点赞、转发支持。

扩展阅读：《指数基金文章目录列表》（新手必看）

$红利ETF(SH510880)$ $中证红利ETF(SH515080)$ $港股红利指数ETF(SH513630)$

@今日话题 @ETF星推官 @雪球创作者中心 @雪球基金

#雪球ETF星推官# #雪球星计划#

风险提示：本文内容仅供参考，不构成投资建议。投资有风险，入市需谨慎。请在做出投资决策前，仔细阅读并理解相关基金的法律文件，如《基金合同》、《招募说明书》等。过往业绩不代表未来表现，投资者应根据自身情况，审慎决策。

本话题在雪球有72条讨论，点击查看。
雪球是一个投资者的社交网络，聪明的投资者都在这里。
点击下载雪球手机客户端 http://xueqiu.com/xz

分享一个平时工作找需求找竞品的方法：通过产品使用的核心技术库 - 即刻App

Tue, 15 Oct 2024 10:40:49 CST

分享一个平时工作找需求找竞品的方法：通过产品使用的核心技术库，找使用这个库的 project showcase。

起源是公司内部最近出现了一个我和 leader 都觉得惊为天人的产品。但是因为是保密项目我们能获取到的信息不够，我们判断这种交互模式和 UI 体验是借鉴了某个海外产品，大概率不是我司的原创。但是因为这个产品是很垂类的 B 端场景，加上保密项目的原因内部获取不到什么技术方案和竞品调研。

灵机一动发现这个产品的核心技术库是 xy-flow（一种画布容器解决方案），于是便从 xy-flow 的官网找到了市面上使用 xy-flow 的 project showcase。

从 project showcase 中，我看到了太多太多以前从未想到、从未接触的垂类场景：

- JSON 与工作流打通的 JSONSea
- 数据监控与工作流画布结合的 Redata
- 客服与弹窗 rpa 工作流的 Botfront
- 与地理数据结合的物流系统 Geoplex
- 包括我们自己的竞争对手 retool 和 wix 的 workflow
- …

这些都在使用 xy-flow 构建工作流、画布容器。今天几分钟的时间，从这一个基础库我看到了许多从未接触过的业务场景，这些业务场景背后代表的是一定数量的用户群体以及潜在的同类型竞品。代表着某个行业、某个市场。

这种查找需求的方法之前 @哥飞飞哥也在社群和公众号分享过类似的，并且可操作性更强范围更广：通过产品的入口流量、出口流量挖掘需求，以及榜单、外链。具体的操作和知识可以去「哥飞」公众号上刷一遍学习一下。

习得了某个方法某个知识后，举一反三在生活工作场景中用出来、总结出来，那种感觉真的是不一样的。

总得来说，这种找需求的方法考察的是多角度多维地看待问题。直接看是现象，从上游看是解决方案，从下游看是业务场景。

reactflow.dev

产品思维和项目思维的区别是什么

Sun, 25 Jun 2023 10:25:56 CST

产品思维和项目思维是两种不同的思维方式，它们在处理问题和解决方案时有着不同的关注点和方法。下面是它们的区别：

关注点：
- 产品思维：产品思维注重长期价值和用户体验。它强调对用户需求的深入理解，并致力于开发和提供具有持续竞争优势的产品。产品思维注重产品的整体规划、市场定位、用户研究、产品生命周期等方面。
- 项目思维：项目思维注重短期目标和任务完成。它侧重于项目的范围、进度、成本和交付等方面。项目思维关注的是如何在规定的时间内完成项目，并达到预期的结果。
时间跨度：
- 产品思维：产品思维是长期的、持续的思考方式。它涉及从产品的概念和设计阶段开始，到产品的开发、发布、迭代和持续改进的全过程。产品思维需要考虑产品在市场上的生命周期，以及如何使产品持续保持竞争力和用户满意度。
- 项目思维：项目思维是短期的、有限的思考方式。它通常关注的是在特定时间范围内实现特定目标和交付成果。项目思维强调项目管理、资源调配、进度控制和风险管理等，以确保项目按时完成。
方法论：
- 产品思维：产品思维通常采用用户中心的方法，通过深入了解用户需求和行为来指导产品设计和开发。它倡导持续迭代和用户反馈的循环，以不断改进产品，并寻找新的机会和创新点。
- 项目思维：项目思维注重项目管理的方法和技术，例如项目计划、进度控制、资源管理和团队协作等。它强调在有限的时间和资源内，通过有效的规划和执行来实现项目的目标。

虽然产品思维和项目思维有所区别，但它们在实际应用中通常是相辅相成的。产品思维关注产品的长期发展和用户价值，而项目思维则帮助实现产品的规划和交付。在实践中，产品经理通常需要同时运用这两种思维方式，以确保产品的成功和项目的顺利实施。

一文讲透产品经理如何用好ChatGPT

Mon, 27 Mar 2023 18:00:15 CST

ChatGPT，特别是4.0版本的出现，对各行各业产生了极为深远的影响。但人类不应该害怕机器，而是要想办法让机器为自己所用。作为产品经理，ChatGPT能帮我们做什么呢？本文作者对此展开了分析，与你分享。

“4.0版本的ChatGPT可以有效提升产品经理工作效率，但并无法充当产品经理的角色。”

一、引言

3月15日，OpenAI发布了最新的基于GPT-4的ChatGPT，关于其智能性的讨论热度在互联网上空前高涨。

我之前体验过3.5版，发现其难以应用于实际工作中。4.0版本推出后，在中文互联网上并没有辅助产品经理工作的详细介绍。这让我意识到相关内容还没有被系统性地总结。因此，我基于GPT-4，梳理了帮助产品经理全流程提效的方法，整理了一些prompt，本文旨在分享这些收获，希望能抛砖引玉。

二、GPT-4简介

关于ChatGPT的介绍屡见不鲜，在此仅简要介绍GPT-4。本文所述的ChatGPT的所有能力均基于GPT-4模型。

GPT-4（Generative Pre-trained Transformers 4）是OpenAI发布的第四代自然语言处理模型。其主要特点和功能包括：

更高的准确性和协作性：与前代模型相比，GPT-4在准确性、创造性和协作性方面有所提升，准确回应的可能性提高了40%。
多模态处理能力：GPT-4不仅可以处理文本， 还具备处理图片和视频的能力，使得用户可以同时提交文本和图片，让模型处理和讨论这两方面的内容。
广泛的应用场景：GPT-4可以应用于各个行业，例如金融、教育、IT等，帮助企业改进业务流程和提高客户体验。

三、如何用好ChatGPT

要解答这个问题，首先需要了解一个新概念： 提示（prompt），即与ChatGPT进行交流时，用户输入的内容。“提示”可以是一个问题、一段文字描述，甚至可以是带有一系列参数的文字描述。AI模型会根据“提示”所提供的信息，生成对应的文本或者图片。 熟练地使用“ 提示” 在五年之内绝对会成为产品经理的必备能力。

需要注意的是，本文中所有的提示，均为本人基于手机里各类APP模拟，不代表我所从事的产品经理工作，也不代表我司的情况。

0. 产品经理的工作流程

要充分利用ChatGPT来提高效率，需要根据产品经理的工作流程进行逐步分析。关于产品经理工作流程的介绍，在网络上有许多不同的版本。在本文中，我选取了一种较为通用的工作流程：

并针对这些流程进行打分：

市场调研：提效能力⭐️⭐️
产品规划：提效能力⭐️⭐️⭐️⭐️⭐️
方案设计：提效能力⭐️⭐️⭐️⭐️
项目推动：提效能力⭐️⭐️⭐️⭐️
运营推广：提效能力⭐️⭐️⭐️⭐️
数据分析与迭代升级：提效能力⭐️⭐️
项目汇报：提效能力⭐️⭐️⭐️

以下是详细的介绍：

1. 市场调研：提效能力⭐️⭐️

在市场调研环节，产品经理需要深入了解市场趋势、竞争格局以及用户需求。从而制定更贴合市场和用户需求的产品规划。ChatGPT的优劣势如下：

先说劣势：

ChatGPT本体的信息时效性很差，数据训练截止至2021年9月。尽管时效性问题可以通过插件解决，但该插件截止至3月26日并未正式上线。
ChatGPT会编造他不知道的内容，需要尤其注意甄别。

再看优势：ChatGPT具有出色的归纳总结能力，在好的 “提示”下，可以进行非常结构化的总结，可加快产品经理分析网上资料的速度。

提示（prompt）建议：

在用于市场调研时，建议 少直接提问市场趋势，回答会过于宽泛不具有参考价值，建议先对市场进行初步研究，整理若干材料，使用ChatGPT进行辅助分析。需要注意的是，如果你只提供文章链接，那他仍可能通过编造的方式回答你。到目前为止，仍需要把文章的内容输入给他才能确保分析的准确性。而每次输入最多只有4096个字。

下面是一些案例：

提示（prompt）负面案例：直接提问， 数据过于老旧，可用性很差。

提示（prompt）正面案例1：输入多份最近的文字报告，要求其进行总结。在我提供了多份文章后，反馈如下：

提示（prompt）正面案例2：行业分析，在已经输入足够信息的前提下，指定针对谁（公司/行业/产品）进行 何种分析（SWOT分析/3C分析/PEST分析等）

输入文章内容，让ChatGPT 分析论点论据也是一种好用的 “提示”技巧。大家有兴趣可以自行尝试。

总结：目前ChatGPT信息时效性太差，在市场调研中的作用仅能评为两颗星。 数据实时化插件上线后，预计评级可提升到 四颗星。但它仍无法替代产品经理的市场调研工作。“要想知道梨子的味道，就要亲口尝一尝”。任何线上信息都无法替代实际的用户调研。ChatGPT只能加速你对市场理解的速度，但真正的判断仍需依赖“人”的智慧。

2. 产品规划：提效能力 ⭐️⭐️ ⭐️ ⭐️ ⭐️

在完成市场调研与用户分析后，产品经理需要明确用户需求并开始产品规划。从这一阶段开始， ChatGPT将会展现出其强大的提效能力。前文已提到，ChatGPT归纳总结能力极强，尽管市面上的具体产品千差万别，但是产品类型其实是相对有限的， 这就意味着ChatGPT 可以很好的输出目前各类产品的规划。

当产品经理面对新领域时，会担心规划的周全性，因此需要投入大量时间学习某类产品规划的方法。而在ChatGPT的加持下，可极大地缩短这个进程。

下面请看案例，都是我不熟悉领域：

提示案例1：咨询新游戏的产品规划

我们公司计划开发一款基于虚幻5引擎的手机跑酷类游戏，能帮我制定一份产品规划吗？需要考虑游戏设计的各个方面，避免遗漏。

提示案例2：咨询风控系统产品规划

我所在的公司是一家本地生活公司，最近频繁受到黑灰产的滋扰，需要设计一款风控系统，能帮我出一份全面的产品规划吗？

作为一个外行，通过他的解答，也能快速了解相关产品的框架。达到了我们预期的效果。

此外ChatGPT 在公式分解产品问题上也表现优异，众所周知， 对问题进行公式化拆解并找到其中的重点，是产品经理的一项关键能力，ChatGPT的出现极大地降低了掌握这项技能的门槛。

以下是案例：

提示案例3：帮忙对某个产品问题进行公式拆解

我部门的用户为C端用户，我想要提升我们部门产品的微信社群渠道的销售额，请对这个问题进行公式分解，拆解到最细粒度。

通过以上三个案例，足可验证ChatGPT在产品规划上的强大能力，对于某一领域的专家来说，可能用途不大，但是对刚涉足某产品领域的新人来说，可以有效提升产品规划思考的周全性，极大缩短规划时间，降低产品规划考虑不周带来的潜在风险。

当然， ChatGPT 提供的只是一个完备的框架 （基于其强大的归纳总结能力），产品经理仍需根据公司业务的具体场景进行详细规划。

3. 方案设计：提效能力 ⭐️ ⭐️ ⭐️ ⭐️

在产品经理完成产品规划后，将进入到了方案设计阶段，需要设计产品方案并输出产品文档。在这个阶段，ChatGPT仍可有效地帮助产品经理。

3.1 产品方案：提效能力 ⭐️ ⭐️ ⭐️ ⭐️ ⭐️

产品经理需要掌握 “提示”的颗粒度，注意避免泄露公司信息。

好的提示应当包括： 背景，痛点，目标用户，求一个解决方案。

这样可以有效帮助产品经理梳理方案需要包括哪些功能。

提示案例1：

为了提升用户体验，我们的电商平台为用户提供一种特色服务：当一个订单产生售后行为时，商品没回去的时候就给用户退款，如果退回商品有人为损坏的问题，已经退的款如何收回？请帮忙设计一个产品方案

如果想要了解某一个功能的细节，还可以进行追问，案例如下：

提示案例2：

你回答得很全面，我想了解一下预售权扣款协议产品方案具体都包括哪些内容？

此外，还可以在提示中引入【资源】的维度，让其提供在资源有限前提下的解决方案。

总之，在设计一个新的产品功能时，产品经理往往需要花费较多时间思考包含哪些功能点，在ChatGPT的加持下，可以很好的启发产品经理， “喔，原来这个点很重要，之前我没想到”。但是具体的产品方案内容还需要产品经理根据公司情况进行详细的调研与撰写。

3.2 产品文档：提效能力 ⭐️ ⭐️

在梳理完产品方案后，产品经理需要撰写产品文档（PRD），因为产品文档中包含大量实现细节，受限于公司的信息安全与ChatGPT的能力特点，指望他完全帮助产品经理直接输出还有一定难度。我仅提供一个案例(虚构场景，不涉及公司内部数据)，请大家欣赏一下他的全面性。

提示案例：

我们部门主要销售生鲜蔬菜，我们的产品已经具备了买菜的全部功能。最近，我们计划在产品中增加学做菜的功能，让用户在购买后也能使用我们的产品做菜。当用户想用我们产品做菜的时候，也会顺便买菜，形成正向循环。请帮我输出一份完整的产品PRD文档，设计学做菜模块。需要细到都在哪些页面展示学做菜功能。

基于有限的 “提示”，ChatGPT竟能输出如此详细的内容，如果把依赖接口文档提供给他，或许他真的能写出完整的PRD。但是这肯定涉及公司信息安全，不应冒险尝试。相信随着大家对ChatGPT理解的不断深入，一定可以找到既能保证公司信息安全，又能快速输出的 “提示”技巧。

4. 项目推动：提效能力 ⭐️ ⭐️ ⭐️ ⭐️

项目推动可分为 广义和狭义。广义上，工作中推动任何事情都属于项目推动。狭义上，则专指在产品文档编写完毕后推动产品上线。无论是广义还是狭义，ChatGPT都能为产品经理提供有效帮助。

4.1 广义项目推动：提效能力 ⭐️ ⭐️ ⭐️ ⭐️

相信许多产品经理都有工作中遇到问题，苦于如何解决的时刻吧。特别是新手产品经理，在成长过程中，难免遇到种种困难，个中滋味，相信大家都有所体会。

我们在工作中常讲，工作有“ 知不知，能不能，愿不愿”三个层次。ChatGPT 可以让大家了解如何正确地做事，极大降低了“知不知”的门槛，让我为大家演示一些案例。

此类提示的格式：角色+场景+事件+问题+相关角色

提示案例：

最近我在支持我们公司一个大型项目的测试工作，负责解答和产品逻辑有关的问题，我发现，经常存在一个问题被反复提问的情况，导致我做其他工作的时间被大量挤压。我应当建立一套什么样的机制，以有效提升支持测试同学的效率？

针对以上场景，ChatGPT提供的方案确实有效。可见ChatGPT确实可以 帮助产品经理解答工作推进中的难题。

4.2 狭义项目推动：提效能力 ⭐️ ⭐️ ⭐️ ⭐️

既然广义项目推动都能应对，狭义项目推动对ChatGPT来说就更轻松了。下面是一个我抽象再加工的复杂案例，看下ChatGPT如何回答。

提示案例：

最近我在推动一个跨部门的产品项目，这个项目对于两个团队来说都具有很高的价值。然而，对方团队还有几个更为紧急的项目在进行。我应当如何推动，确保这个产品项目能按照原预期的节奏上线，因为我方有多位领导都很关注本项目的进展。

可见，ChatGPT考虑得非常全面，甚至都考虑到了要分配一些我方资源用于共建的可能性。通过使用ChatGPT，可以有效的帮助产品经理想清楚如何推动项目， 而产品经理仅需把自己的困难使用提示 阐述清楚。

5. 运营推广：提效能力 ⭐️ ⭐️ ⭐️ ⭐️

当产品上线后，产品经理还需要制定运营和推广计划，以便该产品能产生实际价值。在这方面，ChatGPT也可以给产品经理提供有效的框架性建议。

在提示中，需要提供产品类型和目标受众信息。

提示案例1：

我们产品的主要用户为潮鞋玩家，最近新上线了一款功能，支持搭建一个潮鞋微信社群，让大家在社群里可以讨论，从而反向带动我们APP的活跃。需要把潮鞋玩家的兴趣需求和习惯也考虑到，请输出一份完整的运营推广计划。

还可以进行追问， 帮助定位运营推广计划中的关键问题：

提示案例2：

你总结的很全面，但是我们 人力有限，应当优先关注 哪三个方面， 原因是？

其实，让ChatGPT回答任何问题，都可以在提示中加一句，原因是？帮助大家知其然，知其所以然。

6. 数据分析与迭代升级：提效能力 ⭐️ ⭐️

6.1 数据分析：提效能力 ⭐️

ChatGPT的 数据分析能力其实非常强。但目前，ChatGPT一次最多只支持输入4096个字符。这在分析大量数据时显然是不够用的。指望ChatGPT在这方面大放异彩的同学，可以等一等微软的office365 copilot。

另外我要提醒大家， 数据分析应该已经踩到大部分公司的红线上了，没有公司的许可，请不要使用ChatGPT进行数据分析！而这正是我给他打低分的原因。

6.2 迭代升级：提效能力 ⭐️ ⭐️ ⭐️ ⭐️

众所周知，产品演进是一个敏捷且不断优化的过程。因此，迭代升级实际上就是重复前面几个步骤。在迭代升级过程中，ChatGPT同样可以为产品经理提供有效的建议和解决方案，帮助产品不断优化和完善，我就不赘述了。

7. 项目汇报：提效能力 ⭐️ ⭐️ ⭐️

作为产品经理，项目汇报也是工作的一部分，以及时同步项目的进展及个人的成长。经过实践，虽然ChatGPT的文字输出能力很优秀， 但是仍不能指望依靠他在汇报上节省大量时间。

主要是两方面原因：

汇报中很可能涉及公司的规划和数据，这会牵扯到公司的信息安全问题，轻易不要尝试。
目前， ChatGPT生成PPT的能力还比较初级，要想生成结构清晰，立意高远的PPT，在短期内还不太现实，可以期待一下office365 copilot，或许能有质的飞跃。

尽管如此，我仍然给予该环节3颗星。因为在梳理汇报框架上，ChatGPT还是很在行的，也能一定程度上帮助大家提效。

提示规范：角色+主要工作+汇报场景+汇报对象+汇报目的。

提示案例：我是一位新闻资讯个性化排序的产品经理，需要进行年终总结述职，汇报对象为部门产品委员会（10人，都是部门的高级产品经理），希望能很好的呈现出一年所做的工作，请撰写年终总结汇报。

以上的场景是我虚构的，大家也可尝试下真实的汇报场景。通过输入带有具体场景的“提示”，产品经理梳理汇报框架的时间将会大大缩短，可以将更多时间投入到准备每个章节的内容。

8. 总结

总的来看，ChatGPT在产品经理各个工作流程中都能提供帮助。相较于3.5版本，4.0版本的理解能力有了质的飞跃，更能显著地帮助产品经理提效。

无论是产品方法论还是工作解题的方法论，ChatGPT的表现都很出色。 使每位产品经理都能更快地获得全面、合理的思考框架和行事方法。极大的降低了产品经理“知不知”的门槛，可以把工作重点投入到实践上去，提升“能不能”的能力。

说到“能不能”，受制于企业信息安全，仍需要靠产品自己动手动脑去考虑细节。即使信息安全不成问题，短期内，ChatGPT也不可能解决”能不能“的问题。ChatGPT能做的更多是已有知识的重组和归纳，而不能给你提供世界上原本不存在的新认知。而基于各种真实场景萌发的新认知，正是产品经理的重要价值所在。

如果有一天，ChatGPT能够随着世界的发展，不断【自主】产生一些新场景，新方法论，那么它将不仅改变产品经理的工作流程，而且还将直接重构整个社会的运行逻辑。

四、一些思考

ChatGPT，特别是4.0版本的出现，对各行各业产生了极为深远的影响。正如黄仁勋所言，其意义不亚于第一代iPhone的发布。在我看来，ChatGPT是工业革命4.0的重要标志之一，因为他通过极其简单的交互方式，降低了所有人应用AI的门槛， 使AI成为每个人都能使用的工具。

回顾历史，前三次工业革命每次都充分解放了生产力，推动了全球人口的爆炸式增长和社会模式的深远变革。现如今，以ChatGPT为代表的人工智能，就像第一次工业革命的 纺织机、第二次工业革命的 内燃机与电气设备、第三次工业革命中的 计算机与网络一样，将改变我们现有的工作方式，带来一个全新的时代。

第四次工业革命中的重要事件 移动互联网催生了大量产品经理的岗位，ChatGPT会给大家的工作带来怎样的变化？我非预言家，只能建议大家都要尽早学习这个新生事物。尽管4.0版本目前较难申请，但即使先使用3.5版本，多多练习 “提示”技巧，也能对理解其功能产生极大的帮助。祝愿大家都能保持核心竞争力，运用先进生产力，在新时代浪潮涌动之际，仍能够勇立时代潮头！

本文由 @AI时代新产品原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自Unsplash，基于CC0协议

什么是比较好的低代码产品 - Tw93

Mon, 27 Feb 2023 07:48:46 CST

什么是比较好的低代码产品

Categories: Technology2023-01-02

随便扯扯

可能大家谈到低代码想到更多的是低代码搭建页面的平台，内部不少也是此种，其实对于偏逻辑编排、服务 BaaS 能力的偏可视化方式其实也算低代码，旨在「 通过少写代码，用更便捷的方式来实现原本需写代码的工作」。

说到低代码，喜欢的人特别喜欢，不喜欢的人很不喜欢，此外也有“假装”去喜欢的，也有喜欢得不明不白的，我现在对于低代码是有点儿喜欢的那种，不过只限于「 在特定领域，实现需求的速度比熟练工程师写代码要快的场景」，这种场景下用起来真心会比较爽，可能也用得不爽的时候，但是这种不爽远小于他带来的效益减去原本敲代码的投入，也很值得将这类产品做到好用爱用。

其实低代码产品是比较难做成的，特别是大而全的那种，由于考虑因素过多，导致步调很慢，也很难做到很易用，导致一边投入很大，一边又急切上线落地使用，从而出现平台方觉得投入很苦，使用方觉得不太好用还需吃狗粮的矛盾，往往需经过忍耐很长时间才可「守得云开见月明」，不过很多都在没有见月明的时候就奄奄一息了。反而专门领域的比如说表单、表格、图表低代码搭建活的很不错。还有一些 BaaS 类单领域的活得也还可以，我个人更偏向「 易用的可很轻快解决对应领域问题低代码产品方案」。

此外还有一个误区，有人会认为低代码是给所有工程师都可以使用的，其实我认为不太对，低代码最开始出现的初衷是为了解决「 让不是程序员的人使用视图、组件、模板和表单等方式快速在不写代码情况下构建应用」，这里我们可以引申一下，低代码更适合两类场景，一类是「 让不是这个领域的人也可以很快的写这个领域的应用」，第二类是「 在特定领域通过抽象协议模型通过低代码的方式来快速实现产品」。

这里不多扯低代码的优缺点和喜好了，关于低代码产品内部已经有不少，也都比较熟，这里就不多加说明了，刚好最近在思考团队下一步的提效方式， 我们来看看业界开源的低代码产品，说不定会有一些输入。

一体化的低代码平台

一体化也即从后端到前端的实现全部给包括了，说实话，我认为这种是最难做的，特别在大公司里面，假如各司其职，同时多个团队协作的话比较难做起来，因为各方的标准协议、数据库模型结构均很难一致，但是假如前端、后端均在一个团队，有一整套统一的模型协议，还是有可能做成的，比如说如下这两个产品。

Appsmith

Appsmith 是一个用于构建内部应用的低代码开源框架，一个印度的创业公司弄的，很适合做企业后台管理系统，常用的 CRUD、Dashboards、数据报表啥的不在话下，Appsmith 有一种 Retool“开源版”的感觉。

在使用上和常规的开发套路很像，第一步画 UI 界面，第二步连接到数据源，第三步将数据源和 UI 界面串起来，第四步部署，只不过将原有编码过程变成了可视化过程。

此外还提供了大量的模板可供使用，包括 Project、Management Support、Human Resources、Sales、Marketing、Finance 等方向，有些思路对于不少低代码方向有一定参照作用。

Budibase

Budibase 官方宣称是一个你会喜欢使用的低代码平台，通过简单易用的方式来提高构建一个应用的速度。和 Appsmith 相比，是另外一种实现方式，此外 Budibase 有内置数据库、外部数据源、设计图形用户界面和自动化部分，在创建 UI 界面的使用使用的是偏设计的方式，整体而言会更加美观一点。

ToolJet

此外 ToolJet 也是一个不错的低代码框架，同样支持接入多种数据源，偏拖拽的方式实现前端的界面，包括对于 mobile 端的一些支持，此外使用的是 JS 比较友好。

除去上面外， nocobase、 illa-builder和 refine这三款也可以去调研调研。

BaaS 领域的低代码

BaaS (Backend as a Service) 这个概念我是从 2019 年开始弄 Serverless 的时候开始了解到的，当时想着要是有很多好用的 BaaS 能力，那写 FaaS 函数会不知道有多爽。

对于想快速实现一个产品而言，使用 BaaS，开发人员可以专注于前端开发，而无需花费大量时间和精力来构建和维护后端基础设施，这使得开发人员能够快速构建应用程序，更快地将其推向市场。不过这一块当前在国内其实弄得没有国外那么好用和精致，国外有几个还不错的。

Supabase

Supabase 是一个开源工具的组合，使用企业级的开源产品构建 Firebase 的功能。Firebase 是谷歌旗下的一家 BaaS 云服务公司，可以让开发者通过 Firebase 的框架就可以简单地开发一个 App，无需服务器以及基础设施。了解了他是啥，就大概知晓 Supabase 是什么了。

主要功能是提供了数据库托管、身份验证和授权、自动生成 API、函数服务、文件存储等易用能力，相当于这些代码的实现使用者都不需要写了，只需去调用即可，此外提供了 JS/C#/Flutter/Go/Java/Python/Swift/Rust 等客户端库来供使用，更多可见文档。

Appwrite

除去 Supabase，Appwrite 也是一个很有名的完整后端服务能力，可以当做他的竞品，功能差不多，通过视觉化界面极简了从零编写 API 的繁琐过程，在保证软件安全的前提下为开发者创造了一个高效的开发环境。基于 Docker 的端到端开发者平台，其容器化的微服务库可应用于网页端，移动端，以及后端。

提供对应的软件服务，如账户、用户、团队、数据库、存储、云函数、多语言、头像等通用能力，并搭配对应客户端或服务端的开发套件，使用微服务架构方式让其更好扩展。

此外在数据库领域还有一个叫做 SurrealDB的端到端的云原生数据库，适用于 Web、移动端、无服务器、后端和传统应用程序，通过简化数据库和 API 调用来减少现代应用程序的开发时间，消除对大多数服务器端组件的需求。

Headless CMS

敲代码快 10 年的后端同学应该对 Discuz、DedeCMS、WordPress 这种当时很火的框架很熟悉，还记得大学时期经常用 DedeCMS 去接商业项目，很快很爽。现在这一类偏后端解决方案进一步发展，变得更加简单、美观、好用了，这里简单介绍一下 Strapi 类的无头 CMS，简单而言就是只提供数据的内容管理系统，不关注 UI，内容优先。

Strapi

Strapi 是开源的无头 CMS，使用 JavaScript，很灵活完全可定制，支持不少插件，可以很快的生成一条 REST API 服务，整体使用起来对于前端同学来言还是比较熟悉的，可以一试。

Cube

Cube 是一个用于构建数据应用程序的 Headless 商业智能框架，使用任何来源的数据，将其组织成一致的指标，并将其用于每个数据应用程序。

此外除去 Strapi 、Cube 这两个比较有名的 Headless CMS，你还可以试试 payload、 webiny-js这两个。

流程编排

看起来不少公司都有自己的服务编排的平台，对于大一点的厂，可能每一个 BU 都有一个，不过整体而言都很难做到好用，同时很难讲明白「服务编排比写代码要快要方便」这个点，大多数前期很热闹，中期很平稳，后期很难玩下去，任重而道远，不过很期待正在做的同学能够到达「守得云开见月明」，把这一块能力探得更深一点。

不过在一些特定工作流领域，有做得不错的，比如说 Automate 和 n8n 这两个工具，对于流程编排的建设可以参考一波。

Automa

Automa 是一个浏览器自动化工作流的浏览器扩展，使用连接块的方式来很方便的编排你的常用操作，有自动填充表单、截图、取数据、定时触发、操作浏览器、Web 交互等能力，可以将你重复的操作很好的交给这个工具，好比快捷指令。

他做得比较好的点是很易于使用，同时提供了不少开箱即用的能力，让人很快速就完成自己的需求。

n8n

n8n 是一个可扩展的工作流自动化工具，看了看对于做流程性的节点编排，逻辑控制还是很不错的，此外支持基于代码自部署。

其他奇特的

除去上面常用的低代码能力，还有三个很神器的，其实不少人常用的 Notion 笔记本身也是一个低代码工具，与之对应的开源实现叫 AppFlowy，还有一种通过编写配置 DSL Json 的方式来构建各个部分的功能的开源产品叫做 YAO，最后还有一种是 Airtable模式的开源方式 NocoDB。

AppFlowy

如上所说，其实弄低代码的同学，很有必要去玩玩 Notion，已经被大量人玩出了花，此外可以试试这个开源的 AppFlowy，基于此，可以来看如何控制数据到界面的这个展示过程。

YAO

YAO 是一款开源应用引擎，使用 Golang 编写，以一个命令行工具的形式存在, 下载即用。适合用于开发业务系统、网站/APP API 接口、管理后台、自建低代码平台等。YAO 采用 flow-based 的编程模式，通过编写 YAO DSL (JSON 格式逻辑描述) 或使用 JavaScript 编写处理器，实现各种功能。

去年第一次见到 YAO 的时候，就被他的创新思路给吸引了，此外他自带的界面能力设计很不错，整体安装体验很顺畅，对于他的产品实现对于想做协议驱动的同学应该有不少借鉴作用。比如说下面这个系统居然是用 JSON 配置给写出来的，包括 UI 的展示。

NocoDB

NocoDB 是 Airtable的一个开源替代品。Airtable 是啥呢？Airtable 是一个电子表格-数据库混合体，它具有数据库的功能，但实际上是电子表格，还可以把文字、图片、链接、文档等各种资料整合在一起。反向来看 Notion 的大思路差不多，不过这个是重协作的使用场景。

NocoDB 的作用就是将 MySQL、PostgreSQL、SQL Server、SQLite 或 MariaDB 转换为智能电子表格，使用场景可以参考下面 gif，还是挺有想象空间的。

此外还有一个类 Airtable 领域的新起之秀叫做 ApiTable，刚开源不久，整体而言做的比较精致，很推荐一玩，可以去研究研究。

最后

只能低代码说这一块是很卷了，不过找到了对应的场景，同时可以真正解决问题，比原本敲代码要快，那基本上是可以找到一个很好的发展空间。此外文章中有不少是个人自以为的东西，假如发现有不对的，欢迎指出。

喜欢文章 → 去喂猫❤️

前端如何提升To B产品用户体验

Tue, 06 Dec 2022 17:44:14 CST

云计算产品发展的早期常以技术为核心吸引客户，功能的实现是这一时期产品优先考虑的因素。经过数十年的发展，云计算行业已经进入了深耕细作的时代，市场的激烈竞争与云产品快速发展的同时，用户对产品的可用性与易用性也有了更高的要求。在这一背景下，能够提供良好用户体验的产品在竞争激烈的市场中才更容易赢得用户的信任与市场的认可。故而，在2022财年伊始，阿里云整个产品层面就提出了要将用户体验作为我们今年最大的目标，那前端作为一个直接面向用户提供人机交互界面的工种，体验优化的提升更是我们义不容辞的责任。
本文将从前端入手，探讨如何更好地改善ToB类产品的用户体验。

什么是用户体验？

用户体验并不是指一件产品本身是如何工作的，用户体验是指“产品如何与外界发生联系并发挥作用”，也就是人们如何“接触”和“使用”该产品。

说到用户体验，就不得不提业界内比较经典的书，叫《用户体验要素》，它把体验拆分成了5层要素，如下图所示：

通过上面对用户体验要素层次的划分，我们不难看出，前端的范围主要在 **表现层 **和 框架层，是用户体验的第一道把关者，可以说，前端工程师的每一行代码，每一条样式，每一段交互都直接影响着用户最直观的感受。
通常表现层又直观的包含以下几个方面：

视觉：即是用户所看见产品。
触觉：产品人机交互的过程。
感觉：对产品的满意程度，所使用的服务是否让用户感觉到极致的快感。
逻辑：逻辑上是否用户习惯，是不是下个页面是用户能预测到的。
黏度：用户使用第一次后，用户是不是会再回来使用你的产品。

什么是用户体验我们已经基本搞清楚了，接下来一起看下如何定义体验的好坏呢？

怎么定义体验好坏

如何定义产品体验好坏？通常的做法是通过一个体验模型来综合度量产品体验，常见的模型有 Google Heart模型、蜂窝模型、 5E模型等

为此，阿里云结合自身的业务特点，制定了一套适合云产品与中后台等B端产品的体验模型-- UES（User Experience System）

易用性 - Ease of use：易⽤性是产品使用质量的核心维度，它反应产品对⽤户而言是否易于学习和使用，包含易学性、易操作性和清晰性3个维度。易⽤性的提升可以促进操作效率和任务完成率的提升、降低学习成本、提升⽤户体验和满意度。
一致性 - Consistency：一致性指多款产品间通用范式部分的一致程度，分为整体样式、通用框架和常用场景及组件等维度。对于⽤户⽽⾔，体验⼀致性的提⾼可以降低⽤户的操作时⻓及错误率，降低学习成本，提升⽤户的满意度；对于产品设计及开发者⽽⾔，保持体验⼀致性可以提升开发效能，产品模块的可集成性、稳定性和可延续性更⾼。
满意度 - Happiness：满意度反映着用户对产品或服务的期望被满足的程度，这个指标一定程度上会反映用户再次使用和对产品进行推荐的程度。
任务效率 - Task Success：任务效率包含任务完成率和任务完成时间，云产品的任务链路相对复杂，针对有明确任务或有固定使用流程的产品，通过比对用户路径和产品设计的理想路径之间的差异，能够帮助我们发现产品流程设计上的问题。
性能 - Performance：监控性能的指标有很多，其中最影响用户感知的指标是首屏渲染时间（FMP），指用户从发出请求到看到控制台主要内容的时间。其次，还包括页面请求响应时间、API 请求响应时间等指标。

利用这套模型，接下来我们就可以通过 用户调研（问卷、访谈、回访）、 用户声音（反馈、舆情、工单）、 用户行为（点击率、转化率、跳失率）、 系统表现（稳定性、流畅性）等途径和手段获取体验指标，通过对这些体验指标的洞察，初步定位产品的问题和潜在机会。下一步是进行体验的深入分析和论证，推导出优化方法，这才是我们最终的目标。

如何进行体验优化

前面做了这么多工作，就是为了发现产品中出现的体验问题，问题一旦确定之后，接下来就是如何解决这些问题了。下面分别从性能、 一致性、 易用性、 满意度、 任务效率五个方面阐述在前端层面，如何解决问题。

性能

性能问题是前端体验优化中最为常见的，当产品规模达到一定程度，功能变的越来越复杂，用户量越来越大的时候，那前端的性能问题是一定会出现的。前端的性能问题通常包含以下指标：

对于用户来说比较直观感受的包括以下四个指标，白屏时间、首屏时间、可交互时间、可流畅交互时间。
我们通常认为“首屏时间”在 2秒以内是比较优秀的， 5秒以内用户可以接受， 10秒以上就不可容忍了。（首屏时间是指用户打开网站开始，到浏览器首屏内容渲染完成的时间）
前端能做的事情？

服务端渲染（SSR）
资源预加载、懒加载（require、React.lazy）、按需加载
尽可能减少 http 请求数
cdn 内容分发网络
压缩图片、雪碧图
骨架屏、Loading、占位符等
.......

那么，阿里云在上半年也针对各个产品线提出了**「一秒极速体验战役」**，采用了PCP（Perceivable Contentful Paint，可感知的内容渲染）这样一个自定义指标来度量用户侧的「首屏感知性能」。规定只有 PCP < 1500ms 才符合日常要求，超过这个值将自动报警处理，若产品线未在规定的时间内做出整改，将直接通报到阿里云高层。经过这样的一次性能体验战役，使得阿里云百万营收工单量同比下降 38%，同时得到了 66% 的受访用户的性能提升好评。

一致性

视觉一致性

视觉一致性主要体现在以下几方面：

颜色（主色、辅色、渐变规律、点缀色、提示色、字体颜色等）
风格（扁平、拟物、极简等）
元素属性（字体、控件、间距、图标、图片风格等）
交互一致性

交互一致性体现在各种页面控件布局、操作交互、页面跳转逻辑等的一致性。

文案一致性
- 语气、句式结构统一
- 专业名词、相同功能名称、相同操作统一
跨平台一致性

如果我们设计的产品在不同设备端都提供下载使用，那我们也需要注意 保持产品在不同软件中的一致性，使其视觉、功能方面很好的统一，用户才能够很快适应，没有陌生感。

为了保证视觉和交互的一致性，我们通常会制定视觉设计规范，采用统一的UI组件，统一的前端框架，封装常用业务组件等方式来解决。而对于文案的一致性，一般靠测试和产品的人工走查为主，当然我们在开发的时候也要尽可能保证文案的一致性。

易用性

易操作性
- 键盘、快捷键---支持常用的快捷键、减少频繁鼠标和键盘的切换。
- 扩大点击范围
- 操作反馈---及时对用户的操作给与反馈，包含成功、失败、等待时间等。
- 符合预期---任何操作及跳转都要符合用户心里预期。
- 避免重复/过多的操作---不要要求用户多次输入相同的内容或同一操作。
- 用户的控制度和自由度---能够执行“取消”操作，选择开通或不开通。
- 遵循惯例
- 防错、容错处理
- 帮助记忆
- 灵活高效
- .......
易学性
- 新手引导
- 通俗易懂的文案---将复杂的术语、行话和缩写用通俗易懂的方式表达清楚，“说人话”。
- 清晰的选项---提供清晰的表单列表，分组明确，需要步骤的明确需要几步，需要准备的东西提前告知。
- .......
易见性
- 可交互的元素应该更清楚的显示出来，避免非交互的元素看起来是可交互的
- 选取行高亮
- 明确表单必填项
- ......

满意度

1984年，东京理工大学教授狩野纪昭根据功能满足度及用户满意度画出了一张二维四象限图，即KANO模型，该模型反映了产品性能和用户满意之间的非线性关系。每一款产品都有许多的功能，通常理解下，产品功能增加会带来用户满意度增加，但是KANO模型则反映了更多真相。

必备属性：这一类的产品功能特性是，没有会很糟糕，有了勉强可以及格，但远未达到满意的地步。比如家用冰箱，制冷就属于它的必备属性，即使你把制冷温度能够降到-100度，我也没觉得他让我多么满意，这就是必备属性。必备属性就如同他的名字一样，必须具备但是适可而止，这不是产品功能核心竞争力。

期望属性：这一类产品功能特性是，没有会很糟糕，有了会让人满意度大幅提升。比如一款电动车，如果不能充电续航，我会觉得很垃圾，但是随着你续航里程的持续提升我的好感度会越来越高。这类功能也不是竞争的主战场，不过从用户体验角度来说，100-1=0，我们的产品不应有明显的短板，即便你其他全部满分，期望属性如果有一门打0分，你的总体得分可能也高不到哪里去。因此，最好的状态是期望属性达到平均分即可。

魅力属性：这一类产品功能特性是，没有我也无所谓，而有了会让人满意度大幅提升。如果能把魅力属性提升，那么也就是所谓的“超越预期”的用户体验。提升魅力属性才是我们产品的核心竞争力。

那么带着这个模型回到我们的产品中，不管是一款ToB还是ToC的产品，一旦用户量达到一定的规模之后，必然会为了满足不同的用户而要去实现多种多样的功能。在这些功能和需求提出之前，我们就可以利用这个模型，去想想这个需求它是属于什么属性。不同的属性我们的重视程度和投入度是不一样的，人的时间和精力是有限的，只有把事情的本质、优先级、重要程度弄清楚了，投入产出比才能达到预期。
比如，淘宝交易平台在今年终于推出了支持同一个订单可以选择多个收货地址的功能，以及双11预售付尾款前1天可以提前进入“商品结算”页面，查看最终的结算金额、优惠金额，避免像往年一样用户需要自己拿出计算器去计算。
在我看来，这2个小的体验优化都属于魅力属性，没有这两个功能，我一样能够下单成功，更改收货地址。可是一旦有了这两个小的功能，用户的满意度就会大幅提升。

最后再以我们DMS产品内的SQL编辑器为例：

作为一款SQL编辑器，智能提示是必备属性还是期望属性呢？我们来分析下，如果在智能提示上你能不断的提高它的准确度，能根据语法做精准提示，甚至可以结合业务场景、用户使用频率等做智能化推荐，将用户要查询的表、字段、关键字放到首位，用户可以一路回车回车，不用输入任何关键字，即可完成整个SQL的编写。随着我们精准度的提升，用户的满意度是会直线上升的，那它就是期望属性，值得我们花费一定的经历去投入。

最后总结一下：作为前端来说，要提升用户满意度，可以在用户的期望属性和魅力属性上下功夫，精打细磨能够提升用户满意度的一些功能及交互。

任务效率

发现问题： 任务效率包含任务完成率和任务完成时间，要提升这两个指标，首先必须先计算出这两个指标，我们才知道如何提升。这里以DMS产品内的录入实例为例，使用DMS的第一步就是将数据库实例录入到DMS，我们利用链路分析工具AEM对这一任务进行了链路分析，分析结果如下：

分析问题： 经过分析，我们很明显的发现了问题，用户从输入密码 -> 选择管控模式中间花费了很长时间，流失率也特别大，从 21% 下降到 3%，那么这一步就是需要我们重点关注和解决的。找到问题以后，接下来就是解决问题了。
解决问题： 前端同学可以拿着这份报告，联合产品经理、交互设计师、服务端等人员一起讨论解决方案，制定方案，方案实施，发布上线。
结论验证： 最后再利用链路分析工具进行分析，验证我们的方案是否符合预期。若还未达到预期值，则再重复前面的步骤，直到目标完成为止。

总结

从前端领域来看，我们对于用户体验关注最多的就是页面性能，同时做的最多的也是各种性能优化。快即是好的用户体验，也是最好衡量的体验标准，好到我们可能把对于用户体验的关注都放在了这里。
性能优化的确是提升用户体验的一个重要手段，但不应该成为我们唯一的手段。 用户体验的提升不是一蹴而就的，寻常之处见功力，细微之处见真章，只有在不同的体验细节处发力，积少成多，才能产生质变的效果。

从用户体验要素层次的划分来看，前端主要服务于表现层和框架层，所以有的时候我们对于用户体验的思考可能就仅局限于这两层。但从用户体验层次的影响权重上来看，越往下权重越高，如果在策略层我们都没有想清楚我们的用户是谁？用户真正需要的是什么？那么我们的产品很可能连触达用户的机会都没有，就更不需要提表现层和框架层对于用户体验的影响了。
作为技术同学，我们需要有意识的去打破职能边界，主动以产品设计者的角色去思考，好的产品体验，有时需要的可能就是我们多走那一步的努力。

龙芯称其第四代产品将达到主流 CPU 性能

Tue, 22 Nov 2022 21:15:04 CST

龙芯中科董事长胡伟武在最近举行的活动上透露，龙芯第四代产品 3A6000 和 3A7000 将达到市场主流产品水平。龙芯 3A6000 已经完成设计，预计 2023 年上半年出样片。此前的报道称，3A6000 的性能将达到 2020 年上市的 AMD Ryzen 5000 系列 CPU 和英特尔 11 代酷睿 CPU 的水平。模拟测试显示，相比上一代 3A5000，3A6000 的单核 SPEC CPU 2006 定点得分提升 37%，浮点得分提升 68%。胡伟武表示正致力于打造一个软件生态系统，使中国用户能在龙芯 ISA 上原生运行更多的应用，而不是依靠其它 ISA 的模拟或翻译。

【干货】互联网产品的生命周期，如何评估优先级？

Sat, 21 May 2022 08:31:08 CST

一个互联网产品的生命周期大概可以分为需求阶段，研发阶段，运营阶段。在需求阶段，通常我们会有需求优先级；在研发阶段，会有转测 BUG 等级，BUG 的严重程度；在运营阶段，会有线上 BUG 等级，线上事故等级。

为什么会有等级或者优先级？ 其背后的根本原因是资源是有限的。 在有限的资源内，如何更好地完成需求，修复线上问题，处理线上事故是我们在研发管理过程中要反复面对的问题。而这个要反复面对的问题，业内通用的解决方式是定优先级，也就是我们常说的 P0，P1……

1. 需求优先级

需求优先级，指产品需求的优先级，哪些需求先做，哪些需求后做，哪些需求不做，其关注的是业务价值或者要解决问题的价值。

需求优先级一般有 3 个，P0，P1，P2 在资源有限的前提下，P0 是必须要做的，P1 是在 P0 做完后有空余人力可以去做，P2 现阶段基本可以不做。

当业务方问为啥我们：“这个需求没有咋没有排上，我都提了这么久了，你们是怎么评估优先级的？” 我们需要有一些相对客观的逻辑或方法来回复业务方。

需求的评估可以分两步：

第一步：从需求的角度来看，任何一个需求一定服务于某个战略 / 某个目标 / 某个场景，需要根据其服务的目标来做第一次的优先级评估。

如果是服务于战略，根据战略的级别和影响范围来评估，比如是公司级的战略项目优先级肯定要高一些；
如果是服务于某个目标，这里的目标可能是合同或者营收，根据合同的金额，合同的客户以及营收的大小来评估，比如一个合同金额为 500 万和一个合同金额为 5 万的需求，会有比较明显的优先级区别；
如果是服务于某个场景，那这个场景一定有对应的目标人群，根据目标人群的特征、数量和其影响范围来评估，比如有些需求在业务关键链路上，优化可以影响的用户量比较多，又或者某些影响核心链路可用性的技术建设需求，当核心链路不稳时，所有用户都会受影响，此时需要评估为最高优先级；

在以上评估的基础上，还需要基于具体的实现做第二步的评估：

参考需求实现的成本和难度，对于开发成本低，周期短，但价值高的需求，需要给予更高一些的优先级，其实就是看一下性价比；
对于存在关联关系的需求，可能适当地调整优先级，比如某个需求 A 优先级高，另一个需求 B 优先级低，但是在做需求 A 的时候，再加点点人力就可以顺便把需求 B 给做了，此时可以适当调整，这里主要考虑的是事情的完整性，基于减少了认知成本和沟通成本的出发点；
对于存在依赖关系的需求，可以适当调整优先级，比如在开发某个产品时，可以先把 MVP 版本的需求先做了，实现主体流程先跑通，或者某些需求在前后端上有依赖，可能需要后端先行等等。

以上只是我们评估的逻辑，换成更高大上的说法有如下一些方法：

卡诺模型（ KANO 模型）：必备需求 > 期望需求 > 超出预期需求 > 无差异需求
维格斯法：分为四个纬度进行评估：收益(Benefit)、损害(Penalty)、成本(Cost)、风险(Risk)。收益和损害是从客户角度出发，而成本和风险则从实现角度出发。
波士顿矩阵：由用户价值维度和公司价值两个维度将需求分成了 4 个象限：明星需求，问题需求，金牛需求，瘦狗需求。
RICE 方法：包含覆盖率，影响，信心和努力 4 个部分。对要素进行排名并根据这 4 个因素计算得分，以确定优先级。
WSJF 优先级：加权最短作业优先，项目成本 = 用户商业价值 + 时间成本 + 降低风险 / 新机会
工作量和影响矩阵：也称为「价值与复杂性」矩阵，将工作量和影响组合分为 4 个象限
MoSCoW 方法：必须具备 > 应该具有 > 可能具有 > 非必要
艾森豪威尔矩阵（时间管理四象限）：马上要做(重要紧急) > 计划要做(重要不紧急) > 备选(紧急不重要) > 不需要做(不重要不紧急)

2. 转测 BUG 等级

转测 BUG 等级关注的是对测试执行的影响，这里之所以叫转测 BUG，是为了和线上运营时的线上 BUG 做区别。

转测 BUG 在 CMMI5 标准中可以分为 3~5 个等级，在实际研发过程中，我们常常将其分为 4 个等级，这里的等级属于处理的优先级，即对我们处理的时间和先后顺序有要求，如下：

等级	说明
P0	马上解决，表示 BUG 需要马上解决，否则就无法达到预期，测试执行完全没法操作
P1	急需解决，表示 BUG 的修复很紧要，关系到系统主要功能模块是否正常，严重影响测试执行
P2	高度重视，表示 BUG 有时间就要马上解决，否则系统偏离需求较大或预定功能不能正常实现，对测试执行有影响，但是可接受
P3	正常处理，表示 BUG 按个人计划解决，不影响需求的实现，在需求上线发布前需要确认解决或确认可以不予解决，对测试执行影响较小

以上是 BUG 的处理优先级，但是我们在确认 BUG 时还有一个维度是严重程序，如下：

严重性	说明
致命（非常严重）	在流程、数据或安全方面存在重大问题，导致软件不具可用性，或核心功能项无法使用，如系统崩溃、无法启动、实现和需求严重不符等导致测试无法进行
严重	由于设计的缺陷，导致软件使用中存在较明显的障碍，或者局部功能错误，但可以采取其他变通的操作实现，如功能未实现、功能错误，通讯错误等
一般	由于编码不够完善，使某个小功能无法使用，或者对特殊的操作与要求不能支持
提示	存在某些细微的缺陷，但不影响程序正常应用或该功能在下次升级版本中可以实现

对于转测 BUG 的优先级和严重性，有如下一些注意事项：

优先级和严重性并不总是一对应。有时候严重性高的 BUG，优先级不一定高，甚至不需要处理，而一些严重性低的 BUG 却需要及时处理，具有较高的优先级。如界面单词拼写错误，但是如果是系统名称或公司名称的拼写错误，则必须尽快修正，因为这关系到系统和公司的市场形象；
修复 BUG 不是一件纯技术问题，有时需要综合考虑项目周期、质量风险和修复成本等问题。例如如果某个严重的 BUG 只在非常极端的条件下产生，则可能没有必要马上解决，又或者修复一个 BUG 需要重新修改系统的整体架构，可能会产生更多潜在的 BUG，而且产品由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，需要通盘考虑后，以确认是否需要修正。

3. 产品模块等级

在讲线上 BUG 等级前我们需要先讲一下产品模块或产品链路等级。因为不管是线上 BUG 还是线上事故，其优先级的判定都依赖于产品模块的等级，在产品模块等级的基础上叠加影响范围 / 影响时长之类的因素才能构成线上 BUG 等级和线上事故等级。一般我们将产品模块等级分为以下 3 个等级：

等级	说明
P0	核心功能流程，是一个产品安身立命的根本，最最基础的功能，如电商场景下的浏览商品、商品详情、支付购买等
P1	非核心流程，却是重要的业务模块，如电商的优惠劵兑换、商详页里面的用户评论，在系统遇到问题时，可以降级的部分
P2	非核心流程，当不可用时，用户可以接受晚点再来，如一些运营活动，个人信息的展示等

基于产品模块等级我们讲一下在运营阶段常见的线上 BUG 等级和线上事故等级。

4. 线上 BUG 等级

线上 BUG 是指在线上环境中发现的 BUG，是相对于转测 BUG 来说，其关注点是对用户使用的影响，其优先级的评定也是根据用户影响范围及程度来决定的。在实际执行中我们通常会根据客服的反馈和 BUG 所在的业务的重要程度来决定处理优先处理。

等级	说明	反应时长	处理周期
P0	因程序导致的 P0 级业务流程不可用，影响所有用户或大面积用户，或对用户/公司造成了实际经济损失，闪退	5分钟	1 小时内
P1	因程序导致的 P0 级业务流程不可用，但只影响部分用户正常操作，或 P1 级业务流程不可用，但影响所有用户 / 大面积用户	10 分钟	24 小时内
P2	因程序导致的 P1 级非核心业务流程异常，若持续故障将可能大面积影响用户体验	1 小时	1 周内
P3	因程序导致的 P1 / P2 非核心业务流程异常，影响少量用户使用体验	2小时内	两到三周内

5. 线上故障等级

线上 BUG 专指由于程序的问题导致的线上问题，而线上故障是对所有对线上业务产生了一定范围影响的线上问题。

线上故障和线上 BUG 不相同，线上 BUG 不一定会产生线上故障，而线上故障也不一定是由线上 BUG 造成的。如 DDoS 攻击，机房断网，域名到期等等都有可能产生线上故障。

线上故障等级关注的是对业务的影响范围和持续时长，实际应用中我们用可用性 SLA(Service-level Agreement)来描述和约束线上故障。其优先级如下：

等级	说明	反应时长	处理周期
P0	P0 级业务流程不可用，影响所有用户或大面积用户，或对用户/公司造成了实际经济损失	5分钟	1 小时内
P1	P0 级业务流程不可用，但只影响部分用户正常操作，或 P1 级业务流程不可用，但影响所有用户 / 大面积用户	10 分钟	12 小时内
P2	P1 级非核心业务流程异常，若持续故障将可能大面积影响用户体验	30 分钟	1 周内
P3	P1 / P2 非核心业务流程异常，影响少量用户使用体验	1 小时内	两三周内

6. 后记

优先级是我们以有限应对无限的策略，在没有办法的情况下可以这样用，但是如果人力充足是否就不需要优先级了？

答案是：依旧需要。

对于优先级更深层次的思考是 ROI，如何让研发投入产生更大的价值，是我们要不停思考的问题。

中台工具产品方法论

Thu, 28 Apr 2022 17:50:15 CST

背景

做中台工具产品不是一件容易的事情，需要对接上层所有业务方，做的慢业务方不满意，做的快业务方未必会给好的评价。

属于容易背锅，细节极其多，用户反馈建议多，但又难以出成绩和证明自己做的好。

场景

虚构一些场景，大家肯定都遇到过。

场景1

老板：XX功能我觉得不错，做了吗？

产品经理：收到，我研究下。

几天之后……

老板：XX和XX等N个功能都不错，马上排期做下。

产品经理：收到。

评价：产品经理是初级的工具人，执行命令，最终老板大概率不会满意，因为产品功能都是老板自己提的，上线未必效果好。

老板会认为自己是个有想法的人，同时认为产品经理没有想法，产品经理挺冤枉，干的比黄牛累。出了成绩是老板高瞻远瞩，没有成绩是没执行好。

对话通常以被动接受信息，缺乏有效的反馈和互动。收集大量需求导致执行慢，可能会被技术同事认为是战斗力等于5的渣渣。

场景2

老板：XX功能我觉得不错，做了吗？

产品经理：收到，我研究下…（几小时之后）这个功能挺好，和技术同事工作量比较大，会在下一个版本中增加。

评价：高级工具人，收到信息之后，能够给予执行的时间点，对工作量和项目节奏有一定把控能力。

场景3

老板：XX功能我觉得不错，做了吗？

产品经理：研究过了，用户给我们反馈过，XX竞品也有这个功能。我们已经在当前规划中了，计划在下一个版本中增加。

评价：有一定自主工作意识，对产品有一定思考，老板只是信息源之一，能从用户反馈和竞品等渠道提炼产品需求，有主动找信息和需求的能力。但很少反驳别人的想法，对事情的优先级把控能力还不够。

场景4

老板：XX功能我觉得不错，做了吗？

产品经理：研究过了，会放在下一个版本中增加。我们当前版本是主要提升另外一个模块的易用性，用户意见比较大，是影响产品NPS的主要因素，上线之后预期会影响xx%比例的用户。而你提的XX功能属于体验优化，我们会在下一个版本中迭代。

评价：有优先级掌控意识，在和老板的对话中体现了自身的专业性，体现了用户反馈、NPS和数据来驱动产品迭代，在产品标准上和老板拉齐认知。产品的目的在于提升NPS等，不局限于讨论某个功能点。即使拒绝了老板需求，老板也会认为产品经理有自己的思考。

但是缺陷在于，产品经理的眼光只能看到未来1-2个月的规划，对长期规划还缺乏把控。

场景5

老板：XX功能我觉得不错，做了吗？

产品经理：已经在规划当中了，房产中介对这个需求有很强需求，而其他类型的用户需求不高。我们今年的目标是满足电商等前5的用户诉求，这些行业对公司贡献大，我们最近做了调研发现电商等用户对XX功能有很强的诉求，提炼了N个需求来，比如XX……

评价：对全局有掌控，对公司战略目标有理解，基于战略目标拆解出了自己的目标，能够主导项目迭代。

老板满意，合作方满意，技术同事跟着干活能自己做事情的价值，对产品经理认可度很高，不会带着项目组做无用功。

场景6

老板：XX功能我觉得不错，做了吗？

产品经理：需求可以做，功能产品侧都可以做，细节是永远做不完的，但是缺乏方向性。我认为SaaS产品的核心目标是收入，当前提升收入的抓手我们还没有明确。通过数据分析、用户访谈和专家访谈，我觉得有xx场景是可以深挖的，这些行业还有50%+增量收入，期望与其他团队能联动在未来半年中达成这项目标。而你提的XX功能，不是典型的应用场景。

评价：这样的产品经理已经可以做业务负责人了，有完善的方向判断能力和产品方法论，有能力带领项目组走向成功。

而老板是资源，说服老板投入更多精力在某个方向，老板会对产品经理更为信任，提功能细节的次数会很少，更多是讨论项目方向，输入外界信息来帮助产品经理做判断。

做产品，超出用户预期，他们才会满意。做产品经理也是一样，认知超越周围的同事，大家才会认可你。

大数据AI Notebook产品介绍和对比

Tue, 29 Mar 2022 02:02:55 CST

本文已参与「新人创作礼」活动，一起开启掘金创作之路。

背景

大数据数据需要查询分析可视化工具,AI数据挖掘和探索也需要相关可视化编辑工具，开源产品主要有两个一个是Zeppelin notebook 一个是jupyter notebook，其中juypter主要用于数据科学家、算法分析人员使用python进行数据分析、算法建模，相关企业如aws、百度、腾讯都有基于jupyter notebook去进行定制化开发，zeppelin notebook比较偏重于大数据数据查询分析可视化，支持多种大数据计算引、存储引擎擎如：Spark、Flink、Hive、Kylin等，现在对这两个产品进行介绍

两个产品对比

Apache Zeppelin简介

Zeppelin是一个Web笔记形式的交互式数据查询分析工具，可以在线用scala和SQL对数据进行查询分析并生成报表，notebook可以包括多个paragraph(段)。paragraph是进行数据分析的最小单位，即在 paragraph中可以完成数据分析代码的编写以及结果的可视化查看。因此，一个paragraph 可看做是一个基本的任务单元。Zeppelin的后台数据引擎可以是Spark、flink、Python等，开发者可以通过实现更多的解释器来为Zeppelin添加数据引擎。

多解释器支持

丰富的数据可视化

其他功能

IDEA插件作为一个开发来说，通过idea插件跟zeppelin连接，可以很方便的编写代码，快速的进行数据查询分析。

Zeppelin 架构

image.png

Zeppelin的核心功能就是：通过不同的解释器支持多种语言的repl，并对返回结果进行可视化展示。

主要分成三块 1.Zeppelin 前端 2.Zeppelin Server 3.Zeppelin Interpreter

Zeppelin前端是基于AngularJS

Zeppelin Server是一个基于Jetty的轻量级Web Server，主要负责以下一些功能：1.登陆权限管理、 2.Zeppelin配置信息管理、3.Interpreter 配置信息和生命周期管理、 4.Note存储管理、5.插件机制管理

zeppelin采用WebSocket技术的必要性问题，zeppelin是共享式、Notebook式的大数据分析环境，以repl的方式执行以Paragraph为最小粒度的代码段。

首先repl的方式强调实时反馈执行结果，特别是在大数据环境下，一段代码可能需要执行很长时间，在执行的过程中，zeppelin的用户期望看到执行进度和中间结果，需要在前后端之间建立一个长连接，便于实时传递数据。

另外zeppelin的另一个亮点是其结果可视化能力，需要在前后台传递图片，并且支持较大数据量的传输的能力（相对传统http技术）。

再者，由于是共享式环境，一个Note可能被多个用户同时看到、甚至编辑，需要在各个已经打开了同一个Note的web客户端之间同步Note的代码、执行结果和进度信息。

Jupyter 简介

Jupyter Notebook是一个开源的Web应用程序，允许用户创建和共享包含代码、方程式、可视化和文本的文档。它的用途包括：数据清理和转换、数值模拟、统计建模、数据可视化、机器学习等等。它具有以下优势：

可选择语言：支持超过40种编程语言，包括Python、R、Julia、Scala等。

分享笔记本：可以使用电子邮件、Dropbox、GitHub和Jupyter Notebook Viewer与他人共享。

交互式输出：代码可以生成丰富的交互式输出，包括HTML、图像、视频、LaTeX等等。

大数据整合：通过Python、R、Scala编程语言使用Apache Spark等大数据框架工具。支持使用pandas、scikit-learn、ggplot2、TensorFlow来探索同一份数据。

jupyter项目架构

架构图

项目关系图

jupyter项目利用了利用了ZeroMQ的Publisher-Subscriber模式来做通信，前后端通过websockets和http 请求进行交互。整个项目看起来挺负责，提供了灵活的可扩展的方式，可以通过定制kernel去实现。juypter 相比于zeppelin多进程的实现方式，资源利用率高，但是隔离性不如zeppelin。

总结

两个产品功能都差不多，不过相比较而言zeppeplin比较是适合企业级部署应用，支持比较多的大数据计算引擎，而juypter notebook比较适合于个人用户以及AI建模人员去使用，目前各大云厂商都有类似的解决方案，如果需要企业生产化的化基本上都是以云原生的方式去部署。

参考文档

http://wwj718.github.io/post/架构/jupyter-notebook-architecture/

产品经理规划功能框架四步骤

Sat, 16 Jul 2016 11:26:11 CST

一提到画原型，我想每一个产品经理都接触过，因为通过原型界面，可以更方便与设计师、程序员进行有效的沟通，以实现产品目标。但要设计出优秀的原型，还有一件事情很重要，那就是要先规划好功能框架，所谓“磨刀不误砍柴工”，若是功能框架未规划好，则画出的原型可能会错误百出，未必能有效传达需求目标，甚至是造成后期技术开发的不断返工。

今天我将在这里，结合过往实际工作经验，通过从是什么、为什么，以及怎么做三方面一一介绍如何规划进行功能框架。

一、功能框架是指什么

要想干成一件事，首先要知道干的是什么事。同理，要想规划功能框架，就要知道功能框架是指什么。

所谓的功能框架是指系统为用户提供的功能集合，是从用户角度思考，用户使用系统是用来做什么事，并以此提供什么功能。

这里要避免一个误区，功能框架不是功能的罗列，而是系统化的角度思考功能的有效组合。

我们规划功能框架是理清业务有什么功能，而不考虑小的功能点，注重业务的宽度，而不是业务的深度。

二、为什么要搭建功能框架

在实际的产品工作中，很多产品经理一上手就直接开始画原型，觉得在画原型中就可以不断细化，不断补充原先未思考的地方。

要知道人们思考问题，总是不自觉地往深处思考，爱转牛角尖。这就造成了一旦开始画原型，就很难走出原先视角，整体思考产品需求。

2.1 有效防止功能遗漏

若是我们一想到某个功能，就开始设计具体的功能，往往带来思维上的局限性。从某一点想到令一点，即由点到点的联想很难。但若是一个整体面的了解，再通过各个关系线，联想到各个点会更加容易，即由面-线-点的联想更有效。

这里以自己的设计的中小学的课后托管服务为例，课后托管服务是指在课后时间统一内，学校统一安排一系列学生感兴趣的课程，由学生报名并听课。在这个场景中，我们很容易想到有学生报课的功能，因为详细设计该功能，学生如何挑课，如何报名，如何排班等细节功能点。但是，回过头发现没有考虑到课从何而来，若课的来源都没有确定，又怎么会有后面的学生选课的操作呢。

2.2 加强功能间的系统化

我们一直提到系统思维，所谓的系统思维的核心理念之一是整体思维，从系统整体出发，着眼于系统内部各要素之间的连接和相互作用，从整体上去认识局部，再综合到整体。

我们在进行功能设计时，也需要时刻持有系统思维，要从整体上考虑产品的各个功能，分析功能与功能之间的连接和相互作用。假如产品中的功能之间没有连接，没有数据的关联性，这只会让功能分散，用户体验将会非常糟糕。

同样以设计中小学课后托管服务为例，根据不同的角色，设计了教师端和巡课端，若是在考虑巡课端的学生考勤时，忽略了教师端中教师点名产生的考勤数据，那么这个巡课功能是不完善的，未考虑到教师点名和巡课点评之间的考勤数据的关系。

三、怎么搭建功能框架

产品经理要厘清产品的功能，不能一上来就罗列功能，而是要有用户思维和系统思维，从整体上考虑功能之间的关系。就如系统要很好的运转，就需要关注各个要素，以及要素之间的关系，同时不能忽视系统的目的和作用。

按照这种逻辑，我们要找出各个功能，了解各个功能之间的关系，让各个功能朝着共同的用户目标而运行，而这就是搭建功能框架的原因所在。

下面我们可以按照下面四个步骤，一步步地搭建起产品的功能框架，帮助自己为下一步的原型设计奠定好基础。

3.1 找出所有参与者

什么是参与者？可以简单理解为需要运用到产品，利用产品来没满足其需求的用户群。若是没有明确我们的用户群，那么设计的功能也就是无源之水。

找出参与者，要保证没有遗漏，避免因为没有考虑到某个参与者，而忘记设计某些功能组。

我们可以从产品交互和业务流程两方面来排查有哪些参与者，例如产品交互而言，考虑谁会使用产品获取信息，谁提供信息给产品；业务流程而言，思考业务的主要流程是什么，有哪些人参与到该流程中。

在设计的中小学的课后托管服务时，我们考虑到校长、教务主任、任课教师、学生和家长，但最后发现我们忘记了一个角色，那就是学生的班主任，其实班主任有责任关注学生报名的课后课程的情况以及出勤数据。

3.2 框定功能范围

当我们已经明确了参与者，那么就需要考虑参与者使用产品的目的是什么，对应的需要提供什么功能。即用户用产品做什么事，然后再说产品有什么功能。

这里我建议使用用户故事的方法，把自己带入的场景中去思考，这样才能准确理解功能的含义。这里可以使用一个通用的例句来描述用户故事：作为一个____（身份），我想要____（功能），以便____（价值）。

例如作为一个巡课教师，我想要巡课点评，以便评估课程教学效果；作为一个教务主任，我想要巡课数据统计，以便了解课后课程的教学情况。

当然这里也可以使用用例方式，即通过图形的方式来描述用户的任务或动作，有兴趣的同学可以学习用例图。

3.3 评估实现方案

当我们找到功能，即用户的需求目标时，就需要考虑采用什么解决方案。每一个功能都有可能各种各样的解决方案，我们只有找到性价比最高的解决方案，才能被用户所接受。

解决方案是从问题出发的，要能给用户解决问题，从而创造价值。想要评估出高质量的解决方案，主要有三个环节：首先我们要梳理出所有的解决方案；其次对解决方案进行价值点分析；最后明确各个价值点的高低。

在梳理所有解决方案时，我们很容易找到一个解决方案后，就停止思考了，这样是找不到有效的解决方案的，这里建议使用水平思考的方式，多个角度思考解决方案。对于价值点的分析，可以从用户体验、开发成本、方案目标以及附加价值等四个角度进行评分，最终采用较高评分价值点的解决方案即可。

3.4 细化方案步骤

明确了解决方案后，需要进一步细化方案步骤，即用户是如何一步步地操作，来实现其目标。

解决方案的每个步骤都应该在同一层面，不能出现步骤拆分过粗或过细的情况。我们再对这些步骤进行拆分和合并，就可以划分出设计单元。可能是某个步骤拆分到多个页面，也可能多个步骤合并在一个页面，需依据具体情况具体分析。

老规矩，还是以中小学的课后托管服务为例，巡课教师主要需要做三件事，一是核对学生出勤数据，二是查岗任课教师是否到岗，三是评价课后课程的教学效果。这三件事属于巡课教师的巡课点评的功能，分成三个步骤，其中第一个和第二个是可以合并成师生考勤，与第三个的评价区分开来，所以在设计当中，可以考虑把核对学生出勤数据和查岗教师到岗情况合并在一个页面操作实现，评级课程的教学效果可以单独一个页面操作。

以上是我对产品经理规划功能框架的思考，这四个步骤密不可分。在实际工作中，各个步骤的比重会有所不同，重要的是还是要从整体到局部，再从局部到整体，总-分-总的思考逻辑贯穿其中。

关于规划功能框架的技能，你get到了么？

微服务自动化测试的测试策略 - Web 3.0 Cloud-Streams 产品级敏捷

Sun, 05 Dec 2021 21:19:35 CST

前言:

微服务遵循著单一责任 (Single Responsibility) 的设计原则, 使得微服务较传统的单体 (Monolithic) 能更容易的独立发布、部署。另一方面, 微服务能拥有更大的空间去选择适合自身的编程语言、技术。最重要的一点是, 微服务的架构更容易的能做到 “水平扩展”。

然而, 微服务也有它的技术挑战需要克服。

如图一所示, 微服务的架构是分布式的, 在这样的分布式的架构下, 所谓的 “自动化测试” 将是微服务能否成功的一个首要且关键的要素。

我们将以一系列的文章来探讨微服务自动化测试的策略、方法、工具。首先, 我们从微服务的测试策略谈起。

图一：微服务; 分布式的架构

本文:　

　在谈微服务的自动化测试策略前, 我们需先一起共同的来探讨: 微服务内的架构、微服务与微服务间的协作。然后, 我们就可以探讨微服务需要那些类型的自动化测试。

图二: 微服务内部的主要元素

如图二所示, 微服务的内部主要是由以下的元素所组成：

Resources: 主要的责任是经由所选择的协议; 如: REST; 将微服务所提供的服务暴露给微服务的 Client。Resource 会完整性的校验由微服务的 Client所传过来的请求 (Request), 并且将微服务执行完某个服务后的结果, 按照由协议所界定的响应 (Response) 格式; 如: JSON; 提供给微服务的 Client。
Service layer:主要的责任是派工给多个的 Domain, 以共同的完成微服务Client 的请求。Resource 完整的校验由微服务的 Client 所传过来的请求(Request) 后, 假如, 此请求会需要自身微服务内部或外部的微服务多个的Domain 才能完成时, Resource 便会将此请求, 交由 Service layer 来处理。Service layer 便会派工给多个的 Domain。当此请求需要调用到外部的微服务时, Service layer 便会藉由 Gateways去传递个请求 (Request) 到外部的微服务。
Domain: 主要的责任是专注在微服务业务逻辑的处理。Domain 会将处理完业务逻辑后的结果, 传回给 Resources。
Gateways: 主要的责任是使有关连; 会发生调用; 的微服务可以连接起来。Gateways 引导著来自自身微服务的 Service layer 的请求 (Request), 到另一个或多个的外部的微服务, 并且将外部的微服务的响应 (Response) , 传回给自身微服务的 Domain。Gateways 则是藉由 HTTP client 处理微服务间的 HTTP 协议上的请求-响应 (Request-Response)。
Data mappers/ORM: 主要的责任是将微服务内的对象持久化。

微服务与微服务间的协作

微服务是能独立发布、独立部署的; 但, 绝不是 “孤立而行”。也就是说, 我们往往是需要多个的微服务来共同提供一具备商业价值的特性; 如图三所示。

图三: 多个微服务共同提供一具备商业价值的特性

对于由多个微服务共同提供一具备商业价值的特性的自动化测试, 我们需考量:

多个微服务是由一个以上的团队在负责开发时,如何确保某个团队开发的节奏、自动化的测试, 不会影响到其他团队的微服务的发布、布署? 我们将在 “能独立发布、独立部署微服务的团队阵型” 一文中再作探讨。

微服务自动化测试的类型

单元测试(UNIT TESTING)

微服务自动化测试中的单元测试, 也是以单个或多个相关的类 (Class) 为测试的单元。

微服务自动化测试中的单元测试, 也是分成为两类:

社交型的单元测试 (Sociable unit testing): 主要是专注测试模块接口的行为是否正确? 而将以类 (Class) 为单元的测试, 当成是黑盒。在微服务自动化测试中, Domain往往是采用社交型的单元测试。因为, 往往我们需要多个Domain 来完成某个微服务 Client 的请求。
单独型的单元测试 (Solitary unit testing): 主要是专注测试单个类/ 对象和它的依赖间的行为是否正确? 我们往往会将单个类/ 对象的依赖以 Mock 或Stub 的方式来替代。在微服务自动化测试中, 我们往往会将相对独立就能完成自身任务的 Resources, Service layer, Data mappers/ORM, Gateways, HTTP client 采用单独型的单元测试。

社交型的单元测试, 单独型的单元测试对于保障 “单一个” 微服务内部的质量, 扮演著重要且关键的角色。

对于保障 “多个” 微服务间的所谓 “系统层级” 的行为正确, 我们将要藉助:

集成测试 (Integration Testing), 组件测试 (Component Testing), 契约测试 (Contract Testing), 端到端测试 (End-To-End Testing)。

集成测试 (Integration Testing)

在微服务自动化测试中, 所谓的集成测试 (Integration Testing) 主要是测试微服务内的模块能否与外部的微服务或外部的数据库正常的 “通信” ? 而不是在测试外部的微服务或外部的数据库。

所以, 在微服务自动化测试中的集成测试, 只需测试关键路径上成功/ 异常的场景即可。

如图四所示, 在微服务内的 Gateways/ HTTP client, Data mappers/ORM 需执行微服务自动化测试中的集成测试。

Gateways/ HTTP client 的集成测试: 主要是测试微服务内的模块能否与外部的微服务连接, 并且检测通信协议上的问题; 如: 丢失 HTTP 的表头, 不正确的 SSL 处理, request/response 不匹配。关键的一点是: 所有错误处理的场景一定要都能被覆盖测试到。在后面的文章中, 我们也将会探讨运用 Service virtualization 测试关于 timeout 或者外部微服务延迟响应等的场景。
Data mappers/ORM 的集成测试: 主要是测试微服务外部的数据库内的数据表结构是与微服务所期望的数据表结构是一致的。Data mappers/ORM 的集成测试, 对于 NoSQL 的数据库是相当重要、且必要的测试。

图四: 集成测试 (Integration Testing)

组件测试 (Component Testing)

微服务自动化测试中的组件测试 (Component Testing), 指的是: 微服务自身的测试; 以微服务作为测试的单元。

在组件测试 (Component Testing) 中, 测试的粒度是微服务对外的API; 从微服务Client 的视角, 测试微服务对外的API 的行为是否符合预期?

在组件测试 (Component Testing) 中, 将会以 test doubles (mock/ stub) 的方式, 隔离微服务对外的依赖。

如图五所示, 在组件测试 (Component Testing) 中, 为了隔离微服务对外的依赖, Gateways 被配置成去调用 HTTP Client Stub; HTTP Client Stub 将会取代外部的微服务, 而对请求 (Request) 做出响应 (Response)。
如图五所示, 在组件测试 (Component Testing) 中, 我们会以 In-Memory 数据库; 如: H2; 取代外部数据库。这样的作法, 毫无疑问的, 将大幅的提升组件测试 (Component Testing) 执行的速度。

在后面的文章中, 我们将会探讨如何以 Arquillian 实现组件测试 (Component Testing) 。

图五: 组件测试 (Component Testing)

契约测试 (Contract Testing)

微服务是能独立发布、独立部署的; 但, 绝不是 “孤立而行”。也就是说, 我们往往是需要多个的微服务来共同提供一具备商业价值的特性。

当微服务是扮演提供服务的角色时, 我们便称此微服务是 “Producer”。

当微服务是扮演使用服务的角色时, 我们便称此微服务是 “Consumer”。

微服务自动化测试中的契约测试 (Contract Testing), 会在 Producer 微服务与Consumer 微服务之间, 定义一契约 (Contract)。

契约测试 (Contract Testing) 便会根据 Producer 微服务与 Consumer 微服务之间的契约, 测试 Producer 微服务与 Consumer 微服务之间的交互行为是否正确? Producer 微服务上代码的修改, 是否会影响到 Consumer 微服务, 而使 Consumer 微服务无法再运行?

如图六所示:

Producer 微服务提供了 Resource: {id, name, age}。
根据 Contract A, Consumer 微服务 A, 使用了 Producer 微服务, 取得了 Resource: {id, name}。
根据 Contract B, Consumer 微服务 B, 使用了 Producer 微服务, 取得了 Resource: {id, age}。
根据 Contract C, Consumer 微服务 C, 使用了 Producer 微服务, 取得了 Resource: {id, name, age}。

在某一天, 一个新的 Consumer 微服务 Y, 要求 Producer 微服务提供: last name, first name 。

Producer 微服务的开发人员, 便将 Producer 微服务中的 name 栏位(属性) 改成 name 类(对象); 封装著 last name, first name。
经由契约测试 (Contract Testing), Producer 微服务的开发人员将能立马的发现, 他(她) 在 Producer 微服务上的修改, 将会影响到 Consumer A 微服务与 Consumer C 微服务, 而使 Consumer A 微服务与 Consumer C 微服务无法再运行。

在后面的文章中, 我们将会探讨如何以 Pact 实现契约测试 (Contract Testing)。

契约测试 (Contract Testing)

端到端测试 (End-To-End Testing)

微服务自动化测试中的端到端测试 (End-To-End Testing), 主要是要覆盖产品中从前端 GUI 到微服务的测试。

微服务自动化测试中的端到端测试 (End-To-End Testing) 开发与维护的成本是相当的高的。

在后面的文章中, 我们将会探讨如何以 Arquillian 实现端到端测试 (End-To-End Testing)。

图七: 端到端测试 (End-To-End Testing); 从前端 GUI 到微服务的测试

测试金字塔 (Test Pyramid)

在了解了各种类型的微服务自动化测试后, 我们就可以将各种类型的微服务自动化测试, 放入测试金字塔 (Test Pyramid) 中。

如图八所示, 测试金字塔 (Test Pyramid) 可以帮助我们知道如何的去平衡 “测试成本” 与 “测试粗粒度”。

在测试金字塔 (Test Pyramid)中, 越往上升, 所代表的是: 测试的粗粒度越大, 但测试的成本 (测试执行时间) 就越高 (越长)。

　所以, 在 微服务自动化测试的测试策略应该是:

在测试金字塔 (Test Pyramid) 中, 越往上升的测试类型, 其测试的粗粒度就越大, 而其测试的数量应递减。
反之, 在测试金字塔 (Test Pyramid) 中, 越往下行的测试类型, 其测试的粗粒度就越小, 而其测试的数量应递增。
在微服务自动化测试中, 测试数量最多的测试应该是: 单元测试 (UNIT TESTING) 。
在微服务自动化测试中, 测试数量最少的测试应该是: 端到端测试 (End-To-End Testing) 。

图八: 测试金字塔(Test Pyramid)

结论：

在分布式架构下的微服务, 要进行自动化测试是件相当复杂的工程。

软件工程界的巨擘; Martin Fowler; 提供了微服务测试的指引。

我们可根据 Martin Fowler 所提供的微服务测试的指引, 制订我们微服务自动化测试的测试策略。我们后续的文章, 也将会根据 Martin Fowler 所提供的微服务测试的指引, 探讨如何运用相关的测试框架、工具, 以实现微服务自动化测试。

參考資料

Testing Strategies in a Microservice Architecture; Martin Fowler
Microservices Patterns; Chris Richardson
Testing Java Microservices; Alex Soto Bueno, Andy Gumbrecht, Jason Porter

用户运营平台产品设计指南

Wed, 22 Sep 2021 18:23:10 CST

“用户画像”、“用户标签”、“大数据”这些名词是我们近些年来常听的词，可是这些词却很难直接的产生价值，我们都知道大数据有用，画像也有用，但到底怎么用？又怎样具象成一个产品却很少人能够说清楚。

如何采集数据，形成服务再到供给运营，这也是这篇文章想分享的核心。

在市场上神策、易观数科会将其称之为智能用户运营平台。这篇文章会和朋友们阐述用户运营平台的产品设计，帮助大家理解其 底层支持和产品表现。

产品设计的讲解将分解为3部分，分别是 ：选用户、做运营、看效果。

01 产品建设背景

产品建设的背景如下：

1）数据不可用

数据不可用原因有很多种，没有埋点落库是比较好理解的。

其次则是数据分散， 没有将分散在不同业务的用户数据进行关联，这会导致用户画像不够立体，甚至无法识别是否是同一用户。

假设我们无法识别用户在成交前的关键路径，则很难分析其决策偏好及流失过程，运营的深度也会受限。

而许多数据的使用方式也仅停留于浅层的报表应用，数据分析很重要，但分析后也要将其运用于运营。

2）运营无法管理

这一点指的是大多数企业运营管理都强依赖人力，缺乏平台沉淀运营逻辑。当人员变动，依靠人力、代码维护的旧逻辑会很容易被忽略，而运营策略的跟踪、改进就可能不了了之了。

如何让不同的角色迅速了解自身业务对用户的运营策略和效果，这也是建设的目标之一。

3）运营成本高

运营成本高，原因是投放、干预类的需求非常高频，但却每个需求都需要经过产品、研发、测试及发版的过程，就算再高的上线效率，上线的周期也会滞后。

复用率低，则是由于依赖研发的运营策略很难规模化。

4）效果追踪困难

效果追踪困难主要的原因是较难形成统一的业务标准，评估标准不同则无法对比。我们之前听过一个段子汇报时每个部门的ROI都是正的，但企业却在亏损。虽说是段子，但却很真实。

标准不一，只看正向指标不看负向指标，那当然人人都是喜报。每个业务的形态都不一样，标准很难制定，那能否尽量的去找到运营的同类项呢？

这4点就是用户运营平台想解决的问题了，接下来会进行产品核心架构解读。

02 产品架构解读

用户运营平台的产品分解为： 选用户、做运营、看效果。

将其分解为产品术语则是： 在圈选目标用户并设置运营规则，基于运营渠道发送指定运营内容，效果追踪后再进行自助优化调整。

对上图的解读如下：

1）用户圈选：选择访问商品页未成交，且有工作的男性

2）运营规则：今天晚上8点对用户进行风控判定，如风控通过进行A/B实验，1组由推荐算法决策推荐商品，另一组由运营设置渠道和商品。

3）运营渠道：选择弹窗资源位渠道

4）运营内容：设置弹窗落地页跳转商详页

5）效果评估：投放后追踪漏斗数据及成交数据

选用户对应用户数据平台，做运营对应规则引擎和用户交互平台，看效果是分析中心。

大致理解了所提供的运营服务，我们再逐步理解这核心服务对应的 底层支持和产品表现。

03 用户运营平台：选用户

选用户对应前文的痛点是数据不可用，我们要让数据可用，也要解决数据分散的问题， 将分散在不同业务的用户数据进行关联，识别是否是同一用户。

最终实现 可视化选取目标用户。

3-1、底层支持：用户数据平台

要让数据可用，需要建设的是用户数据平台，它是一切的开始。哪怕不用于实际干预用户的运营，进行画像分析、个性化推荐也离不开它。

从用户运营平台的角度，我们要去采集全站的数据让数据多元客观，然后去过滤掉无效、异常的值，在关联成为同一用户，保障画像更为立体。

最后则是将一条条明细的数据，加工成可用的圈选条件，并将其供给运营。

理解表现层之前先了解其底层支持，知其然也知其所以然。

1）数据采集

运用数据的前提是拥有数据，采集数据则是第一个环节。人工采集就是上传数据导入数据库，自动采集则是埋点上报、第三方数据传输相关的工作。

2）数据处理

第二个环节是数据处理，主要包含了 数据落库后的清洗、合并、去重、加工4个步骤。

清洗指发现并修正数据中可识别的错误，包括检查数据一致性，处理无效值和缺失值等。

合并和去重概念，关于数据上的理解可以查阅的这篇文章: 《Tableau基础·如何合并你的数据？理解与逻辑（上）》，Tableau已经描述的非常全面了。

合并的目标有2个，一方面是关联不同业务的核心数据，让用户画像更为立体。 另一方面，在离线查询大批量的时候查询速度能够更快。

不同的数据存储在不同的表，我们希望在查询订单时同时查询用户的关注数据，常见的办法是连表查询。

但这种方法只适合小量的数据，当数据量达到百万级开始连表查询就会非常慢了，而这个时候就会用到 宽表， 它可以理解为一张拥有大量数据字段的表。例如在订单表增加用户的公众号关注数据。

加工逻辑，则涉及到条件的组合。

我们的原子数据如：年龄、性别，这是可以直接使用的查询条件，但如果我们想要的是“中年男性”这个条件，就涉及到加工了，它能让我们查询数据时更加敏捷。

3）数据管理

数据采集、处理后下一个环节是数据管理，它是数据服务的基础， 它负责定义数据标准，管理数据权限，并保障数据质量。

标准是指，我们怎么定义一个完整的数据，需要有名称、值类型、取值的范围、加工的逻辑等。而权限则决定这个数据归属于谁管控，密级程度又决定了不同角色的操作，包括读、写以及使用。

最后的质量部分则是通过对应的监控措施保障数据质量， 数据是否及时更新，更新的进度和速度是否符合预期，生成的数据是否符合规范，量级波动是否达到了告警线。

假设一切正常，它又 是否正常的被下游消费，消费过程又是否存在阻塞。

4）数据服务

数据服务，这个词广义的说数据的采集、处理、管理都是一种服务。在这里特指的是供给实际运营的服务，例如：人群服务、风控服务、运营服务。

风控服务

具备了数据，就能够对不同的场景制定不同的风控评分规则，用于识别黑产、金融产品售前评估、金融产品的定价。

异常监控则指当号码、账户发生了冻结等情况可能造成用户的违约，在金融产品层面做预警。

运营服务

智能推荐实质也依赖于数据平台，通过用户的特征输出推荐结果。RTA则运用于广告，基于特征决定是否参与定价。

人群服务

人群服务会运用于用户运营平台的“选用户”环节，数据的管理能够提供可选择的用户条件，进行前端渲染。

而选完条件后则涉及数据的去重，不同人群包之间的计算，在最后的运用环节又涉及到了加解密。这个部分在下文会详细描述。

描述完了底层支持，下一个部分就是用户运营平台的表现层“用户圈选”，那数据平台到底是怎么为“用户圈选”提供能力的呢？

3-2、产品表现：用户圈选

在选取用户时须考量的产品功能为： 圈选方式、圈选频次、圈选条件及人群服务。

实质上这4个功能的底层支持都来自于用户数据平台，用户运营平台则负责服务的运用及表现。

1）圈选方式

条件选取

这是在 可视化、自助化选择用户条件后，通过与其取值范围进行比较经计算生成人群数据包的一种形式。

一般来说，具备抽象为可视化条件的数据使用较为高频，数据准确性较高。 它的底层原理是对条件和计算进行标准化，然后拼接类似SQL的数据查询语句。

智能选取 & 自主上传 & SQL提取

智能选取、自主上传、SQL选取，是对“条件选取”的补充。

智能选取主流分为2类，1类是用户规模无法满足要求时 对用户进行相似度计算，从而扩大用户的规模。

另类的运用场景则是 运用算法模型选取用户，结合运营的效果数据对模型进行调优，不断寻找最优的高响应人群。

SQL选取与条件选取的原理相近，它主要运用在数据未被标准化，无法可视化选择的场景。

另一个场景则是追求更快的查询速度，因为标准化的查询语句追求的是通用性，查询速度对比自主撰写语句时大多较慢。

2）圈选频次

单次提取

单次提取，指一次性提取数据，当前时间提取后数据 不再发生变化。

运用的场景多为在做运营实验，而运营实验的效果还不够好，暂时没有固化为标准的运营方案；另一个场景则是用户运营的规模数据量大，担心投放时再取数其时间过长，先提前提取数据。

动态提取

动态提取，指相同的条件在不同的时间提取。这种情况，基于数据的时效性，其数据可能会发生变化。常见于定期固定的运营计划，如：用户成交10日后赠送积分。

自主上传则没有动态提取这一说法，都是一次性的操作。

3）圈选条件

下方的交互仅面向于条件选取，而SQL、上传、智能的交互都是不同的表现方式。

条件的来源主要有4种，除了接口上报都应来源于用户数据平台所管理的数据，然后再 基于其数据标准，渲染前端的页面。

实时事件

主要面向时效性要求高的场景，是用户实时发生的行为，例如用户访问某页面。
接口上报

实质上是非标准化的实时事件，一般在临时性的活动会使用，如活动任务完成。
用户特征

对时效性要求低，一般用于定时的运营，且无须查询用户的关联数据。
宽表字段

概念与用户特征相近，但主要用于数据时效性要求低且需查询用户关联数据的场景。

在这里额外描述一下关于“用户特征”和“宽表字段”的区别，详见下图：

关于非实时的查询条件主要分为宽表字段及用户特征。

为了能够快速的查询更多用户数据，会将用户数据基于userId集成在一张数据表中，由于存储了大量不同业务字段，也称之为宽表，如：在订单表基础上增加用户年龄、性别等字段。

宽表字段是明细数据，数据量多意味着查询的速度会受限，但你也能迅速的提取其关联数据；当需要 快速进行点查询且不需要用户的关联数据时，则会使用用户特征。

例如：需要对前一日关注公众号的用户并发放短信，会使用具有明细数据属性的宽表字段，从而获取其手机号。但如果是在活动的页面，需要实时判断用户是否关注从而引导用户关注，则会使用用户特征。

理解了条件的来源，下一个部分会介绍条件的比较方式，它和数据的值类型有关。前端页面也应基于值类型渲染比较条件。

时间条件一般不会进行枚举，因为日子一天天的在过，很难将它数清楚。

其对应的条件选择交互式日历选择器或日历范围选择器，而动态时间则一般使用T+N的形式，在这里T指的当时（一般为天），而N也可以为负数。

例如：关注时间=T-1，意思为1日前关注的用户。

而数字、字符串的比较方式都相对接近，只是数字和时间能够有“大于”、“小于”这类的比较方式，但字符串没有。

4）人群服务

前面的部分描述的是如何选取用户，而这一部分则是选了后还要做的事情。

其执行流程如下：

通过条件查询得到了人群包，然后对不同人群包进行交并叉相关的数学计算。在计算后进行数据去重，最后再查询这批用户的数据提供于内容话术及接口使用。

接下来详细介绍下这几种服务：

交并叉

去重

去重就好理解了，核心原因是防止数据重复，避免因数据重复在查询数据时浪费资源。

关联数据查询

这里分别在内容话术和接口使用提供2个例子。

对于内容话术，我们推送了一批待续费保单的客户给予售后部门进行引导续费，但如果需要能够指导策略，还需要给予售后关于的保单详细信息，如：保额、保费、投被保人关系等。

而接口使用，则与调用接口要求的入参有关，如风控接口一般会需要用户的身份证和手机号等。

04 用户运营平台：做运营

产品和运营的工作主要为 策划和执行，而痛点也由此而生。

策划的痛点是过往的逻辑难以追溯，很难能体系化的了解过往的运营思路，过往面对谁做了什么事效果如何，当前又是否正在运行？我们的新方案总是从零开始，需要重新的踩过往的一个个坑。

而执行痛点则是要上线一套成体系的运营方案链条太多，不同任务完成的方式不一有的需要配置有的又需要研发，不仅接口人不同，上线的周期即慢又零散，非常依赖于项目管理的能力。

有没有一个方式能够尽可能的让多变的运营规则实现配置化，让运营能够实现线上管理呢？ 这里的解法是 规则引擎负责运营规则的组合，而交互平台则提供组合的内容，再提供不同运营视角的管理视图以及自助化的配置工具。

这2者如果能够做到极致，那就是no-code。

4-1、底层支持：规则引擎与用户交互

4-1-1、规则引擎

规则引擎业界也称自动化营销平台，规则引擎这个名词有点抽象，不妨理解为但运作一件事的规则或逻辑。

这里又来到了耳熟能详的的5W2H法环节，规则引擎是什么时间对什么人在什么地方以什么方式做什么事（5押）。

什么时间做和对谁做是触发条件，对谁做在实时事件触发的场景，例如用户签到立即下发奖品，这种情况事件即是触发条件又是判断条件的一部分。

判断条件的本质是过滤，例如过滤昨日签到用户中的黑产用户，除了用户本身的特征，我们还会接入风控、推荐等接口。

流程控制从计算机运算角度是改变流程执行顺序的指令，浅层的理解为判断条件和执行条件的衔接器。

在实际运营中不一定每次判断生效都会立即执行，会加以时间等待或者分组执行。例如：当用户访问页面后等待15分钟触发运营逻辑，等待指令就是流程控制。

执行条件就相对简单了，但在思考的时候不要被束缚。

一切对用户的运营干预手段都可以是我们的覆盖范围，无论是触达还是弹窗，无论是非人工、人工还是智能，做B端重要的是连接和共赢。

理解了规则引擎核心的4要素，下一个问题就是如何能够让研发、产品、运营不同的角色都可以使用，适用的角色每向前一步，易用性就更高一层。

如果连研发敏捷提升都无法做到，那这套引擎就没有存在的意义了。

关于敏捷，我理解的是低代码或者无代码实现运营需求，并且能够自主测试无须发版，所以对应的解决方案是 可视化的拖拉拽，上图是易观数科的智能运营Work Flow，是一个很好的案例。

但对比no code我个人还是倾向于low code，no code基本是通用的模型和标准化的模版，无需研发、人力投入，即可快速上线应用。

它可以参考网页、活动等标准化服务的提供商，这种方式的缺陷是，强依赖于模版。如果不具备适合的模版，其实用性会大打折扣，而且很难兼容复杂逻辑， 最简单实际上也最不灵活。

low code，则是通过建设一些基础设施，实现部分逻辑配置、部分编码，实现部分逻辑可配置，测试可自助。适用于有一定研发理解能力的产品、运营等同学。

4-1-2、 用户交互

交互，顾名思义是交流与互动。 规则引擎负责规则组合，而交互内容负责规则最后的一个节点：执行。

我们希望做用户运营便需要与用户产生联系，这则依赖于能够触及用户的渠道，不同的渠道又有各自特点交互内容。

这一章节没有太多复杂的底层支持逻辑，基本就是渠道能力的建设，渠道内容的维护和管理，更多要关注的反而是视野。

这幅图枚举了大致可能与用户交互的渠道以及渠道支持承载的内容方式， 渠道不仅推送，还有企微这类私域的聊天讯息，其次还有电话对应的人工服务以及站内的资源位。

下发的内容也不仅是文字、图片，也可以下发任务或者奖品。任务可以理解为你希望用户完成的事情，奖品则是完成什么事情后你所要提供的激励。

在这里大家可能会有的疑问是，落地页不就一般承载了任务和奖品么，这一点来说是的。但就是有的场景会没有落地页，例如智能外呼、短信。这时候则会运用到通用化的用户任务体系和奖品了。

至于说内容的产品支持工具，还包含二维码、海报、短链、落地页生成等，这些产品怎么实现并不是这篇文章的重点，这里也不做描述了。

4-2、产品表现：方案管理及方案配置

做运营的痛点是：管理困难、成本高及上线周期长。

线上的列表视图只是最浅层的管理，我们还应该还应提供不同类型的视图帮助运营同学了解运营方案的运行状况和业务逻辑。

而成本、周期的问题，则应通过自助化、一站式、可视化的配置来解决，这个部分则依赖则是4-1的底层支持。

4-2-1、方案管理

方案管理，首先定义何为运营方案，它包含三部分： 目标用户、运营策略、效果评估。

对方案的管理，常见的是列表视图，包含基础的列表及列表筛选。这一点就不描述了，而当我们要了解业务运行状况时就会使用到：执行视图、逻辑视图等。

1）执行视图

从运营的角度，任何的投放类的运营基本都涉及到KPI， 先无论效果如何，每个运营策略要先关注执行是否按时、按量执行。这是运营效果的基础。

时间部分，主要分为开始时间、持续时间，部分的业务是对任务完成时效有强诉求的。

而量级部分首要的是任务的成功率，在产品设计时再往前做一步还可以基于对应方案的总量级、成功量级做同比或者做趋势，方便我们定位问题。

2）逻辑视图

逻辑视图，承载了运营方案的逻辑。其次想帮助运营同学建立运营的全局视角。

这一部分对于不同的产品形态、业务目标，其差异就很大了，下图举一个基于商品的逻辑视图。

商品视图是单一商品在不同的运营场景，在什么时间节点、使用了什么渠道进行运营。

每一个渠道都可能拥有自己的细分目标，点击“目标：引导加购”，则能够进入详细的运营方案，从而查看运营逻辑。

第二幅图则是从品类的角度，来查看场景运营是否缺失，这个视图不关注渠道、时间等具体的细节。

这只是2个示例，大家可以基于自己的业务形态去设计自己的管理视图。

4-2-2、方案配置

上文的商品视图，只承载了逻辑的一部分，更详细的逻辑则会进入运营方案页面。它包含了运营方案的面向用户、运营策略、评估指标。

接下来为大家讲解的部分是，一个方案配置的表现层是怎样的。配置的方式， 业界主要有2类，一类是流程视图，另一类是表单视图。

流程视图可以参考钉钉宜搭、易观数科，在这里只做简单的图片展示：

钉钉宜搭

易观数科

表单视图，也是比较主流的方式。个人的设计将运营方案拆分为了4个部分：运营频率、面向用户、运营策略、效果评估。

这一小节，先阐述前3小点。

1）运营频率

一个运营方案，首先要处理的是在什么时间范围内运营，其次是以什么样的频率在什么时间运营。

事件触发则不依赖时间，基于事件发生实时触发，这一类型没有运营时间的概念。而循环触发、单次触发则会有时间的概念。

循环触发，是指多次的触发任务，触发事件仅适用于每日定时任务，间隔日定时任务。对间隔日定时任务举一个例子辅助理解：每周一都要上班。

单次触发，则是一次性的任务了，可以是方案建立后立即发送或者定一个创建方案完毕后的时间进行发送。

交互示意如下：

2）面向用户

这个部分，在讲解用户数据平台的表现层时是有详细介绍的，在这里只做交互示意。

3）运营策略

上图是一个简单的模式，能够服务大多数的场景。但在实际的过程中还是会涉及到判断、执行条件的组合。

复杂的模式，会在上图额外增加运营规则字段，规则由研发可视化托拉拽配置而成，然后规则再渲染执行相关的渠道、内容提供运营填写。

但规则多了，也就难以维护和理解。除了流程视图，怎么样做能够更易用、更易懂，我目前也没有很好的答案。

灵活和通用，真的没那么容易做取舍。

05 用户运营平台：看效果

终于到了主流程的最后一个部分：看效果。

回顾一下看效果的痛点：评估标准不一，无法对比，并且缺乏负向评估。

这一部分从个人的角度主要是需求方，而非实现方，所以没有太多的底层实现可以分享，而表现层则是基于运营方案的执行结果，对干预成功的用户进行漏斗统计、ROI计算，以及下钻的画像分析。

这里主要描述漏斗统计和ROI计算的一些思考：

1）漏斗统计

漏斗的统计主要看端到端的转化，指标的定义如下

目标用户总数：用户圈选组合后的用户总数
干预成功用户数：经过防骚扰屏蔽、红黑名单或运营策略等判断条件过滤后下发成功数量
点击人数：下发用户后，用户进入落地页的人数
转化人数：点击用户实际完成转化目标的数量

转化人数的概念非常的广，取决于你希望这个用户完成的行为指标。这个指标每个运营方案都可能不太相同，包括成交、续费、访问、关注等。

如果你不是数据产品关注的核心应该是梳理不同业务的转化指标，并交付数据部门实现统计再集成进你的平台。

2）ROI统计

ROI统计这是一个比较难设计的模块，在这里可能也只是抛砖引玉。

之所以说难，难在不同的业务指标不相同，统计的方式也不同，如果强行输出，可能得不到大家的认可。

这里个人的思路是 分业务计算，抓小局放弃大局。理解梳理不同业务的计算方式，并为其提供通用的配置计算能力。帮助不同部门的 内部能够比较，能够衡量。

ROI的计算公式，相比传统的计算方法额外多了一个参数： “负向指标经济价值”。

道理也很简单，每发一篇公众号文章，有人关注也会有人取关，有正向也当然会有负向。但这并不是说不需要继续运营了，而是要让分子大于0，并且尽可能的靠近、超出分母。

以上图的第二个例子进行解读，假设是某东Plus会员年卡，临近过期用户仍未进行续费，这时平台运营会将这部分用户推送至外呼专席，由外呼同学引导用户进行续费。

过程指标体现了结果指标的完成方式，要提升结果指标的经济价值，要么减少完成过程的损耗，要么提升完成结果的单价。

而负向指标，即这种运营行为可能导致的损失，这是这个运营举措带来的负向影响，如第一个例子中的取消关注。

负向指标同样需要换算为经济价值，如：1个公众号粉丝的费用，1个小程序UV的费用。正负向的结合，才能使计算更为客观。

写在最后

这篇文章，写的很艰难也很畅快。艰难是我从未想过我最熟悉的B端产品，沉下来写会多了这么多的产品方向。畅快则是终于我不用管那该死的边界、价值、实现难度，能够设计理想中应该包含的东西，应该呈现的交互样式。

完整的用户运营平台非常复杂、成本也很高，它要求你的业务是强依赖于召回，并具备足够大的业务量级与收益。 否则，我还是建议从这里去汲取灵感，自己做自己的MVP。

思维可以更开阔一些，有了用户数据平台，基于特征做拖拉拽的BI报表也可以，画像分析也可以。有了规则引擎解决审批流配置、调研问卷的问题也不错。做了渠道能力，为外呼团队、客服团队提供支持也是很好的路径。

其实能设计这样一个产品真的运气挺好的，它把我过往的产品经验进行的连接，在第二份工作的时候，我做的B端产品非常多，包括：页面配置、任务、奖品、用户特征等等，但它们的连接都非常的疏离。

这一次才有点点所谓生态的感觉了，而不是假大空的一个名词。

最后呢，还想要建议B端产品在设计时尽可能的屏蔽底层逻辑，减少配置项。这么多的可视化、自助化配置，确实减少了研发的成本，但只是转换成了是产品和运营在负重前行。

回到C端也快3个月了，写一篇B端产品的毕业论文，还还2个月不更的债。

非常感谢你看到这里，谢谢宁。

8000字干货教你打造电商产品的用户体系

Mon, 16 Aug 2021 10:10:06 CST

各位小伙伴好，本文是电商产品设计系列文章的第六篇，用户体系产品。对于任何电商产品来说，没有用户的产品是没有未来的，拥有用户但却不懂用户的产品也是没有未来的。产品经理需要从心理上去理解用户、预判用户的行为，在现实中挖掘用户的需求，从行动上给予用户激励与反馈，因此建立一套完善的用户体系产品就显得尤为重要。本期我们将从四个方面系统介绍用户产品的相关内容，分别是用户账号、用户画像、付费会员、免费会员。

一、用户账号

1. 账号价值

我们在导言中说过了对于一个电商产品而言，了解用户、运营用户是非常重要的，一个好的产品需要持续为你的用户产生价值，这样用户才会愿意持续使用并为产品付费。为了寻找用户，我们首先要找到代表用户的载体。在线下我们常用的代表用户的载体有身份证、社保卡，相应的在线上产品中我们也会有唯一的能代表用户的载体——用户账号。

在电商产品中，用户账号是能唯一代表真实用户的载体，用户账号中记录了用户的一系列信息，包括用户基本信息、交易数据、行为数据等。我们可以据此分析用户，进而进行精细化、个性化的运营，为用户提供精准的服务。因此，账号对于电商产品在用户信息收集、用户安全性、会员服务以及后续的精准营销中都有较大的价值。

2. 注册/登录方式

了解账号价值后，我们来看看账号最基础的注册与登录方式，只有注册之后我们才能拥有自代表自己的账号。首先我们来看看需要用到账号的场景，主要分为三种：

1）核心节点需要注册登录。常见的有电商、咨询类产品，如京东、淘宝、今日头条等。

2）非注册登录也可使用。一般是工具类产品，如墨迹天气、剪映等。

3）强制注册登录。一般是和账号息息相关的产品，使用任何功能都需要登录，如某些社交类产品。

这里我们说一下电商产品，常见的允许非登录状态下浏览商品、活动等，核心节点如商品加购、提交订单、查看订单等节点会触发账号登录。

在上述需要登录的节点，我们需要登录账号，对于未注册的新用户则需要进行账号的注册，常见的注册方式有4种：

1）自定义账号注册：自定义账号，由字母和数字组成，账号唯一不可重复。

2）手机号注册：通过手机号和验证码注册，密码需要自定义，也可以通过验证码登录。这是目前主流注册形式。

3）邮箱注册：通过邮箱地址注册账号，发送邮箱验证码确认通过，目前会慢慢淘汰掉。

4）第三方注册：引入第三方社交账号，读取社交关系，快速注册账号，一般需要在册填写手机号。

账号注册完成后，不同的账号体系可以引入多种的账号登录形式：

账号＋密码
邮箱＋密码（不常用）
手机号＋验证码
手机号＋密码＋验证码（不常用）
第三方登录
第三方登录＋手机号绑定
第三方登录＋密码（不常用）
第三方登录＋密码＋手机号绑定（不常用）

建议不同的产品根据自身特点，选择最通用最适合自己的方式，不宜设计的过于复杂。

接下来，我们重点介绍一下手机号与第三方账号的注册/登录流程。

首先是手机号注册登录流程，这部分的重点在于对手机号格式的校验，校验通过并完成密码设置后即完成了账号的注册与登录流程。

然后是第三方账号注册登录流程，我们以微信登录为例，主要的步骤是获取微信的授权以获取用户在微信的信息。

用户授权第三方账号资料信息，与平台账号绑定，通过openID来获取账号信息。这里需要注意的是，这种方式一般是需要绑定手机号，以沉淀用户信息。

3. 账号信息与安全

注册账号之后，我们便获取了自己的账号，账号包含的基本信息如下：

账号：用户注册的账号，如QQ号、自定义的字符串、手机号、邮箱等，不可更改。
UID：后台记录用户唯一身份的id，不会展示给用户。
昵称：展示在前台的名称，可更改。
头像：账号唯一的头像，可更改。
邮箱：UID绑定的有效邮箱，唯一，可更改。
手机号：UID绑定的有效手机号，唯一，可更改。
密码：账号的唯一密码，可更改。
实名信息：用户真实姓名、身份证、性别等，不可更改。

账号产品内包含了用户账号、登录方式、注册登录、密码、账号安全的相关流程与内容。

因为账号内包含用户很多重要的信息，因此账号安全也是在产品设计时需要重点考虑的问题，特别是在用户对于自身隐私越来越重视的今天，账号安全是任何一个产品都必须重点考虑的问题。我们总结了一下，账号的主要安全措施如下：

短信验证码：用于注册、登录、密码找回等操作
防刷机制：防止批量创建账号、批量验证账号等恶意操作
异地提醒：不常用地址登录提醒，防止盗号
邮箱激活：邮箱注册方式需要邮箱激活
图形识别码：登录时，设计图形验证码能防止机器人刷
手机号：绑定的有效手机号，进行真伪性验证
IP限制：用于防止恶意的大量注册、登录行为
实名信息：用户真实姓名、身份证、性别等，不可更改

对于这些账号安全措施，密码找回是最常见也是使用频率最高的方式，我们重点介绍一下找回密码的流程。

其中用手机号找回密码最常用，主要是利用已和账号绑定的手机号通过短信验证的方式证明操作者身份后，为用户重置密码。

二、用户画像

1. 基本定义

我们都知道，产品设计的根本依据与来源是用户需求，而用户需求的主体就是用户。我们大都知道需求来源于用户，但是许多产品经理在实际设计产品时，往往会忽略用户而从其自身角度出发去思考问题，这样设计出的产品也会脱离用户。而用户画像就是帮助我们更好理解用户的工具。

用户画像的定义有很多，在这里我们对用户画像的定义是：用户画像是真实用户的虚拟代表，是建立在一系列真实数据之上的目标用户模型，即用一组数据标签表达一个或一群用户的特征。

因此，想要精准描绘用户画像，关键在于获得更多的用户真实数据，包括用户的基本信息、行为数据等等。在电商产品中，我们可以根据用户的基本数据、交易数据、电商行为数据等描绘出一个人或一群人的用户画像，用户数据越多则用户画像描述更准确。因此阿里对于用户画像的描述非常准确，因为他可以通过淘宝天猫获取用户购物数据，通过支付宝获取用户实名信息、财务信息、投资信息等，通过高德地图获取用户出行信息，通过饿了么获取用户外卖信息，通过虾米音乐获取用户听音乐信息等等。将这些用户信息组合在一起后对于用户画像的描述是非常准确的。

举个例子，我们可以根据用户在电商产品产生的数据，描绘出典型的男性购物者画像，其特点如下： 1）目的性强，决策速度快。 2）容易受到展品营销影响容易被孩子恳求说动。 3）不喜欢咨询，更喜欢自己研究，自己上网获取信息。

2. 应用场景

用户画像最基本的应用场景主要有四个：数据挖掘、精准营销、产品迭代、用户研究。

数据挖掘主要是对收集到的数据进行挖掘分析，基于数据推荐用户可能喜欢的商品。常见的就是电商产品的猜你喜欢、智能推荐等。

精准营销指根据数据对用户打上不同的标签从而形成不同的用户群，在设计运营方案时根据不同用户群体的特点，设计针对性的营销手段以取得更好的营销效果。常见的有新人优惠，老客回归礼包等。

产品迭代指根据用户画像的数据，挖掘出不同用户群体对于产品的诉求，比如不同性别的用户对于产品的使用有什么差别、他们对于产品的期待是什么，这些都可以通过数据去反映。

用户研究指的是根据前期算法得出的画像，研究不同画像的用户的社会属性，用于指导产品的发展方向等。

3. 用户模型

我们建立用户模型的主要步骤是获取用户数据并对数据清洗，提取特征并将清洗后的数据放入模型进行训练测试。

接着，我们介绍三个常见的用户模型。

第一个是购物性别判断模型，我们用这个模型去判断用户的性别。首先我们要明确一点，用户填写的资料不一定真实，我们对他/她的性别数据持怀疑态度，需要其他数据辅助证明其性别，如订单数据。以判断男性用户为例，我们需要综合其填写的信息与其订单数据，认为填写信息为男性且购买过的男性特征类目商品数量>购买过的女性特征类目数量的用户为男性用户。

确定完模型的规则后，我们需要用到机器学习中的交叉验证方法去不断优化模型。简单来说就是先将样本分为训练集与测试集，比例可以自定。其中训练集用来训练模型的数据能力，测试集用来测试模型的效果。最后用另一份样本做预测集，验证模型的预测能力。

比如我们输入预测集数据，得到其结果如下。以第一列为例，预测集数据为1500000个男性，实际模型预测为男性样本数为1403749，预测准确率为93.58%。我们可以据此继续对模型调优提升其预测准确率。

上述只是简单描述，这部分工作主要由开发完成，但是作为产品经理基本的原理还是可以了解一下。

第二个模型是购买力模型，用于评估电商用户的购买潜力。

建立模型后，即可用此模型评估用户的购买力。我们根据用户购买商品价格的高低，将用户分为土豪级买家、高级白领、白领、蓝领、底层。

第三个模型用于评估用户对促销的敏感度。促销敏感度是评估用户是否对促销敏感化指标，敏感用户只有促销时才会下单。另外，国内用户几乎都是敏感型用户。

促销敏感度是评估用户是否对促销敏感量化指标，敏感用户只有促销时才会下单。

三、付费会员

在完善基础的账号体系，建立顺畅的登录流程并能保障账号的安全性后，我们可以考虑引入会员体系。

为什么要打造会员体系呢？我们先来看几组数据：

Costco 是美国最大的连锁会员制仓储量贩店，作为其主要收入来源的会员费收入占其营业利润比例在80%以上，全球范围内的会员续费率保持在80%以上。
山姆会员商店是世界500强企业沃尔玛旗下的高端会员制商店，是全球最大的会员制商店之一，其在全球共有超过5000W的会员，为其带来了超过20亿美元的收入。
亚马逊（Amazon）是美国最大的一家网络电子商务公司，同时它也是全球第二大互联网企业。2017财年其订阅服务（Amazon Prime会员的阅读与年度会员费收入，以及Prime会员对有声读物的订阅收入）净销售额为97.21亿美元，占亚马逊净销售额5.47%。2018Q2其订阅服务净销售额65.1亿美元。
淘宝2018年超级会员数超过1500W，会员用户带来的销售额占其总销售额20%以上。其普通会员客单价为50+，而超级会员的客单价高达150+。

从上述数据我们可以看出，会员用户能为企业带来巨大的收入。我们可以从GMV的构成去解释会员产品的价值:

所以提升用户UV、转化率和客单价自然就能提升GMV，会员用户相对普通用户来说有更高的更高的粘性，有更高的UV。而会员用户会享受一些会员的权益，再加上其更高的忠诚度，所以相对普通用户他们会有更高的转化率和更高的客单价。因此，会员用户能为企业带来比普通用户更高的GMV。

1. 会员类型

我们来看一下常见的会员产品：

在这些产品中，会员类型主要分为免费会员与付费会员两种类型，而免费会员又可细分为品牌会员与业务会员两种类型。

以免费会员与付费会员为例，我们探讨一下常见的会员产品设计思路。

付费会员，即需要用户支付会员费用才能加入，对应的付费会员权益一般是一系列的大额优惠权益包，一般价值高于会员费5倍以上，还包括一些限时领取的权益。其核心在于会员定价、权益特权、价格计算器的设计，给用户营造一种自己占了便宜的感觉。付费会员的目标场景是提升用户复购率。

免费会员，即用户不需付费即可加入，不同的等级会有不同的权益包，一般是一次性领取。其核心在于积分兑换、任务体系、等级制度的设计。免费会员的目标场景在于提升用户粘性与平台的活跃度。

这里有一点非常重要，即付费会员与免费会员不是绝对对立的，他们可以相互转换。如果你服务好了免费会员，他可能会成为付费会员。相反的，如果你付费会员的服务很差，他会变为免费会员甚至脱离平台。因此，我们需要建立完善的付费会员体系，吸引更多的免费会员加入。

2. 付费会员

上文说到了我们需要建立完善的付费会员体系，吸引更多的免费会员加入，接下来我们探讨一下付费会员的相关内容。

在前面的数据中，我们可以看到，付费会员除了给企业带来会员费的收入之外，比普通用户拥有更高的粘性与忠诚度，能够给企业带来比普通用户更多的购买，甚至发展出了专门的会员制电商形态。因此，付费会员对企业的重要性不言而喻。

那么，一个企业在什么时候需要付费会员呢？

从不同用户占平台总销售额的比例来看，如果头部的20%的客户，其占整个平台销售额的80%以上，那么我们可以考虑引入付费会员体系，这个时候，少量的付费会员能够给平台带来绝大多数的收益。

为什么付费会员会产生比普通用户更多的购买呢？

在解答这个问题前我们先来探究一下电信诈骗的过程以及这其中的原因：第一步，受骗人被告知可以投入小钱赚大钱，因此投入了金钱；第二步，受骗人被告知原先投入的钱不够，需要继续加量，才能继续赚钱并拿回本钱，因此继续投入；第三步，受骗人继续被告知需投入更多，并不断重复投入；第四步，诈骗人卷款跑路。

在这个过程中，在投入了第一笔钱后，当被告知需继续投入的时候，其实很多人应该是会有犹豫的，但是大多数人心理会有这样一个想法“我已经投入了一笔钱了，如果不继续投入，那我原来的钱就没有了，我应该继续投入”。就是这样的心理让被骗人持续不断的投入直至被骗。在心理学上称呼这种现象为“厌恶损失”，举个例子，你损失100元消耗的快乐感要远大于我送你100元获得的快乐感，损失要比同样多的收益对我们的影响更大。

厌恶损失的心理同样可以用在付费会员上，当用户付费购买了会员，如果不利用会员权益购买更多东西获得更多收益以值回会员费的付出，我们就会感觉自己吃亏损失了。因此，在这种心理的驱使下，付费会员往往会给企业带来更多的购买。

最后，在设计付费会员产品时，我们需要从定价策略、权益价值匹配、全链路身份透出策略三个方面去考虑。

关于定价策略，我们首先需要考虑的是权益本身的成本，Costco和山姆会员店能够跑起来正是付费会员给他带来的收益能覆盖他提供的权益的成本。第二个考虑的是竞品成本，在差不多的权益下，我们需要参考竞品的定价。比如京东plus会员是99元，淘宝的超级会员是88元，他们的会员定价相差不多，提供的权益也接近。但是如果在权益不变的情况下，一方的价格远高于另一方，这个价格就不合理了。第三个考虑的是使用率，根据用户的使用频率去定价，让用户每次使用都感觉自己赚到了。

关于权益价值匹配，我们主要梳理能给用户提供的权益，一般是通过一个价格计算器来展现付费超值，比如实时展示会员已帮助用户节省了多少钱，权益可以通过折扣、优惠券、特权等体现。一般是通过高价值与稀缺性的权益来体现出付费会员与免费会员的不同。

关于全链路身份透出，即在产品各个地方展现付费会员的权益与尊贵，比如商品价格处专门展示会员价格，评价处会员的评价也会特殊展示等等，用这种展现与透出满足用户，提升其付费带来的愉悦感。

四、免费会员

说完了付费会员，本小节我们来探讨一下建立免费会员体系的相关知识。因为，并不是所有人都愿意去付费，我们可以给普通用户一个成为免费会员获取权益的机会，以提升其活跃度和粘性，最后甚至将其转化为付费会员。

在互联网流量红利接近尾声的阶段，精细化运营是未来非常重要的一个模式，而会员模式是精细化运营中非常重要的一个部分，接下来我们就来介绍一下免费会员产品的相关知识。首先，我们可以将免费会员产品的价格分为四个部分：等级规则、积分体系、会员任务、权益中心。

1. 等级策略

会员的等级策略包含两部分，分别是会员等级策略和成长值策略。

首先是会员等级策略：

1）等级划分可以具象化，如京东原会员等级：铜牌、银牌、金牌和钻石会员

2）目前电商平台正日渐消除具象化的会员等级title，代以简单的数字区别

3）等级划分可以数字化，到达某个数值后即可升级，即可拿到该级别对应的权益

4）等级对应的丰富的权益奖励是吸引用户升级的手段

接着是成长值策略：

1）会员等级是基于成长值，成长值到达一定数值后，会员即可升级

2）成长值获取途径：

购物，购物获取一定分数，但是有次数限制
互动，通过一些玩法获取成长值
基本资料，日常行为和资料完善可增加成长值
信誉评级，如购物履约行为，购物合规行为均会影响评级，评级越高则成长值越高

3）成长值变化：

长时间未获取成长值（如1个月），可约束成长值降低
每隔一段时间，成长值重新计算

2. 积分体系

会员积分是电商产品虚拟货币的一种，不同的电商可以自定义积分规则与积分名称，如淘宝的积分叫淘金币，京东的积分叫京豆。但是建设积分体系也有一些共通点。

积分体系主要可分为4部分，分别是积分获取、积分消耗、积分流水和积分成本。

积分获取部分中，我们可以设置多元化的积分获取渠道，常见的有升级获取、购买获取、任务获取等，但为了防止恶意获取我们也会设置获取限制，比如总的积分上限的限制和一段时间内积分获取的限制。限制积分获取主要是为了保证积分价值，如果积分无限制获取的话会导致积分泛滥而不值钱。

积分消耗部分中，同样的我们需要设置多元化的积分消耗渠道，常见的有积分兑换、积分抽奖、积分抵现。在积分消耗的环节，用户能最直观地感受到积分的价值，所以这部分对于积分体系的建设非常重要。在积分兑换与积分抽奖等环节我们有时也需要设置积分消耗的规则，以保证尽可能所有用户都能兑换到奖品或参与抽奖。

积分流水，即积分获取与消耗的记录，主要让用户能够方便查询自己积分的使用情况，对积分的来源与去向清楚掌握。

最后一个是积分成本，积分其实就是钱，是实实在在的成本，我们需要根据部门的预算去做好规划。

总结一下，在建设积分体系时，有3个核心规则：

1）积分价值：我们需要确保积分的价值并维护其长期的稳定，不让用户心理产生落差，比如固定好100积分=1元钱。

2）积分出入口：我们需要保证积分有合适的获取/消耗口子，做到积分可拿可兑。

3）积分成本：我们需要根据相应的权益提供方，合理规划积分成本。

3. 会员任务

会员任务指会员完成的一些任务，可以帮助用户获取额外的积分，同时为平台带来更多的活跃与收入。根据场景的不同，我们可以设计3种任务类型的免费会员任务：

1）引流型：一般为长期的任务，用户能够一直玩，玩的时间越长，得到的奖励会越高。常见的活动有日常签到、每日抽奖、礼包领取等。

2）激励型：一般为短期的一次性任务和奖励，该类任务用于引导用户完成指定任务，可让用户在短时间内得到奖励。常见的活动有引导购买、补充资料、下载APP、申请信用卡或浏览页面等任务。

3）分享型：一般是用于引导用户自传播的分享形式，主要可分享至社交媒体。在任务完成后，任务传播者和带来的新用户会获得不同的奖励，奖励的形式有京豆、优惠券、商品等。

接下来，我们拆解会员任务在系统内的交互：

我们以京东为例，看一下免费会员的权益中心能够获取积分的途径：

除了内部电商产品的内部权益，很多会员还可享受一系列的外部权益，常见的如视频网站会员卡、酒店差旅折扣券、打车券等等。

五、总结

在总结全文之前，我们来探讨一下会员产品的建设路径。

会员产品并不是在电商产品刚建设时就要引入，但是引入时机迟了也会造成用户流失，所以我们需要在合适的时机开始会员产品的建设。我们以电商产品的发展时间为区分，将其分为初始期、成长期、成熟期三个时期。在产品初期，我们应该重点建设基础账号体系。到了电商产品的成长期，我们就可以先引入免费会员，进行会员忠诚度运营。而当电商产品进入成熟期后，我们就可以同时引入付费会员和免费会员体系，大力建设与完善会员产品，培养高端用户。

总结一下本文内容，主要有三部分的内容：分别是账号产品、用户画像、会员产品。

1）会员产品：这部分主要讲解了注册登录的流程，包括第三方登录流程。梳理了找回密码的流程，并探讨了账号安全相关的策略。

2）用户画像：这部分我们了解了用户画像的具体形式，包括用户画像的数据来源和应用方向，并对不同标签产出流程和逻辑有比较清晰的认识。

3）会员产品：会员产品主要分为付费会员和免费会员。付费会员优先考虑定价规则、权益匹配和全链路的展示；免费会员主要设计会员等级的增长和下降，会员积分的获取和消耗，以及会员任务的设计流程。

在电商系统中，会员产品是提升用户活跃、增强用户粘性、提升用户忠诚度，进而提升用户复购的关键产品，所以学习如何建设用户产品对于电商产品经理来说非常重要。

以上就是电商用户模块所有的内容了，部分内容只是简单介绍，有兴趣的小伙伴可以深入了解。下一期，我将分享电商的重要的产品——购物车相关的知识，尽请期待。

欢迎关注本人公众号：书丰产品记

注明，本文内容来自王伟与刘志远老师的产品课程《电商产品经理精进计划》，我在学习相关课程后加上自己的理解后，总结输出，巩固自己所学。本文只是部分课程内容，更多详细内容请搜索课程参加。

敏捷产品管理之发布、迭代计划_Yanelnan的博客-CSDN博客

Tue, 20 Jul 2021 09:58:43 CST

上篇我带你从理解产品 Backlog 最好的形式 Story 开始，经过建模、搜集、编写、估算这四个步骤，编写出有效并且粒度合适的 Story 来帮助团队成员在理解需求上达成一致。让“一张卡片”发挥出它的洪荒之力，快速挖掘需求，理解需求。本篇我会带着你用编写好的 Story 来制定发布计划、迭代计划，并且在过程中进行有效测试和监控。

发布计划

当 Scrum 团队按照 Sprint 的方式进行迭代交付的时候，他们更加关注的是发布，而不是项目。那么什么是一个发布呢？简单的说，它就是一个开发团队交付一个可以工作的软件给团队外部的人使用，以满足他们的某个目的。当你交付一些内容给下游的QA验证团队来做测试时不是一个发布，当你把你的软件功能和其他团队开发的功能进行集成的时候不是一个发布。当你告诉其他人：“来吧，你现在可以使用它了”，这叫做一个发布。一个发布是多个Sprint 集中交付工作的一个成果，这常常是对市场、业务和客户产生影响的标志性的时刻。
那制定发布计划的步骤有哪些呢？我来带着你一步步实践

确定优先级
大部分软件项目以每 2 到 6 个月作为一个发布周期，一般以产品开发线路图开始规划发布。它可以是未来几个发布要关注的重点，可以是之前我在产品 Backlog 里讲到的“主题”，也可以是必须包含的功能，那如何排列出优先级呢？
这里推荐莫斯科规则（ MoSCoW ) 排列优先级的方法：
必须有（Must ) ：指系统的基本功能
应该有 ( Should ) ：很重要但短期内有替代解决方法的功能
可以有 ( Could ) ：如果没有时间可以不予考虑
这次不会有 ( Won’t have this time ) ：客户期望拥有但同时承认需要在后续发布中实现

这里需要考虑面对高风险故事和有价值的故事如何权衡。我之前讲过风险驱动开发可以让我们尽早的消除风险带来的不确定性，但是敏捷宣扬先做最有价值的部分，这样可以使项目尽早发布，提供最有价值的功能，所以在高风险和有价值之间，优先选择价值最高的需求并且充分考虑到它的风险因素。

选择 Sprint 长度
确定完优先级之后，团队所有成员需要一起选择一个适合的 Sprint 长度，一般建议1～4周，一旦固定了 Sprint 长度，就避免在项目实施期间随意更改。
从 Story 到工期
这里要说一个概念 — 团队速率，指团队一个 Sprint 能完成的工作量。前1～2次 Sprint 先进行观察，粗略计算出不受干扰的环境下团队平均能完成的 Story 数量。如 PO 已经排好所有 Story 的优先级，并且累计卡片数量是 100个。如果经过几次 Sprint 观察，团队速率是25，那计划经过4轮 Sprint 可以发布。这里需要注意三点：

速率不是人天，是经过估算的 Story 规模（上篇估算 Story 有具体讲解），比如一个 Story 估算了 1 个故事点，实际花了 2 天完成，本次 Sprint 预估完成 3 个这样的故事点，那团队速率是 3 ，而不是 6 。
速率是团队内部衡量工作量的标准，不与其他团队做比较，因为每个团队对于估点的单位、规模是不一致的。
速率是实际完成的 Story ，不是列在 Sprint 计划里未完成或者完成一半的点数。比如本次 Sprint 预计完成 3 个故事点，实际前两个故事点全部完成，最后一个故事点只完成了一半，那团队实际速率是 2.5 ，而不是 3 。

创立发布计划
最后一步将 Story 按照优先级分别分配到每个 Sprint 中，这里建议将发布计划钉在墙上。这样可视化的方式让团队成员每天能看见。
注意，不要迷信发布计划！如果在 Sprint 的过程中获得任何新的信息，应该不断调整期望和计划。

迭代计划

迭代计划是发布计划的进一步计划，但只在 Sprint 开始是才开始做迭代计划。Sprint 是以功能为纬度，而发布计划是以时间为纬度。这里要引入一个敏捷里的重要实践 - Spint 会议，即整个团队通过举行 Spint 会议来为下一轮 Sprint 做计划，会议的内容包括：

讨论故事
会议的输入是已经排好优先级的 Story 集合，团队成员可以根据自己的想法对优先级进行讨论。流程是 PO 根据优先级顺序将 Story 依次将给开发人员，开发人员可以进行提问，直到全员统一理解，并且可以从中分解出任务为止。
从 Story 分解任务
很多人会问我，为什么要做任务分解，把 Story 继续细分成更小的故事不就好了么？在我看来，分解任务其实是敏捷即时设计（just in time design)中的一次短脉冲,它取代了 Waterfall 模式前期的设计阶段。它不是用户价值的功能描述，是作为开发人员的待办事项。这里需要注意一点，任务卡片的模式可以不参照 Story 卡片的格式，只要能表示出完成 Story 的最快途径就好。
开发人员承担每个任务的职责
开发人员可以在分解任务之后对任务进行认领，理想的任务卡片标准是一个任务卡片对应一个责任人一个人天，责任人最好是写在卡片旁边，即使是结对编程，每个卡片也需要有一个责任人。
讨论过所有故事，开发人员单独估计承诺他们的任务
每个开发人员对认领的任务进行估算，如果 Sprint 时间内估算超过了开发人员所能承担的工作量，有以下几种选择：请求团队成员接受一些任务；与 PO 讨论，放弃其中一个 Story （或者是分解后的一部分）

小结

本篇我们将项目分成一系列 Sprint 来做发布计划，每轮 Sprint 中安排一定的 Story 和任务。一轮迭代完成的故事点就是团队的速率。下篇我带着大家详细了解怎么根据不同速率的可视化管理工具，测量并监控速率。

工信部发布网络产品安全漏洞管理规定

Tue, 13 Jul 2021 19:25:37 CST

工信部发布了《网络产品安全漏洞管理规定》，从 9 月 1 日起开始实施。《规定》旨在规范网络产品安全漏洞发现、报告、修补和发布等行为。《规定》第四条：任何组织或者个人不得利用网络产品安全漏洞从事危害网络安全的活动，不得非法收集、出售、发布网络产品安全漏洞信息；明知他人利用网络产品安全漏洞从事危害网络安全的活动的，不得为其提供技术支持、广告推广、支付结算等帮助。第五条：网络产品提供者、网络运营者和网络产品安全漏洞收集平台应当建立健全网络产品安全漏洞信息接收渠道并保持畅通，留存网络产品安全漏洞信息接收日志不少于 6 个月。第七条：工业和信息化部网络安全威胁和漏洞信息共享平台同步向国家网络与信息安全信息通报中心、国家计算机网络应急技术处理协调中心通报相关漏洞信息。鼓励网络产品提供者建立所提供网络产品安全漏洞奖励机制，对发现并通报所提供网络产品安全漏洞的组织或者个人给予奖励。第十条：任何组织或者个人设立的网络产品安全漏洞收集平台，应当向工业和信息化部备案。工业和信息化部及时向公安部、国家互联网信息办公室通报相关漏洞收集平台，并对通过备案的漏洞收集平台予以公布。

作为最广泛支持的操作系统，HarmonyOS目前用在哪些产品了？

Thu, 03 Jun 2021 03:38:12 CST

6月2日晚，华为在线上举办 HarmonyOS 2 及华为全场景新品发布会，从发布会我们获知，原本只用于智慧屏、可穿戴设备等产品的HarmonyOS系统已经可以在更多产品品类上使用。

华为消费者业务CEO余承东表示，过去10年是转型的10年，华为引领了手机的多项创新，比如摄像、通信、解决安卓卡顿，续航、快充、新材料新工艺、折叠屏等；未来十年华为消费者业务的战略是 全场景1+8+N智慧生活解决方案，重点围绕智能家居、智慧办公、智慧出行、运动健康、影音娱乐5大生活场景来构筑体验。而 HarmonyOS 2的推出，支持多设备多硬件，解决PC、手机、平板、手表等系统之间的体验割裂问题，同时还将支持大量的 IoT设备。

华为消费者业务软件部总裁王成录表示， HarmonyOS 2推出后，无论设备大小，只需一个系统。除了HarmonyOS 2，没有其它系统能够做到这点。据介绍，鸿蒙操作系统是一个全栈解耦的架构，一套代码可以在手机上使用，也可以在手表上使用，以及很多小设备上使用。依靠其统一控制中心，多设备之间可以组成超级终端，从而选择最适合的设备。

HarmonyOS 2采用了分布式技术，通过软总线将独立设备连接起来。用户可以根据需要自由组合硬件，比如手机连接无人机摄像头和运动相机，进行多机位拍摄；PC、平板和手机连接一起，协同办公；手机与冰箱的连接，智能推荐不同食材的温度。值得一提的是，对开发者而言，HarmonyOS可以实现一次开发、多端部署，让多设备应用开发更加简单。

HarmonyOS的真实实力如何，我们只能通过在众多搭载HarmonyOS的硬件中去体验才能得知。本次发布会上，华为消费者业务COO何刚介绍了多款搭载HarmonyOS 2的新产品，包括HUAWEI Mate 40系列新版本、Mate X2新版本、HUAWEI WATCH 3系列、HUAWEI MatePad Pro等手机、智能手表、平板产品。同时带来了新一代半开放主动降噪无线蓝牙耳机HUAWEI FreeBuds 4和两款高端显示器HUAWEI MateView和MateView GT。

点击查看原文>

入职新公司，如何写一份优秀的产品体验报告

Mon, 10 May 2021 07:19:20 CST

笔者最近开始带新人啦，我司新人入职的第一份作业是输出产品体验报告，以快速熟悉产品，增强产品感。总结几位新人写的报告，笔者梳理了一份产品体验报告模板，希望可以帮助到即将从事新产品的你。下面将从产品概况、功能体验、竞品分析、业务拓展思考四个方面介绍体验报告。

01产品概况

了解一个新产品，首先从底层逻辑出发，总结出产品定位、目标客群、业务模式。因为知道产品提供什么服务，目标客群是谁，了解产品的赚钱模式，才能更加深入地理解产品。下面详细介绍这三要素：

产品定位：

句式一般是为哪些用户，解决什么问题，提供什么服务。以360借条为例，360借条的产品定位是：为缺钱的用户提供现金贷服务，以满足用户小额资金周转需求。

目标客群：

1）客群属性：一般包括性别、年龄、地域、职业、收入等，大致可描绘出用户画像。

2）客群分类：可以按照用户身份、用户能力分类。用户身份分类例如学生、上班族、创业者；用户能力分类例如普通用户、优质用户

业务模式：

描述用户、平台、第三方之间的服务关系和资金流转。以美团医美为例，下图是美团医美的业务模式，描绘了消费者、美团生活费、美团医美、医院商户之间的关系。

02功能体验

产品概况了解清楚后，接下来开始体验功能了。你可以先列出产品的功能架构，然后体验核心功能和特色功能。体验具体功能的思路是先整体了解流程，然后再慢慢体验界面、交互等细节，最后从业务视角思考功能背后的意义。

不仅要体验，咱们最后还需要提出优化建议，产品经理总是要提出点想法提升业务嘛。

下图展示的就是体验功能四要素：流程、界面、交互、业务视角。我们可以对着四要素体验原则和方法，总结产品哪里做的好，哪里还有优化空间。

四要素详细介绍：

流程：看流程是否符合用户习惯和认知，即好不好理解；流程是否还可以继续简化

界面：

1）界面结构：看界面是否简洁、结构是否清晰、重点是否突出；

2）界面元素：看组件是否合适，文案是否简洁易懂，图片是否生动，配色是否符合客群；

3）界面内容：推荐的产品或信息是否符合用户需求

交互：操作前是否符合预期，操作中是否有反馈，操作后是否可撤销，界面转场是否过渡自然。

业务视角：

1）匹配效率：人、货、场的匹配度是否准确，即某个客群，在特定场景，平台提供的货品是否满足用户的需求

2）价值感知：界面的价值感知如何？价值感知不够的话，可以充分利用效果图、商品数据来放大商品价值

3）决策成本：决策成本如何？如果要降低决策成本，可通过品牌、用户评价增加用户信任。另外，还可以利用认知偏误来提高临门一脚（即将支付）的转化，例如从众心理、损失厌恶、锚定效应等

4）流程效率：流程效率是否还有优化空间？可参考以下方法提高效率：删除不必要的步骤；减少输入、点击、页面跳转；门槛高的步骤后置；减少用户等待；降低失败率；低意愿用户激励

5）流量利用率：流量利用有达到最大化吗？可参考以下两个方法提高利用率

提高首屏利用率：重点业务前置，优先投放千次曝光收益更高的业务

用户下一步的行为引导：完成一个任务后，充分利用用户注意力，引导下一个任务

03竞品分析

上边从整体分析了产品概况，从局部分析了功能细节，整个产品了解得差不多了。此时需要向往外看，正所谓知己知彼，百战不殆。我们需要摸清行业头部竞品有哪些，我们跟竞品对比有哪些优缺点，找到未来增长的一点思路。

常用竞品分析维度有对比客群、业务模式、功能架构、产品要素及流程。

对比客群：竞品用户量级有多大，目标客群特征是什么，我们未来是否也服务这类客群

业务模式：业务模式不再赘述。可对比业务模式的差异，学习借鉴优秀的模式

功能架构：分析核心功能和特色功能，思考功能背后的业务意义

产品要素：产品要素是所提供服务的具体参数，比如借贷产品的额度、定价、期数、还款方式、计息方式等

功能流程：这个很好理解，比如可对比借贷产品的进件、借款、还款流程，学习借鉴优秀的流程

04业务拓展思考

向内分析了自家产品，向外总结了竞品业务，接下来可以根据公司业务存在的问题，结合竞品业务走向，思考公司未来业务发展。

业务拓展横向可扩大客群，挖掘存量优质用户，新增获取新用户；纵向可延伸用户场景，满足更多需求，最终提升交易额。

下面以360借条为例，看这家小贷公司如何根据客群以及场景，拓展自己的交易业务。

分客群：360借条拆分了优质客群、一般客户、次级客群，优质客群例如企业主、车主，因为客群较优质所以可授信更高额度，为企业带来更多交易额；一般客户是产品内最主要的客群，资质一般，平均授信额度范围可能是几千。额度虽不高，但量级最大，是交易额的主要来源；次级客群是资质最差的客群，可导流至第三方或次贷赚取利润。

分场景：用户借钱的目的有很多，一般是消费或个体经营。消费场景中，线上购物可提供购物分期；线下购物或线上第三方平台支付时，可提供虚拟信用卡，满足用户超前消费需求，提高交易额。

以上就是体验报告的全部内容，希望可以帮助到你。

什么是平台型产品的核心竞争力 - 简书

Wed, 17 Feb 2021 19:35:38 CST

不是所有被称作平台的产品都是平台型产品，我们平常说的广义的平台，既包括像Windows和IOS这样的技术平台，也包括滴滴、京东、美团这样的商业平台，我们今天说平台的特指连接供给方和需求方两个群体，帮助双方直接或间接达成交易等性质的对接的平台，也就是说要同时满足连接两个群体和促成两个群体的交易两个条件。像Intel这种很多开发者基于它们开发产品或服务的技术平台，有交易但是没有属性明显的两个用户群体，像京东商城的自营部分和非自营部分就同时满足两个条件，区别是自营部分是京东自行整合各种商品提供给消费者，通过中间环节对质量等方便的把控间接促成交易，非自营部分则是直接促成交易。

大家都知道网络效应是平台构建生态的利器，当一个潜在用户因为有更多同类用户存在而觉得平台更有价值时，我们称该平台具备直接网络效应，如社交网络；当一个潜在用户因为有更多的另外一种群体存在而觉得平台更有价值时，我们称该平台具有间接网络效应，如电商平台。有的平台同时具备两类网络效应，如微信作为一个社交平台连接近十亿微信用户，形成直接网络效应，在海量用户的基础上微信开放了平台连接用户与服务，自媒体与读者，形成间接网络效应。淘宝作为一个电商平台，在已经建立了强大的间接网络效应的同时，也在试图建立买家之间和卖家之间的关系链，在直接网络效应上发力。

对于这种连接供给方和需求方两类用户群体促成交易的平台型产品，核心作用是促成两方的交易，照这个思路来看，那平台的核心竞争力是不是交易量呢？是不是交易量越大、交易品类越广、交易用户越多平台的核心竞争力就越强呢？是但又不全是，交易量大且全代表平台有了成熟的业务体系，但核心竞争力有个本质的特征就是要有壁垒，否则很可能是虚假的繁荣，很快被人弯道超车，壁垒指的是不光有别人难以企及的交易量，而且要别人对平台有依赖，转移到别的平台上沉默成本很高。这也说明了两端用户的量是基础，这些用户甚至都是公共资源，你可以用别人也可以用，构不成核心竞争力，在交易环节上创造价值才能形成核心竞争力。

这就很容易理解为什么如果只做一个纯撮合平台是没有前途的，因为这种模式平台本身不能直接满足双方的需求，如果在交易的过程中或结果上不创造价值，天然面临被绕开的风险。所以平台除了创造交易机会，还需要做一些其它的事情来提升平台价值巩固平台模式，如把控交易质量、提高交易效率、降低交易门槛等。当然这也跟产品属性相关，C端产品更多的提高交易效率和降低交易门槛和费用，B端产品更多的是把控交易质量。

比如C端产品-淘宝，淘宝不仅仅是作为一个电商流量分发平台和销售渠道聚集了大量的供给方和需求方用户群体，更重要的是它在交易环节做了很多事情使得交易变得更容易、体验更好，如支付工具支付宝、卖家买家的沟通工具阿里旺旺、卖家服务培训阿里大学、卖家营销工具、物流全程追踪菜鸟裹裹等等，在用户进入后的每一个环节，淘宝都为交易的达成做了增值，以及这些工具使用的过程中沉淀的大量数据，反过来为两个用户群体提供决策依据，这都构成了淘宝的核心竞争力。

比如B端产品-外包大师，外包大师是基于全球最大的产品经理社区PMCAFF的互联网产品众包平台，基于社区35万产品经理作为供给方为需要互联网产品设计、研发的需求方提供服务，海量的供给方用户是资源优势，那么把这些人呈现在产品上直接展示给需求方就能提供吸引需求方过来吗？就能产生高质量的交付吗？很明显不是，产品经理是公共资源，哪个平台都可以用，今日头条一下就可以买知乎的300大V过去排他性的生产内容。B端和C端的区别是行业属性强、业务属性强、专业度高，平台的价值更多是为交付提供保障，外包大师的优势和价值在于对供给方和需求方的筛选、需求的严格把控、优质人才的调用、服务方案的输出、清晰的流程、规范的标准、高质量的交付物，用创意管理和工程管理为双方创造更高的价值。

根据网络效应的实现规则，供给方和需求方需要产生直接的互动和吸引才有价值的感知，照着这个思路，需求方应该能直接拿到供给方的信息，供给方能直接拿到需求方的需求，但实际上在专业度较高的领域，两方任何一方的不专业都可能会导致不好的结果，需要有个专业的中间方来做管理，但如果供需双方的信息不公开出来，由后台去匹配相应的结果然后促成交易，网络效应又被人为的截断了，一端积累的优势对另一端就变的不透明，难以形成双方相互吸引的效应。这些都极其考验一个平台对资源和信息的组织和管理能力，而这些才是一个平台型产品的核心竞争力。

降价狂魔特斯拉，正被国产品牌“围殴”

Sat, 02 Jan 2021 15:24:00 CST

来源：深燃

作者：周继凤

牛牛敲黑板：

在这场残酷的竞争中存活下来的，除了实打实卖给私人消费者的造车新势力外，就是真正面向C端用户的自主品牌车型，比如宏光MINI、欧拉R1、奇瑞eQ、比亚迪汉等。

新年伊始，新造车一哥特斯拉就送来了一份大礼——又降价了。

据其中国官网消息，Model Y 2020年1月1日正式上市销售，长续航版和Performance高性能版起售价分别为33.99万元、36.99万元，相较此前的非国产版本大幅降价约14.81万元、16.51万元。

一口气降了这么多，不难看出特斯拉想要通过Model Y抢占市场的决心。这一点确实如此，因为相比于轿车而言，SUV车型更受中国、美国等地消费者的欢迎。

而在另一方面，特斯拉也确实是急了。毕竟它在中国市场，被一个国产自主品牌旗下的电动车吊打了。

没错，说的就是五菱宏光MINI。

这款微型电动车可以说是现象级爆款车型，上市4个月时间，卖出将近8万台，连续三个月力压特斯拉Model 3，稳坐国内新能源汽车销量第一的宝座。

《华尔街日报》在其官方Facebook上发文称：「五菱推出的微型电动汽车宏光MINI ，已经超越特斯拉的Model 3，成为中国最畅销的电动汽车。」

不止五菱宏光，2020年10月份，比亚迪的新能源汽车整体销量也超越特斯拉，一举成为新能源车销量排名前二的车企。

不得不说，在2020年的新能源汽车市场上，宏光MINI们是拉动销量的大功臣。

2019年，新能源车市迎来史上补贴降幅最大的一年，这一年中国新能源汽车销量共计120.6万辆，同比下降3.5%，近十年来首次出现负增长。2020年上半年叠加疫情冲击，新能源乘用车销量仅31.3万辆、同比下滑44%。

至2020年下半年，新能源车市场才结束了「十二连降」（即月销量连续12个月同比下滑）。而背后的原因，正是五菱宏光MINI、比亚迪汉等车型的上市和火热，拉动着整个市场的销量。

一直以来，大家既有的品牌认知是，外国豪华品牌>合资品牌>国产品牌。那么这半年里发生了什么，让国产自主品牌又「支愣」起来了？

谁在挑战特斯拉

我们都知道马斯克发起力来有多狠，疫情期间为了不耽误交付进度愣是强行让工厂开工，2020年2月份以来，特斯拉就一直以一辆Model 3稳坐全国新能源乘用车销量榜榜首。

但谁也想到，这个市场上会出现黑马，而且不止一匹。

2020年7月底，上海通用五菱的宏光MINI刚上市20天，销量就超过了1.5万辆。2020年9月份乘联会公布的零售销量排名快报中，宏光MINI直接打败特斯拉Model 3，以月销14495辆车的成绩雄踞榜首。

更狠的还在后面，此后两个月的时间，宏光MINI的销量不仅没有掉下去，反而节节攀升，一直稳坐销冠宝座。11月份，宏光MINI销量达到33094辆，单日最高销量超过2000辆，成为2020年国内新能源市场上，唯一单月销量超过3万辆的车型。短短4个月的时间，宏光已经卖出去将近8万台。

除了宏光MINI，伴随着2020年下半年国内车市加快复苏，国产自主品牌旗下的几款车型也火爆了起来，成绩亮眼。

长城欧拉R1（欧拉黑猫）11月份单月销量9463辆，排名第三，同比增长415%。除了2月份受到疫情影响外，3-11月的销量一直在稳步增长，这也是欧拉黑猫2020年来最好的成绩。

比亚迪汉上市以来就是国内高端新能源汽车市场的「爆款」车型，销量节节攀升，7月份上市首月，汉的销量为1205辆，8、9、10月份销量分别为4000辆、5612辆、7545辆，月平均增速超过30%。尤其是汉EV，11月销量突破万辆，达10105辆，位列排行榜第四。

而在宏光MINI出现以前，2020年的1-8月，销量领军的车型都来自特斯拉，而紧随其后的第二三名，销量往往不及特斯拉月销量的一半。比如7月份，特斯拉的Model 3以远超第二名埃安（Aion S）三倍有余的成绩稳坐销量宝座。

但到了下半年，国产自主品牌突然开始大爆发。根据各家发布的数据，10月份，上汽通用五菱凭借着宏光MINI这张王牌、比亚迪凭借比亚迪汉 EV等，一举成为新能源车销量排名第一、第二的车企。

必须抢「人」了

别看最近一段时间蔚来、理想、小鹏等造车新势力股价飞涨，销量节节攀升，但事实上，2020年对于新能源市场来说，是艰难的一年。拿到这个「进步奖」，对于自主品牌而言，并非易事。

首先是政策的变化。要知道，2018年之前，因为新能源汽车补贴力度过大，甚至出现了「5家车企骗补10亿元」的奇闻。到了2019年7月，新能源补贴全面退坡，销量也跟着断崖式下滑，下半年销量同比下滑28%，全年销量102.5万、仅微增3.2%。

转过年的2020年上半年，疫情让新能源汽车市场的整体形势更加复杂，乘用车销量再次下跌，半年仅卖出31.3万辆、同比下滑44%。整个新能源市场出现了「十二连降」（即月销量连续12个月同比下滑），直到2020年7月份，市场才逐渐回暖。

政策和疫情的双重压力，让行业竞争加剧，销量暴跌成为不少车企的关键词。 对于自主品牌来说更是雪上加霜，因为过去倚赖的企业端需求正在减少。

如今的新能源车市场，主要有三大派，一是合资品牌；二是造车新势力，也就是用互联网模式造车的企业，特斯拉、蔚来、理想都是这一派；三是国内造车界的主力军——传统车企的自主品牌。

传统自主品牌做新能源汽车，早在十年前就开始了，某传统车企前高管李铭向深燃解释道，最早做新能源的势力是传统车企，从我国2009年推进「十城千辆」试点就开始了。而且在他看来，「前几年做得好的，就是传统车企，比如北汽、奇瑞、江淮等」。

做得既早又好，为什么普通大众说不出几个自主品牌旗下的新能源车型？因为这些车型，一开始就没打算卖给普通大众。

起初，传统车企做新能源车大多面向B端的网约车出行市场，真正让消费者买单的没有几款。「不少厂商左手倒右手，销量的水分较大。」李铭告诉深燃。

有数据作为佐证，根据保监会交强险2019年的数据，个人、单位和租赁的车辆所有权占比分别为52.6%、18.5%、28.9%。其中的个人部分，还包括自己买下来用于出租车营运的情况，也就是说，真正用于私人消费的占比不足五成。

2019年，小鹏汽车董事长何小鹏甚至在社交媒体公开表示，这一年前9个月，在中国实际卖给真实消费者的电动车大概只有十几万辆，和特斯拉在美国前三季度14万的销量「相差无几」。

但2020年疫情突然到来，B端市场的车卖不出去了。北汽新能源的相关负责人就曾对媒体指出，疫情使得出租车、网约车相关企业的运营率只有40%到50%，这也就导致B端市场的购车需求大幅下降。

从2019年、2020年的销量排行榜不难看出，自主品牌们很难再吃老本了。

2019年、2020年（1-11月）TOP10的新能源乘用车车型零售销量对比

数据来源 / 乘联会制图 / 深燃

2019年，榜上有名的车型，如北汽EU系列、比亚迪e5、荣威Ei5、帝豪EV，到了2020年，销量纷纷垮掉。2019年全年销量（11万辆）排名第一的北汽EU系列，在2020年掉出前十。

上述车型，无一例外主要面向B端市场，在2020年普遍销量遇冷，甚至逐渐被市场抛弃。

把车卖到白菜价

如何打开C端用户市场，摆脱对B端企业的依赖，成了不少自主品牌「卡脖子」的关键性问题。而行业内公认的说法也是，「车能不能打，还是要看消费者满不满意」。

爆火的宏光MINI做出了一个好榜样。

2020年10月，宏光MINI蝉联单月新能源车型上险排名冠军，其中个人上险占比达96.5%。这意味着，宏光MINI在没有补贴的情况下，实打实地靠消费者「用脚投票」投成了爆款王，而且抓住了 下沉市场小镇青年的心。数据显示，20-30岁的用户占比为30%，30-40岁的用户占比为47%，60岁以上的用户只占5%。

具体看车型，宏光MINI这款微型电动车，最高时速105km，有120/170km两个续航里程版本，甚至没有安全气囊、无法快充，却被评为「人民的代步车」。

「人民」图啥？

首先从定位上，不难看出门道。

资料来源 / 乘联会

从乘联会2020年1-11月份的销量榜单看，在惨烈的退坡补贴政策中存活下来、快速增长的，有两大类车型，分别是B级纯电动车，以及A00级纯电动车。

翻译过来就是，整体销量除了被特斯拉、比亚迪汉、蔚来等少数高端电动车（也就是B级纯电动车）带动外，另一类功臣是以自主品牌五菱、欧拉、宝骏为代表的A00微型代步小车。

也就是说， 目前消费者对新能源汽车需求两极分化，微型车、中型高端车的受众不断增多。对于一般车企来说， 冲击中高端有难度，需要品牌力支撑，且这个市场一直被特斯拉、蔚来等品牌霸占；而 微型车门槛低，可以从打低价入手。

一个背景是，2017年、2018年这两年，中国电动车销量的增长主要是A00级车的拉动，在纯电动车市场的市占率在一半以上。但这一车型原本成本就高，一旦没了补贴，车企难以盈利，而大部分A00、A0级电动车的价格不低，C端消费者并不买账，于是，微型电动车在2019年一直遇冷。

市场需求存在，「伴随着技术的进步和成本的降低，我们有能力制造出续驶里程在200公里左右、价格在5万元左右的微型电动汽车，以满足市场需求。」国家新能源汽车创新工程项目专家组组长王秉刚曾对媒体指出。加之不少车企为了抢占市场打起了差异化竞争，微型电动车在2020年又火了起来。3月上市的奇瑞新能源小蚂蚁eQ1女王版，补贴后售价为7.88万元，4月上市的长安新能源奔奔E-Star补贴后售价为6.98万元起，都是瞄准微型电动车市场。

」微型电动车一直都有很大的市场，但是需要好的产品。之前奇瑞等品牌推出过类似的很好的微型车产品，但是价格上没有优势。「李铭指出。

宏光也是踩准了这一定位，且做到了对成本端的把控，拿出了足够低的价格。目前宏光MINI共有三款车型，分别是2.88万元的轻松款、3.28万元的自在款和3.88万元的悦享款。

毫无疑问，低价是一把利器，对于真正需要电动车的大多数用户，三四十万的蔚来、二十多万的特斯拉，都是遥不可及的奢侈品。尽管大部分微型电动汽车价格都不高，普遍在10万元以下，有些甚至下探到5万元左右，但宏光突破了5万元这道门槛，压到了两三万的价格，这对于普通大众来说，几乎就是白菜价。

「很少有人像五菱一样，做到如此低的价格，又能满足国家新能源汽车标准。」汽车分析师张翔表示，五菱把做燃油车的供应商体系运用到了新能源汽车上，才能控制造车成本。

不止是低价，某传统车企的研究员周峰告诉深燃，「我们其实挺羡慕五菱对于市场的灵活反馈的，真正切中了用户的需求」。

按照五菱这边的话说，「我们要按市场需求来做导向，而不是按规划去做导向。」上汽通用五菱总经理沈阳曾对媒体表示。

比如，五菱通过市场调研发现，84%的用户每天实际行驶里程在40公里以内，日常出行场景多为通勤、购物、接送孩子等，100公里到150公里的续航就可以覆盖日常代步需求，因此续航就定在这个范围内。

比如，宏光MINI找明星陈赫直播带货；在小红书上的推广文案是，「逛街探店拍照、买菜接娃超方便」。

「它们（宏光）能成功其实不止靠低价，还很会玩营销，我们品牌就没有这种敏感度。」周峰称。之前「地摊经济」如火如荼的时候，五菱也曾借势营销。

卖低价车，不是五菱们的理想

「新能源汽车之前一直不被业界看好。 很多车企的油车业务活得很好，相比转型投入新业务，更愿意维持现状。「周峰坦言，只有一些在油车业务没有建树的车企才愿意换道超车。

但政策摆在了眼前。2020年6月22日，工业和信息化部等部门正式修改了《乘用车企业平均燃料消耗量与新能源汽车积分并行管理办法》（即双积分政策）。所谓「双积分」，是指乘用车企业平均燃料消耗量与新能源汽车积分并行管理办法， 每个汽车厂商都需要生产新能源汽车。

「再加上这两年特斯拉、比亚迪都量产了，国家还是一如既往地扶持新能源汽车，电池等技术也都成熟了，不少车企开始行动起来。」周峰补充道。

而卖低价车，不是五菱的理想。

「宏光MINI两万多的售价，其实对于五菱来说只有微薄的利润。宏光在内的各大厂商布局微型电动车，也主要是为了占领市场。自主品牌正在不断洗牌中。中国的汽车品牌有100多家，大部分车企卖的是10万元左右的经济型轿车。」张翔称，企业要想做大做强，就必须往高端走。

不冲击高端是不行的，不止五菱，各大传统车企都向中高端新能源项目发起了冲锋。

2020年11月1日，上汽通用五菱上市了其旗下五菱凯捷四款车型，定位高端；同年11月份，长安、华为、宁德时代三家联合打造新品牌；12月，上汽、张江与阿里联合打造的智己汽车首度对外发声；最近，东风汽车又推出了岚图FREE，定位中大型SUV；长城汽车也被曝出，计划推出新的智能电动汽车独立品牌，定价高于长城目前已出的所有产品，内部代号为「SL项目」。

在造车这件事上，自主品牌拥有颇多优势。

在周峰看来，「造车新势力其实非常羡慕和尊敬传统车企，从集成到设计到一些生产技术，传统车企非常有优势」。

「但在最核心的用户思维、技术软件能力上，（传统车企）其实是弱势的。」李铭表示，造车新势力大部分借鉴了互联网的玩法，在用户思维和软件能力方面明显更优。

尤其是用户思维方面，自主品牌欠缺颇多。传统购车价值链十分复杂，从用户到销售顾问再到经销商管理层等层层反馈，高层做战略、规划，再到研发、采购、生产，最后反馈到销售层面。这一系列操作下来，决策往往滞后于用户的想法。

对此，周峰也有相同的看法。「很多时候，不是我们做不出来，而是高层不让做，其实最要命的是自主品牌的管理架构问题，直接影响到企业产品的质量、迭代速度、战略选择等问题，甚至有可能影响企业的生死存亡。」

高端市场更不好打。周峰表示，自主品牌20万以上的油车都很难卖。因为同样的车，用户可能更愿意去买合资品牌的，就目前而言，比亚迪在新能源品牌上的布局可圈可点，做到了产业闭环。「有品牌基础，有核心技术，用户池子养得很好。所以汉这个高端品牌一出来，很多用户愿意买单。」

而其他自主品牌的车企还需要时间证明自己。「传统汽车市场压力越来越大，几乎所有车企都在搞品牌向上，推出高端品牌。但是最终成功的不会太多，有3-4家成功的就不错了。」李铭表示。

编辑/lydia

盘点Facebook 、YouTube等主流产品的10大创新设计

Wed, 23 Dec 2020 18:47:25 CST

编辑导读：每个设计师都会有创意灵感缺失、大脑一片空白的状态，这个时候去看看最新的一些设计趋势会是一个寻找灵感的好方法。本文作者梳理盘点了国外主流产品的10大创新设计，希望能帮助解决你设计时遇到的灵感枯竭。

国内的产品设计同质化严重，将众多同类产品放在一起，去除图标和主题色的话，很难区分是哪个App。

设计师的视野如果长期只关注国内，那么设计创新能力很容易被束缚，导致创新能力下降。

应对突发需求，国内没有相对应的竞品，就无法做出可落地的方案。

本篇文章盘点下国外主流产品的10大创新设计，通过本篇文章，希望可以打开视野，提升创新能力。

01 左滑进入聊天界面

Instagram在首页界面，用户左滑进入消息聊天页。这是一种全新的交互形式。

国内的产品，左右滑是切换首页的二级导航。

我第一次使用时不习惯，很容易误操作。当习惯之后，就觉得超级方便。它可以快速地切换到聊天消息页。

为什么Instagram要做这个交互？猜测原因有以下2点：

Instagram发力即时通讯，鼓励用户相互发消息。底部已经有了5个tab，没办法继续增tab。这时候只能想办法找其他流量大的入口。
流量最大的入口毫无疑问是首页。所以Instagram在首页新增手势操作，当用户左滑，就能快速地到达消息聊天页。此方案可以完美的满足业务需求。

02 视频小窗口播放

在YouTube视频详情页，没有视频关闭功能。用户不想看视频时，只能点击播放器左上方的收起箭头。

当用户点击之后，会变成卡片小窗口，进行小窗口播放。如下图所示：

这样设计的好处：

可以让用户边找视频，边观看。尽可能地利用用户时间。
使用户消费更多视频，提升用户的观看效率。

03 推荐视频

YouTube在播放过程中，底部会出现四个视频，用户上滑时全部出现。

用户可以在播放过程中，点击推荐视频观看。

这种设计更加强化推荐视频功能。用户可以在播放过程中，选择更感兴趣的视频。

国内视频产品，在全屏的情况下，无法推荐视频，只能在视频结束后推荐视频。国内这样的好处是可以更聚焦当前视频。

04 筛选订阅视频观看

在订阅内容Tab，用户可以根据标签，进行筛选视频，这种操作可以极大的提升用户查找视频的效率。

像继续观看、未观看内容，这些标签，可以高效，不遗漏地观看订阅up主的视频。

05 提升push打开率

当订阅up主后，push推送没有打开时，会出现消息未打开的图标，用户点击，进入设置页面，进行打开通知设置。

这种设计的好处是：推送设置入口固定展示，用户打开push的概率大大增加。

而push打开率的提升，对提升产品的日活帮助巨大。

06 导航和设置展示在一起

Google Chrome 首页，将用户最常访问的网站和功能项放在一起，如下图所示：

一般来说，国内产品很少将两个不同属性的模块放在一起，这样的话容易被误解为一种类型。

但是为了让用户使用更加方便。Google Chrome将其放在一起，都采用宫格导航的形式，通过图标和背板的不同做了一定程度的区分，用户的体验更加友好。

07 下拉操作

Google Chrome下拉时，展示三个选项，左右滑动选择对应的操作。

这种交互方式，即做到了界面简洁，也做到高效方便使用。

08 为其他app引流

Facebook作为一个超级App，所涉及到的业务庞杂，公司内部各个部门利益复杂。为了业务利益，不同部门组织在不断地博弈。

如下图所示，为了尽可能的给其他业务引流，Facebook底部有6个tab，这在主流产品中是不可思议的存在。

为了给messenger引流，首页右上角增加了一个闪电消息图标，会和messenger App联动，当有新消息时，会出现消息提示。点击跳转到messenger。早期facebook 是将底部一个tab给messenger引流，点击tab，直接跳转到messengerApp。

Facebook的这种导流设计，粗暴高效，短期内使得messenger也成为一个超级app。

09 删除中倒计时

Telegram在删除联系人时，底部会出现倒计时提示，在这个期间，用户可以撤回删除操作。

这种交互设计，使得用户在删除过程中更加有安全感，可以回撤毁灭性操作。

10 一次发多条动态

Twitter在发布动态的时候，可以一次性发送多条，这种设计，可以一次性批量的发送，提升用户效率。

以上就是我发现外国主流产品的创新设计。而这些设计，国内基本没人采用，所以分享出来给大家。

如果大家有其他的发现，欢迎在评论区留言。

#专栏作家#

UX，人人都是产品经理专栏作家。前美团点评高级交互设计师。微信公众号：Echo的设计笔记，欢迎关注

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

题图来自 Unsplash，基于 CC0 协议

从项目到产品化转型，从产品到运营和SaaS服务构建(201116)

Mon, 16 Nov 2020 08:03:59 CST

今天谈下在进行产品规划的时候，从产品化到运营化方面转型的一些思考。

产品化和运营

对于大部分的软件企业来说，最希望实现的就是产品化，简单来说就是将自己开发的软件变成一种通用型的可以类似光盘快速零成本负责的产品，这种软件产品只需要少量的现场服务或支撑就能够方便客户快速的开始使用，类似微软的操作系统和Office办公软件。

对于企业应用服务市场，各个垂直业务领域往往个性化差异都很大，这也是导致产品化本身有相当大的难度，这对于核心业务价值链相关系统最难，相对来说对于OA，HR等支撑类应用，平台等中间件等相对容易。

类似可以看到的上市公司包括了做中间件的东方通，普元软件，宝蓝德，做工具类软件的福昕软件，这些都是相对来说比较容易实现产品化的软件。

还有就是广联达，这家做建筑软件信息化的公司很早就听说过，原来一直很奇怪为何能够支撑这么高的估值，因为对于这种做企业信息化的公司一般不会给出这么高的溢价。后面才发现这家公司卖一个标准化的工程造价软件，这个软件每年可以收大量的license和维护费用，只要是稍微大点的工程项目估计都用的这套软件。

这就是一个典型的软件产品化后带来的具体价值。

但是实际上也可以看到，真正做到如此产品化的相当少，更多的还是产品软件+实施的模式。这也就导致大部分软件公司其实很难挣钱。

一个软件产品要做到真正的产品化，首先需要底层的业务模型和技术模型更加复杂以满足各种个性化和差异化的扩展需求。在有了这个底层灵活模型后，还需要做到。

业务可配置：能够通过前端界面灵活的进行各种配置，以满足差异化需求。
接口可开放：所有接口开放，方便客户就能快速的进行二次开发定制。

产品，不是技术或能力的输出。技术和能力是属于你的，产品是属于用户的。--刘润

从项目到产品化的转型，核心仍然是构建公司的技术平台+产品平台，基于平台来开发和定制上层的客户差异化功能。做到80%左右的可复用即可。其次就是尽量做到一前一后统一和集中管理，包括了集中化进行方案设计，其次是所有项目集中化运维。

对于产品化的思考，不仅仅需要考虑技术和能力提供，这些技术和能力应该如何进行整合为用户提供有价值的输出，这种输出不应该是单一的，而应该是一个完整的解决方案包。

一个解决方案本身包括了咨询规划+产品+实施，以产品为核心，但是有围绕上下游进行展开，实现整个解决方案本身的可落地性。

对于咨询服务同样也是产品，需要的是对已有咨询经验进行总结和抽象，形成适合客户需求的方法论，知识库和模式库。

你可以观察下埃森哲的IT规划，完善的IT规划方法论，而且观察后发现对于电信运营商行业就形成了一套完整可复制的规范咨询方法，可以快速进行复制。

当前产品化思路不应该是传统固化单一产品的思路。

而应该是形成一个完整地覆盖了咨询规划，产品，实施各个维度的知识库，子产品库，只要这些基础库可复用，那么我们就很容易根据客户需求快速的去复用和集成已有能力。

而上面这个思路可以看到整合也是SOA架构的核心思想。

从产品化到运营

一个完整的产品不一定就可以运营，一个产品是否可以运营，还需要看这个产品本身是否具备足够的独立自治，能够将其能力以通用化的服务提供，如果满足这个产品才具备基本的可运营的能力。

产品要可运营必须对产品进行各种服务化改造，其中最重要的就是增加运营管理类能力，类似基本的产品，服务，订单，计费，运维等基础运营和运维监控能力。其次就是关键的多租户改造，以满足一套产品服务满足诸多企业用户的基本需求。

一个产品如果最终做到可运营，那么这个产品本身已经能够做到产品化和产品可配置化，而且这种产品化的要求往往比单独的私有云部署产品更加严格，由于是单套产品服务部署，因此产品的变更或升级将影响到所有的企业和用户，更加需要考虑产品本身的通用性和可配置化，建设各种个性化需求改造和配置。

当你是按照类似SaaS运营模式来规划产品的时候，那么往往就会放弃一些客户，包括客户的个性化差异需求。即经过可配置也无法解决的个性化差异需求，这些需求本身没有共性，那么你去支撑这些需求就没有意义。

产品化和可运营是大部分软件企业的产品规划和发展方向，但是真正要走到这步仍然很难，一个是本身做一个产品化的产品需要更多的研发投入和改造，另外一个就是企业本身没有大量前期实践积累，连要做一个产品化产品的业务和技术通用模型也无法抽象出来。

产品-运营-生态-模式

对于软件公司简单来说就是实现软件，软件是产品，也可以是服务，可以标准化，也可以根据客户进行定制，因此这就形成了各种产品的形态和推广模式。简单来说包括了：

纯粹的软件人力外包公司
软件项目型公司，按人天报价定制化软件，接客户项目，软件难产品化
产品化的公司，工具产品或重产品+轻实施
软件产品运营类的公司，即我们常说的SaaS软件即服务，将软件真正转变为服务运营
内容运营类的公司，构建一个软件平台，以内容运营为主，类似电商平台

对于第一种和第二种基本是人头的方式，第一种方式更加纯粹，而且没有太大的资源闲置压力，只是从软件公司来说从每个人头上获取差价，要扩大营收和盈利必须不断扩大公司人员规模。这种公司本身最大的风险就是人员流失，由于人员流动极大，因此人员管理和人员的招聘入职是关键，因此这类公司HR岗位就是很关键岗位。

大部分软件企业实际为第二种模式，项目型公司，本质还是堆人，只要是按人天报价，那么公司要大幅盈利就必须规模化发展，但是规模化后最大的风险仍然是人，万一业务缩减人员如何处理就是大问题，软件类公司看似轻资产运作，实际却是重资产，人员如何管，人员空闲如何处理？如何缩编都是大问题。

如果要给软件公司能够做到产品化，或者说60到70%部分能够做到产品化，那么日子相当来说好过，即报价模式变化了可以是产品+定制开发实施一起报价。在产品研发出来后的销售基本就是零成本，因此这种模式解决两个问题。一个是盈利能力增强了，能够分享产品规模化的收益；其次就是人员团队规模可控了，不会类似原来模式在拓展规模的时候要大幅地扩编人员。

那么产品化后公司的问题体现在哪里?

在产品化后你会发现实际上销售成本会上升，其次就是在竞争中产品价格会下降。一个软件产品只要产品化后，就不会让你一直能够卖高价。否则还不如完全找个团队进行定制开发。

第四种就是aaS软件运营类公司，但是我们实际看到最近几年SaaS类软件运营公司发展的并不是特别好，一个SaaS运营类软件需要研发团队，运营团队，销售团队，同时需要购买云数据中心资源，这些都是硬成本。一个软件变成SaaS模式后价格会进一步降低，因此必须用户到一定规模才能够进入到盈亏平衡点。

对于国内两大传统ERP厂商用友和金蝶，可以看到最近几年都在加速软件软件和实施朝云服务的转型，包括了金蝶云苍穹和用友NCCloud和用友数字化服务平台，各个领域云服务平台。从用友公布数据，19年实际云服务营收增长132%，20年也继续保持高速增长状态。

当前用友市值1500亿左右，是少数的几个市值上1000亿的软件企业。如果仅仅是做传统软件项目和实施定制很难支撑这个市值，但是云服务却带给市场足够的想象力。

但是很多SaaS类软件公司可以看到，很难真正跨过这个盈亏平衡点。

就拿在线协同和项目管理类软件来说，这几年好几十家都在做，最终存活到现在的已经不多，竞争很激烈，有些SaaS软件还是免费模式，因此收费价格不可能高，那么你要迈过盈亏平衡点对用户规模基数的要求就更高。

其次我们也可以看到，对于SaaS类软件，单纯地从提高效率角度很难真正大面积和推广，人们很多时候并不愿意在效率上面投资，而更多愿意在类似获利或降低成本上投资。所以你可以看到对于类似crm和商机发布类的SaaS应用软件往往来说运营的很好。

最后就是我们说的内容运营类公司，比较典型的就是电商平台，当然还有很多类似的平台，但是核心仍然是电商。简单来说你可以通过平台卖货，或者卖服务，而这些内容本身是可以不断持续发展的，可以不断的产生和运营新内容，但是软件平台本身并不用大变动。

这类平台解决两个问题，一个是资源，你可以理解为买方资源和卖方资源你都要去考虑，有了资源才能够产生流量，有了流量才可能促成最终的交易，有了交易你作为平台运营方就可以进行分成，这个分成可以带来持续不断的运营获利。

拿简单的美团外卖来说，一开始是商家，消费者，骑手多方补贴，最后形成流量和交易后进行抽成。或者你也可以看到这个时候软件平台在哪里已经不是最重要的，而且一开始的业务规划，商业模式的设计，软件平台只是其中的一个支撑平台。

因此可以看到，真正能够不断的规模化，能够持续盈利的都是运营类软件平台公司。但是这些真正的创业机会点基本被寡头所占据，小的创业团队很难再有机会。你的创业项目可能是一个好项目，但是流量入口不在你这里，你要获取流量就要烧钱，但是及时烧钱你也很难真正形成优质高粘度的流量。

这也是为何19年大家都在谈流量，特别是更多的人在谈私域流量，你微博，头条，公众号有多少粉丝，你访问量和转化率如何？如果是做微商的你直接或间接管理了多少微信群。流量本身即价值，我们原来谈知识变现，实际上本质是流量变现。

作为个人或自媒体运营，一个重点就是运营好你的流量，你可以通过不断优质的内容创造来持续积累你的流量和高粘度粉丝群。这是你变现的一个点，你带货或变现的时候可以说是知识变现，好物推荐，也可以说是间接割粉丝韭菜，都没毛病。

如果你现在做一个软件平台，你就要考虑如何引流的问题，我们原来看到过类似在行，小鹅通知识分享平台等应用，可以看到实际本质是通过大V帮自己引流。

简单来说你一开始不但不能抽成，你还得考虑返现，来完成大V私域流量朝你公域流量的转变。一个现实类似的例子就是大商城招租，你要去招租类似绿茶，海底捞这种商家，你一定是免租的，这些商家的入驻本身就是为你商城带来巨大的流量。私域流量朝你公域流量的转变后，你平台才可能拥有更多的薅羊毛机会。

把这个想明白，我更容易去思考当下的社群和连接，简单来就是进一步的私域流量交互，相互薅羊毛。当然你也更加容易去理解类似瑞幸咖啡的裂变营销，也是让个人的私域流量转化为平台的流量。因此低成本地找到愿意出卖自己私域流量的个体，一定是一种很好的平台引流模式。

互联网运营和SaaS服务

可以先看下百度百科对互联网产品运营的一个说明，即：

互联网产品运营要对用户群体进行有目的的组织和管理，增加用户粘性、用户贡献和用户忠诚度，有针对性地开展用户活动，增加用户积极性和参与度，并配合市场运营需要进行活动方案策划。因为需要能对产品和市场数据进行分析，并以此为依据推进产品改进，并且始终保持敏锐的用户感觉。

而对于互联网运营的大框架，一般的总结会包括五个方面的内容，即：

1:获客 2:认可 3:付费 4:体验 5:传播五个核心阶段

根据每个阶段设置合理连贯的用户路径。而这五几个阶段正好也是一个持续迭代，持续优化改进提升的过程。最终的目的是实现用户消费产品，持续产生价值创造。而对于运营工作指标而言，更加精简的总结就是三拉新、留存、促活。我们经常谈到的的用户数，用户日活数，用户平均停留时长，用户转化率等基本都是围绕着三个指标展开。

在传统的市场营销里面我们会讲到市场和营销两个方面的内容，而市场则主要针对市场活动策略，品牌推广等方面，而销售则主要针对在有潜在的销售机会后具体的销售机会跟踪，一直到最终的项目立项，合同签订过程。而对于互联网产品运营可以看到，对于运营角色更多的是覆盖了市场销售两个方面的能力，同时实现了两者之间的平滑衔接。

比如我们做的关键节假日的市场策划活动，我们微信公众号推广的文章属于市场层面，但是这些最终活动和传播最终会带来新用户的注册，也就是所说的获客，但是获客只是第一步，用户注册并不代表用户马上产生消费行为，因此下一步还得跟踪用户的，留存用户，让用户获得很好的体验，最终促成消费和购买行为。而这也就是我们经常说的运营里面的一个关键指标，即转化率。没有转化率，那么一些用户数，日活数都无法产生真正的价值。

对于互联网产品运营人员，和传统的市场和销售人员最大的区别就是，运营人员往往对最终用户是透明和不可见的，用户并不需要知道有运营人员，运营人员需要的是直接建立用户和产品之间价值纽带，你需要在用户体验，产品易用性，售后服务等多方面下功夫来加强这种价值纽带。最终达到的效果就是用户愿意在你平台上多停留，多买东西，这就是最终的目标。这是和传统企业的市场和销售的一个区别点。

第二个区别点，就是互联网产品更多都是软件即服务模式，通过软件我们更好的实现数据的采集和记录。那么互联网产品运营来说，一个核心就是真正形成基于数据驱动的运营持续迭代。所有的用户登录行为，浏览行为，消费购买行为软件平台都有记录，你都可以进行初步的分析乃至后面的大数据分析。

因此互联网产品运营完全可以说是数据驱动的运营，所有的问题往往会通过数据反映出来，运营要做的就是如果通过数据表现出来的现象看到更加本质的内容，比如我们用户体验如何改进，产品如何改进，服务如何改进，我们的活动策划如何更加细分和有针对性，所有的这些都可以通过数据运营来给出更加合理的改进方案。

对于运营里面的留存和促活，简单来说就要首先要让低频用户变成高频用户，其次就是让高频活跃用户变成实际产生价值消费的用户。低频变高频，简单来说就是要先产生很好的用户浏览体验，产品的易用性要好，产品的个性化推荐要有针对性，这样用户愿意多停留使用。而当低频用户变成高频用户后，你需要的是考虑产品和服务本身的针对性和性价比等，让用户产生实际的消费行为。

类似当前大的互联网产品，下面的一些信息可能也是你会经常收到的。

滴滴如果经常不打车，会收到好久不见，送你一张7折券的推送信息。
电商平台会收到再购买满几单，可以收到多少的优惠券等。
在线教育的，经常有19元10节课还送书的广告推送

所有这些都在解决引流，成单，留存和促活的问题。而这些一个方面是需要有一个强大的大数据分析后台，一个是需要有大量的人工运营和销售人员跟进。

从互联网运营到SaaS产品服务

对于互联网产品，要意识到向用户卖的很多时候已经不是一个产品实体，而是产品提供的服务，一个产品可以为一个用户群体提供服务。

其次，市场营销和销售过程本身存在差异，传统方式是从销售机会产生到形成订单，核心是销售转换和订单形成。而在互联网产品下变化为了先获取用户，然后再促使用户形成订单完成转化过程。同时我们还看到这两个过程本身即可以关联，也可以分解。

即我们说的拉新可以是独立的，留存和促活可以是后续行动。

再次，由于互联网产品提供的是服务，因此这个服务是不断在使用的，而且这个使用过程我们还能够不时的得到用户操作和行动上的反馈，而这些反馈本身又帮我我们进一步优化和改进产品。这也是互联网产品运营更加的强调数据驱动分析来促进产品持续改进和优化。

在做互联网产品的时候，产品是基础，运营才是真正的面向客户贴近市场持续让产品创造价值的手段。运营真正起到了衔接产品和用户之间的关键桥梁，其目的是让产品为用户创造价值，也间接地使互联网产品本身体现了自己该有的价值。

对于运营，我们经常会听到一种方法就是我有多少用户，你和我对接我可以直接导入多少用户给你，这个看起来挺不错，也符合我们前面说的运营的关键第一步拉新上面。但是实际上如果导入的用户本身不活跃，或者说没有最终进行消费和订购，那么仍然没有产生价值。这个也是我们常说的，运营往往最关键的还是在用户活跃度和用户持续的消费和订购产品和服务上面。

如何做到？

简单来说就是我能够根据用户的使用和行为习惯，持续的优化我们的产品和服务，并持续的推送体现产品核心价值的服务能力。让产品具有吸引力是其一，让产品本身促进用户高度粘性是其二。而真正要做到这点就相当不容易，里面涉及到用户行为数据分析，操作数据采集，大数据分析，产品优化改进，定向针对性推荐，产品策划和推广，互联网营销，市场线下活动，市场需求收集和反馈给产品部门等一系列的事情。

只有真正将这些事情从市场需求，到用户，到最终的产品价值提供形成一个完整的闭环，并持续优化，我们的运营才可能真正做好。运营我始终觉得不在于理论，而在于实操，没有任何放之四海而皆准的标准，而在于我们的运营人员是否真正的贴近了用户，并熟悉了产品，只有这样你才能够去考虑产品和用户之间的价值连接如何建立才是最有效的。

传统产品朝运营转型的一些思考

都觉得做项目化软件建设和实施很辛苦，也都觉得做SaaS运营服务是趋势。但是实际上真正朝运营转型却不是容易的事情。

为何说做SaaS运营很困难，个人理解主要包括以下几点：

其一就是你想做的SaaS运营服务，可以说大部分都被别人做了，你要后来居上进入，那么就必须有明确的产品核心竞争力或者确定的市场。比如你已经明确签订了一个大市场范围的合作，或者说你规划运营的产品有一个核心技术价值很大。

其二是软件公司或团队本身的持续运作问题，一个软件公司最重要的仍然是有稳定的现金流，能够活下去，但是大部分运营项目至少都是1到3年的长时间亏损，那么是否有这么多钱投入。很大做互联网运营类企业最后由于后续融资不顺现金流断掉而倒闭得太多。

其三就是传统技术公司转运营的时候，思维没有转，仍然是技术驱动。你会发现真正的SaaS运营很重要的还是运营模式，市场策划，引流方法，宣传推广方式等。你产品再好，没有用户和流量，那么所有努力都是白费。

其四就是你本身运营的产品或服务的技术壁垒，实际上对于大部分企业仍然很难有这个壁垒。对于很多创业或做SaaS运营的，经常会面临一个问题就是你做的东西很好，如果被BAT盯上了介入，你如何应对？BAT有钱有流量，如果看上一个好方向你基本没有化解的方法，最好的归途反而是自己被BAT收购。

对于我们主要做SOA，微服务和云原生解决方案，实际上可以看到这个本身朝运营转型有难度。那么是否有朝运营转的一些思路，自己初步思考如下：

构建一个可运营的能力中台

这个我在前面强调过，即我们做一个能力聚合平台，将各类接口服务能力聚合起来形成一个统一的能力对外暴露。API接口服务本身即商品，可以进行运营，可以按调用的次数或周期进行收费，如果是类似商品订购类接口服务还可以按实际的流量进行提成。

这种能力聚合后形成的服务能力开放平台本身价值就在于平台本身做寻找下游可用能力并接入的事情，同时做了大量的API接口服务的适配和标准化，方便第三方的消费方能够快速的消费和使用这些能力，避免和多家下游供应商对接的工作量和麻烦。

构建一个面向公有云的DevOps支撑平台

我们完全可以将我们的DevOps平台在完善后部署到公有云环境，形成一个面向所有企业团队，第三方开发者的PaaS服务能力平台。而我们平台本身又或部署在类似阿里云，腾讯云等公有云IaaS环境下。

实际上我们看到对于以上公有云本身也提供了类似DevOps的支撑工具和环境，那么我们再做这个的价值在哪里？你可以理解为整个平台是衔接企业内部私有云和公有云的一个关键衔接和适配平台，帮助企业构建一个完整的基于云原生的混合云架构。其次就是对接和适配到阿里，华为，腾讯多个云，可以实现这些公有云间的快速迁移和切换。

从toB的福利平台来构建社交电商

对于公司的SaaS运营的福利平台，我前面专门写博客文章介绍过，但是更多的是toB的一个SaaS平台，当然先入驻企业，企业是独立的租户，然后是企业员工使用，也可以理解为一个B2B2C的一个平台。

当前的福利平台，已经接入了衣食住行，吃喝玩乐等各类下游服务商后实际上已经变成了一个强大的能力中台，因此福利平台本身也就不再局限于只能够为企业端服务，更多的也可以直接面向C端服务，而这个面向C端服务更好的借鉴就是一个社交电商或导购类服务平台，比较典型的例子就是类似大V店的模式，而非什么值得买APP的导购模式。

大家可以看下知乎，当前已经推出了可以维护自己的商品橱窗的功能，即别人访问你的回答或者你的知乎主页的时候可以看到你推荐的商品，如果通过你推荐的商品产生的购买行为，那么你可以得到相应的提成。而我们完全可以借鉴这个思路来考虑如何在当前已有的能力中台基础上来做一个社交电商的服务平台。

从18年开始我们就看到，谈得最多的词就是流量和私域流量，有流量就能够带货，最终依靠个人的品牌和人气来产生最终的购买行为。谁掌握了流量往往就掌握了话语权，那么当你做一个运营平台的时候，一种获取流量的方式就是找有流量的人合作，利益共享。

在我们做产品和服务的运营过程中一定要借力，而这个借力最不能忽视的就是个体崛起。

在福利平台本身提供了足够的下游服务商接入，同时本身接入的产品和服务具有了价格优势后，剩下的关键就是基于社交电商的思路来考虑如何进行产品和服务的推广，直接到C端客户的引流。

如果我是一个掌握了流量的大V，那么可以看下实际上从平台功能上需要提供的包括：

我自己能够开店，简单来说我能够从你的能力中台上选择产品和服务放到我自己的店铺上，我只负责引流，实际的支付，物流等我并不关系。我需要根据实际的引流和交易情况来分成。

如何推广，实际上包括了多种方式，常见的实际上两种。

微信群推广：直接发送商品的链接，通过链接进入到商品购买页面。
发朋友圈：直接发图片，通过识别二维码进入到商品购买页面。

可以看到对于发朋友圈的情况下，一定不能是简单额发链接，而最佳和最醒目的方式就是发图片，然后有具体的价格对比，然后是醒目的给出识别二维码进入到购买页面的方式。在有人通过链接或识别二维码进入到购买页面的时候，需要代入你自己的userid信息，方便后续根据实际的交易情况进行提成。

在最终的用户进入到购买页面后，实际上在购买前仍然需要先注册，因此这个注册过程必须足够的简单，注册后就成为平台最终的用户，在购买前还需要维护相应的地址信息，最终的支付直接对接常见的微信或支付宝支付即可。

在最终用户产生购买行为后，这里一方面是会让用户之间关联相应的微信公众号，以后可以直接进入公众号看到自己的订单和物流信息。或者就是用户还是通过链接或二维码识别进入到购买页面的时候，能够很容易跳转到商品首页和个人中心，以方便查看相应的订单物流。

在完成第一次引流并产生购买行为后，一个好的社交电商平台要做的就是能够根据后续的运营，产品的推广等让最终的用户产生二次购买行为。也就是在能够产生独立的二次购买行为私域流量会转化为平台流量。简单来说你并不需要烧钱去引流，而是让利的方式进行引流。

网易严选数据产品实践

Mon, 26 Oct 2020 00:00:00 CST

数据产品是个新兴的产品分类，每个人眼里都有一个自己的数据产品，尽管在绝大部分人的概念中都是一堆报表。在过去的3年里，我们在用户需求的推动下一步步构建了网易严选数据产品体系，下文分享我们在构建过程中自己的一些思考和总结。

背景

本文内容来自我在2020产品经理大会上《网易严选数据产品实践与方法论》分享的文字总结，由于篇幅原因，只包含了实践部分。数据产品是个新兴的产品分类，每个人眼里都有一个自己的数据产品，尽管在绝大部分人的概念中都是一堆报表。在过去的3年里，我们在用户需求的推动下一步步构建了网易严选数据产品体系，在构建过程中也有一些自己的思考。

网易严选数据产品实践主要分为以下4个阶段：“业务有数可看”、“数据质量保障”、“CXO有处看数”、“场景化数据产品”。这4个阶段其实并没有明显的阶段之分，各阶段高度重叠，很多时候都同时在推进。接下来，我会从每个阶段面临的需求(问题)，以及我们采用的产品解决方案来详述我们的实践之路。

一、业务有数可看

2017年，我刚来严选的时候，是严选数据产品起步的阶段，我们主要面临事多、人少、工具差的三大问题(应该也是各个数据部门长期面临的问题)。

“事多”主要是因为业务方多且当时业务数据需求有一波激增。现代商业(特别是在线业务)数据重要性不言而喻，业务需要通过数据来了解业务现状，发现业务的机会点和风险点。网易严选作为品牌电商，业务链路特别长，相较于纯互联网业务主要有产品运营部门，品牌电商还有很重的供应链、商品、客服等部门，记得当时光二级部门就有30+，每个部门都有数据需求。当时还不断有电商互联网大厂的管理层加入严选，基于他们在原来公司比较先进的数据监控体系，提了大量数据需求，带来一波业务数据需求的激增。“人少”是部门初建的常规问题，当时我们数据开发10个不到(还有2个实习生数据产品经理)，跟我们合作的数据分析师应该也就10个左右。当时使用的报表工具有BIEE、excel、自己开发的数据产品(报表集合)，数据开发主要写MR加工数据，网易猛犸+网易有数尽管也已经引入，但是没有用正确的姿势大规模的使用起来。

面对“业务有数可看”的需求，我们通过构建数据仓库+严选有数(敏捷BI平台)的方案来解决。数据开发工程师在网易猛犸大数据开发平台使用SQL高效地进行数据开发构建数据仓库，数据分析师基于数据仓库在网易猛犸上使用SQL高效地进行分析集市的开发，再使用网易有数通过拖拽和配置的方式快速进行报表开发。经过数据分析师和数据开发工程师的辛勤工作，严选有数目前有8w的图表(加上其他数据产品一共10w+)，工作日PV 6K+，周UV900+，对于一个事业部级别的BI平台，报表量和访问量应该算是非常不错了。那我们是如何做到这样的规模呢？首先应该感谢数据分析师和数据开发工程师的辛勤开发，开发了大量的报表和数据模型。因为本文主题是数据产品，接下来我主要从数据产品(严选有数)的角度展开讲下我们方案的优势。

严选有数是网易有数在严选的一个私有部署版本，在网易有数的版本上结合数仓做了性能优化，在开放协同上也做了一些功能扩展。

严选有数继承了网易有数简单易用的特性，只需要简单拖拽即可进行可视化分析，支持分析师快速制作数据报表。PPT式的操作，让分析师能够快速进行报表布局、图层管理、图表样式优化，制作出业务人员友好的报表。

由于严选有数承载的报表数量大、大数据查询引擎的并发性能差、业务人员集中在开始上班时间(9点多)并发查看报表，性能问题一直是影响业务人员高效阅览报表的主要问题。在性能方面，我们优化查询引擎(Imapla)的同时，通过数据产出驱动的缓存极大的提升了性能，支持业务人员快速阅览报表。最早，严选有数采用常规的被动缓存，图表首次访问落库查询(并缓存)，后续访问查询缓存。业务人员上班后(9点多)集中访问报表，大量图表首次访问进行落库查询，查询引擎瞬间就崩了。那时候几乎每天早上都被严选有数群里用户对BI平台崩了的抱怨，搞得焦头烂额，尽管暂时通过限流排队，解决崩的问题，但还是大量用户排队访问不了报表。我们的第一次改进，是把被动缓存改成定时主动缓存，因为报表数据绝大部分是T+1的，当日数据产出后不会变化，所以在每天7点数仓(及分析集市)产出后，集中进行主动缓存。改进后70%以上的图表访问都能命中缓存，秒级影响，极大地提升了用户的阅览体验。随着图表数量的快速增加，7点-9点多之间缓存的占比越来越低，平台的平均性能越来越差，用户图表平均访问时间也不断增长，每天早上严选有数群里各种用户抱怨又开始出现。我们再次改进了我们的缓存方案，把定时主动缓存改成了数据产出驱动的缓存。通过监听数仓表(及分析集市表)产出的消息，每次有表产出时遍历依赖该表的所有图表，如果相应的图表依赖的表都已经产出就开始进行缓存。这样我们就不用等到7点开始进行主动缓存，而是从0点开始只要图表依赖的表已经产出就开始进行主动缓存，这样从0到9点多，我们就能预先缓存大量图表。我们的图表缓存命中率达到80%以上(最近缺乏人力持续优化下跌到70%左右)，命中缓存的图表都秒级响应。

在网易有数的基础上，我们还增加了一些开放协同的功能点。我们根据业务人员所属业务域，开放了尽量多的数据权限(能看到更多数据，才能产生更多分析的想法)。我们开发了维度/指标级搜索功能，让业务人员通过搜索维度/指标名称，快速从众多的报表中找到他想要的报表。我们在报表右上角提供了联系作者的快速入口，当业务人员阅览报表时，如有疑问可以快速唤起popo联系报表作者。通过一系列开放协同的产品功能，让业务人员可以看到更多的数据，可以更快速的找到想要的数据报表，可以便捷的联系报表作者(分析师)，形成业务人员看更多数据->产生更多数据需求->联系分析师提进一步分析需求->分析师开发更多分析报表的分析闭环。

二、数据质量保障

由于数据源多、数据链路长、数据指标口径复杂等原因，数据质量问题多、保障难度大。从用户的角度看数据质量主要存在晚、错、不一致的问题。

“晚”是指报表产出晚，实时数据延迟。由于报表数量大，对应的数据处理任务(数仓、数据集市)也很多，任务的出错和运行超时都可能导致数据产出晚。18年时，严选有数用户群里，用户反映报表晚产出是常态。实时数据延迟主要会在大促时候出现，实时UV、在线人数常常会延时。“错”主要指数据指标错误和用户标签错误。数据源里一条记录的丢失、一个字段的错误，数据处理任务链路上一个处理逻辑的错误、任务的延迟都可能导致数据指标、用户标签的错误。“不一致”主要指同一指标在不同的报表不一致，指标口径业务理解不一致。因为同一个指标会出现在不同的有数报表以及不同的数据产品中，经常会出现业务在不同的报表里看到指标不一致的情况。同一个指标名称在不同的上下文可能有多种口径，光毛利相关的口径就有5+个，业务人员对同一个指标的口径理解可能会不一致。

数据质量保障是一个复杂而系统化的工程，展开讲可以写一本书，本文的主题是数据产品，下面主要从数据产品的角度讲下我们的数据质量保障的解决方案。针对数据质量保障需求，我们设计开发了一系列中台数据产品来保障数据的完整性、准确性和稳定性。

在刚开始构建数仓的时候，我们就形成了默认的规则，所有的业务数据库、业务日志都接入数仓，保障了在线化数据的完整性。尽管我们严选产技团队，几年来加班加点地不断研发系统，但是严选依然有很多业务没有线上化，进而数据不能通过业务系统、日志进入数仓。一方面是因为作为品牌电商，业务链路长，对应的业务线上化的需求也多，另一方面业务不断更精细化运营、不断探索新的业务方向(这样才互联网)，进而不断产生新的业务线上化需求。针对尚未线上化的业务过程，我们开发了数据填报系统，业务通过excel就可以快速把数据导入数仓。

数据产品经理结合业务需求通过指标管理系统先定义指标(口径、描述等)，数据开发同学通过数仓设计系统根据指标定义进行数仓模型的设计，网易猛犸大数据开发平台根据数仓设计系统的模型设计来新建表。通过需求->设计->开发的在线化协同，来保证指标开发的一致性。指标地图，提供所有核心指标的定义，业务人员可以在指标地图查看指标定义，来解决指标口径理解问题。从数据源的角度看，业务DB的数据一方面有数据库scheme的校验，另一方面应用层也会进行校验(业务DB的数据是通过应用层代码写入的)，出问题的概率很低。数据填报系统excel导入的数据，因为在excel里直接操作数据且操作非常灵活(约束少)，很容易出现导入的数据有问题。我们首先控制数据填报系统的建表权限(只有数据开发可以建表)，同时在系统里提供了大量的校验规则。业务人员需要导入数据到数仓时，先联系对应的数据开发提数据导入需求，数据开发根据需求设计表的结构，并配置对应的表级/字段级的校验规则。业务人员导入excel的时候，相应的校验规则就能提前发现不符合规则的数据，并要求业务人员修改后重新导入。埋点由于端多、涉及的开发人员多、没有强scheme约束，也是数据源问题重灾区。埋点管理系统提供了埋点的定义，埋点流程管理和埋点测试。埋点开发人员使用埋点管理系统的单元测试能力，在埋点开发完成后就能进行单元测试，检查埋点数据是否符合埋点定义。测试人员可以使用埋点管理系统的回归测试能力，对核心埋点进行回归测试。通过埋点测试，可以保障埋点数据源的准确性。

由于数据任务量大(1W+任务节点)、大数据平台本身稳定性相对较差，任务稳定性保障一直是个难题。我们跟杭研共建任务运维中心，提供任务治理、智能监控报警、任务影响分析等功能保障数据稳定产出。通过任务运维中心，发现高耗时、耗资源风险任务，及时进行任务优化。智能监控报警，在任务出错、预测基线有破线风险时及时报警给数据开发值班人员，数据开发值班人员自己或组织对应的开发人员，及时进行问题的处理，保障任务的稳定(准时)产出。

三、CXO无处看数

看到“CXO无处看数”，大家可能觉得很奇怪。上文不是说了，在有数上已经制作了大量报表，怎么CXO会无处看数。因为CXO有不一样的场景，进而产生不一样的需求。尽管BI平台（严选有数）上有大量报表，CXO依然面临“难找”、“不能随时看”的问题。CXO有整个BI平台的权限，进入平台后面对海量的报表，难以快速找到想看的数据(CXO的时间又很少)。CXO工作特性需要随时随地查看数据。CXO事情特别多，电商CXO尤甚，品牌电商CXO更甚，CXO不是在开会/出差，就是在开会/出差的路上(连我自己现在也差不多)。

针对CXO的看数场景和需求(痛点)，我们设计开发了VIPApp-移动数据工作台。VIPApp为CXO提供了随时随地监控KPI以及所见既所得商品、类目、流量数据。下图中是VIPApp很早期版本的一些UI，因为数据安全的原因数据部分打了码。早期VIPApp主要为CXO及少数中高层服务，现在已经逐渐发展成面向严选全员的移动数据工作台了，承载了整个严选KPI体系监控及各业务运营的数据监控体系。VIPApp从技术角度看是以严选app为容器，内嵌了一个wap(数据产品)网站；从用户角度看依托严选app提供了所见既所得的交互入口。用户可以长按类目唤起类目数据页，长按商品唤起商品数据页，长按流量位置唤起流量数据页。移动化让用户随时随地可以查看数据，所见既所得的入口让用户可以快速找到对应的数据模块。好的用户体验一定会带来高频访问的回报(每个产品人都应该信仰)，VIPApp也不另外，是我们最成功的数据产品。

四、场景化数据产品

在日常接到的用户数据需求中，我们发现的一些数据需求场景，相对于作为整个严选业务数据监控体系的一部分，作为一个垂直场景的数据解决方案会是一种更好的表达，比如大促、市场投放、用户体验等数据需求场景。大促是电商最重要的节日，要渲染大促氛围，要实时追踪大促的爆发效果，以进行运营动作的及时调整。市场投放要及时追踪市场拉新KPI，及时评估渠道ROI来决策放量/停投，要测试/挑选拉新的新品等。互联网产品都是以用户为中心，网易更是极度重视用户体验，如何量化评估用户体验，如何从用户视角改进业务。

针对电商大促场景化数据需求，我们设计开发了电商数据大屏和客服数据大屏。在17年双11之前，我们开发了第一版严选电商双11数据大屏。跟业界双11数据大屏类似，数据大屏通过主动的实时数据呈现，让业务实时追踪大促爆发。通过炫酷的视觉样式和动画来渲染大促氛围。在电商双11大屏上线后，我们客服部门负责人找到我们，希望帮他们在下一次大促前做个客服数据大屏。由于没找到mock数据的客服数据大屏(下图的大促数据大屏数据是mock的)，且客服数据大屏上数据太多打码难度太大，大家根据大促数据大屏自行脑补下UI吧。客服数据大屏包含实时的会话、排队、坐席数据，还有满意度、CPD、满意度报警、超30分钟会话等排行榜。我们发现电商数据大屏只在双11、周年庆等极少数电商大促节日的正点时段使用，但是客服数据大屏在我们两地的客服部门长期放了好几块。这种现象让我想到在房产中介看到的月度榜单墙，客服大屏是一种更实时的可视化的劳动竞赛榜。

针对用户体验场景化需求，我们设计开发了谛听-舆情洞察中心。用户体验的难点在于难以定量的衡量和分析。除了复购、退货量这些间接的量化指标外，我们能收集到的用户直接的声音是用户评论、客服咨询等非结构化、定性的数据。用户在严选的消费链路(访问->浏览->咨询->...)的每个节点，在严选内部都有对应的业务部门/业务环节为用户提供服务。我们根据业务环节建立舆情的分类体系，通过算法+规则将舆情分到对应分类中。将归属到具体分类的舆情数量求和，就完成了舆情从定性到定量的过程，舆情类别就是舆情分析的维度。因为我们建立了用户舆情->舆情分类->业务环节(部门)的映射关系，就可以通过分析对应业务部门所属分类的数据来评估对应部门的用户体验，进而可以将对应的负面舆情分发到对应的部门进行改进。质量相关的舆情我们早已完成线上评估->分类->分发->改进的线上化闭环，当前我们也正在推进其他分类的线上化闭环。

针对市场拉新的场景化需求，我们设计开发了刑天-推广渠道管理系统。整体的思路和逻辑类似，这里就不展开叙述了。

总结&后记

3年多的不断建设，经过以上4个阶段，我们基本完成了严选数据产品体系，并伴随业务的精细化与创新进行相应的开发与迭代。从用户(严选业务人员)角度看，自上而下是场景化数据产品、敏捷BI平台和数据管理数据产品(又可以叫中台数据产品)，分别应对业务场景化数据需求(CXO看数也可以理解为一种场景化数据需求)、大规模的看数需求和高效高质量的数据管理需求。

在写文章的过程中，我发现文章信息密度还是很大，包含了很多数据产品和解决方案，难以在一篇文章中全部展开来讲。如果大家对数据产品感兴趣，想了解具体的产品或解决方案，请在评论区留言，我们会根据反馈发表对应的解决方案或数据产品的文章。当然我也会视本文的热度，决定后续是不是把方法论部分再写一篇文章发表出来。

作者简介

魏文庆，现任网易严选数据技术及产品部总监。2007年浙江大学计算机硕士毕业后入职网易杭州研究院，从事前端开发，后历任技术主管、技术经理、技术总监。曾负责网易摄影、网易企业邮箱、易信公众号等产品开发，以及网易前端微专业课程开发。2015年开始内部创业，孵化敏捷BI平台-网易有数，任网易有数总经理，负责产品研发和商业化。2017年开始负责网易严选数据技术及产品部，从0到1搭建网易严选数据中台和数据产品体系。

本文由作者授权严选技术团队发布

银行业务中台这么搞，新产品上线提速60%

Thu, 15 Oct 2020 14:29:40 CST

前言：什么是中台？

开始正题之前，首先要讨论下什么是中台。按网上搜集到的信息，有些人说中台是技术中台，像微服务开发框架、Devops平台、PaaS平台，容器云之类的；有些人说中台就是微服务业务平台，像最常见的什么用户中心、订单中心，各种微服务集散地，叫做”业务中台“；还有人说中台是组织的事情，组织架构有调整的话，也可以叫”组织中台“；也有人说中台是一种思想，一种体系，可以快速聚合后台的数据与能力。因此不同的人对中台有不同的理解。

在三湘银行去年做中台项目的时候，我们在网上找到了一个定义： 中台是企业级能力复用平台。这是我们去年比较认同的概念，理由是：

企业级定义了中台的范围，区分开了单系统的服务化与微服务；
能力定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；
复用定义了中台的核心价值，传统的平台化对于易复用性并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部转换到平台对于前台业务的支撑上；
平台定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细力度能力的识别与平台化沉淀，实现企业能力的柔性复用，对于前台业务更好的支撑。

在去年我们主要使用此定义描述对中台的理解。

但是上面这些概念是否能真正解释中台？在中台项目完成后，我又重新做了思考。如果按照上面的定义，并不能完全清晰说明什么是中台。因为传统的SOA架构、微服务架构、标准化和平台化的一些改造都可称之为”中台“，所以中台的概念感觉还不是太清晰。

我们看一个中台的演变示例，它是参考了阿里架构的演变。假设有一家电商公司，一开始创建了中间蓝色这块食品电商平台，实现了一些订单、商品、用户、支付的功能。食品电商平台对应的业务部门是食品业务部。

后来随着公司业务发展，又成立了药品业务部，通过复制食品电商平台的模式创建了对应的药品电商平台，其实这个新平台用到的功能类似于食品电商平台。但由于这两个平台售卖的货物存在差异，两个平台并没有结合。公司再大点，就汽车电商平台。最后，三个平台各自独立发展自己的服务架构和内部的业务管理。

在支付功能层面，这个公司的不同电商平台可能会跟不同的支付机构进行合作来实现交易功能。三个电商平台都有对应的用户管理和支付功能。由于三者处于竞争关系，导致支付通道不能实现统一。

基于这些问题，公司不得不开始建中台。把三个电商平台负责用户管理的人力集中起来，成立用户拓展部，创建起用户中台，实现用户的管理和营销功能；同理公司又成立了支付结算部，创建支付中台。当公司建立起用户中台和支付中台，它的用户管理和支付管理能力就能统一起来，整合了资源，这就是中台的大致的演变示例。

根据这个示例我提出了一个新中台概念， 中台是基于企业资源整合的需要，通过运营模式变革、组织架构调整、IT架构重构等方式形成的企业级服务复用能力。

中台的战略目标是实现企业资源整合；
中台的能力体现在企业级的能力复用；
中台的实现手段是运营模式变革、组织架构调整、IT架构重构，且运营模式变革是重点；
中台可以解决一些问题：突破组织壁垒，不会因为组织间的竞争关系导致资源只能服务某一个部门；统一公司内部资源，实现资源共享；快速支持业务创新。

一、为什么建中台？

讲完中台的概念，我们想想银行为什么要建中台。

大部分银行的组织架构和图类似，银行组织架构本身已经区分出前中后台的体系：像营业部、分支行、金融市场部等做具体对客业务拓展的部门属于银行前台部门；对于一些做业务管理和产品设计的部门，像风险管理部、信贷审批部属于银行的中台部门；而银行内部的管理机构，像办公室、人力资源部等服务于银行经营的部门则属于银行的后台部门。

再看看传统银行的IT架构设计。最上面的是银行的渠道端，就是对客部分的系统和一些整合服务平台；中间部分属于银行金融产品运营类的系统，由于银行的金融产品种类特别多，所以对应系统也非常多；在后台，会有银行核心系统，包括互联网核心系统、银行核心系统和账户系统；最下面的是BI类的系统。从架构图可以看出，银行的系统数量非常之多。就拿三湘银行这样小的银行来讲，系统数量其实也有140多个。

正因为银行IT系统数量众多，通常银行都会存在以下几个问题：

能力重复建设：不同系统基础能力重复建设，例如客户信息管理、账户管理,新建系统或优化规则时造成整体成本的浪费和项目周期的增加；
系统调用复杂：新产品的实施会涉及多个关联系统共同改造，导致改造成本高且实施周期长；
产品/账户/交易/核算紧耦合：产品与账号、交易与核算的处理放在同一个模块中实现，当需要产品支持不同的账号类型、交易需支持不同核算规则时，则必须通过修改代码逻辑或接入相应的新系统才能实现相应功能；
架构复杂难以重构：调整架构所需的成本、周期、业务影响和风险，因此多数采取局部优化的方式，难以一次性完成整体架构重构。

从推出一个全新产品的实施周期来看，银行跟新兴互联网公司会有不少差距。金融科技公司一般在1个月以下，传统商业银行通常要3个月以上，大行可能需要半年到一年时间。

到这里我们已经看出为什么银行要建业务中台，其实银行建业务中台的驱动力不是来自业务部门。对于商业银行来说，它的业务运营和组织架构本身就是前中后台的模式，本身就切合中台的设计理念。业务部门对中台的建设并没有太急迫的需求，动力不足，即使不建中台，其业务的流转还算顺畅。 实际上银行的中台项目的发起都是由科技驱动力为主。随着互联网金融竞争加剧，业务对需求的响应时间要求逐渐向互联网企业看齐。而传统银行应用架构难以支持这种快速响应、快速上线的改变，因此科技部门迫切期望通过中台项目改变IT的交付效率，这就是银行建中台最大的驱动力。

二、银行业务中台架构设计

对于中台的建设，会有很多种不同的设计。主要以三湘银行中台设计为示例供大家参考。

首先我们讲下建业务中台要解决的问题。银行建中台最大的问题主要解决新产品上线 成本高、周期长这两个问题。

该图是银行某个简单产品的流转示意图，左边是渠道系统，中间两个是产品系统A和产品系统B，负责提供产品的服务；右边是银行账户类的系统，像传统核心和互联网核心，还有涉及第三方支付系统。大家可以看到，我们如果要做一个产品的购买，渠道系统要对接到每个产品系统来实现产品的展示，以及发起一个产品的购买交易。通常银行会把一些产品的扣款，以及支付的一些功能落在产品系统上，由产品系统去对接银行的核心，以及银行相应的支付系统实行资金扣划。

每创建一个产品，每个渠道系统要实现同样的一套接口对接。看图右边列出了主要的五个接口，实际上真实情况下接口数量会比图中的更多。

对于产品系统来说，除了要提供渠道系统要访问的接口以外，还要实现跟行内核心系统以及支付系统对接的一些功能。大家可以看到，当产品系统越多，那渠道系统要实现对接的接口数就越多。

另外产品系统也需要对接行内的一些系统，以接入核心系统系统为例，假设我们有两个核心系统，一是银行核心，二是互联网核心，那么产品系统就要实现两个核心系统的对接。如果是支付系统的话，每一个支付通道就要接一次，比如人行系就有大额支付、小额支付、超级网银这三种支付通道，再加上微信、支付宝等等其他第三方支付通道。同时，产品系统还要实现记账和支付的异常处理的功能，这些规则如果没处理好，也会容易造成银行的短款和账务问题。这就是为什么银行在现有传统架构下创建一个新产品成本高和周期长的原因。建中台的目的就是为了解决这么一个问题。

那针对上述问题，就有了四个对应的业务中台设计目标：

快速创新，这是最主要的目标，支持创新产品的快速实施，并能有效降低整体成本和实施周期；
系统复用：不推翻现有银行的整体应用架构，已有系统可以得到有效复用，无需重构现有系统；
全业务支持：支持银行现有业务场景在新架构的落地；
平滑过渡：支持现有业务场景的新老架构并行和逐步迁移，实现业务的平滑过渡，降低中台建设过程的实施风险。

基于以上四个目标，三湘银行在去年建业务中台的时候，挑选了银行六个最基本的业务能力去建对应中台，也是第一期业务中台建设项目中六个最核心的功能： 用户中心、账户中心、支付中心、核算中心、交易中心、产品中心。

我们认为业务中台的定位为：作为产品系统与渠道系统、账户系统、支付系统、核算系统之间的桥梁，利用传统银行应用架构中已有的系统，通过标准业务模型来实现系统间的解耦。这个业务中台的理念其实跟平台标准化、或者SOA的理念很相近，不过还涉及到业务模型的调整。所以三湘银行的业务中台跟一个纯IT项目还是有所区别的。

1、用户中心

首先讲用户中心。那用户中心要解决的其实有五个问题：客户管理、生命周期管理、电子渠道互通、客户信息整合、签约管理。

设计用户中心就是要解决这些上面五个问题。

对于用户中心来说，首先要解决的就是用户生命周期的问题。可能大家也会有疑问，为什么会叫做用户中心，而不把它称为客户中心？

在做用户中心设计的时候，我们有思考过这个问题，实际上用户和客户的定义是有所区别的。在传统银行来说，它通常会把开了账户的客户才叫客户，对其他用户银行基本上是不管的。就像游客，银行基本上是不登记游客的信息。但是互联网公司就不一样了，互联网公司会收集游客、注册用户、实名用户、实体用户的信息进行管理，包括登录信息、浏览信息，目的是为了更好去做客户的营销，以及提升客户体验。我们把互联网公司这套设计模式放到用户中心里面。

我们要求把从游客开始到实体用户这四类型的用户都要管起来。

第一类游客，纯过来浏览，但是没有做过任何注册，也没有留下任何联系方式的。但实际游客还有一个关键信息我们可以保留，那就是游客的设备号，就是他通过某个手机访问，后期可以通过这个设备号就能找到这个游客是谁；
第二类是注册用户，只要他在银行渠道或系统留下了联系方式，像手机号、微信号、邮箱，就认为他是一个注册用户，这代表我们可以联系到客户；
第三类就是实名用户，实名用户顾名思义就是客户在银行系统中通过了实名认证，比如通过了身份证认证、人脸识别。这类用户就叫实名用户；
第四类实体用户跟传统银行的概念一致，就是在银行开过户的客户。

对于这四类用户，在用户中心都需要统一进行管理，包括用户信息管理、用户行为登记等等。

在用户中心里面，还会设计统一登录的功能，比如说用户能够在三湘银行所有的电子渠道上支持用户名这种方式登录，或者手机号登录，或者账号邮箱登录，就是在各个电子渠道都是一致的。同时，也可以通过一些设备的验证方式，比如说人脸登录、指纹登录、手势、扫码这些登录方式，也能支持一些第三方的登录方式，像微信、支付宝授权登录，这些登录模式我们的用户中心上面都能支持。

第二块就是统一签约。统一签约这块我们会把用户所有签约的数据，都会在用户中心有管理起来，同时所有的签约和解约的动作，都会在用户中心上支持，这样保证能在用户中心查到用户所有的签约内容，以及实现所有用户的签约解约的动作。

第三块就是统一视图，把所有跟客户相关的信息，包括客户的基本信息，客户的私有资产、负债的信息，客户的交易流水还有一些行为，都会统一在用户中心对外展示。这就是统一视图的概念。

实际上用户中心的整体功能包括六部分：

下面这个图是用户中心大体功能示意图，除了刚才介绍的客户管理、统一视图等功能以外，还有关联管理能力，无非就是把客户的收藏夹、收款人名册、收件人地址类似这些信息在所有渠道上共享，这样使用户在银行所有的终端都能获取到他的信息，提升客户的体验。

所以说整个用户中心等同于传统银行几个系统的集合，一个就是ECIF，其次就是实时CRM，实时能获取用户360°的视图，再加上对于用户在所有渠道端操作和体验的渠道支持，这就是对于传统银行用户管理能力的整合。

2、产品中心

产品中心需要解决的问题有以下四点：产品目录、产品管理、产品查询、产品上下架。

对于产品中心，我还想解释几个概念：

我们做的产品中心就属于狭义上的产品管理类系统。

上图是我们产品中心整体的功能架构。

左边是管理产品的基本属性，包含产品的基本信息、销售属性，比如它在哪个渠道销售、销售额；促销信息，某个产品在某个期限可以打折，或者通过优惠券减免手续费等；收费信息，购买某个产品所需要收取的对应手续费，类似以上这些就是产品基本信息的管理。

但其实还会存在某些信息需要从各个产品系统上同步过来。相当于产品中心一方面会从传统核心系统把产品同步回来，另外在产品中心维护好某些产品信息，也可以反向把这些信息同步到产品系统，实现对应的产品的创建。这是产品中心里面产品属性管理的一个功能。

在产品中心那块，属于产品渠道和店铺的管理，其实在做产品中心设计的时候，就考虑到把产品中心作为统一销售管理的功能。在产品渠道里面，我们设计了店铺和机构的概念，在店铺（机构）底下设置了分类，那对于所有的产品，就会上下架到所有的分类里面。

比如说在分类里面会有一个推荐或热销的产品分类，那可以在产品中心进行配置把产品上架到对应的产品分类。那对于渠道系统来说，就能直接看到这些分类上面的产品清单和产品的信息。同时产品中心会实现所有产品信息的缓存，所以它能支持一个高并发的产品查询。所以说所有的渠道系统不用再去访问一个具体的产品运营系统，相当于手机银行就不用再去访问核心系统就能获取对应的产品信息。所有要销售的产品都从产品中心直接获取就可以了。

同时产品中心还会有个功能——实现产品的过滤。渠道系统可以把查询产品对应的渠道和客户标签送给产品中心，产品中心可以通过产品所设置的可销售渠道以及可销售客群来决定哪些产品能够在渠道上能看到。

比如说有个客户登录了手机银行，他查看他能购买的产品时候，产品中心就会根据该客户能看到的产品返回对应的产品信息，不需要渠道系统再去做对应的产品信息过滤，从而实现千人千面的产品销售展示功能。

3、核算中心

三湘银行今年才开始建核算中心，去年建业务中台的时候还没有把核算中心建起来。

这是建核算中心要解决的4个问题。要理解这4个核算中心的问题，先讲下银行的账务处理流程。其实银行的账务处理通常是这样：客户在银行的交易系统上可能产生了一笔交易，这个交易可能是一个产品的购买，那这笔交易实际上会实时的输送到核心系统来进行产品的扣账，以及对客户产品账户的入账。

比如说一个理财产品的购买，客户就需要实时把他理财购买所花的钱扣下来，同时对客户生成一个理财产品的分户，把他所持有的理财产品份额送入他的分户里面。这部分交易需要实时实现，在我们银行内称为“客户账”，就是跟客户相关的账。

其实银行里面还有另外一部分账，叫做总账，就是银行账。银行账一般来说属于银行内部使用，用于实现银行核算报表，资产负债报表等信息。这些账没有要求一定要实时，所以通常在银行里面夜间通过批次的方式进行记账处理。

所以建核算中心就是为了要解决刚才说的4个问题，分成核算规则配置、批量过账、实时过账3个功能：

这是我们设计核算中心的一个大的流程图：

大家可以看左边，当你实时处理一笔交易的时候，交易系统是不需要再产生银行核算的这部分账户。它也不需要关心银行核算的规则，只需要实现银行客户账的扣钱，以及产品的入账。把这个做了就行了。然后交易系统就可以把这个交易数据，和它的交易流水直接送到核算引擎里面，那核算引擎会把交易流水的接口映射成银行内部的标准交易格式，再关联上配置好的记账账套。比如说一笔交易流水会有多少借贷的分录，以及借贷的金额该怎么计算，这些都是通过对应的配置实现，最终核算引擎会生成具体的银行账的借贷分录，再把该分录实时送给总账记账。这就形成我们实时记账的功能。

同时对于批量来说，它其实跟实时记账很像。批量的话，可能该系统通过准实时模式集合了一批的账户，或者说每天夜间集合了所有的账户，送给核算引擎，核算引擎也是用刚才处理的这些方式，把生成对应的这些交易数据快速登录送到总账去进行批量计算。这是一个核算大的流程设计。

4、账户中心

账户中心要解决的问题有四个：账户能力重复建设、跨系统记账复杂、账户能力参差不齐、缺乏统一账户视图。

在账户中心的设计里面，我们提出了三个概念：产品与账户分离、介质与账户分离、账户与账户分离。

刚才在讲到产品中心的时候，其实讲到产品的概念，产品属于一些运营规则集合。把产品跟它的账户分开有什么好处呢？举个例子，在传统的核心系统上，有一个产品已经实现了一套规则，这个规则假设放在I类户里是可以用的，但放在II类户是用不了的。如果要实现同样的产品规则，那必须要花时间重新进行开发，又比如未来遇到积分系统要实现类似的功能，我们又要去积分系统上实现对应的规则。

如果能把账户和产品剥离开，自然而然一套的产品规则可以应用在不同的账户上，就像刚才说的存款取利息的功能就可以放到I类户也行，II类户也可以，甚至像一些积分账户也能做到对应规则的处理。

第二块概念就是介质与账户分离。这里面主要还是区分介质的概念。介质是由银行提供给客户，用于证明客户身份的凭证，介质本身不具备金融属性。真正具备金融属性的是介质所绑定的账户。把介质跟账户区分开有很多好处，比如说客户的卡丢了，他换卡只是换介质，只需要重新绑定原来的账号，另外账户和介质分离后也能支持一个账户绑定多个介质。

最后一个概念是账户与账户分离，这其实相当于在设计上把所有的账户放在同一个层级中，而账户和账户之间的关系是通过账户中心的合约管理来去实现这些账户之间的关系。通过账户之间的合约可以实现各种各样的账户层级关系支持，扩展性也会比较高。这也是账户中心的设计理念。

我们在设计账户中心的时候，也设计了账户的基本模型：

这个账户基本模型包括了账户的基本信息，账单信息，冻结/止付信息，余额信息，扩展信息，合约关系，介质绑定。我们把所有的账户都统一抽象为这样的一个模型，对所有的账户都会按照这个模型做管理和访问。对账户来说，我们还会提供一些标准的基础功能，比如说账户的限额管理、合约管理、智能路由、睡眠户管理这些基本的账户功能。

其次我们还把账户的基础功能标准化成几个最基础的原子服务：所有账户的操作无非都是开户、销户记账（存/取/冲正）、冻结解冻/止付解止、挂失、查询、信息变更。这些功能对于所有的账户都是一样的。把账户服务都标准化以后，在银行里面进行账户的处理，包括记账、冻结等操作，都可以沿用这个统一模型去做处理。

对账户中心里面刚才说的合约概念，大家可能不清晰。其实我们把合约认定为账户和账户之间的关系，并且通过合约可以实现账户和账户之间一个资金流向的管理。这个图提出了5个账户流向的管理：

资金流转合约：进行账户之间的资金流向限定，即限制账户资金只能向签订了合约的账户转入；
虚拟子账户合约：账户上实下虚，将结算户与虚拟户结合形成类似会员卡性质的资金台账管理，虚拟户的动账联动执行结算户的动账；
虚户资金归集合约：账户上虚下实，将多个结算户资金归集到一个虚拟户统一展示，结算账户的动账联动执行虚拟户的动账；
资金归集合约：将多个产品户与结算账户关联，通过产品户控制结算账户的资金用途，产品户的动账联动执行结算户的动账；
集团账户合约：通过合约将集团公司之间的账户关系关联起来，供业务应用进行集团账户的操作和管理。

各种各样的账户关系其实都是通过合约类型去支持，而且合约类型未来还可以不断拓展。

在账户中心的建设里面，我们也考虑到成本的问题。不可能说建一个账户中心就把原来的账户系统全部干掉，把账户都迁移过来，所以在建账户中心的时候，要考虑账户中心本身有账户功，能但同时也能实现把原有的账户系统直接对接过来。比如说我们要把传统核心的I类户接入进来，可以通过一个适配接口把传统核心接入账户中心。

那对于外围的产品系统，它以后不会再直接去访问传统核心，而是所有对账户中心操作的处理都通过账户中心的标准服务去访问，来实现对所有账户的处理。通过这种模式，可以让所有渠道、产品系统对账户的操作都可以采取同一个模型，而且都通过账户中心来实行。那未来假设有某些系统我们要重构的时候，这时候自然而然就可以把对应的账户迁移到账户中心实现。这个模式可以极大地减少数据迁移的成本，以及避免了比较大的实施风险。

5、支付中心

所有银行都有统一支付的概念。支付中心要解决的问题其实跟统一支付的概念类似：

对支付中心的设计我们提了一些概念：

我们把银行的I类户的扣账也放到支付中心处理，并且将所有涉及的资产的动账我们都放到支付中心去实现。

以下这个图就是刚才说的支付中心的大致功能图。

其实我们把三块支付、记账、产品通道都交给统一支付去实现。这个支付模式和我们后面讲的支付订单模式会有关系。支付概念的变化是我们这次做中台一个比较大的特点。

6、交易中心

交易中心原来在银行基本不怎么提到，交易中心主要解决的问题有：

那基于刚才那几个问题，我们在建中台提到一个订单的概念，就相当于我们利用了一个电商的订单模型来去创建银行的一个交易过程，大家可以看到现在这个图，是我们交易中心里面的订单模型。

对于渠道系统来说，它每次发起一个产品购买行为，其实就是创建了一个订单，然后呢订单里面有的信息跟电商很类似，第一会有订单最基本的信息——订单日期、币种、总金额、执行参数等信息；第二个就是产品的交付清单信息——产品信息、购买数量、支付金额、扩展信息，这个交付清单可以放多个产品在里面；第三个的话就有费用调整清单，涉及到我在处理这张订单需要收费或者促销、优惠的调整，调整整体上要支付的金额，这个可以通过费用调整这块实现；最后就是对于这个订单通过什么样的支付工具去进行支付，比如通过I类户还是II类户，或者通过第三方的账户去支付。可以支持在订单里放进去多个支付工具，相当于多个支付方式来同时对一张订单进行支付。

这个就是一个订单的模型，跟电商的模型是非常类似的。

下面这个图是一个订单的处理过程：

一开始在渠道系统，我们会给客户创建一个订单，会包含刚才说的支付和交付的信息，然后走到一个支付流程。支付流程也是通过统一支付进行对应的支付动作。支付的内容其实可支持很多种类，比如说客户可以通过资金支付，也可以通过权益支付。比如说积分就是一种权益，代金券也是一种权益。甚至说客户可以通过持有的产品去支付订单。比如说客户手上有一个理财的产品，那他可以通过理财产品的份额去支付订单。当支付成功以后，就到了银行把资产交付给客户的过程。

那交付的话，其实跟刚才类似，像贷款类交易，银行就会把钱交付给客户；对于某些交易会产生权益的，银行就会把权益交付给客户；比如说产品购买，银行就会把钱交易给客户。其实大家可以看到支付和交付都是通过统一支付实现，这也是为什么我们刚才提支付中心时候提到三块：包括记账、产品、第三方支付，其实都统一放在统一支付，也是这个原因。通过统一支付支持的所有资产动账类型，可以保证我们整个模型的简单化。

同时对于订单模式，我们也做过了一些演练，其实订单模式在设计里面可以支持银行所有产品的处理，也包括一些特殊场景。

对于贷款类的交易，也可以通过订单模型去实现。像我们贷款的放款，这在我们这属于采购订单。那客户支付给银行的实际上是一笔负债，客户给银行支付的你可以理解为一笔借据，然后银行交付给客户的是资金，就把贷款的钱给到客户。还款情况就是刚好相反。

所以银行所有业务都可以基于这个订单模型去处理。

基于刚才我们讲到的六个中心，这个图就解释了我们为什么通过这6个中心能够让银行的一些产品都快速上线，然后能够降低我们开发的量。

最左边的渠道系统不会直接跟产品系统产生对接，渠道系统只要需要按照这里面的用户中心、产品中心、交易中心这三个中心进行一次标准的接口对接，对接完以后不需要再去改造。假设我们现在新建了一个产品系统，产品系统只要按照六个中心的标准接口，实现对应产品信息的同步，实现对应的交付接口，实现对应的核算功能，这时候这个产品系统就能嵌入我们的整个业务中台的体系里面。这时候渠道系统就可以原生的访问到这个产品的功能，实现对应的产品的销售和运营的管理。所以，整体上要上新一个新的产品特别快。

这个图算是业务中台的一个整体的描述。这里面最大的点就是可以看到，业务中台最重要是解决了渠道系统和产品系统解耦的问题。

我们再回顾一下最早时候提的中台的概念，中台通过运营模式变革、组织架构调整、IT架构重构等方式形成的企业级服务复用能力。在我们这次的业务中台建设里面，除了组织架构调整我们没有做以外，我们的运营模式也发生了一些变化。当然这个运营模式指的是IT层面对业务处理的运营模式。其次也做了一个IT方面架构的重构。所以在这个业务中台建设里面，我们其实是通过我们三个模型，货架模型、订单模型、支付模型，来实现渠道系统与产品系统的解耦，产品系统只需实现产品规则，无需处理支付；渠道系统无需改造；中台业务系统配置或轻量级改造支持新功能，就可以支持一个产品的新上线。这就是一个业务中台建设后的效果。

三、三湘实践经验分享

讲完中台的整体架构，接下来分享一下三湘银行在去年建设中台的大致经验和情况吧。

三湘去年的中台项目总共建了22个系统，但这22个系统不是全都是业务中台，实际上业务中台只占了其中的六个系统，其他系统包含渠道中台、数据中台以及公共服务这些系统。

整体的项目从去年的3月份开始启动，5月我们完成总体设计，6月完成招标工作，8月就完成了开发，9月完成测试和上线，10月份完成第二期，算是三湘银行历史以来最大的项目。这个项目建设了我们行的业务中台，虽然在项目里只占了6个系统，却是最核心的业务系统。另外项目也建设了我们行的数据中台、渠道中台和公共服务，同时我们也跟阿里合作部署了飞天私有云。这中间我们做了很多事情，整体投入相比大行来说不多，但是对于小的银行来说，这个投入算是特别大的。大家可以通过这个案例可以看到建设中台并不见得要花特别长的时间和周期，也不见得投入是特别大，同时也不见得一定说需要行方的人员充足情况下才能建。以外包的方式也可以去做一个相应的中台建设。

但是在这个中台建设的过程中，确实存在很多问题或者困难，是一步步克服过来的。我有一些经验可以跟大家分享一下：

1、发起中台建设项目

业务部门不会有动力去建设中台，通常都是由IT部门发起，那么IT部门要怎么去说服行里面去做中台的项目呢？当时我们做了几个事情：

第一，我们是联合了一些专业机构共同去开展评估工作。有句话说得好，“外来和尚好念经”，找专业机构可以让银行内部去信服我们的评估结果。如果是由行方人员评估，那么行里很可能会认为我们是出于做项目的目的而得出的结果。
第二，评估的过程中必须要进行高层和业务的访谈。在这个访谈的过程中，让高层和业务理解建中台能带来什么好处，建中台的理念是什么样的。
第三，报行里面去审批，像三湘当时是报了行办会、董事会汇报批准以后才开始建中台。

评估环节主要出的是两份报告：第一份报告就是一个应用架构现状评估。第二份就是应用架构整体的建设方案。这个整体的建设方案实际上就是中台的整体框架。

2、建立开发规范

在建中台的时候，会涉及到非常多的人，非常多的厂商。中台为了实行解耦，我们还分拆了很多的功能系统去建设。那对于这么大面积的改动，一定需要一些公共的开发规范来去限制大家。不能各做各的，不然很难去整合。在建中台的时候一定要规范先行。我们制定了好几个规范，而且特别严格去实行。

这些都要求整个中台建设过程中，所有人都必须严格执行规范，来保证我们系统建设不会出现偏差。

3、坚持自主设计、严守架构定位

这点对于城商行来说有一定的借鉴意义。

在建设中台的时候我们是一直坚持自主设计。虽然我们当时的人员并不多，但是所有的高阶设计都是我们行方自主完成的，并且是行方内部通过的。当然过程中也会和跟厂商的人员一起评审，不过最终所有的设计都是由行方的同事提出。

坚持自主完成高阶设计，包括功能设计（需求分析）、详细接口设计，并要求厂商严格按照设计进行实施。

厂商的产品可以拿进来，但必须严格执行由厂商适配我们的设计的要求，而不是我们根据厂商的产品来调整设计。这是银行在建中台必须明确的做法。如果把设计交给厂商，很容易出现厂商按照原生产品设计，最终出来的不是我们想要的效果。

同时在中台建设中一定要严守架构设计定位。严守架构设计中每个系统的功能定位，并按定位落地系统功能，当出现定位模糊的情况快速进行明确和调整。已经明确的定位不接受任何开发人员的挑战。不能因为某些开发人员或者厂商觉得这个定位不合理，我们就会为此放弃定位。

这么短时间能把中台建设起来，我觉得这两个坚持是很重要的，这样到最后系统整合测试的时候才不会出现那么多问题。

4、“架构并行，平滑过渡”

这点是为了说服业务的。在建业务中台过程中，当时我们没有停止任何的业务需求，科技部一边接常规的业务需求，一边在建新的业务中台。基于这种情况，要保证两种架构是能平滑过渡。为此提出了三点：

旁路架构：整体架构不阻断原有交易，而是在原架构基础上新增旁路架构，交易在两个架构上可以正常处理；
复用已有系统：尽量复用原有系统功能，原有系统按照中台标准新增接入接口，并保留原接口，兼容两套接口模式并行，无需进行数据迁移；
逐步迁移：按产品逐个分批进行业务迁移，降低整体迁移的风险，出现问题影响范围减少。

上面就是我在做业务中台时总结出来的关键经验，希望能给到大家一些参考。

职场常备的 TOP 20 AI 产品工具 (www.jeffjade.com)

Thu, 24 Sep 2020 00:00:00 CST

随着第四次工业革命的来临，人工智能（AI）已经从科幻逐步走入现实，成为人尽皆知的概念；智能支付、无人超市、AI 美图已然融入日常生活，更有 AI 写作，邮件智能助理等四处开花；除此之外，人工智能在 Web 应用这一块，也不遑多让：如智能网页设计排版，PPT 制作，音乐艺术，图片处理，应用配色，文字翻译等相关应用已在市场掀起波澜，层出不穷的设计让人叹为观止。这里整理了倾城之链所收录的，可为生活添彩的 10 余款 AI 产品工具，分享给有需要的朋友。

效率相关

Beautiful.ai Presentation Software - Basic to Beautiful in Minutes

Build better presentations with Beautiful.ai in minutes, not hours. Just think of an idea, choose a template, and work beautifully…and efficiently. Sign up now!

推荐语： Beautiful.ai是款超棒的 PPT 构建工具；你只要拥有一个想法，即可在众多实用模板中选择一个，即可分分钟生成漂亮且高质量的演示文稿；因为有 AI智能加持，你不需要手动调整任何参数。更为可贵的是，它除了能在线分享之外，还支持导出 PPTX、 PDF等格式，而且还是免费可用。如果你有想快速制作优质 PPT，那么 Beautiful.ai绝对是一众 PPT制作神器中的首选。

除了上述优秀特性， Beautiful.ai还有非常多值得提及的功能，譬如：它支持个性化的页面版式布局，可全局轻松更换页面元素样式，内置丰富的图片素材库，拥有比 SmartArt 更强悍的智能图形（其尺寸可随数据自动变化，十分贴心）…… 当然，也会有些局限，诸如其导出的 PPTX，每页是基于所生成的图片，不能修改等。 ── 出自倾城之链 | Beautiful.ai Presentation Software - Basic to Beautiful in Minutes。

Tara AI | Simple sprint management designed for modern teamsMenu

关键字：sprint, agile, project management

The smart and free Jira alternative, designed to help teams move faster in product development. Brilliantly simple, with zero setup required.

推荐语： Tara AI，专为效率而打造、智能且免费的 Jira替代产品，旨在帮助团队加快产品开发速度它的；使命是帮助团队以可见性和可预测性制定计划。使用非常简单，无需任何配置。通过将 Git 连接到任务和 sprint， Tara AI帮助团队中的每个人，在从工程到销售的整个发布周期中保持清晰。

值得一提的是， Tara AI通过使用机器学习模型，实现更高效的开发方式，打造业界首个全面的自动化产品管理平台，从而将帮助企业预测如何最好地构建软件，整个开发流程将花费多长时间，以及该使用哪些技术来完成开发。── 出自倾城之链 | Tara AI | Simple sprint management designed for modern teamsMenu。

翻译相关

DeepL Translator

Use the free DeepL Translator to translate your texts with the best machine translation available, powered by DeepL’s world-leading neural network technology. Currently supported languages are English, German, French, Spanish, Portuguese, Italian, Dutch, Polish, Russian, Japanese, and Chinese.

推荐语： DeepL Translator是一个新颖好用的翻译神器；它不仅支持在线版本，也支持 Windows 版本。其主要的特点是翻译出来的内容接近真人语义，并且读起来准确通顺，非常自然；它通过训练人工智能来翻译文本，并且尝试添加特殊的语言细微差别和表达方式，不只是局限于字面翻译，从而拥有极其出色的翻译效果；除此之外，还可以用于学术翻译，效果也是非常出色。目前， DeepL Translator支持的语言包括：中文、英语、法语、德语、西班牙语、葡萄牙语、意大利语、荷兰语、波兰语、俄语、日语。

它不仅支持在线翻译文本，也支持在线翻译文档；所支持在线翻译的文件类型包括：Word 和 PPT ，但是它的在线文档翻译功能并不是完全免费的。DeepL，一款优于谷歌（Google）、微软（Microsoft）和脸书（Facebook）的在线翻译器，如果你有相关需求，尝试使用 DeepL Translator将是一个很不错的选择。── 出自倾城之链 | DeepL Translator。

视频相关

Synthesia - AI video generation platform

Synthesia CREATE enables you to make AI videos by simply typing in text. Generate engaging video content without the need for actors, film crews and studios.

推荐语： Synthesia) 工具，可以创建引人入胜的视频内容，而无需演员、电影摄制组和电影制片厂。您需要做的就是输入一段文字即可；它支持近 40 种不同语言来制作视频，从而消除语言障碍，并利用本地视频内容吸引当地市场和部门。基于 Synthesia企业现在可以大规模地制作专业的视频。企业正在将其用于：️企业学习与沟通、️个性化销售和客户成功视频、️电子商务产品视频、电子学习等。

您可以使用它免费生成带有水印的样例（内容长度也有限制，如之前基于 Synthesia 制作的 NICE LINKS 介绍视频），但专业版本需要付费。── 出自倾城之链 | Synthesia - AI video generation platform。

Remove Video Background – Unscreen

Remove the background of any video - 100% automatically, online & free! Goodbye Greenscreen. Hello Unscreen.

推荐语： Unscreen是一个 在线免费的扣视频背景神器，它支持 mp4、 gif、 .mov、 .webm、 .ogg等格式，上传视频或 GIF 自动去除背景保留主体。使用及其简单，如果您有类似需求，不妨试试这款。值得一提的是，这也是 remove bg公司的产品，他们以“使个人和企业，能够使用面向未来的产品，简化其工作流程“作为使命，创造了很多智能化产品，值得关注。 ── 出自倾城之链 | Remove Video Background – Unscreen。

音乐相关

AIVA - The AI composing emotional soundtrack music

关键字：Alva,AI,人工智能,音乐,算法,深度学习,强化学习,神经网络,创造性艺术

Compose emotional soundtrack music with AI. Use AIVA to supercharge your creative abilities, by having access to an endless supply of personalized themes.

推荐语： Alva(人工智能虚拟艺术家)一个新的AI可以写出音乐和人类作曲家，构成情感原声音乐的人工智能； Aiva Technologies是 AI音乐创作领域的领先创业公司之一，他们教会 Alva如何创作古典音乐：一种通常被认为是独特的人类品质的情感艺术。 Alva的音乐作品被用作电影导演，广告代理商甚至游戏工作室的配乐。

Alva背后的技术基于使用强化学习技术的深度学习算法。深度学习是一种特殊类型的机器学习，其中多层“神经网络”被编程为在各种输入和输出点之间处理信息。虽然只是松散地基于人类大脑的神经结构，但有助于以这种方式来思考它。这允许 AI 理解和模拟数据中的高级抽象，例如旋律中的模式或人脸中的特征。另一方面，强化学习是一种机器学习技术，它教授软件代理（AI）决定接下来采取什么行动，以通过最大化其“累积奖励”来达到某些目标。与监督学习不同，强化学习不会要求标记输入和输出数据。这允许 AI 围绕数据“找到自己的方式”并在不给出任何明确指令的情况下改善其性能，这使得更容易捕获像音乐这样的创造性艺术中发现的多样性和变化。 ── 出自倾城之链 | AIVA - The AI composing emotional soundtrack music。

图片相关

Remove Background from Image – remove.bg

Remove Image Background: 100% automatically – in 5 seconds – without a single click

推荐语： remove.bg是一款相当厉害的在线抠图工具，完全免费且过程全自动，只需五秒钟就能完美去除背景。 remove.bg通过时下相当热门的 AI技术，训练出足以分辨前景（人物）和背景的工具，让机器实现快速去除背景，只留下前景中的人物，不用进行任何操作。对于图片来源，可以是本地上传，或者提供在线图片地址；但需要注意⚠️的是需要有一个人在照片中（目前还不支持处理动漫人物）。── 出自倾城之链 | Remove Background from Image – remove.bg。

Automatically Remove Background from image-slazzer.com

Use slazzer.com Online background removal tool & create transparent backgrounds automatically in just few seconds without a single click - Try it for Free

推荐语： Slazzer： 基于 AI技术，可以在短短几秒钟内自动删除图像背景，只需要 5 秒钟，即可实现 一键抠图去除背景，同时 Slazzer也在不断的根据 AI技术进行自我改进，目的为了不断的提升准确率。如果您有这方面的诉求，推荐使用。── 出自倾城之链 | Automatically Remove Background from image-slazzer.com。

Bigjpg - AI Super-Resolution Image lossless enlarging / upscaling tool using waifu2x Deep Convolutional Neural Networks

关键字：bigjpg, waifu, waifu2x, waifu2x, miku, CNN, image enlarge, image enlarge, fangda, waifu github, upscaling, Image Super-Resolution Using Deep Convolutional Networks, Chao Dong, Chen Change Loy, Kaiming He, Xiaoou Tang, Anime-style art, without losing quality, PhotoZoom pro, photoshop cc, image enhance, image enhance

Bigjpg - Image Super-Resolution for Anime-style artworks using the opensource waifu2x Deep Convolutional Neural Networks without quality loss. Photos are also supported.

推荐语： Bigjpg是一个可以无损放大图片的网站；它使用最新 人工智能深度学习技术，通过神经网络，针对放大图片的线条、颜色、网点等特点，做特殊的算法调整，实现图片的无损放大。它会将噪点和锯齿的部分进行补充，放大效果非常出色, 色彩保留较好, 图片边缘也不会有毛刺和重影，更重要的是，影响画质的噪点基本在放大的图片上看不出来。

处理图片类型，它针对动漫、插画图片的放大，几乎可以说是完美的；将小图片放大后，无论是色彩、细节、边缘，效果都很出色；同时也兼容普通的照片放大。目前可以上传 3000x3000 分辨率、10MB 以下的图片。如果您有放大、清晰图片的诉求，那么这款工具，你绝对值得拥有；关于更多详情可参见 Bigjpg | 常见问题。── 出自倾城之链 | Bigjpg - AI Super-Resolution Image lossless enlarging / upscaling tool using waifu2x Deep Convolutional Neural Networks。

PickPik - Beautiful Royalty-Free Photos Sorted By AI

关键字：free Images, free stock photos, PickPik, hd images, high resolution photos, royalty free, free for commercial use

All images in PickPik are free for commercial and personal use, we developed an intelligent AI to rate every photo’s aesthetic score, and searching results are ranked by aesthetic score

推荐语： PickPik是一个由 AI智能分类的无版权图片分享网站，为了获得更好的搜索结果，该网站中的每张照片都是手动命名，并且该团队还开发了一个智能 AI神经网络来对每张招聘进行美学评分，只有评分最高的图片才会在搜索中展示。该网站上的所有图片几乎都可以用于任何商业设计项目，包括网页设计、应用程序设计、Wordpress 主题、PSD 和 HTML 模版等，博主和社交媒体团队都可以免费使用这些图片。

── 出自倾城之链 | PickPik - Beautiful Royalty-Free Photos Sorted By AI。

配色相关

Khroma - The AI color tool for designers

Khroma is the fastest way to generate, discover, search, and save color combos and palettes you’ll want to use.

推荐语： Khroma是一个设计师的 AI 在线颜色工具，能够让你发现，搜索和保存您喜爱的颜色组合。它利用人工智能，通过分析你选择的颜色，来生成实用性非常高的调色板的配色工具。甚至可以实现更高精度的组合，可以说是能够 「成长」的配色工具。有了这个工具，你就可以在短短几分钟之内，完成一个非常时尚的配色方案。── 出自倾城之链 | Khroma - The AI color tool for designers。

搜索相关

夸克官网更好的搜索智能免广告

关键字：夸克, 夸克智能搜索, 夸克智能搜索官网

夸克，是追求极速智能搜索的先行者，为用户的信息获取提供极速精准的搜索体验。搜索，就该更好的！

推荐语： 夸克是阿里巴巴旗下的智能搜索 APP（据悉是 UC 浏览器团队出品），搭载极速 AI引擎；目前只有移动端，没有电脑版本。据官方叙述有以下特点：

极速极简：毫秒启动，网页瞬间呈现，无信息流、无推送、拒绝打扰；
AI 高考服务：智能诊断志愿表，智能分析录取概率，选对大学更要选对专业；
AI 引擎：智能预测，问题问一半就已出答案高效的搜索结果呈现，部分问题唯一答案精准命中；
AI 识图搜索：自动扫描识别花草、宠物狗等，点击搜索框相机即可体验；
AI 应用：拍照搜题目，各种学习问题一键解决，利用好小工具，做学霸也不难；
生活小捷径：首页第一的导航位，查天气、读小说，看新闻、学知识走捷径，不让你多一步麻烦；
夸克宝宝：能聊能撩的AI朋友，帮你查询百科、知识问答、天气、汇率、新闻等；

整体使用来看，搜索功能跟 某度差不多，精准度不高，收录词条不足，厚权重而轻原创，与谷歌相去甚远；不过看起来很是 干净清爽，同时提供非常多实用功能以及很多 AI 应用；值得一提的是，它提 供隐私保护（无痕模式下不保存浏览记录、缓存和 Cookie）、 超强去广告功能（万条过滤规则，屏蔽大部分站点广告，同时支持手动标记屏蔽广告）、以及 视频模式（夸克视频播放器可进行倍速调整、云收藏、快进/退10秒等操作）。如果您受够了其他浏览器花里胡哨的各种广告，这款浏览器值得尝试。── 出自倾城之链 | 夸克官网更好的搜索智能免广告。

Magi

关键字：Magi, Peak Labs, Search Engine, Knowledge Engine, Information Extraction, AI, Artificial Intelligence, 搜索引擎, 人工智能, 知识引擎

用 AI 梳理互联网的知识引擎 - Magi 通过机器学习将互联网上的海量信息构建成可解析、可检索、可溯源的结构化知识体系。

推荐语： Magi是由 Peak Labs研发的基于机器学习的信息抽取和检索系统，它能将任何领域的自然语言文本中的知识提取成结构化的数据，通过终身学习持续聚合和纠错，进而为人类用户和其他人工智能提供 可解析、 可检索、 可溯源的知识体系。

Magi能做什么? 它与搜索引擎不同， Magi不仅收录互联网上的海量文本，还会去尝试理解并学习这些文本中蕴含的知识和数据。不妨在 magi.com（使用帮助）尝试搜索一些您关心的事物，或者直接提出问题，Magi 都将竭力为您提供高度聚合的结构化知识结果。

Magi蕴含一套从零研发的互联网搜索引擎，所以 magi.com同时提供 全网规模的普通搜索结果。因此，即使不巧没有结构化结果，您也不会白来。

值得一提的是，上述的学习过程是在无人干预的情况下 7 x 24 小时不间断运行的，实时新闻事件中的知识一般只需要 5 分钟就会被掌握。随着可 交叉验证的信息源不断增加，先前学习到的知识的可信度会被重新评估，使结果中的错误被自动纠正。

作为公众版本的 magi.com为人类用户提供了与互联网数据交互的新方式，而 Magi 系统背后的技术平台则承载着另一半重要的意义： 让机器像人一样能理解并充分利用互联网中无穷无尽的知识。如果想了解关于 Magi更多内容，请参见：欢迎使用 Magi。 ── 出自倾城之链 | Magi。

历史图谱

全历史

关键字：历史, 全历史, 知识图谱, 时空化, 关联化数据, 数字人文, 社科, 历史人物, 历史事件

全历史(Allhistory）以AI知识图谱为核心引擎，通过高度时空化、关联化数据的方式构造及展现数字人文内容，尤其是历史知识。让用户沉浸在纵横开阔、左图右史的（历史、人文、社科等）知识海洋中。

推荐语： 全历史(Allhistory)以 AI知识图谱为核心引擎，通过高度时空化、关联化数据的方式构造及展现数字人文内容，尤其是 历史知识。网站有将内容划分为：全画作、全古籍、全帝国、全人物、全战争、全古迹等模块（在其专属应用 APP 上，还设有历史地图、关系图谱、古典音乐、国家简史、疆域变迁等、AB 路径等），并且将整个宇宙的时间压缩在了一根轴上，使得用户可以拖动滚动条，即能看到这根轴上发生的大事件。网站提供了聚类、综合、模块等搜索功能，使得您可以轻便的查看所想知道的事物；当然，网站也允许您注册账号，亲自参与编辑，增加条目等。对于如何 快捷了解历史，这实在是不可多得工具网站，如果您对历史感兴趣， 实可典藏。

对于该网站所提供的功能，有必要举一例加以说明；比如您想对唐伯虎增加了解，即可在搜索框输入 唐伯虎，即可查阅其个人简介、生命主要历程（时间地图、时间线）、关系图谱（朋友、师从、归属、成就、影响等等）、作品（60 余画作且没有水印）及贡献、以及差不多同时期，世界上相同领域（画家 & 文学）的名家….. 一番查阅下来，相信你也会感叹：这网站简直不能再强大。── 出自倾城之链 | 全历史。

「倾城」，所收录内容，涵盖有技术、产品、工具、社区、旅行、美图、历史、人文、娱乐等诸多方向；欲更多了解更多优质网站，可移步至 「倾城之链」，或是先前分享的文章：

鉴于篇幅考虑，这里就先分享这些；如果您有相关诉求，推荐关注 倾城之链小程序或 网站应用，更多价值工具，有待您前去发现 & 使用。如果您想了解关于倾城之链更多讯息，请移步至官网查看。

订单系统：从0到1设计思路 | 人人都是产品经理

Thu, 27 Aug 2020 22:58:16 CST

文章主要跟大家分享在订单系统承载的角色，以及梳理了主要功能的设计思路，一起来文中看看~

概述

本文主要讲述了在传统电商企业中，订单系统应承载的角色，就订单系统所包含的主要功能模块梳理了设计思路，并对订单系统未来的发展做了一些思考。

1. 订单系统在企业中的角色

在搭建企业订单系统之前，需要先梳理企业整体业务系统之间的关系和订单系统上下游关系，只有划分清业务系统边界，才能确定订单系统的职责与功能，进而保证各系统之间高效简洁的工作。

2. 订单系统与各业务系统的关系

（1）对外系统：

所有给企业外部用户使用的系统都在这一层，包括官网、普通用户使用的C端，还包括给商户使用的商家后台和在各个销售渠道进行分销的系统，比如与银行信用卡中心合作、微信合作在合作商的平台露出本企业的产品。这类系统站在与客户接触的最前线，是公司实现商业模式的桥头堡。

（2）管理中后台：

每个C端的业务形态都会有一个对应的系统模块，如负责管理平台交易的订单系统，管理优惠信息的促销系统，管理平台所有产品的产品系统，以及管理所有对外系统显示内容的内容系统等。

（3）公共服务系统：

随着企业的发展，信息化建设到达一定程度后，企业需要将通用功能服务化、平台化，以保证应用架构的合理性，提升服务效率。这类系统主要给其他应用系统提供基础服务能力支持。

3. 订单系统上下游关系

由此可见，订单系统对上接收用户信息，将用户信息转化为产品订单，同时管理并跟踪订单信息和数据，承载了公司整个交易线的重要对客环节。对下则衔接产品系统、促销系统、仓储系统、会员系统、支付系统等，对整个电商平台起着承上启下的作用。

5. 订单系统的业务架构

（1）订单服务

该模块的主要功能是用户日常使用的服务和页面，主要有订单列表、订单详情、在线下单等，还包括为公共业务模块提供的多维度订单数据服务。

（2）订单逻辑

订单系统的核心，起着至关重要的作用，在订单系统负责管理订单创建、订单支付、订单生产、订单确认、订单完成、取消订单等订单流程。还涉及到复杂的订单状态规则、订单金额计算规则以及增减库存规则等。在4节核心功能设计中会重点来说。

（3）底层服务

信息化建设达到一定程度的企业，一般会将公司公共服务模块化，比如：产品，会构建对应的产品系统，代码、数据库，接口等相对独立。但是，这也带来了一个问题，比如：订单创建的场景下需要获取的信息分散在各个系统。

如果需要从各个公共服务系统调用：一是会花费大量时间，二是代码的维护成本非常高。因此，订单系统接入所需的公共服务模块接口，在订单系统即可完成对接公共系统的服务。

订单系统核心功能

1. 订单中所包含的内容信息

为了使订单系统能够对订单进行高效、精准的管理和跟踪，订单会储存关于产品、优惠、用户、支付信息等一系列的订单实时数据，来和下游系统，如：促销、仓储、物流进行交互。

以一个通用B2C商城的订单为例，梳理其包含的信息如下：

这里要注意的是订单类型，随着平台业务的不断发展，品类丰富、交易方式丰富后，需要对订单进行多维度的分类管理，同时订单类型利于订单系统的扩展性。每种订单类型将会对应一套流程及一套状态，便于对订单进行分类管理和复用。

2. 流程引擎

流程是指从平台角度出发，将订单从创建到完成的整个流转过程进行抽象，从而行程了一套标准流程规则。而不同的产品类型或交易类型在系统中的流程会千差万别，因此为了方便对订单流程进行管理，会组建流程引擎模块。

每套订单流程中会包含正向流程及逆向流程，正向流程可以比作一次顺利的网购体验过程中，后台系统之间的信息流转。逆向流程则是修改订单、取消订单、退款、退货等各种动作引起的后台系统流程，同时每个流程触发的条件又可分为系统触发和人工触发两种场景。

（1）正向流程

以一个通用B2C商城的订单系统为例，根据其实际业务场景，其订单流程可抽象为5大步骤： 订单创建>订单支付>订单生产>订单确认>订单完成。

而每个步骤的背后，订单是如何在多系统之间交互流转的，可概括如下图：

订单创建：

用户下单后，系统需要生成订单，此时需要先获取下单中涉及的商品信息，然后获取该商品所涉及到的优惠信息，如果商品不参与优惠信息，则无此环节。

接着获取该账户的会员权益，这里要注意的是：优惠信息与会员权益的区别，比如：商品满减是优惠信息，SUPER会员全场9.8折指的是会员权益，一个是针对商品，另一个是针对账户。其次就是优惠活动的叠加规则和优先级规则等。

增减库存规则是指订单中的商品，何时从仓储系统中对相应商品库存进行扣除，目前主流有两种方式：

下单减库存——即用户下单成功时减少库存数量

优势：用户体验友好，系统逻辑简洁；
缺点：会导致恶意下单或下单后却不买，使得真正有需求的用户无法购买，影响真实销量；

解决办法：

设置订单有效时间，若订单创建成功N分钟不付款，则订单取消，库存回滚；
限购，用各种条件来限制买家的购买件数，比如一个账号、一个ip，只能买一件；
风控，从技术角度进行判断，屏蔽恶意账号，禁止恶意账号购买。

付款减库存——即用户支付完成并反馈给平台后再减少库存数量

优势：减少无效订单带来的资源损耗；
缺点：因第三方支付返回结果存在时差，同一时间多个用户同时付款成功，会导致下单数目超过库存，商家库存不足容易引发断货和投诉，成本增加。

解决办法：

付款前再次校验库存，如确认订单要付款时再验证一次，并友好提示用户库存不足；
增加提示信息：在商品详情页，订单步骤页面提示不及时付款，不能保证有库存等。

综上所述，两种方式各有优缺点，因此，需结合实际场景进行考虑，如：秒杀、抢购、促销活动等，可使用下单减库存的方式。而对于产品库存量大，并发流量没有那么强的产品使用付款减库存的方式。

将两种方式带入到销售场景中，关联商品类型、促销类型、供需关系等，灵活使用，以充分发挥计算机系统的优势。

订单支付：

用户支付完订单后，需要获取订单的支付信息，包括支付流水号、支付时间等。支付完订单接着就是等商家发货，但在发货过程中，根据平台业务模式的不同，可能会涉及到订单的拆分。

订单拆分一般分两种：

一种是用户挑选的商品来自于不同渠道（自营与商家，商家与商家）；
另一种是在SKU层面上拆分订单：不同仓库，不同运输要求的SKU，包裹重量体积限制等因素需要将订单拆分。

订单拆分也是一个相对独立的模块，这里就不详细描述了。

订单生产：订单生产，是指产品从企业到用户这一流程的概述。如电商平台中，商家发货过程已有一个标准化的流程，订单内容会发送到仓库，仓库对商品进行打单、拣货、包装、交接快递进行配送。

订单确认：收到货后，订单系统需要在快递被签收后提醒用户对商品做评价。这里要注意，确认收到货不代表交易成功，相反是售后服务的开始。

订单完成：订单完成是指在收到货X天的状态，此时订单不在售后的支持时间范围内。到此，一个订单的正向流程就算走完了。

（2）逆向流程

上面说到逆向流程是各种修改订单、取消订单、退款、退货等操作，需要梳理清楚这些流程与正向流程的关系，才能理清订单系统完整的订单流程。

订单修改：可梳理订单内信息，根据信息关联程度及业务诉求，设定订单的可修改范围是什么，比如：客户下单后，想修改收货人地址及电话。此时只需对相应数据进行更新即可。

订单取消：用户提交订单后没有进行支付操作，此时用户原则上属于取消订单，因为还未付款，则比较简单，只需要将原本提交订单时扣减的库存补回，促销优惠中使用的优惠券，权益等视平台规则，进行相应补回。

退款：用户支付成功后，客户发出退款的诉求后，需商户进行退款审核，双方达成一致后，系统应以退款单的形式完成退款，关联原订单数据。因商品无变化，所以不许考虑与库存系统的交互，仅需考虑促销系统及支付系统交互即可。

退货：用户支付成功后，客户发出退货的诉求后，需商户进行退款审核，双方达成一致后，需对库存系统进行补回，支付系统、促销系统以退款单形式完成退款。最后，在退款/退货流程中，需结合平台业务场景，考虑优惠分摊的逻辑，在发生退款/退货时，优惠该如何退回的处理规则和流程。

（3）状态机

状态机是管理订单状态逻辑的工具。状态机可归纳为3个要素，即现态、动作、次态。

现态：是指当前所处的状态。
动作：动作执行完毕后，可以迁移到新的状态，也可以仍旧保持原状态。
次态：动作满足后要迁往的新状态，“次态”是相对于“现态”而言的，“次态”一旦被激活，就转变成新的“现态”了。

状态机的设计需要结合平台实际业务场景，将状态间的切换细化成了执行了某个动作。

以一个B2C商城的订单系统举例如下：

订单系统为了高效的对订单进行跟踪和管理，会对订单流程当中的关键节点，抽象出订单状态。而订单状态从不同用户的角度可分为，系统订单状态、商家订单状态、买家订单状态等。

对于订单系统来说，订单状态细分的颗粒度越细、越明确，订单系统管理的精度和可靠性就越高，比如：在待付款和待发货两个状态中，订单系统后台会细分为订单超时取消、订单支付失败、订单付款完成等。

因此，订单状态模块中，通常会维护状态映射表，以不同的用户角色对系统订单状态进行重新划分，以满足不同用户的需求。

除此以外，随着电商平台的不断发展，不同的业务类型，所对应的订单状态都会有所区别。所以，订单系统中一般会储存多套状态机，以满足不同的订单类型来使用。

订单系统的发展

订单系统的主体框架，和主要业务模块已基本讲完，那么随着企业的发展，业务量和业务形式不断变化，企业有可能形成多个订单系统并存以满足不同的业务需要的情况。

业务系统架构如下：

这种状况的出现，将会给平台带来非常大的发展瓶颈，如：

三个订单系统，每个订单系统处理不同类型的订单，没有统一的订单销量、订单状态信息，网站前台对订单的状态展示与控制不统一，只能是在网站前台会员中心硬代码维护一套面向会员的统一订单明细与状态数据。而无线侧上线后，由于不了解前台网站会员中心的订单状态管理逻辑，所以需要把前台网站的订单明细及状态管理再在无线应用侧再实现一遍。

三套后台订单系统与公共业务系统如会员中心、支付与财务、促销工具、客户分单等系统都需要对接一遍，公共业务处理逻辑不统一，一旦逻辑变更多个系统统一个接口都要修改一遍，接口的重复维护开发工作量大。

订单开发目前分到事业部，各个事业部只会考虑自己的逻辑，不会考虑公共架构，只会越走越远。碰到像无线这样的项目，需要对接各个事业部，无线侧应用上线进展慢。

因此未来的订单系统可拆分为订单中心与业务订单系统两个模块，以管理公司所有订单数据，并为各个模块提供统一服务。

业务系统架构如下：

最后

对于企业订单系统的搭建，并不是要做的大而全、也不是要小而精。而需要结合市场、公司、业务的实际情况来最终制定系统设计方案和产品迭代计划。

最终，和公司整体发展相互协调，相辅相成。

本文由 http://www.woshipm.com/pd/1392102.html

微服务下产品集成和集成测试框架流程(200818）

Tue, 18 Aug 2020 18:48:04 CST

今天谈下微服务架构下的应用集成和集成测试方面的内容。在微服务架构下，由于传统的的单体应用以及拆分为多个微服务，那么原来单个系统内部的API接口调用以及变成了微服务间的外部接口调用，而且还可能已经由不同的开发团队在开发不同的微服务模块。

在这种情况下如果不能很好的进行产品应用集成和后续集成测试，那么会经常出现类似单元测试问题遗留到集成测试，端到端流程无法测试通过，测试用例和数据反复制作，集成过程中出现问题故障排查困难等诸多问题。

也正是这个原因，今天准备讲下产品集成和集成测试方面的内容，可以看到微服务下的产品集成和集成测试实际和传统组件化开发下的组件集成思路基本是一致的。当然在CMMI三级的时候我们有一个PI的过程域，该过程域也给出了产品集成的核心指导思路。

产品集成概述

大型软件产品开发一次可能开发多个新的业务系统，同时一个业务系统本身又包含多个业务模块和组件。只要在前期产品规划中存在子系统和模块的分解，那么后续就一定存在产品集成的动作。

在微服务架构设计下可以看到，我们通过传统单体应用的大拆小，形成了多个松耦合的微服务组件模块。一方面是通过分而治之降低大系统复杂度；另外一方面则是通过分解和接口定义后各模块可以并行开发。

只要架构阶段存在微服务模块拆分动作，那么最终在各模块开发完成后一定存在集成动作。

架构做出一个假设，只要在分解的时候各组件模块按预定的接口契约进行实现，那么后续各个组件一定可以进行集成和组装形成一个完整的产品。所以架构不能仅仅只关心解耦，还必须关心集成和装配。解耦后的东西无法集成，那么分解过程仍然是失败的。

在新的平台+应用，微服务+容器云平台下应用集成可以看到比常规的产品集成更加复杂，对于一个业务应用或组件首先是要考虑和平台层类似消息，缓存等技术服务能力的集成，其次才是考虑组件之间的进一步横向集成。

在这种场景下本身对应用集成的方案，策略和执行等都提出了更高的要求。

应用集成的内容

对于应用集成的内容主要分为三个方面的内容。

其一：单个微服务模块和平台层能力的持续集成和发布

对于单个微服务模块的持续集成，首先是编写好自动化编译脚本代码，如使用ant工具完成，然后设置定时作业和任务，开发人员按时check in相关代码。使用CI持续集成工具根据定时任务点在构建环境自动获取最新代码，自动运行ant自动化编译脚本对代码进行编译，编译完成后自动化部署到某个环境。部署完成后运行单元测试自动化脚本对代码进行自动化测试，输出自动化测试结果和报告；如果通过的话测试人员通过QTP进行进一步自动化测试或手工执行一遍冒烟测试脚本，完成本次持续集成。

在持续集成模式下，一方面是可以尽可能早的发现问题，一方面对测试人员随时都可以有一个可进行详细功能性测试的可用环境；其次如果对于多环境，涉及到开发环境测试通过后自动部署集成测试环境，集成测试环境测试通过后自动部署到验收环境等一系列动作。对此我们叫部署流水线模式，实现跨环境的持续集成管理。

其二：微服务两两之间上下游通过API接口服务间的服务集成

对于微服务两两间的横向集成主要是通过微服务提供的API接口服务集成，因此一方面是微服务需要和自身需要消费的提供业务服务能力的上游微服务组件集成获取输入信息和输出；一方面微服务本身也提供相应的API接口服务，需要配合下游的微服务组件进行服务集成和联调。

对于该步骤的集成重点是保证组件上下游之间能够集成通过，业务和数据能够正常流转，其集成的主要依据是组件概要设计中的服务接口设计进行。

其三：基于端到端业务场景的跨多个微服务之间的集成

在微服务两两集成通过后，接着的关键步骤就是根据端到端的业务场景进行跨多个业务组件的应用集成。确保端到端的业务流程能够在多个微服务模块协同下顺利完成。在这个阶段首先是需要保证组件两两集成通过，然后是依据相应的业务流程和业务架构文档，总体应用架构设计文档分析相应的业务场景，准备相应的业务数据进行。

在整个应用集成过程中，微服务间的集成顺序和集成场景是需要重点考虑的问题。

应用集成顺序

应用集成顺序分为两种模式：

一种是自顶向下的模式进行集成

对于自顶向下方式的集成，首先集成最外层或流程最末端的业务模块，业务模块前置依赖用模拟器(桩)实现。然后继续在每一层按宽度或深度优先，用完全实现模块代替模拟器，并建立下层。以这种方式继续直到所有被测系统中的桩已经实现和测试。在这种模式下可以看到整个集成过程完全是顶层需求驱动进行，集成工作可以较早的开始进行，如果产品集成图是正金字塔结构较容易，模拟器开发较少；反之同理。

一种是自底向上的方式进行集成

对于自底向上集成，首先集成最底层的业务模块，只在底层模块未实现前使用模拟器(桩)。然后继续在实现并测试对上一级模块，这些构件使用已经测试的下级模块。整个系统使用根一级模块测试。对于这种模式模拟器开发较少，同时上次各模块基本可以开始并行测试。这种集成方式最大的风险是如果上次需求变化可能直接影响到最底层。

应用集成的场景

集成场景分析目的是为后续的集成测试用例设计提供依据，集成测试用例要覆盖所有场景。对于场景分析输入主要包括跨模块协同业务流程图、系统需求规格说明书、概要设计说明书等。

对于集成场景分析可以从静态和动态两个层面进行分析：对于静态分析主要分析模块依赖关系，分析某一个服务接口影响到的业务模块具体功能点，可以模块-》模块的矩阵分析方法进行；对于动态分析主要是根据跨系统或模块流程入手，分析跨模块的流程协同，流程协同中所涉及到的所有接口服务。

集成场景的分析将为集成测试用例的设计提供核心输入，要明白，集成测试不是简单的接口测试，接口反映的是跨系统或模块的交互流程，需要通过交互流程的贯通来检验接口本身的正确性。

产品集成和持续集成的关系

产品集成强调是的是把左右的组件最终能够组装和集成起来，形成一个完整的系统。

Martin Fowler对持续集成是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译、发布、自动化测试)来验证，从而尽快地发现集成错误。

许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。可见持续集成只能算做产品集成的一个子实践。

要明白持续集成只是产品集成的一种方式，不论是开发过程是瀑布模式、增量模式还是迭代模式，都可以采用持续集成的思路。要明白持续集成的一个核心是将整个开发过程透明化，同时将集成工作提前化。尽可能早的暴露问题和风险，同时纠正在前期系统分析和架构设计中的不足。

对于持续集成我们往往会强调每日构建、冒烟测试、自动化测试等内容。

强调开发、测试和生产环境的部署流水线作业。但是要明白对于大型产品集成仍然会包括模块内测试和集成、模块间测试和集成、跨系统间的测试和集成工作。对于单个模块内可以采用每日构建和持续集成策略，但是对于模块间和跨系统我们可以采取分迭代式的集成方式进行集成。

集成测试流程

集成测试是将模块按照设计要求组装起来同时进行测试，主要目标是发现与接口有关的问题。如数据穿过接口时可能丢失；一个模块与另一个模块可能有由于疏忽的问题而造成有害影响；把子功能组合起来可能不产生预期的主功能；个别看起来是可以接受的误差可能积累到不能接受的程度；全程数据结构可能有错误等。

对于集成测试阶段的流程可以参考上图，在验收测试阶段流程和该图类似不再说明。

从该图中可以看到作为集成测试的负责方在进行集成测试执行前需要制定集成测试计划，集成测试方案和策略并联同甲方信息化管理部门和开发厂商共同进行计划和方案的评审。在方案评审通过后再开始单个业务组件的集成测试用例的设计，业务组件间的接口和服务测试用例的设计工作。

开发厂商在开发验证环境自身的单元测试通过后将形成一个稳定的可用于集成测试的版本，在这个时候可以提交集成测试申请；而对于配置管理方来说则根据提交的集成测试申请进行待测试版本的提取，并将测试版本部署到集成测试环境，成功部署完成后通知集成测试负责方进行集成测试工作。

集成测试方根据设计好的功能测试用例和接口服务测试用例开始进行业务组件的功能测试和上下游的接口服务测试工作，确保单个业务组件功能正确，和上下游业务组件之间的衔接正确。在这里重点还是集成方案中的集成顺序分析。在集成测试执行完成后输出相应的集成测试结果，如果存在相应的缺陷则打回到开发商，开发商在进行缺陷修复和自测通过后再提交第二轮的集成测试。

在多轮集成测试缺陷全部关闭后，需要在集成测试环境再进行一次回归测试。当回归测试仍然通过后可以开始输出相应的集成测试评估报告并提交评审。在集成测试评估报告和开发商，验收测试商一起评审通过后该业务组件可以开始提交验收测试，并进入详细的验收测试流程。

集成方案和策略

可以以多种方式进行集成测试，而下面是三种常用的类别：

第一种方法是由上而下的集成测试方法

首先测试和集成最高级别的模块。这使高级别的逻辑和数据流可以在过程的早期阶段测试，有助于最大限度地减少对驱动程序的需求。但是，对存根 (stub) 的需求使测试管理变得复杂，低级别的实用工具在开发周期中相对较晚的阶段测试。由上而下的集成测试的另一个缺点是不能很好地支持有限功能的早期发布。

第二种方法是由下而上的方法要求

首先测试和集成最低级别的单元。这些单元常被称为实用工具模块。通过使用这种方法，使用工具模块在开发过程的早期阶段测试，最大限度地减少了对存根 (stub) 的需求。但是，不利的方面是对驱动程序的需求使测试管理变得复杂，高级别的逻辑和数据流在晚期测试。与由上而下的方法一样，由下而上的方法也不能很好地支持有限功能的早期发布。

第三种方法（有时也称为伞形方法）测试沿功能性数据和控制流路径进行

首先，函数的输入以上面讨论的由下而上的模式集成。然后，每个函数的输出以由上而下的方式集成。这种方法的主要优点是对有限功能的早期发布的支持程度。它也有助于最大限度地减少对存根 (stub) 和驱动程序的需求。但是，这种方法的潜在缺点非常明显，因为它的系统性可能比其他两种方法低，会导致对回归测试的更大需求。

由于自顶向下的测试方式需要建立大量的技术服务和业务服务模拟器，而且底层的需求变化会对上层的业务组件模块造成较大的影响。因此对于私有云PaaS平台中应用的集成测试最好的方式还是以自底向上的模式进行，在这个过程中为了保证测试工作的尽早开始和并行，可以对少量涉及到技术服务集成的场景采用自顶向下的方式进行集成。

在整个集成测试方案策略中重点是集成依赖关系和集成顺序的分析，具体如下：

在此图中可以看到，首先需要分析业务组件模块之间的相互依赖关系，每个模块涉及到的前置依赖模块，以及和依赖模块之间需要交互的业务服务接口。基于初步的模块依赖关系分析可以开始考虑业务模块的组装和集成顺序，在集成顺序的分析中可以根据依赖关系按正向和逆向两种方式进行集成测试顺序的分析和梳理。

对于正向分析来说则是当前业务模块测试完成后可以测试哪些下游的业务模块；而对于逆向分析来说则是当前模块的前置依赖模块是哪些；如果需要测试当前模块需要首先测试哪些上游的业务组件模块等。通过这两种方式的梳理基本可以形成一个大框架的组件集成流程图。但是由于业务模块集成本身的复杂性，以上的初步集成方案和策略分析还不足够，最好的方法还是需要进一步结合业务场景尽快跨模块的业务协同分析，具体如下：

结合该图，在集成场景分析中首先是选择需要集成的业务流程，分析该业务流程中的各个业务活动以及这些业务模块之间的交互和协同点。对于这些交互点需要详细的分析业务功能以及该业务功能涉及到的业务服务接口，将这些业务服务接口全部识别出来并进行测试设计和测试数据准备。

基于以上步骤后可以有针对性的对识别出来的业务流程进行跨模块的端到端测试，在这种测试模式下虽然无法保证所有业务模块间的接口全部测试覆盖到，但是可以保证关键的业务流程实现跨模块的业务协同和贯通。

集成测试执行和评估

对于集成测试执行设计到冒烟测试、业务组件模块的功能测试、业务组件间接口服务测试、性能测试、易用性测试等多方面的内容，具体可以参考业界标准的测试方法规范体系。对于在测试执行阶段可以简要描述如下：

在集成测试执行过程中需要有相应的缺陷管理工具和平台对缺陷进行统一的管理和跟踪。如果从更加全面的工程变更角度来说，则需要有完善的需求变更、缺陷管理、版本管理、测试流程管理、发布管理等一系列的研发过程管理工具平台提供支撑。

对于测试评估则是根据需求设计文档（系统需求，产品集成方案、集成设计文档等），描述经过测试后，哪些组件接口已经实现，哪些组件接口没有实现或存在什么问题，产品对应系统需求是否通过测试，测试执行是否覆盖到所有集成测试用例。同时需要对集成测试执行结果以及因测试不充分而引起的风险进行评估，说明对系统测试的影响。集成测试评估的主要输出包括了：

集成测试清单和测试结果；
集成测试覆盖率分析：接口覆盖率，功能覆盖率；
测试结果统计分析：Bug分析，集成次数和成功率，遗留Bug分析；
测试结果评估；
测试结论和后续改进建议。

集成测试的其它关键点说明

通过DevOps实施来实现整个持续集成过程的自动化

持续集成和集成测试还是有很大区别，持续集成强调的是自动化的编译构建，部署，自动化的冒烟测试，保证开发过程的产出随时都可以构建一个冒烟测试通过的可用版本。而集成测试则涉及到严格的测试策略，测试方案，集成测试顺序，各个集成功能点的覆盖，详细的功能性测试等。集成测试不仅仅是接口测试，更重要的是以接口质量为前提的跨组件功能性测试。

而对于DevOps最佳实践本身就包括了持续集成的过程。

持续集成不仅仅是实现了自动化的编译，打包和部署，自动化的单元测试。更加重要的是实现了环境之间的自动化迁移。

这个能力在我们整个产品集成中相当重要。

可视化的版本部署看板实现可追溯

在产品集成整体策略下，一个核心就是对于后续类似验收测试，生产环境等都是做环境迁移，而部署重新进行版本构建。只有这样才能够保证最终测试人员测试版本的一致性。

同时根据部署流水线方式，需要建立版本部署情况追溯表。比如上图，我们可以很清楚的看到当前在每一个环境各个微服务模块处于什么版本。

集成测试执行顺序

集成测试是整个测试里面的一个完整阶段，不仅仅是包括接口集成测试，而应该是包括了功能冒烟测试，接口测试，功能性测试，非功能性测试等完整内容，具体如下：

我一直认为这是集成测试中非常关键的一个内容，集成顺序的确定涉及到前期大量的组件间依赖关系分析，业务功能点和接口对应关系分析等。特别是发展到现在，我们发现很多时候组件间不再是以前单纯的单向依赖关系，由于接口服务注册在总线上，导致多个组件间可以相互依赖，所以前面简单的组件依赖分析已经不适用，替代的方法是基于跨组件的流程协同分析，以核心流程驱动组件间的组装顺序。

同时，对于传统的自顶向下集成和自底向上集成方法往往都不能完全覆盖。很多时候采用的都会是混合集成的策略。一个是为了及早的看到集成的效果我们期望从上向下，但是却需要大量的模拟器和stub桩模块。另外一个是为了减少模拟器，我们从最底层向上集成，但是往往却将风险延迟到最后发现。

腾讯产品项目流程的七个阶段

Tue, 12 May 2020 00:00:00 CST

“腾讯”是产品经理的黄埔军校。笔者有幸学习到腾讯产品经理对产品项目的流程管理，特此整理并结合实际工作经验分享给大家。

长话短说，腾讯产品项目的主题流程划分成了七个阶段，“概念阶段（CONCEPT）”、“提案阶段（PROPOSAL）”、“原型开发阶段（PROTOTYPE）”、“产品开发阶段（ALPHA）”、“内测阶段（CLOSE BETA）”、“正式运营阶段（OPERATION）”和“结项（CLOSE）”.

一、概念阶段（CONCEPT）

概念阶段主要由“专家评审组”和“概念提出人”共同参与。

概念提示人负责【概念提出】，交由专家评审组进行【概念评审】和【存入概念库】操作。

二、提案阶段（PROPOSAL）

提案阶段主要由“决策委员会”、“专家评审组”、“项目组”和“研发”共同参与。

由决策委员会组织【成立提案小组】，项目组和研发负责【准备提案评审材料】，材料交由专家评审组进行【提案专家评审】，通过专家评审后交由决策委员会进行【提案决策评审】。

未通过评审则提案PASS；待修订则打回至【准备提案评审材料】步骤；通过评审则进入下一阶段。

众所周知的是，“提案阶段”类似“需求调研阶段”。日常工作中，对于需求调研咱们会分成三个部分“行业调研”、“市场调研”和“竞品调研”。

1. 行业调研

行业调研：行业分析是指根据经济学原理，综合应用统计学、计量经济学等分析工具对行业经济的运行状况、产品生产、销售、消费、技术、行业竞争力、市场竞争格局、行业政策等行业要素进行深入的分析，从而发现行业运行的内在经济规律，进而进一步预测未来行业发展的趋势。

政策！政策！政策！没有亘古不变的行业，要时刻拥抱变化，顺势而为，做该做的事。

2. 市场调研

市场调研：市场调研常用手法有“定性研究”、“定量研究”、“技术观察”和“试验设计”四种。

专业的事尽量交由专业的人去做，可以有效规避企业在市场调研上所承受的风险。转移市场调研的风险，在国内有诸多知名机构可以选择，具体如下。

China Ceidea Market Research 策点市场调研公司
Acorn Marketing & Research Consultants 毅群市场研究咨询股份有限公司
上海伊霍珀信息科技股份有限公司
北京新数易博（EBMRS）信息咨询有限公司
华通明略（MillwardBrown ACSR）信息咨询有限公司
中机系（北京）信息技术研究院
中国商业数据中心
尼尔森市场研究中心
数字100市场研究公司
益普索（中国）市场研究咨询有限公司
凯度（中国）购物者指数（Kantar Worldpanel China）
上海AC尼尔森市场研究公司
盖洛普（中国）咨询有限公司
华南国际市场研究公司
百维数元信息科技（北京）有限公司
艾斯艾（北京）市场调查有限公司（SSI China）
欧睿（Euromonitor）市场调查机构

2. 竞品调研

竞品调研：主要是对导入期竞争对手的市场经营情况与策略进行深入的调研分析。 ^[1]

竞品分析一词最早源于经济学领域。市场营销和战略管理方面的竞品分析是指对现有的或潜在的竞争产品的优势和劣势进行评价。这个分析提供了制定产品战略的依据，将竞品分析获得的相关竞品特征整合到有效的产品战略制定、实施、监控和调整的框架当中来。

竞品分析包含了三部分内容：竞品、分析维度和分析准则。

（1）竞品选择

竞品选择的范围并不局限于具有直接竞争关系的产品，以iPad版即时通讯应用为例，除了QQ、MSN等产品以外，我们还需要选择一些国外的产品如IM+、AIM、IMO等优秀且受众群体较大的产品。

（2）分析维度

通常我们进行竞品分析，可能会从以下几个维度进行对比分析：战略定位、盈利模式、用户群体、产品功能、产品界面（交互方式、视觉表现）等。

竞品分析是每一个互联网从业人员都需要做的一项基本工作，不同的职能区分，侧重点会不一样。如运营人员可能更加侧重产品的战略定位、盈利模式、推广方式，产品策划人员更侧重于产品定位、目标用户、产品功能。交互设计师更侧重于产品界面、具体的交互形式。当然这些维度是有机联系的，断然不可以孤立对待。

（3）分析准则

拿交互设计的竞品分析来说，需要参照“可用性准则”来进行分析，可用性准则有很多不同版本，当前较为常用的10项可用性准则为：

一致性和标准性
通过有效的反馈信息提供显著的系统状态
方便快捷的使用
预防出错
协助用户认识，分析和改正错误
识别而不是回忆
符合用户的真实世界
用户自由控制权
美观，精简的设计
帮助和说明

三、原型开发阶段（PROTOTYPE）

原型开发阶段主要由“决策委员会”、“专家评审组”、“项目组”和“研发”共同参与。

决策委员会负责【成立原型小组】，交由对应的项目组和研发进行【原型版本制作】，完成制作后，交由专家评审组进行【原型专家评审】，通过专家评审后，交由决策委员会进行【立项决策评审】。

评审期间，立项决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入立项流程。

“原型开发阶段”对应咱们日常工作中的“需求澄清”和“需求设计”。

1. 需求澄清

需求澄清：通过具体的方法论，澄清需求本身，消除项目参与人员对需求的认知差异。

关键步骤

（1）需求池（Demand pool）

需求池（Demand pool）需求池将需求列成合同式的文件，最常见的方式是将需求列入一个合同式的表。

（2）功能需求点列表(Function List)

功能需求点列表(Function List) 在功能需求分析完成后。要详细列出用户需求功能点列表。

（3）用例图（use case diagram）

用例图（use case diagram）是用户与系统交互的最简表示形式，展现了用户和与他相关的用例之间的关系。通过用例图，人们可以获知系统不同种类的用户和用例。用例图也经常和其他图表配合使用。

尽管用例本身会涉及大量细节和各种可能性，用例图却能提纲挈领地让人了解系统概况。它为“系统做什么”提供了简化了的图形表示，因此被誉为“搭建系统的蓝图”。

由于其简单纯粹的本质，用例图是项目参与者间交流的好工具。用例图的画法是对现实世界的一种刻画，可以让项目参与者明白系统要做成什么样。箫庆龙等（Siau and Lee）曾研究是否存在用例图不适用或不必要的情景，结果发现用例图可以更简洁地传达系统的设计意图，“比类图诠释得更加完整”。

用例图的目的就是为了可以让人在一个更高的层次概览整个系统，用平白的话语让项目参与者理解系统。它可以辅以额外的图表和文档，以更加完整地展现系统的功能和技术细节。

（4）流程图（Flow Charts）

流程图（Flow Charts）是表示算法、工作流或流程的一种框图表示，它以不同类型的框代表不同种类的步骤，每两个步骤之间则以箭头连接。这种表示方法便于说明解决已知问题的方法。流程图在分析、设计、记录及操控许多领域的流程或程序都有广泛应用。

弄清楚用例图中的这些角色，在系统中每一步需要走什么流程，对应不同的判断状态进入怎样的子流程，是否支持逆向操作

（5）产品整体架构图

产品架构图暂无一个标准答案。这里我们借鉴软件架构的解释来参考：软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

图片来自CSDN社区-PMCAFF产品社区-一张图讲清楚产品架构

（6）产品信息结构图

产品信息架构图暂无一个标准答案。个人认为，产品信息结构图就是告诉研发有什么关键信息，同时给需求提出者自查的一份文档。

2. 需求设计

需求设计一般指的是设计是“原型文档”和“PRD文档”。

在日常的工作中，时间紧任务重的项目，通常在绘制原型图的时候，专门备注了对应的说明文档。这样做的目的是为了方便研发人员快速理解需求，跟上快速迭代的节奏。

四、产品开发阶段（ALPHA）

产品开发阶段主要由“决策委员会”、“专家评审组”、“项目组”、“研发”和“运营”共同参与。

①决策委员会负责【成立项目组】，交由对应的项目组和研发进行【PRE-ALPHA版本制作】，完成制作后，先自行进行【产品版本评审】，如有问题自行修订，再交由专家评审组进行【PRE-ALPHA专家评审】，通过专家评审后，交由决策委员会进行【PRE-ALPHA决策评审】，通过后交由运营准备【内部转产】。

②项目组和研发进行【ALPHA版本制作】，完成制作后，先自行进行【产品版本评审】，如有问题自行修订，再自行安排【内测规划及准备】，下一步再交由专家评审组进行【产品内测上线专家评审】，通过专家评审后，交由决策委员会进行【P产品内测上线决策评审】。

③项目组和研发进行【总体运营规划】，交由专家评审组进行【总体运营规划专家评审】，通过专家评审后，交由决策委员会进行【总体运营规划决策评审】，通过后研发和运营准备【封测上线发布】并收集【封测运营反馈】，用于矫正项目组和研发进行【ALPHA版本制作】。

评审期间，决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入内测阶段。

五、内测阶段（CLOSE BETA）

内测阶段主要由“决策委员会”、“专家评审组”、“项目组”、“研发”和“运营”共同参与。

①项目组和研发进行【版本制作】，完成制作后，先自行进行【产品版本评审】，如有问题自行修订，再自行安排【正式运营规划及准备】，下一步再交由专家评审组进行【正式运营上线专家评审】，通过专家评审后，交由决策委员会进行【正式运营上线决策评审】。

②运营负责【产品内测上线发布】、【内测运营服务】以及【内测运营反馈】。交由对应的项目组和研发佐证【版本制作】，通过后交由研发和项目组负责【正式运营规划及准备】。

评审期间，决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入正式运营阶段。

六、正式运营阶段（OPERATION）

正式运营阶段主要由“决策委员会”、“专家评审组”、“项目组”、“研发”和“运营”共同参与。

①项目组和研发进行【版本制作】，完成制作后，先自行进行【小版本评审】，再交由运营负责【正式运营上线发布】、【正式运营服务】以及【正式运营反馈】如有问题自行修订，再交由项目组和研发安排【运营结项计划和准备】，下一步再交由专家评审组进行【正式运营结束专家评审】，通过专家评审后，交由决策委员会进行【正式运营结束决策评审】，通过后交由运营负责【正式运营结项准备】，准备进入结项阶段。

②在【小版本评审】通过后，交由专家评审组进行【大版本评审】，通过后交由研发和项目组进行【版本制作】。

评审期间，决策评审未通过直接PASS，部分通过则继续开发；完全通过则进入正式运营阶段。

七、结项（CLOSE）

结项阶段主要由“运营”负责。

确认项目进入结项阶段后，交由运营负责【产品下线】，OVER。

结项是一个项目的尾声，难免有种飞鸟尽良弓藏的感觉，这是正常的。

一方面，有“柯达”这样相当优秀的企业，带着遗憾离场，他没做错啥，只是不被大家所需要。

另一方面，正是有数不清的产品被干掉，咱们产品的存在才被衬托得更有意义。那为什么不去拥抱变化，选择去创造更能经得住时间检验的产品！

尾记

产品经理他可以是一个改变世界的神，他也可以是一个普通人。

普通的人，专注好眼下的一件事，那他就是最棒的产品经理。你也可以，谢谢支持，共勉~

作者：木深；公众号：异世治人录

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

题图来自Unsplash，基于CC0协议