阿里云产品经理（阿里云产品经理待遇）

今天给各位分享阿里云产品经理的知识，其中也会对阿里云产品经理待遇进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

微信号：cloud7591
如需了解更多，欢迎添加客服微信咨询。
复制微信号

本文目录一览：

• 1、魔筷星选是什么
• 2、B端产品体验度量模型调研
• 3、小荷才露尖尖角（26）——云计算那些五花八门的工作岗位
• 4、阿里云IoT云产品交流会：物联网痛点多，阿里能做什么？
• 5、阿里云这次冤不冤？
• 6、阿里云售前架构师是产品经理吗

魔筷星选是什么

魔筷星选就是快手小店，也是所谓的小黄车，是方便用户在快手里面下单的一个商城入口。

杭州魔筷科技有限公司成立于2015年，创始人团队来自阿里系，是快手战略投资的企业，总部位于浙江杭州，是网红电商综合服务平台，致力于更好地链接、赋能和服务网红与供应商群体，并为消费者带来创新、优质的社交购物体验。

扩展资料：

代表人

1、王玉林

CEO王玉林，国内首批淘客、站长，原阿里巴巴技术专家、产品经理，负责淘宝店铺、生意参谋、手机淘宝等多款产品的设计，曾任唯一优品母婴电商公司副总裁，2015年创办魔筷科技。

2、曾章强

曾章强，联合创始人兼CTO，原阿里巴巴技术专家，曾供职于淘宝、阿里云，负责淘宝多媒体平台、淘宝CRM平台、图片空间和阿里云RDS平台等多个大型系统的设计与研发工作，2015年联合创办魔筷科技

参考资料来源：魔筷星选官网

B端产品体验度量模型调研

一、 前言

          作为一个B端产品的产品经理，我们会面临很多问题：复杂的产品需求、纠缠的技术逻辑、难以决策的设计方案、难以计量的产品迭代效果。而对于作为支撑平台的B端产品经理而言，提高效率和体验又常常作为评估价值的主要方向，故因此我们需要一套科学的体验度量体系来指导我们前进的方向：产品目标的确立、需求价值的评估、迭代效果的量化。

          那么何为产品的使用体验：即用户在产品使用场景中完成期望目标时所产生的体验。这是用户和产品直接接触的部分，也是最有感知的部分。无度量，无管理，我们如何管理体验？现代管理学之父，彼得·德鲁克说：「如果你不能很好地度量它，也就无法有效地管理它。」If you can’t measure it, you can’t manage it。Druker

         但是B端产品相对C端产品而言产品体验更加难以度量，因为C端产品有明确的业务数据指标作为向导，但是B端产品由于功能流程冗长、业务交叉复杂、包含产品价格、安全性、稳定性等综合因素，用户体验的要素被掩盖在这些复杂的「变量」中难以剥离。而控制和分离变量，是一个科学的度量系统最基本的要求，故做了如下调研，方便大家参考借鉴！

二 、 谷歌HEART -GSM 模型

1、简介

Kerry Rodden 作为谷歌资深用户体验研究员和数据分析师，在大量度量用户体验的探索与实践中总结出了HEART用户体验度量模型，帮助团队高效选择正确的数据指标。该模型在谷歌内部广泛使用，并通过论文、博客等渠道传播，使其他公司、团队也能够在使用的过程中受益。

2、 HEART 模型 五个维度 ：

HEART模型主要包括五个维度：愉悦度、参与度、接受度、留存率与任务完成度

3 、 GSM- 目标、信号、指标 拆解 三 步法

为了将这个抽象的度量标准应用于实践，Google又提出以“目标（Goal）——信号（Signal）——指标（Metirc）”的拆解流程来定义HEART指标数据。让使用该模型的产品团队，可以根据用户体验目标和业务目标，完成数据指标的选择，最终保证指标是服务于业务目标和用户体验的。

4、操作指南

5、优劣势分析

6、 总结

HEART模型的C端倾向较明显，并不完全适用于B端产品的体验度量（需要在此基础上改良）。

三 、 阿里云UES模型

1、简介

UES（User Experience System）是阿里云设计中心通过多年设计实践中沉淀下来的云产品使用体验度量系统，它不仅是一套方法论，更是一套可运行的体系。

2、五大度量维度 （ 有主观，有客观，有定性，有定量 ）

UES（User Experiences System）是基于阿里云易用性量表扩展而成的度量体系，包含易用性、一致性、满意度、任务效率和页面性能 5 个指标维度。

易用性 - Ease of use

易⽤性是产品使用质量的核心维度，它反应产品对⽤户而言是否易于学习和使用，包含易学性、易操作性和清晰性3个维度。易⽤性的提升可以促进操作效率和任务完成率的提升、降低学习成本、提升⽤户体验和满意度。

一致性 - Consistency

一致性指多款产品间通用范式部分的一致程度，分为整体样式、通用框架和常用场景及组件等维度。对于⽤户⽽⾔，体验⼀致性的提⾼可以降低⽤户的操作时⻓及错误率，降低学习成本，提升⽤户的满意度；对于产品设计及开发者⽽⾔，保持体验⼀致性可以提升开发效能，产品模块的可集成性、稳定性和可延续性更⾼。

满意度 - Happiness

满意度反映着用户对产品或服务的期望被满足的程度，这个指标一定程度上会反映用户再次使用和对产品进行推荐的程度。

任务效率 - Task Success

任务效率包含任务完成率和任务完成时间，云产品的任务链路相对复杂，针对有明确任务或有固定使用流程的产品，通过比对用户路径和产品设计的理想路径之间的差异，能够帮助我们发现产品流程设计上的问题。

性能 - Performance

监控性能的指标有很多，其中最影响用户感知的指标是首屏渲染时间（FMP），指用户从发出请求到看到控制台主要内容的时间。其次，还包括页面请求响应时间、API 请求响应时间等指标。

3、 指标拆解方法

①、明确业务目标和体验目标

②、确定度量维度

③、拆解数据指标

④、完善度量方法

4、优劣势分析

优势：度量维度多、全面、包含主观、客观、有定性，有定量

劣势：实施成本高、开发成本高、分析成本高

5、总结

UES确实是比较科学全面、适合技术类B端产品的体验度量体系。但其庞大的体系、复杂的度量手段和工具可能都会使得我们在日常业务中无法轻量化地实施起来。

四 、 蚂蚁金服 TECH 模型

1、度量模型诞生背景

企业级产品 / 企业级中后台这些概念在互联网经常被提到，一般提及这个词儿，我们往往能够想到以下这些产品：财务审批系统、CRM、ERP、算法专业人员训练模型的平台等等。在我们的印象中，这些平台往往具有以下特征：

流程冗长，操作繁杂，一个平台往往是若干复杂功能的合集；

相对于 C 端产品动辄百、千万级别的用户量，企业级产品往往用户量级不大；

开发流程简单，往往是产品经理画个 demo 就上线了；

页面设计难看，用户体验往往比较糟糕；

......

现阶段企业级产品也在慢慢演变，对于体验的追求也比前几年更为饥渴。他们的体验需求可以明显看到两个阶段的演进：

效能需求阶段：这个阶段的企业级中后台页面设计混乱，业务对于体验的需求显性表现在美化页面设计，提高设计效率和一致性。

体验需求阶段：这个阶段产品开始关注使用过程中的问题，慢慢转向注重于用户需求和体验设计。

就蚂蚁金服的企业级产品来讲，Ant Design 已经帮助解决了绝大多数第一阶段的需求。目前基本都处于第二阶段。体验度量实践也正是从这里开始。

2、实践过程

以HEART度量模型为基础，蚂蚁金服根据企业级产品现状和特征做了部分的补充和修正，修改点如下：

将 NPS 改成用户主观满意度：NPS 对 C 类产品是一个很有效的指标，对于企业级中后台来说，往往由于企业产品的封闭内环、用户基数等众多原因，可能还是满意度来的更加有效；

不强调留存率：企业级产品用户往往没有太多的可选余地，因此留存率未必适合用来衡量用户对于产品的喜好；

参与度和接受度指标合并：对于企业级中后台系统，用户使用的目标性更强，TA 就是来完成某个任务（或者说 TA 就是来完成工作的）因此活跃度基本和产品能否满足用户的需求强相关；

3、 最终体验度量模型

基于 HEART 模型，结合企业级产品体验度量实践修正后的度量体系如下：

核心任务体验（Task Success）：主要聚焦于产品核心任务流程中的体验问题。可以采用定性、定量，或者两者结合的方式，最终来反映体验的细节问题。

参与度（Engagement）：产品能够提供的需求和用户预想之间距离有多远？

清晰度（Clarity）：引导、帮助清晰，用户是否能够顺利完成所想做的事情？

满意度（Happiness）：用户对产品及其他方面的满意度，比如视觉外观等。

4、优劣势分析

优势：多维度、多指标、主客观结合

劣势：客观的用户行为数据指标较少

五、总结

那么如何去搭建符合自身平台业务的体验度量体系呢？我们发现不同类型的产品差异较大。如办公协同类产品与业务平台类工具的体验目标就很难进行统一化的抽象处理。所以，「构建适合具体类B端产品的体验度量模型」显得更加对症下药。他山之石，可以攻玉。从诸多体验度量模型中取经总结（各大其他平台的度量模型都是基于HEART模型改良的），不难发现“先梳理产品目标+参考HEART+阿里云指标拆解方法”的思考方向可以帮助我们构建适合具体B端产品体验的度量模型。

小荷才露尖尖角（26）——云计算那些五花八门的工作岗位

先说一个有意思的说法，在云计算领域存在一个客户BS链：金融——软件互联网——电信——政府——服务——制造——农业。

什么意思呢？越往BS链的上游，生意越好做，好比金融行业，资金本身就容易数字化，而数字化带来的提效可以很容易转化成利润，因此金融行业养活了很多的软件类上市企业。越往下游越难做，行业利润率越低，当然拿不出多少钱来做数字化。

客户不是重点，今天重点是讲云计算公司围绕着这些客户有哪些岗位，这些岗位怎么协同起来拿下客户的单子赚钱到，以及 最重要的，分析一下这些岗位特点，方便我们就业、择业 。

我们接下来分析一下云计算公司的岗位。

先从售前、售中、售后几个角色来讲清楚产品是怎么卖出去的：

第一、售前

售前有两个最重要的角色：销售、解决方案架构师。

销售主要是拓展、维护自己的客户关系网，在云计算公司中，销售的组织架构可能会以行业、区域、KA等几个不同维度划分。比如，银行、保险、交通、医疗等行业维度；北方大区、华南大区、西北大区、东南亚等；KA，简单来说就是专门伺候大客户的部门。云计算领域有个典型特点，极少数客户贡献了绝大部分的收入。翻开A股那些toB的软件类上市企业财报，一般能看到很重要的一项：前五大客户对营业额的贡献度。如果这个比例比较低，比如，30%，那说明企业比较 健康 ，不会因为某个大客户突然出问题而导致软件公司挂掉。如果这个比较比较高，比如，80%，那一旦某个大客户出现问题，软件公司也会跟着业务凉凉，如果赶上资金流紧张，挂掉的可能性都有。

解决方案架构师就是跟在客户后面忽悠客户的，不同于销售，他们一般会具备技术背景、行业经验，当然，少不了一些销售技巧，毕竟也是为了“卖”嘛。

比如客户想买一下CDN产品，解决方案架构师就会把自己公司拥有的网络产品打包到一起给客户一个完整的方案，解决尽量多的问题，让客户尽量多的下单。

本质上来说，任何销售的工作其实就是不停地做漏斗，一单生意一般从PPL开始，经历投标、签约等环节，到最终客户验收产品，销售拿着客户的验收单交给财务变成公司账上的应收账款，销售的工作才算结束。在每个环节转化率固定的情况下，当然PPL越多，最后成单数量就越大，销售收入也越高，销售的提成也就越高。

当然，也有特殊情况，我就听说过一个阿里云的销售花了三年时间跟进一个大客户，连续三年绩效不好，后来大客户谈成了十亿的生意，奖金一下子可以够吃上十年了。

云计算公司的销售向客户卖的东西是什么呢？拆开来看，有两部分：软件产品、技术服务费，其中技术服务费又分为一次性的交付费用，以及每年都会收的维保费用。

早年银行的机器和软件系统都是购买国外的，中国金融行业从老百姓身上赚到的钱就这样大笔的转移到IBM之类的外企头上去了。现在，终于轮到中国人自己吃了。

第二、售中、售后

比如，某个银行客户要向阿里云买一个部署在私有云的金融核心系统，也就是银行最核心的存贷业务系统。那阿里云需要做几件事。

1、从服务商厂商那里采购机器，从机房建设服务商那里采购服务，帮助银行把机房建起来。

2、将阿里云自己，或合作研发的金融核心系统部署到机房，让它们可以正常工作。

做这两件事就需要两个关键角色：

1、交付项目经理，负责统筹安排参与项目的所有人员，把控进度，控制风险，推进项目按期完成。

2、交付工程师，负责把金融核心这套软件系统部署到机房，填写各种参数，把系统启动起来，然后测试一遍，交给客户。

上面这两项工作，就是向客户收取一次性交付费用的原因。

软件启动起来了，客户用了一遍，很满意，就给开一个验收单，约定打款日期。销售拿着验收单回公司交给云计算公司的财务，变成公司账上的应收账款。对销售来说，这单子就算结束了。

但对云计算公司和客户来说，还不算完。因为软件系统在运行过程中肯定会出些bug之类的各种各样的问题，银行自己又解决不了，那就需要阿里云随时提供维保技术支持。

这就涉及到另外一个重要的售后角色：维保工程师，负责根据客户的付费购买的维保服务级别来提供不同程度的服务。

维保嘛，字面理解，维修、保养，大概就是这个意思。阿里云的维保工程师可是很贵的，所以银行每年还需要交一笔钱来做技术支持费用了。一般来说，每年的维保费用是初期一次性产品购买费用的10%左右。

到这里为止，产品怎么卖出去的就算讲清楚了。 接下来，我们讲讲产品是怎么做出来的。

阿里云卖给客户的这个在银行用来做最核心最重要的“存贷业务”的金融核心系统，可能是阿里云自己研发出来的，也可能是阿里云的合作伙伴研发出来放到阿里云上售卖。不管是哪一种，这都是一个大团队做的事情，涉及到关键的几个角色：产品解决方案架构师、产品运营、产品经理、软件开发工程师、数据分析师、算法开发工程师、测试工程师、二线技术支持。

第一、产品解决方案架构师

这里的产品解决方案架构师与前面提到负责售前的解决方案架构师相比有很大的区别。

售前的解决方案架构师是从客户视角思考问题，一直在想把客户的需求跟自己公司卖的产品集合中的哪些产品比较匹配，然后挑出一部分产品组合起来成为可以解决客户问题的解决方案。售前解决方案架构师不限于某个产品，围绕着客户需求来做解决方案。

而产品解决方案架构师则是从自己团队负责的产品出发，横向协调售前、售中、售后把自己的产品卖出去，从客户那里收集需求，加工之后输出给自己背后的运营和产品经理。产品解决方案架构师在与客户沟通时，只会专注在自己的产品上，成就成，不成就算。

第二、产品运营

所有业务本质上来讲，都可以用“人、货、场”理论来解释，而运营就是运营这个“场”，让货更好地卖给人。比如，针对不同的客户分层推送不同产品，组织产品发布会向客户透传产品信息等。

第三、产品经理

这个比较简单、通俗，所有软件产品都离不开产品的功能规划、设计、迭代等。

第四、软件开发工程师

程序员喽！拿阿里云上的产品来举例，做ECS的码农、做CDN的码农、做短信的码农等等。

第五、数据分析师

对于数据产品来说，对数据进行清洗、建模，将模型交给软件工程师整合到系统中。另外，还会对公司业务数据进行分析，面向投资人、业务决策层提供决策建议。具体不再聊，可以看看我这篇文章： 屋顶的闪闪星光：小荷才露尖尖角（22）——企业中的大数据开发在做什么？

第六、算法开发工程师

对于特定的场景，需要加入复杂的算法来解决问题。比如，自动驾驶、 游戏 中的人机对战、调度系统中的订单分配、物流场景中的路径规划等。

第七、测试工程师

一般人的通俗理解中，这个岗位是在软件开发工程师做出产品来之后，点啊点、滑啊滑，模拟用户操作，看看有没有什么问题。但这其实只是黑盒测试，软件工程中还有更复杂的白盒测试。我以前写过一篇文章专门讲测试工程师的工作，这里不再详细说了，大家可以看看： 屋顶的闪闪星光：小荷才露尖尖角（20）——聊一聊软件工程中的测试工程师

第八、二线技术支持

一般会雇佣一些技术弱一些、工资低一些的工程师来负责处理客户的问题。为什么叫二线技术支持呢？它对应的是前面的维保工程师，也就是一线技术支持。系统交付之后，当客户在使用过程中出现问题时会首先找维保工程师。但维保工程师往往会同时处理很多个产品，对于单个产品中比较复杂的问题是处理不了的，这时就会把问题甩给产品研发团队中的二线技术支持。

二线技术支持是和产品研发团队一起的，平时只负责处理这个产品的问题，可以处理的问题难度会比维保工程师高得多。有人可能会问，对于二线技术支持也处理不了的问题怎么办呢？那就流转到产品的软件开发工程师手中喽。

到这里为止，云计算公司中所有岗位工种就介绍完了。

最后，也是我们这篇文章最重要的一件事：从就业、择业的角度来审视一下这些岗位。

在公司做事，简单来说可以分为与人打交道、与技术打交道。但事实上这世界上所有的事都不是非黑即白的，比如，即使最前线的销售，如果是技术出身，在工作中也是个很好的优势，而离客户最远的软件开发程师，有时也需要去客户那里交流、处理问题，擅长沟通的甚至可以拿回单子来。

这里我们用对技术的依赖强与弱来对所有岗位排一个序，如果你学习编程或者算法，走的开发方向那就从前往后看，如果你不会编程，那就从后往前看：

软件开发工程师/算法开发工程师——数据分析师——测试工程师——解决方案架构师——二线技术支持——维保工程师（一线技术支持）——交付工程师——产品解决方案架构师——产品经理——项目经理——产品运营——销售

接下来从起步时的待遇方面来看，可以分为几档：

工资方面，一般来说产研线大于售前售中售后，但售前是与单子有关的，浮动空间比较大。

产研中涉及到的几个角色也是有差异的，一般来说从高往低是：算法开发工程师——软件开发工程师——白盒测试工程师——产品经理——产品运营——技术支持——黑盒测试工程师。

最后，从发展空间方面来说，算法开发工程师、软件开发工程师、产品经理、产品运营都是几乎无上限的，都可以说是一个业务中的最核心的角色，而其它角色跟业务的关联度比较弱，可替代性明显变强。

另外，职业生涯起步时，产品经理、产品运营的待遇虽然比算法工程师、软件开发工程师、白盒测试工程师弱，但做业务做产品的发展空间却又比技术高得多。对于一家公司来说，技术是相对比较稳定的变量，而业务才是成败的关键。

看到这里，相信你不再对所谓云计算的各种岗位应该会比较清楚了。

阿里云IoT云产品交流会：物联网痛点多，阿里能做什么？

经历了互联网、移动互联网，人类正在迈入万物互联、万物智能的世界。5G、IoT、云计算、人工智能成为 社会 关注的对象，数字经济成为政策宣传的重点，各种概念和解释产生，使得当下有很多话题可以讨论。

数字经济背景下，企业竞争最核心的能力是什么。

不同行业发展数据智能的潜力有何不同？

企业如何高效进行物联网应用开发？

企业对云平台的使用体验如何

对于类似问题，阿里云IoT、ICA联盟一直希望与行业人士进行对话。上周，ICA联盟物联网万亿生态伙伴聚合沙龙在杭州举办，活动以“粘合行业碎片，共创IoT基石”为主题，以阿里云IoT云产品为话题，吸引近200名行业人士到场交流。

4位嘉宾依次上台分享

物联网需要化繁为简

物联网产业链很长，覆盖了感知层、网络层、应用层三大层次。它改变了传统的商业运作方式，让商业 社会 变得更加复杂。

首先，物联网让产品变得复杂。增加了传感器、模块等部件，需要进行更多的开发管理。

其次，物联网让需求变得复杂。企业从生产产品变成了提供个性化的服务。

就是这两个变化，让产业体会到很多新的发展痛点。

1. 物联网开发过程链路极长，从获客到交付典型过程常常要经历十几个环节。

2. 将软件研发、硬件研发、嵌入式研发，云产品的购买，施工/安装/维修费用计算在内，物联网开发成本极高。

3. 调查表示目前78%的用户需求为定制化需求，65%的物联网软件需要定制化开发，这导致软件复用性较低。

4. 设备联网、用户交互产生海量数据，众多场景亟需数据实时分析、可视化的能力，提升使用效率及用户体验。

新的形势促进了变化的发生，计算力的进步预示着满足更大的信息处理能力，更强的灵活性。

物联网平台在整个产业链中地位，也从当年行业所关注的“要不要上云”，随着企业自身数据资源日渐丰富，应用数据意愿的显著增强，过渡到了“如何高效地上云”。

物联网云平台，由此更直接地承担起IoT产业“基础设施”的角色，为物联网项目的规模化落地减负降压。

阿里云IoT 产品结构

阿里云 IoT 资深产品专家JASON CHEN从各个原子化产品角度，描绘了阿里云IoT的全局样貌。包含物联网操作系统AliOS Things、边缘计算Link Edge、网络管理平台Link WAN、开发平台IoT Studio、物联网设备接入与管理、物联网数据分析、物联网市场Link Market、物联网安全Link Security等功能在内，展现阿里云为各类IoT场景和行业开发者赋能的能力。

将各个基础产品分别阐述，体现出阿里云IoT强化基础设施角色，希望阿里云的产品技术变成合作伙伴解决方案一部分的心态。再次印证阿里云智能总裁张建锋在3月阿里云峰会上所提出的“被集成”口号，阿里云的重要转变已经发生。

以下，我们就将重新认识阿里云IoT云产品。

物模型

阿里云 IoT 技术运营专家薛圆在交流中表示，ICA联盟推出物模型，定义物联网设备模型与属性。通过对任意物联网设备建模，合作伙伴共创设备数据标准模型，确保数据标准的准确性、合理性，实现设备间的互联互通互懂。

类似将拼图碎片整理成更完整的拼图模块，物模型将实现碎片数据结构化、差异模型统一化、烟囱场景联动化、软硬一体标准化的目标，帮助用户缩短开发时间、标准化开发工具。

物联网数据分析

在任何商业活动中，数据都是一种资本，数据分析是可以产生创新收益的手段。

阿里云 IoT 高级产品经理腾春艳在对物联网数据分析产品介绍时表示，阿里云为物联网开发者提供数据分析服务，覆盖了数据存储、清洗、分析及可视化等环节，有效降低数据分析门槛，助力物联网开发。

在空间数据可视化方面，阿里云IoT提供二维、三维空间数据的可视化功能，致力用数据连接真实世界。比如对智能停车场的车场现状、排队数据、收入进行分析；比如定义电子围栏，当物品超出围栏范围时，配置报警；比如在物流追踪、设备管理等物联网低频定位场景下，展示设备轨迹；比如在三维空间可视化需求下，基于阿里云物联网平台构建监控、展示、控制为重点的BIM可视化系统，实现园区、建筑、楼层、房间、设备的逐级可视化。

图：阿里云IoT数据分析产品架构

IoT Studio 物联网应用开发

如前文所述，物联网产业的痛点很多都落在了开发上。阿里云 IoT 产品专家曲文政在演讲中再次阐明IoT Studio作为物联网开发者生产力工具的产品定位与功能。

1. 一站式完成云端SaaS 搭建 ：用户可以通过IoT Studio轻松搭建出简单IoT SaaS系统，或构建出部分功能集成在原有的SaaS系统中

2. 可视化搭建，降低定制化成本 ：通过可视化搭建、服务编排的方式让一般嵌入式开发者经过简单培训也可以快速搭建出各种物联网应用；

3. 提供AI 等高阶能力： 将高阶能力输出给开发者，增加营收，扩展业务边界；

4. 后续提供更多解决方案模版： 通过模版的方式给用户提供即刻可用的IoT SaaS解决方案（包含硬件、嵌入式代码、页面/APP、服务）。

整体而言，IoT Studio作为开发工具，向上承接业务需求帮助用户快速搭建SaaS，向下汇聚能力将阿里体系的能力更快更好地输出给用户，是阿里云IoT产品中承上启下的关键一环。

图：IoT Studio 产品架构

结语

在 汽车 行业，定制化需求增多，产品的敏捷规划、全生命周期运维是厂商的关注焦点；在零售行业，企业追求着精准化营销的目标；在农业，看天吃饭需要向精准化种植转变……

未来的各行各业，在面对各种不确定的因素之时，都希望用数据说话，用数据管理、用数据决策。

在这样的产业愿景之中，阿里云IoT将继续践行技术和商业基础设施的角色，覆盖物联网云管边端开发环节，提供满足各类开发者需要的基础产品，助力合作伙伴创新模式，发展商机。

阿里云这次冤不冤？

有读者转了一篇某大V批阿里的文章给我看，内容是阿里云被工信部暂停合作单位的处罚。

这个作者的意见是这样的，大概是说，阿里发现了服务器中的漏洞，不先报告给咱们自己，反而先报告给了美国。

我们跟哪儿知道的呢？晚了十五天，全世界都知道了，我们才知道。这十五天，不知道有多少网络安全，有多少黑客得以怎么怎么样。

首先，我们先说立场。

我其实挺开心的，或者讲，幸灾乐祸。

很多年前，我第一次创业的时候，亏的撑不下去了，到处引入资本，或者讲，拉合作伙伴。

我们常务副总和我两个人，就有拜访阿里，实际上拜访的就是阿里云。

当时阿里方一个副总裁，一个总监，一个记录的产品经理小弟，仨人接待。

那个副总裁看着措辞很客气，但是很明显，他授意手下那个总监，对我们各种讥讽。

大体的意思就是说，他们每年有上百亿的预算，不为赚钱，就为了在业内交个朋友。当然，这不是原话，这是我盗取罗永浩老师的台词。

他们的原话是培 养生 态链，只要产业生态培养起来了，钱有得赚。

你看到了，阿里一直都很傲慢，很多年前，就是这样了。

反正说来说去，意思就是说我们穷，没有资格和他们谈合作，如果我们想要钱，就现场表演一下才艺，看看我们公司有什么值得收购的地方，人家可以考虑考虑。

当然最后还是合作了，因为我们背后的大BOSS，和他们的大BOSS，大家都知道的那位，是朋友。但是你说人不记仇是不可能的。

老读者知道，我对阿里半分好感都没有，对腾讯充满了好感，起源就在于此。

我可不是什么君子，如果阿里落在井里，我是很乐意扔点什么的。

所以对于这个结果，我觉得，大快人心。

但咱们这是聊天，我不能忽悠读者。这件事在我看来，和那位大V描述的，肯定不一样。

Apache是很常用的web服务器软件，我们昔日和阿里合作的内容就是WEB服务器，我们的服务器，部署在他们的机房里。

这个常用的程度就像linux是一个很常用的操作系统，到处在用。

那我们现在想一个问题，如果你发现Apache上有个BUG，你第一反应是跟谁说？

想不明白就回顾我昔日写的一个例子。

我说，我在第二家公司的三年里，曾经给linux团队上报过一个内核级的BUG，为此得到了Linus维护团队的回信，感谢信。

我挺骄傲的，因为不是那么容易发现。

那如果按照这个逻辑说，当年我也有错，我所在的公司也有错。

linux是操作系统，这玩意儿可比web服务器底层多了。如果说攻击，你发现窗户上有个漏洞没上报，那我发现地基里还有个漏洞，也没上报呢。

问题是，当年我也没地儿上报呀。没人说要先给国内的谁谁谁打报告。

我想，这就是那个具体发现web服务器上BUG的工程师，他的处境了。

他当时第一反应估计啥也没想，就直接给人家Apache团队写信去了，这是技术人员的第一直觉。就像我当年第一直觉也是写信给linux内核维护团队。

作为技术人员，我也就知道这么一个途径呀，否则呢？我跟谁说？跟部门经理说？他都不一定懂这些细节。

好，阿里栽了，为什么？

因为此前工信部交代过，发现BUG，先上报，然后听指挥，让你咋做就咋做。

你现在明白阿里不冤了吧？

我们当年没有这个交代，没人说发现操作系统内核级的BUG先跟领导讲，没人交代过。

而现在不一样了，现在有人说，让你往哪儿报。

说了你不做，不罚你罚谁？

当然，这个工程师本人很冤，这个不用想。

因为他就是个码农嘛，一个码农怎么可能操这份心，他要是能有这点情商，就不会只是一个码农了。

所以责任在于他的直接上司。他的部门经理肯定没有认真交代遇到了这种事该怎么处理。

当然，也有可能是总监这个级别就没重视，没有跟经理说清楚，所以经理也没有交代过，大家都这么迷迷糊糊的，直到事情一出来，就是公司级的。

处罚这么重，都傻了。

这种处罚很好，我相信从此之后，无论是阿里，还是其他大公司，都学乖了。这个学乖了就是产生了敏感意识。

当你能够意识到我们和美国之间的关系很微妙的时候，说明你成熟了，你不再是一个彻底的码农了。

昨天在大号里，我写过自己忍受低薪，在某家芯片公司里待了三年。比在外企好的一点就是接触到了很多核心技术。

不过，这些并不是一年后在甲方连升三级傍上领导的唯一原因。甚至连主要原因都不一定是。

我觉得主要原因在于我的情商够了，我大概是昔日待过的那个甲方大领导身边所有懂技术的人里面情商最高的，所有情商高的人里面技术最好的。

这就是差异化竞争。

而且我认为，情商很多时候比技术还重要。我见过很多技术很差很差，甚至其他能力也很差，但是混成高管的。但是我没有见过一个情商很低的人混成高管的，哪怕他技术再神奇。

我第一次创业的时候，带过一个产品经理，非常喜欢这哥们，很年轻，也很小白，不过人非常认真负责，而且不骄不躁，还能够听得进去不同的意见。

或者讲，此人可塑性极佳，虽然起点不咋地。

我曾经有个晚上，和他远程协同工作。他改文档，发给我看，改到凌晨两三点，发给我最后一版。

我看完之后暴跳如雷，跟他通电话，把他一直骂到天亮。

我骂的理由只为一件事，他在我们给某家外企的报价单里，有一处细节，没有改掉给另一家民企的名字。

当时两家都在和我们谈合作，都有收购我们的意向。说穿了，我们就是一女许二夫，背着老公偷汉子。就这么档子事儿。

这种时候，人就要打起十二分精神，你要有偷汉子的谨慎，要有做间谍的心态。一个不慎，被人家看穿，咱们可就前功尽弃了。

这就是我愤怒的原因，我觉得他做事不带脑子。说到底，他勤于谋事，拙于谋身。你连这点子心眼都没有，我怎么能指望你日后负责更重要的事情呢？

我一心想把他调到售前部门做经理，无奈没有足够多的时间。他长大还需要很久，所以只能挖了一个昔日很熟悉的前同事。

那哥们说实话，要技术没技术，要人品没人品，问题是，合适。合适的地方就在于情商够了。

你看到了，这世界就是这样。你觉得好像不重要的地方，其实才是任命一个人最首要考虑的地方。

因为一个人如果情商不够，马上就会捅漏子，而且很有可能能力越大，捅的漏子越大。回头你盖都盖不住。

今天又被我们写偏题了，不过我觉得没偏。因为阿里冤不冤，和我们半毛钱关系都没有。但是复习一下职场里那些重要的点，和我们大部分人，息息相关。

阿里云售前架构师是产品经理吗

是。根据查询阿里云售前架构师相关资料显示，阿里云售前架构师是产品经理，负责汽车事业部数据部门的团队搭建及人员管理，结合发展需求，进行数据管理及数据规划；深入研究汽车行业数字化转型之路，快速捕捉企业业务痛点，挖掘项目机会等。

阿里云产品经理的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于阿里云产品经理待遇、阿里云产品经理的信息别忘了在本站进行查找喔。