大数据采集与分析小站

一个大数据采集、分析的经验分享平台

奈飞文化的理解

奈飞文化如果用几个词来概括,书中提到了「自由」、「责任」、「纪律」。

我给自己又出了一道题,如果用一句话来概括奈飞文化,我的答案是什么?

帮助员工达成卓越的高效能文化

从价值观谈起

我经常在想一个问题:为什么我司的企业文化能够真正的深入到员工人群中,且能指导日常工作?

我想真正的价值观不应该只是动听的宣言,在公司层面是通过哪些人被奖励、被提升和被解雇来体现;在员工层面是,而应该是员工所重视的行为和技能,即使这些品质或者技能是反人性的,比如沟通力、自驱力、勇于担当。

奈飞文化能够落地如此成功,我认为一个很大的前提是公司整体对价值观的统一认同,自上而下,缺一不可。

书中提到了一个非常重要的观点:伟大的工作与福利无关,而是拥有一群超级棒的同事。这点我是强烈认可的,我有一个朋友,曾经向我吐槽过,他们的公司有一个程序员遇到问题,不懂装懂,用非常拙劣的代码设计来完成代码开发,前后端联调的时候互相推诿。我在想,如果我身处这样的环境真是槽糕透了。任何团队的协同,本质上还是人与人之间的协作,如果人本身是靠谱的,是优秀的,那么协作的效率将会大大提升,这是任何流程和机制都没法去替代的。

说到人,自然联想到了那句著名的话「我们只招成年人」,这句话基本上成为了奈飞文化的符号。那么我们怎么理解「成年人」?

成年人的特征

情绪管理

这是成年人的基本素质之一。这里的「情绪管理」要纠正一个误区:不情绪化不是意味着你不会生气或者开心,只是它们所有的情绪都能在理性的思维里兜兜转转,却不控制你的行为。

当你开心时,你知道你很开心;当你愤怒时,你知道你在生气。当你能够正式自己的内心,知道自己的情绪的变化,那么就已经在做情绪管理了。

责任感

经常发现一个有趣的现象:有责任的人往往能获取到更多的自由;无责任感的人恰恰被限制了更多的自由。

  • 自驱力

    • 之前和这样的同事合作过:需要有人不停的在后面催促,他会动一步;再催一次,再动一步,这样实在太累了。你必须给他明确指出具体要做什么,甚至他不关心目标,只关心手头的一亩三分地。这是思维的惰性,也是管理的认知对齐没有做充分。
  • 自知

    • 对自己定位的认知,能够客观理性认知自己,优点和缺点
  • 自律

    • 和自己的惰性斗争,养成良好的习惯,善始善终,认真对待每一件事情
  • 自我提升

    • 有些同事经常提到一个词:「工作太忙,个人成长有限」。员工个人发展,如果是依赖于公司规划他们的职业生涯,那么他永远只是被动的成长。真正的提升应该是来源「自我提升」,建立在「自知、自驱」的前提下,进行自我提升,高绩效人才大多能通过经验、观察、内省、阅读和讨论自我提升。
  • 没有边界感,如果领导者行事

  • 不会等着被叫去做事

    • 回顾下 2021 年来我们出现一些一类 bug,往往都是一些非常简单的原因导致。开发缺少了充分自测、code reviewer 随意应付、测试疏漏了一个 case 最终都有可能导致很严重的后果。最为可怕的是这往往这些过程其他人是感知不到的,甚至无法追溯。这些工作日常,如果没有强大的责任感趋势,总是在侥幸的边缘疯狂试探,再好的流程和机制也会漏洞百出。

团队管理

以我的目前的认知,团队管理最终目标是帮忙员工达到卓越。完成这个目标从团队角度来说最大的阻碍在于两点:平凡的同事和无挑战的工作。

特别对于研发这种具有创造性质的职位来说,我比较认可书中提到的观点:需要追求高效能文化、高绩效人才。需要清醒的认识到以下两点:

  • 不是所有的人都是和这种高效能文化,有的人可能就是不适合神策的工作方式,我们要找到一批有相同基因,志同道合的人。

  • 对于「不羁天才 」类型的人才,前提是能够契合公司文化,如果不符合,对于保持团队效率的代价太大。

  • 公司发展节奏和员工的节奏需要保持一致,按照书里的话「和岗位高度匹配」,如果不能匹配了,离开是更好的选择。

控制或设定目标

如果你想造一艘船,先不要雇人去收集木头,也不要给他们分配任何任务,而是去激发他们对浩瀚汪洋的渴望。

最佳的管理通过设定合适的情景而非试图控制员工以达到最大成果,这里涉及到团队管理的理念。这点我认为不太符合目前神策的现状,但这句话背后的思路值得借鉴。

先简单说明下什么叫做情景,我个人理解就是让任务目标和策略足够清晰和深入人心,我们现在 OKR 沟通工具是这种理念衍生的方式之一。

  • 目标

    • 需要绝对透明,将任务目标,和部门目标、公司目标关联性、优先级、相关干系人、界定目标成功的标准。整个团队对于目标有清楚的认知,消除信息差。
  • 策略

    • 光有目标还不行,因为认知水平的差异,需要提供给团队一个具体可达到目标的策略、路径。

流程建设

我有过这样的困惑,比如出现了一些问题,解决的方式大致有三种:

  • 建立周密流程,通过流程降低后续类似问题发生的概率

  • 依赖灵活性,强化人的主观能动性,通过知识库沉淀来解决

  • 上述两种方式结合

奈飞的团队组成是有着一批「高绩效人才」,拥有超级棒的同事。所以更倾向于灵活性大于流程,主要观点在于:

  • 雇用更多高绩效人才来抑制混乱的产生

  • 既有的流程在市场变化大前提下,新的混乱又会产生

客观来看,我理解我们需要有这样视角:区分好的流程和差的流程。

好的流程可以帮助我们有效的预防问题,高效的团队协作;坏的流程会阻碍效率,为预防极端的错误阻塞了整体效率。

实际心得,两者结合,在灵活性和流程层面各取其长。针对「高绩效人才」,更倾向于采用灵活性方式。

无论哪种方式,作为管理者,我们都需要做最终的 check 和迭代优化,实践是检验真理的唯一标准。

总结

奈飞文化有很多值得我们学习的地方,对于自由、纪律、责任三者做到较好的平衡,一定程度上是一种极致的高效能文化。我们不能忽略的一点,这里面有一个很大的前提:拥有超级棒的同事。

我们切回神策的视角,这几年团队快速成长的阶段,我理解远远未达到「拥有超级棒的同事」。在这个过程中,我们既要脚踏实地,又需要放眼未来,打造卓越的团队,比如奈飞中提到的成年人、责任、透明坦诚文化,以此持续改善团队的健康度。

保持头脑极度开放

  • 探索不同的观点和可能性,而不是让自我意识和思维盲点阻碍自己
  • 人与人是不同的

科学的工作方法

  • 目标是什么
  • 问题是什么(调查统计)
  • 产生问题的原因是什么
  • 规划方案
  • 验证、迭代

头脑极度开放

在痛苦中反思并进行自我突破

  • 痛苦是成长的催化剂

杏仁核和前额叶皮层的战争

  • 杏仁核,人类大脑里一个发育相对健全、历史更为久远的部分。杏仁核主导了人的原始欲望和冲动,构成了人类的潜意识(也称为下意识或者无意识)。
  • 前额叶皮层为人的理性思考提供了物质基础,是人类意识与自由意志的来源。

做到头脑极度开放

  • 你在决策时看到的情况也许并不是最符合事实的情况。头脑极度开放是一种能力:有效地探析各种不同的观点和不同的可能性,而不是让你的自我意识或思维盲点阻碍你。这需要你克服对自己始终正确的渴望,愉悦地探求事实。奉行头脑极度开放的话,较低层次的你就无法控制你,而始终是较高层次的你在观察和考量所有不错的选择,做出最佳决策。

  • 我们的分歧不是沟通不良造成的,相反,我们不同的思维方式导致了沟通不良

  • 要知道最常发生的斗争是情绪和思考的斗争。情绪和理性思考之间的斗争是最大的斗争。情绪主要是由潜意识性的杏仁核控制的,而理性思考主要是由意识性的前额皮层控制的

怎么做到头脑开放

借助一个契机来反复锻炼,让更高层次的我来进行控制我们:经常会产生心理痛苦,尤其是当相关挑战涉及你的某种缺点的时候。这种心理痛苦是一个迹象,说明你可能是错的,你需要以高质量的方式思考这个问题。为此你需要先让自己冷静下来。

理解人与人的不同

创造者、推进者、改进者、执行者
任务导向(细节)和创造性、目标导向。思维的不同,导致沟通的问题

沟通的分歧有两种可能

  • 思维的不同
  • 沟通过程中自主意识的介入或者没有营造出足够安全的对话氛围

内向与外向

  • 内向者聚焦于内心世界,从思想、记忆和经验中汲取能量;外向者聚焦于外部,从与人相处中汲取能量

直觉与感知

  • 关注细节的感知者在看到像把 their(他们的)写成 there(那里)的错误时会很不舒服,但直觉者往往注意不到这种错误,这是因为他们关注全局,不重视细节

计划者与随机应变者

五步解决问题

1.有明确的目标

  • 目标排列优先顺序

  • 合理的目标是你真正需要实现的东西,欲望则是你想要但会阻止你实现目标的东西

2.找到阻碍你实现这些目标的问题,并且不容忍问题

  • 合理的目标是你真正需要实现的东西,欲望则是你想要但会阻止你实现目标的东西

3.准确诊断问题,找到问题的根源

  • 先把问题是什么弄明白,再决定怎么做。

  • 区分直接原因和根本原因。直接原因通常是导致问题的行动(或不行动),所以通常用动词描述(我因为没有查列车时刻表而错过了火车)。根本原因是更深层的原因,通常用形容词描述(我因为健忘而没有查列车时刻表)

4.规划可以解决问题的方案

  • 前进之前先回顾

  • 把你的问题看作一部机器产生的一系列结果

  • 你应当从总体框架出发,一步步落实到具体任务和预计的时间线(如“在未来两周里选好能找到人才的猎头”)。无疑,在你推进的过程中,成本、时间、人员等方面的现实问题都会浮现,这将促使你进一步完善方案,直到机器里的所有齿轮都啮合良好、流畅运转。

5.做一切必要的事来践行这些方案,实现成果

各司其职

  • 在管理其他人方面,我能想到的比方是一个好乐队。乐队指挥是塑造者、引导者,他主要不是“做”(例如他不演奏乐器,尽管他了解很多关于乐器的知识),而是勾勒结果,并确保乐队所有成员一起发力实现目标指挥要确保每个乐队成员知道自己的长处和短处,以及各自的职责。不是每个人都自己演奏得最好,而是通过合作实现“1+1 > 2”的效果。

决策

  • 影响合理决策的两个最大的障碍是你的自我意识和思维盲点

    • 潜意识里的防卫机制,它使你难以接受自己的错误和弱点
  • 最好的选择是好处多于坏处的选择,不是毫无坏处的选择。看看有些人,发现一点问题就反对某件事,而不合理权衡所有的优缺点。这样的人通常不善于决策

  • 简化

    • 撇掉无关细节,让重要因素及其相互关系呈现出来
  • 了解事实以及事实背后的因果机制

把事情摆在桌面上

我们发现,把所有事情摆到桌面上的好处在于:(1)不必刻意展示好的一面;(2)节省了猜测别人想法的时间

打造允许犯错,但不容忍罔顾教训、一错再错的文化

痛苦+反思=进步

聪明的人善于拥抱自己的错误和不足,从而能远远超越那些与他们水平相当,但更自负的同学、同辈。

一个人犯下的最严重的错误,就是不能直面自己的错误。这也是桥水强制采用问题日志的原因。

用对人

一个人能否取得成功,最重要的因素是客观的自我评价,包括对自身缺点的认识。人的价值观、能力和专业知识

价值观是驱动行为的深层信仰,决定着人际相处。人们会为价值观而斗争,他们会与那些价值观不同的人斗争

能力体现在思考方式和行为方式上。一些人是了不起的学习者、问题的快速处理者,另一些人拥有从更高层次看问题的能力。有些人更关注细节,而另一些人善于创新思维、逻辑思维或者心思缜密。

技能是可以习得的工具

严厉的爱,最难给,也最重要

交叉核验

背景

在服务近 2000 家客户的过程中,客户对埋点采集 SDK 提出各式各样的需求。

从需求的类型来看大致分成两种:安全你合规以及功能类需求。

安全合规类型

  • 禁止特定属性上报
  • 禁止特定 API 进行调用
  • 源码里禁止特定关键词
  • 个人信息匿名化
  • 数据采集、存储、传输加密

功能类型

  • 用户行为数据精细化采集,如点击、浏览、曝光
  • 支持多实例,同一个 App 可将数据发送到不同地址
  • 配合分析以及营销相关数据采集,如推送、弹窗、可视化埋点

从端的角度来看,数据采集分成客户端以及服务端

系统
客户端 Android/iOS/Web/小程序/三方框架/游戏引擎
Paragraph Java/PHP/Ruby/Python/Lua

对于什么时候应该用客户端埋点,什么时候使用服务端埋点,遵循一个原则:永远优先从服务端采集,只有当服务端采集不到,才考虑在客户端采集。

埋点系统软件架构原则

开放性

足够的开放,数据采集、存储、传输全过程是可以任意定制的,比如加密算法定制、采集数据定制、上报的数据格式、数据传输过程中 SSL 证书配置等。

稳定性

一个优秀的埋点 SDK ,在任何场景下不应该影响到宿主容器应用,比如性能以及 crash 问题。

数据准确性

由于网络环境以及用户行为不确定性和设备的多样性,SDK 需要尽可能保证数据不重不漏。

SDK 技术架构

数据存储和传输策略

服务端 SDK 相对于客户端 SDK 来说简单很多,这里以客户端举例来看:

不同于服务端,移动设备上的资源是非常有限的,采取实时上报的方式势必会造成 App 整体性能的下降,如何平衡性能与数据上报的时效性是 SDK 需要面临的一个挑战。

目前 SDK 中使用的数据上报策略是事件触发后不立即上报,而是先将事件缓存在本地,然后满足一定的条件再进行上报。

SDK 每次触发事件时会检查如下条件,用于判断是否向服务端上报数据:

1. 当前网络是否符合发送策略 flushNetworkPolicy(默认 3G、4G、5G、WiFi);
2. 与上次发送的时间间隔是否大于指定的时间间隔 flushInterval(默认 15 秒);
3. 本地缓存的事件条数是否大于最大缓存事件数 flushBulkSize(默认 100 条)。

只有 1、2 或者 1、3 满足时,SDK 才会发送数据。当然,为了满足不同的需求,可以通过修改 flushNetworkPolicy、flushInterval、flushBulkSize 的值来控制事件上报。

对于 Web 以及小程序而言,和 Android & iOS 相比最大的区别在于缓存的稀缺的,通常用 localstorage
来进行存储,一般 200-300 条就会满,所以需要更频繁的去发送,确保数据不会漏掉。

极端场景适配

典型场景如退到后台和强杀应用,这两个场景,需要针对性进行处理,确保数据尽快的存储和发送。

技术架构

需要考虑以下几个模式的应用:生产消费者架构,事件队列。
依照数据流处理过程,可将模块抽象为数据采集拼装、数据入库、数据传输。

Q&A

在什么场景下,数据可能会发生丢失?

以下场景下会可能发生丢失:

  • SDK 本地缓存满了,达到上限
  • Web SDK 采用实时发送模式,网络环境较差或者浏览器强杀则丢失
  • App 卸载和浏览器清除数据
  • 数据未入库前 App 强杀

上述场景是由 App 或浏览器的用户行为发起,在极端环境下产生的数据丢失。这种现象从理论上来看无法真正消除,只能尽可能去保证数据不丢。

如何保障数据不重不漏?

  • SDK 端持久化缓存和数据重试发送策略
  • 本地数据库(持久化)
  • 合理的上报策略(数据条数以及数据发送间隔)
  • 异常场景优化(退后台、App 强杀)
  • 重试发送(根据状态码判定上报状态)
  • SDK 优秀架构(生产消费者模型)
  • 服务端状态回传以及去重机制

总结

以上就是埋点采集系统技术架构上需要考虑的点,埋点是一件看起来简单,实际很复杂的一件事情。随着系统以及合规政策的日新月异,埋点也需要不断适配。只有构建好了足够坚实的数据根基,才能有效支持上层的数据分析以及运营。

职场工作十年有余,见证了老同事带领团队辛辛苦苦做了一个项目两年多,项目上线后,发现一个关键的性能问题未解决,导致客户无法集成使用,几十人的团队,两年多的付出都付诸东流。
这件事给我深刻的感触,如果是我或者你,身处棋局,如何尽可能保证我们做出来的事情达成目标,降低失败的可能性?

什么是逆向工作法

逆向工作法指的是把战略建立在不变的事物上。来源于亚马逊创始人贝佐斯,每当他不得不做出重大决策时,他常常会以这种方式来思考问题,比如贝佐斯认为在零售业,客户永远不变的就是想要更低的价格、更快捷的配送和更多样的选择,企业必须先搞清楚客户究竟要什么,再进行逆向操作,在对的事情上投入大量精力,只有这样企业才能在未来持续获血。

贝佐斯的逆向工作法

贝佐斯在选择创业时,老板多方挽留。他也不确定自己创业是否能成功,在他作出决定之前,他做了一个最小化后悔表,“假设自己80岁高龄时,对20岁时没有创业会不会后悔?”

  答案是显而易见的,他不会因为自己没有成为更高阶的职业经理人而后悔,但是如果没有创业他一定会后悔。贝佐斯后来还将这种逻辑应用到他的个人生活中,每当他不得不做出重大决策时,他常常会以这种方式来思考问题。

  这就是“逆向工作法”,其最关键的就是找到你一开始做这件事情的最初目的,然后根据这个目的去工作。

  而与之形成鲜明对比的“技能导向法”则主张“我们擅长做什么”、“ 通过做什么,还能再做什么?”尽管不少时候,技能导向法是一种有用并且一定程度上奏效的商业模式。但如果沉浸于此,就会丧失创新的动力。

  乔布斯领导的苹果公司采取的常常是“技能导向法”,苹果公司的创新往往是技术的变革以及乔布斯天马行空的想象力结合的产物。在这个方法下,企业更倾向于领导客户,改变消费观念,让顾客接受它的产品和理念。

  而贝佐斯认为,亚马逊网站设计的总体哲学是对客户友好,应该将注意力放在顾客身上,而不是网站上。他的目标不仅是让浏览书籍变得更容易,而且要让这成为-种愉快的体验。正是在这种哲学之下,亚马逊发明了“一键下单”功能以方便顾客购买;还有“书内阅读”、“书内搜索”功能,获得了广大顾客尤其是大学生群体的喜爱和追捧。

  正是这种为顾客着想的态度赢得了顾客的好感,亚马逊的书评区更像-一个社交平台, 人们在这里畅所欲言,也正因为通过这种方式建立起来的顾客群体和良好口碑,亚马逊的图书销量不断提升。

以终为始

逆向工作法是一个很好的思维方式。通过以目标倒推关键节点或产品策略,最终达成聚焦的目的。
如果要问逆向工作法最重要的一点是什么?一定是思维习惯的转变:
“逆向工作法” 的根本出发点,是从内部或公司的视角转变为客户的视角。

新闻稿

逆向工作法说起来简单,实施起来却很难。因为人的思维习惯天然的从正向思考,根据已有的经验和思维习惯惯性的往前冲。亚马逊的逆向工作法中有一点我想和大家分享下:新闻稿

新闻稿让读者拥有最精彩的客户体验。常见问题提供关于客户体验的所有重要细节,同时又能全面而清晰地评估公司打造该产品或创造该服务将面临多大的成本或挑战。

新闻稿主要包括下列部分:

  • 标题:以阅读者(你的目标客户)容易理解的方式点出产品的名字。

  • 副标题:描述产品以及客户使用该产品的益处。

  • 摘要:首先写明城市、媒体渠道以及计划发布的日期,然后简述产品的情况及其好处。

  • 问题:描述产品要解决的具体问题。一定要从客户的角度写这个部分。

  • 解决方案:较为详细地描述你的产品,以及它如何便捷地解决客户的问题。

  • 引用及购买:引用公司发言人的一句话,再引用假想客户的一句话,表明他们使用你的新产品所获得的各种好处。要表明购买该产品方便、快捷,给出网站链接,以便让客户获取更多信息和购买产品。

常见问题通常可分为对外常见问题(关注客户)和对内常见问题(关注公司)。对外常见问题是客户或媒体会对有关产品提出的问题,包括产品的工作方式、价格、如何及何处购买等更为细节的问题。这些问题是针对具体产品的,因而每份 PR/FAQ 的常见问题都是独特的。对内常见问题则有更标准化的、需要予以解答的问题清单。

其实这里就是 “以终为始” 的思想,我们可以同时引入 “新闻稿” 和 “常见问题”。

Kindle

Kindle 作为家喻户晓的电子书阅读器,这个产品的决策过程是非常值得学习的。Kindle
的两大创新在于无线传送和电子墨水屏。作为一个市面上从未见过的产品,这些创新点在决策时运用了逆向工作法,只有无线传送,才可以把图书馆装到自己的口袋,而不是先考虑技术如何实现;只有电子墨水屏,才能实现接近纸质书的阅读体验。从客户的需求出发,倒推出产品的核心竞争点。这是典型的应用场景。

总结

逆向工作法本质上是思维方式的改变,由公司内部转变成市场客户,把战略的设定基于「不变的」的基本点,倒推执行。

在大数据领域,数据源有多种途径,如服务端、数据仓库、客户端等。客户端包含 Android、iOS、网页、小程序,以及 Flutter、React Native、uni-app 等第三方框架或平台。对于客户端应用和网页而言,埋点是大数据分析系统中不可或缺的组成部分。

什么是埋点?

自 2010 年起,国内涌现出一批专注于用户行为分析和自动化运营的大数据服务商,如神策数据、GrowingIO、易观、火山引擎等。在为银行、证券、零售、企业等多个行业提供服务的过程中,我们意识到一个基础且关键的点:数据根基的重要性

常见的问题有:为什么我的数据丢失了?为什么不同平台的数据量存在巨大差异? 这些问题时常发生。这些问题都印证了一点:数据质量对整个系统至关重要。

数据质量的重要性

如果数据质量出现问题,后续的分析和运营几乎无从谈起。即使生成了一份看似完美的报表和结论,其背后的真实性依然存疑。

常见的埋点类型

1. 代码埋点

代码埋点,顾名思义,就是通过代码实现数据上报的方式。它的优点是灵活性高,可以根据业务需求采集更具针对性的数据,提升数据分析的精确度。

但它的缺点同样明显:代码埋点需要随 App 版本发布才能生效,周期较长,开发成本较高。随着时间推移,滚动增加的埋点可能导致质量和效率的下降。

2. 可视化埋点

可视化埋点,即通过直观的界面操作,用户可以通过点击、选择等方式轻松完成埋点操作。这种方式降低了技术门槛,使得没有开发背景的人员也能独立完成埋点工作。

这种方式虽然提高了便捷性,但也存在埋点碎片化的问题,尤其是在 App 或网页频繁更新时。比如,今天设置的埋点有效,可能几个月后就失效了。此外,不同平台(如 Android、iOS、Web)仍需分别配置,增加了工作量。

可视化埋点和代码埋点相辅相成,适用于不同的业务场景。例如,在 App 内嵌的 H5 活动页面上,运营人员可以通过可视化埋点轻松满足需求。

3. 无埋点

无埋点,也被称为全埋点,是通过集成 SDK 的方式,自动采集用户行为数据,如页面浏览、停留、点击、离开等用户操作信息。这种方式的最大优势是显著降低了开发成本,便于快速采集基础的用户行为数据。

然而,无埋点的局限性在于只能采集标准的用户交互数据,无法捕捉具体的业务信息。例如,用户购买了哪件商品、商品的价格等细节数据是无法自动获取的。

4. Tag Manager

Tag Manager(标签管理器)在国外较为流行,典型代表是 Google Tag Manager。它不仅仅用于埋点,还可用于管理网站或 App 上的各种追踪代码。

Tag Manager 结合了代码埋点和可视化埋点的优点,尤其适合 Web 场景。由于 JavaScript 的灵活性,Tag Manager 可以根据设定的规则动态下发代码,避免了每次更新代码都需重新发布的问题,埋点也能实时生效。然而,对于移动端,它的应用场景则相对有限。

未来,国内或许也会诞生类似 Google Tag Manager 的工具。

总结

无论采用哪种埋点方式,都需要结合实际的业务场景进行选择。如果是偏业务类的信息,服务端埋点更为合适;而偏向应用交互的信息,则适合在客户端埋点。对于开发资源紧张的团队,可以选择无埋点或可视化埋点;若追求数据的全面性和灵活性,则代码埋点是不二之选。

归根结底,埋点的核心是围绕业务指标服务,而不是追求面面俱到。合适的才是最好的

0%