决胜B端 产品经理升级之路

good

他的这本书描绘了B端产品经理的成长路线图,并且分享了相关的产品设计经验以及可供参考的方法论,我从中受益匪浅。 P7

——王建斌,饿了么星选用户运营高级总监B端产品和C端产品的差异很大,比如B端产品主要用于提升企业效率、降低企业运作成本,使用者是企业用户;C端产品主要用于满足个人需求,使用者是个人。 P8

随着产业互联网的兴起,各大企业对内部运营效率越来越重视,B端产品是企业提升运营效率的核心武器,在企业持续的精细化运营管理中具备不可替代的作用。 P9

——郭兴锋,美团外卖后台产品负责人我曾在传统商业银行与互联网企业工作了近20年,深感不同类型企业中的软件设计人员在意识形态、思维方式、价值取向、行事风格上的巨大差异。 P10

本书讲述清晰、透彻又发人深省,仔细阅读,收获良多。 P11

没想到发表的几篇长文非常受欢迎,均被几家网站首页置顶,并在微信公众号推送,甚至还被技术类媒体InfoQ、聊聊架构、极客时间转载。 P13

成果本书一共分为4篇。 P14

致谢写书是一件痛苦并快乐的事情,从2018年2月确认全书的内容大纲、2018年3月开始写作,到2019年1月完成初稿,然后经历了多次反复修改,直到2019年4月完成终稿,这本书的写作耗时近一年半,可以说凝聚了我的心血。 P15

本篇第1章将带你了解这些知识。 P28

即便入行几年的产品经理,也可能对产品经理的分工和发展方向存在困惑。 P29

1.1.1 产品经理的起源产品经理的概念起源于20世纪30年代的宝洁公司。 P30

Brand Man的理念被引入中国后,和本土管理模式融合,并以“产品经理”的名字流传开来。 P31

目前BA岗位在传统企业依然大量存在,其工作性质和互联网公司业务端产品经理岗位非常类似,但又有不同之处。 P32

这种新的在线业务模式对软件产品设计人员提出了全新的要求。 P33

移动端的重要性逐渐超越PC端,成为新的流量入口。 P34

本书后面讲到的产品经理,如无特殊说明,都是指互联网产品经理。 P35

但是由于负责数据与策略产品需要具备较强的相关专业知识,所以在实际中并不由普通的B端产品经理或C端产品经理负责,而是由专门的数据与策略类产品经理负责。 P36

用户通过C端产品体验企业所提供的商品或服务,C端产品是企业和客户接触的重要媒介之一,在企业中具有举足轻重的地位。 P37

· 运营决定存亡:对于C端产品来说,产品运营和产品设计同样重要,共同决定了产品的成败。 P38

· 社交类产品:实现陌生人、熟人之间的沟通交流,例如微信、陌陌、脉脉等。 P39

新形式带来的新挑战是,如何通过线上渠道导入流量、提高转化率:需要通过各种运营手段,吸引有购买保险诉求的客户进入公司网站或landing page(着陆页);需要保证自己的产品界面清晰、交互友好,以实现让尽可能多的潜在客户转化为成交客户;同时通过各种策略和机制,鼓励客户帮助产品传播口碑,引入更多流量和销售线索。 P40

例如,我们熟悉的电商,对于消费者来说,只需要使用App挑选商品、下单、收取快递,退款退货也都能在App中轻松完成。 P41

· 收益难以量化:B端产品要支持、解决业务问题,但业务成效的影响因素非常多,很多时候并非取决于B端产品设计的好坏。 P42

B端产品的技术架构可分为:· B/S(Browser/Server)架构,即浏览器/服务器模式,用户通过浏览器访问系统。 P43

B端产品中还有很独特的一类,叫SaaS产品。 P44

· 报表设计:将成熟的数据分析体系和思路,通过操作简便、易于理解的可视化工具呈现出来,让阅读者能够轻松、快速地通过图表解读数据。 P45

例如,一套BI产品设计的好坏,并不在于其可视化效果是否炫酷,而在于其呈现的指标体系、内在逻辑是否合理,以及能否对业务做到全面的解读和诊断。 P46

例如,抖音会设计符合自己App风格的广告素材与投放管理后台。 P47

AI技术使产品更智能,更迎合新时代的需求。 P48

常见互联网公司的盈利模式可以概括为四类,分别是广告变现、增值服务、佣金提成、买卖差价,每一类盈利模式都有自己的产品建设诉求,以及独特的运营和管理模式。 P50

同样,各家公司为了尽最大可能地利用流量,给广告主提供优质服务,也都选择自主研发广告投放和管理产品。 P51

百度、今日头条的目标客户是所有中小企业,上千人规模的电销呼叫中心团队不停地打电话寻找线索、商机,说服客户投放广告;美团、饿了么的目标客户是所有商家,上千人规模的地推团队挨街挨巷地拜访门店,说服客户进行曝光推广。 P52

过去,大家的固定支出可能只有水费、电费、有线电视费,现在,邮箱服务、视频服务、音乐服务、存储服务、个人助理App需要的花费,也都成为固定开销了。 P53

1.3.4 买卖差价买卖差价,即自营模式的互联网企业通过赚取商品或服务售卖的差额来获得收入的盈利模式。 P54

例如,滴滴快车采用平台模式运营,专车则采用自营模式运营。 P55

本章就一起分析一下,选择B端产品方向会给你带来怎样的好处,并对不同背景的同学步入B端产品方向给出建议。 P58

然而今天,流量变得越来越珍贵,单纯的线上运作非常容易被对手抄袭并超越。 P59

试想每晚睡觉前你有1小时的自由时间,几年前只能看看视频和新闻,但现在你要决定是刷今日头条还是沉浸在快手中。 P60

· “美菜网”实现了对餐饮采购行业的创新。 P61

· “社区拼团”实现了对社区零售的创新。 P62

· 众多无人货架公司在城市内摆放了成千上万的货架,如何完成商品的采购、补货、货损处理?这需要上百人的线下团队完成一系列的工作。 P63

例如,对于外卖公司来说,配送员的效率是业务成败的决定因素之一,而配送员的效率取决于TMS的建设情况。 P64

此外,行业之间、领域之间的信息打通,全面线上化也是势在必行的,2B和2G领域的消费者和客户都希望享受更加便利、优质的服务。 P65

B端产品经理既要涉足软件设计领域,又要涉足业务运营领域,有机会接触并深入理解企业运作机制,而我们知道,无论商业模式如何创新,企业的运作机制都是相通的。 P66

· 对于为餐饮业带来革新的美团公司来说,有大量的地推人员和客户需要管理,而且销售区域和销售过程都需要基于门店坐标定位进行管理,传统的OCRM(操作型客户关系管理)软件根本无法满足这种对地理位置管理有很高要求的客户管理需求。 P67

首先我们看一下今日头条招聘的产品岗位的类型分布,如图2-1所示。 P68

另外,美团拥有支付牌照,智能支付产品是其战略布局中很重要的一部分,需要具备相关专业知识的产品经理来负责,招聘岗位占比达到7%,我们把它单独提出来作为一个分类展示。 P69

而我们前面已经分析了业务模式创新催生了众多与线下结合的公司,这些公司都属于重业务模式的公司,所以,不论是现在还是可预见的未来,市场对B端产品经理的需求将持续旺盛。 P70

技术知识储备规划、设计B端产品需要讲究体系架构、模型抽象,这和技术体系架构是一脉相承的,甚至很软件技术架构的设计思想也会体现在B端产品的设计中,例如SOA、微服务。 P71

业务与经营管理知识B端产品经理从某一个细分业务方向入手,可以收获丰富的业务知识,从业务的角度理解公司的运转。 P72

举个例子,我之前的一位同事去某电商做了配送产品经理;两年后,O2O火了,配送方向的人才紧缺,他被一家外卖公司挖去做配送产品负责人;又过了两年,同城闪送火了,因为他在配送业务领域积累了专业和丰富的经验,所以他加盟了某闪送公司,成为产品合伙人,统管产品研发和业务运营。 P73

咨询顾问现在很多互联网公司都会将自己的成熟技术方案、解决方案进行商业化包装,并向外输出,此时产品经理要承担售前咨询顾问的工作,与销售团队一起发展客户,帮助客户分析业务问题,给出解决方案。 P74

· 了解市场上所有类似业务模式公司的业务特点、产品特点。 P75

根据服务的对象,大体上可以将B端产品划分为三个方向:支持业务团队的业务平台方向、支持员工内部协同的办公协同方向,以及平台业务模式中支持供给方的商家管理方向,这三个方向覆盖了企业对内、对外所有的经营管理与业务运营工作。 P76

广义上的CRM包括从客户开发、管理、营销、服务的客户全生命周期管理;狭义的CRM是指给销售人员使用的销售过程管理软件。 P77

· CallCenter:呼叫中心。 P78

对于开展了多个业务的企业,建设一套统一的客户账号管理平台,可以让客户更加顺畅、便捷地体验企业的所有产品和服务。 P79

· Msg:Message Service,消息服务。 P80

交易平台的部分模块可能会发展为公司的基础服务产品,例如支付模块就可能发展为集团的公共服务,为所有业务线提供支持。 P81

· 内部IM:内部沟通工具,有条件的公司会选择自研,多数公司会选择钉钉、企业微信、Lync(外企常用)等。 P82

图2-7 商家管理系统的常见模块商户管理系统对于入驻企业平台的商家,企业需要利用强大的后台系统来进行全面管理和控制,这就是商户管理系统,主要实现处理商家账号、管理商家订单、进行风险评估、资质审查等功能。 P83

图2-8 B端产品的方向和分类请大家注意,图2-8只是列出了一些常见的产品和模块,并不是企业中可能涉及的全部产品。 P84

具体来说,C端产品经理转型B端产品方向的优势、挑战和建议如下。 P86

· 转型建议? 将某个C端产品背后的业务方向,或者自己了解或对口的业务方向作为切入点。 P87

商业变现产品经理如何转型商业变现产品方向,尤其是广告相关方向,是一个专业性极强的领域。 P88

AI产品经理转型B端产品方向的优势、挑战和建议如下。 P89

· 优势? 懂技术。 P90

我见过很多从传统软件公司转型互联网产品经理的人,他们在产品经理的岗位上做得非常成功。 P91

? 尝试主动做出业务决策,改善业务。 P92

为了便于大家理解,我们将结合一个完整的案例——设计一个分销平台,来讲述B端产品设计中各个环节的方法、要素和技巧。 P93

此外,我们还将对比B端和C端产品建设流程的区别,帮助大家理解二者的不同。 P95

第一种情况不需要设计完整的产品,只需要设计一个方案,让业务以最低成本做初步尝试,论证可行后再考虑产品化支持。 P96

通过业务调研找到关键业务问题,这是设计产品解决方案的核心前提。 P97

· 核心业务流程:梳理整个业务主干流程,并确定其中哪些环节需要由该产品实现线上化。 P98

在后续的学习中,你会慢慢理解为什么数据建模是产品细节设计成功的基石。 P99

运营迭代新系统上线后,产品经理要和业务人员一起参与产品的运营迭代工作,包括宣传、推广、使用效果分析、问题和反馈意见的收集,以及持续的迭代优化。 P100

其中,C端产品的建设流程是根据经验总结抽象出的常见流程,不同的需求和背景下的流程可能略有不同。 P102

当然,如果是一家SaaS软件公司,设计的B端产品要卖给具体客户,那么设计的起点就和C端产品一样,是进行商业分析,而不是进行业务调研。 P103

所以在选取最小功能集合时,C端产品要聚焦用户的核心痛点,C端MVP可能只包含一两个功能点。 P104

在图3-2中,我们将C端产品运营迭代的过程绘制得更长一些,以体现运营工作对C端产品的重要性。 P105

首先,我们来介绍一下案例的背景。 P106

项目期间CTO全力提供资源支持。 P107

在制订项目计划时需要略微卡紧节奏,我们按照两个月来安排,这样能够为各种意外情况留一些应对时间。 P108

在刚开始的阶段,这个表格可能只是产品经理自己的行动计划,并没有向团队或项目组展示,但是它可以让产品经理对事情有基本的判断和预期。 P109

业务调研要讲究方法和技巧,了解并运用这些方法和技巧,能够让业务调研工作事半功倍;反之,很可能没有太大的收获,无法为设计提供有效的参考。 P111

具体应该如何确定调研目标,详见4.2节。 P112

在实践中,需要结合具体情况选取合适的调研方法,例如,某业务团队一共有10人,可以很方便地对每个人都进行访谈,因此就没有必要准备调查问卷了;又如,某个项目预留的调研时间非常紧迫,因而无法安排轮岗实习。 P113

需要注意,设计良好的B端系统能够规范流程、提升效率,但这不代表所有的业务问题、管理问题都可以通过软件系统来解决。 P114

那么,面对一项并不熟悉的复杂业务,该从何处切入呢?我们可以参考典型的业务分析框架,如图4-2所示,我们按照它拆解并分析业务,就可以分析得全面、透彻,梳理出现状,总结出问题。 P115

理解战略定位、战略计划,可以在产品方案设计的关键点上做出正确选择。 P116

例如,某流量巨头App对销售渠道做了这样的规划:针对一线城市,计划开展大客户地推直销、中小客户电销直销;针对二三线城市,计划开展代理商合作模式。 P117

4.2.3 执行层执行层包含比战术层更具体的执行策略,包括管理层和运营层两方面。 P118

4.3.1 深度访谈深度访谈是了解业务全貌的最快的手段。 P120

提前研究访谈对象访谈前要从各种渠道了解访谈对象的背景,尤其针对高级别访谈对象,了解得越充分、细致越好。 P121

假设你是一家外卖公司的配送产品经理,负责设计配送员接单用的App。 P122

产品经理要当一个冲在前线的人,而不是在后方拍脑袋的人。 P123

避免诱导性问题在问卷设计中,要避免诱导式的提问,例如“我们要做一个更好的个人管理功能,您会使用吗?”而要尽量采用中性描述,例如,“您使用这款产品的体验如何?”也尽量不要设置非此即彼的问题,例如“您是否喜欢我们的产品呢?”可以提供多个描述主观感受的选项供调研对象选择。 P124

4.3.4 数据分析调研时,有必要掌握业务的关键过程指标和结果指标。 P125

例如,如果研究CRM,可以试用SalesForce、销售易等;如果研究电商ERP,可以试用管家婆、商派等;如果研究报表可视化,可以试用Oracle BIEE、IBM Cognos、Tableau、百度指数等。 P126

图4-4 B端与C端产品业务调研的区别4.4.1 调研目标不同B端产品面向企业用户,产品目标是更好地支持业务运转。 P127

4.4.3 调研方法略有不同B端产品和C端产品的调研方法大体相同,但在竞品分析的处理上区别很大:· C端产品必须做竞品分析,因为将来需要和那些已经存在的同类产品瓜分用户。 P128

本书M公司的分销业务调研属于第二种情况。 P129

管控模式通过对业务负责人的访谈,我们了解到M公司对下属部门采取了事权下放的管控模式,下属部门在遵守基本规则的前提下拥有售卖定价权、运营管理权等权利。 P130

通过梳理组织架构图可以理解人员结构和岗位设计,为系统的权限管理设计做好准备。 P131

图表采用了经典的泳道流程图,横轴代表相关的业务部门,纵轴代表涉及的业务系统。 P132

由于生鲜价格实时变化,和客户签订的商务合同又要求在商品售价的基础上按一定折扣出售,因此下单人员每次需要根据客户提报的采购清单拉取当天的商品售价,按照该客户的折扣系数表换算售卖价格,再手工改价录入订单系统。 P133

· 不能及时控制账期客户的回款进度和账期风险。 P134

· 支持客户多门店分别定价与下单(高优)。 P135

[3]所谓账期,是B2B分销交易中很常见的一种结算模式,即商品发货后买方并不马上给卖方结款,而是在约定的某个时间,例如每个月15号,先进行对账,无误后,在一定时间内完成打款。 P136

B端产品的整体方案设计需要遵循自顶向下的设计思路,可以依次设计核心业务流程、产品定位、应用架构、功能模块、演进蓝图,从抽象到具体,逐步勾勒出B端产品的轮廓。 P137

根据第4章对M公司的业务调研,我们总结出当前紧迫的业务诉求包括客户自主下单、自动定价,以及支持客户对多门店分别定价与下单。 P138

我们将这套系统暂且称为分销系统,将图5-1中的流程图略修改,体现出包含新系统的新业务流程图,如图5-2所示。 P139

通过对M公司分销业务的核心流程梳理,我们已经对分销系统在整个系统中的位置有了初步判断,现在,我们进一步思考更精确的形态和定位。 P141

· 运营管理后台(PC端):为分销业务部门提供客户及商品定价管理的业务支持功能。 P142

在设计一套新系统时,必须考虑如何和公司现有系统架构融合,不同系统的模块之间如何衔接。 P143

接着我们要思考如何管理客户账号体系。 P144

这样就实现了分销平台和仓配系统的完美解耦。 P145

产品经理设计的功能模块代表了其对业务本质诉求的理解和提炼,蕴含了他对业务、系统未来发展的期望。 P147

从购买流程的角度考虑,商城需要具备以下功能或模块:首页、搜索、推荐、列表页、详情页、购物车、结算页、收银台。 P148

· 客户管理模块,支持子账号管理与门店管理。 P149

· 报表管理:报表管理模块将提供各类分析报表,实现对业务运作情况的监控和诊断。 P150

但是我们不可能一次实现全部功能,而要根据业务优先级,拆分成几期来完成,所以接下来需要做减法:确认产品的功能规划与实现节奏,就是常说的演进蓝图(Roadmap)。 P151

例如,报表管理功能可以通过定期运行SQL语句实现;价格系数设置功能的使用频率低,可以由RD在后台改数据库完成;缺少搜索、推荐功能并不会对客户下单的效率产生明显影响,因为根据调研,目前每个客户维护的SKU数量最多也不过20个。 P152

设计软件产品时必须遵循自顶向下的设计思路,这是非常重要的,相信大家已经有了初步的感觉。 P153

本章将首先介绍业务数据建模,这是对业务进行抽象的过程,合理的建模会让后续的功能设计水到渠成,而不合理的建模会导致后续设计重复返工。 P154

为什么产品细节方案设计要从业务数据建模开始呢?这是因为软件系统的模块和功能实际上就是对现实世界的对象和规则的抽象。 P155

6.1.1 设计理想版的分销业务客户模型在业务数据建模工作开始之前,我们首先回顾一下客户诉求。 P156

企业往往有多层级管理的需求,需要软件系统支持多层级业务体系。 P157

这个组织机构树究竟是如何支撑各种灵活的客户下单管理需求的呢?我们在6.2.2节中会进一步分析。 P158

因此,产品经理最终决定采用一套简化版的客户模型来支持一期业务,不过这个简化版客户模型完全可以在需要时升级为理想版的客户模型。 P159

根据上述规则对理想版客户模型进行简化,如图6-4所示。 P160

如果没有梳理清楚这些关系,在做功能和界面设计时必然会一头雾水、漏洞百出。 P161

可见,设计人员在设计之初就需要做好预判,虽然早期业务诉求中账号和门店是一对多关系,但是因为在现实世界中多对多关系是一种合理的存在,因此数据模型依然要按照多对多的关系来设计。 P162

流程合理、角色清晰是系统正确设计的前提和保障。 P163

· 分销–销售人员:M公司分销业务的销售人员,负责完成客户开发与合约签订(目前继续采取线下作业的方式)。 P164

· 客户–管理员:分销客户的管理员,维护并管理客户公司内的所有子账号、门店。 P165

运营人员添加了客户和客户管理员账号后,必须由分销业务总部的管理人员(角色名称为“分销-管理员”)在分销运营管理后台进行审核,这是为了控制风险的必需环节。 P166

通过跨职能分系统流程图,可以清晰地看出谁(操作角色)在哪儿(哪个系统)做什么(完成什么工作)。 P167

这种安排相当于要求员工身兼两个岗位的工作,在一些规模比较小的公司或业务开展初期的团队中,这种情况比较常见;在管理步入正轨的公司中,这种情况很少见,如果在系统管理中发现某些员工需要被赋予多个角色,最好和业务部门确认一下岗位的分工与定位是否合理。 P168

我们以分销-运营人员创建客户和客户管理员账号,以及分销-管理员审核客户这两个子流程为例,演示如何绘制页面流转图。 P169

图中对每个页面做了编号,如果两个流程中某一页面的编号相同,则代表同一个页面,例如两个流程中都有“2.1 客户列表页”。 P170

表6-1 分销业务要开发的页面(部分)从本质上讲,一套软件系统就是对不同数据对象的增删改查操作的集合,这个特点在业务系统中更加显著。 P171

此时,界面设计已经是水到渠成之事。 P172

6.3.2 线框图的绘制产品经理需要将每个页面的排版样式、控件设计及交互效果,用通俗易懂的形式表达出来,以方便其他同事快速理解。 P173

虽然互联网公司的分工越来越细致,有些公司甚至会给产品经理配交互设计师,但是大多数情况下,B端产品经理还是需要自己完成交互设计的。 P174

反馈原则(Visibility of system status)系统应该在合理的时间、用正确的方式,向用户提示或反馈目前系统在做什么、发生了什么。 P175

在人机交互设计中,程序的沟通和表达、功能的呈现,都要用最自然的、用户容易理解的方式,避免采用计算机程序语言的表达方式。 P176

对于误操作,软件系统应该尽量提供“撤销”“重做”或“反悔”的功能,让系统迅速返回错误发生之前的状态。 P177

如果你特立独行地把个人中心放在第一个位置,或者采用奇怪的图标作为个人中心的icon,用户使用时肯定会觉得别扭。 P178

这样做一方面可以让问题更简单,另一方面可以让用户避免或减少无谓操作。 P179

计算机应该减轻人们的记忆负担,而不是相反。 P180

灵活易用原则(Flexibility and efficiency of use)系统的用户中,中级用户往往最多,初级和高级用户相对较少。 P181

在视觉设计中,要掌握好“突出标记”的度,以及内容的呈现方式。 P182

访问网站时,如果页面不存在,服务器提供的标准错误提示是404错误(如图6-19左图所示),很多用户并不理解404是什么意思。 P183

帮助信息应该易于检索,通过明确的步骤引导用户解决问题,并且不能太复杂。 P184

列表页是B端产品中最重要、最常见、最基本的元素,并且列表页的设计非常讲究技巧,因而我们将列表页设计单独列出一节,详细阐述。 P185

我们可以对列表页进行高度抽象,因为在所有列表页上实现的不外乎增删改查操作。 P186

其次,增加某个搜索条件之后,还可以设置它的默认搜索值,例如可以对图6-22左侧虚线框中的“PRD开始日期”字段设置搜索默认值,从图中也可以看到,JIRA的日历控件功能非常强大,可以进行各种时间检索类型的设置,比如过去多久以内、多久之前、某个时间范围之间等,非常灵活。 P187

图6-24 JIRA列表页的批量操作功能进入批量操作界面后,如图6-25 所示,在“步骤1”中让用户选择需要批量处理的条目,在“步骤2”中选择要完成的操作,例如编辑问题、移动问题等,然后继续后续操作。 P188

6.3.5 列表页设计Bug“找茬儿”下面我们通过一个案例,让大家体会设计不合理的列表页界面导致的各种问题。 P189

如果每天要重复数次类似的操作(B端产品的用户往往需要每天重复使用某些功能),那将是很崩溃的。 P190

问题三:技术风险与安全风险在列表页设计中,分页问题是一个典型的问题,如果处理不好,会造成很多潜在隐患。 P191

当然,具体的分页设计要结合实际业务来处理。 P192

图6-27就是对原型绘制软件“墨刀”的某个模板中的一个页面进行修改后,得到的分销运营管理后台的门店管理列表页。 P193

什么叫标准的控件呢?Visio或Axure里提供的可以绘制的控件就是标准控件。 P194

业务报表的核心价值是掌握事实、发现问题、分析原因、产生对策。 P195

从什么维度进行汇总?这里面蕴含了观察、监控业务的视角和思路,因而汇总表的设计具有较高的难度,需要产品经理和业务人员、领导层等一起讨论决定,形成一套科学的指标体系,来准确、有效地监控业务运转中的各种情况。 P196

例如,我们需要监督并考核线下销售团队,该如何设计一套分析体系来进行合理的评估、管理呢?可能的思路是对销售过程和销售结果两个方向进行监控诊断,对于销售过程,重点在于判断销售人员的努力程度,可以进一步拆解为电话拨打量、线下拜访量、客户线索录入量等;对于销售结果,重点在于判断销售的业绩是否达标、利润率是否良好。 P197

例如,是采用数据表格还是柱状图呢?在这个环节,产品经理要和实际用户多讨论,寻找最佳的呈现方式。 P198

管理人员要认真对待、分析报表中各种数字的变化、波动。 P199

因此实际中往往不这么做。 P200

除非有很特殊的呈现需求,其他情况都强烈推荐采用成熟的报表引擎。 P201

图6-31 汇总报表表样动态仪表盘也叫管理驾驶舱,是BI中的概念,在业务系统中也经常采用。 P202

图6-32 动态仪表盘表样图6-33是报表引擎提供的套打报表表样。 P203

6.4.3 二维表格设计Bug“找茬儿”在报表的可视化呈现中,二维表格(即常见的汇总统计表、明细表等)是最常见的数据呈现形式。 P204

表6-2是一张非常常见的销售统计二维表格,请大家仔细观察,看看你能找到多少个设计瑕疵。 P205

· 没有使用占位符。 P206

不论是何种情况,产品经理都要尽量贴近业务,即便是被动地接受报表需求,也要努力思考其背后的设计思路。 P207

鉴于此,报表上线后,应该谨慎、小心地进行一段时间的并行验证,即将线上系统的计算数据和线下手工计算的数据进行核对、验证。 P208

B端产品经理需要了解数据仓库的基本概念,包括掌握数据体系的逻辑架构,理解数据集市、星形模型、数据立方体等基础概念,这对报表设计十分有帮助。 P209

6.5.1 什么是数据埋点数据埋点的历史和含义在Web 1.0时代,网站设计人员及分析人员需要了解网站的访客数量、访客来源、页面访问情况等信息,从而优化网站结构和内容。 P210

知名的网站分析软件有国内的CNZZ(后来和友盟合并)、百度统计,国际上有Adobe的Ominiture和大名鼎鼎的Google Analytics。 P211

Web端埋点工具GA:功能强大、全面,遗憾的是国内访问GA站点很不稳定,经常无法访问。 P212

6.5.3 埋点工具的数据分析完成埋点后,埋点软件就开始采集用户访问网站或使用App的各种行为数据了,登录埋点工具管理后台,产品经理便可以查看、监控数据,进行各种有趣的分析,我们主要以GA为例进行介绍。 P214

一张典型的GA分析报表如图6-38所示,这张报表呈现了网站页面的访问情况,包括Pageviews(页面浏览量)、Unique Pageviews(页面唯一身份浏览量)、Bounce Rate(跳出率)、Avg.Time on Page(平均停留时长)等基本信息。 P215

桑基图桑基图(Sankey Diagram)也叫能量分流图,可以通过桑基图方便地观察流量的流转情况。 P216

图6-40 GA的Cohort分析图访客分析客观分析全面的用户行为数据,是线上业务取得成功的重要因素之一。 P217

有很多埋点软件甚至还提供录屏功能,可以回放用户的操作过程。 P218

· 对每一个搜索选项进行埋点监控,观察每个按钮控件的点击情况。 P219

GA:https://analytics.google.com/analytics/web/易分析:http://www.yeefx.cn/demo.show.php6.5.4 B端产品与C端产品数据埋点的区别B端产品和C端产品在数据埋点的诉求和方案上有较大区别,产品经理应该准确理解两者的不同,以便确定合适的方案。 P220

C端产品多为移动端App版本,用户的操作都在屏幕的方寸之间完成,保证良好的用户体验非常重要,因此C端产品对各种点击、交互行为的监控非常严格,会对所有交互行为做细致的埋点,以便全面掌握用户的动作,并进行准确优化,工作量会大很多。 P221

对于这种情况,我们没有开发两套客户列表页,而是在一套客户列表页上设计了不同的权限,非常方便地满足了不同角色的需求。 P222

6.6.1 功能权限设计设计页面的功能时,要考虑页面中的各个功能点是否要做权限控制。 P223

“门店列表页”上列出了各个门店的名称,每个门店名称都是一个超链接,点击会跳转到相应的“门店详情页”。 P224

[书籍分 享V信 iqiyi114]6.6.2 RBAC权限模型在6.6.1节中,我们通过一张权限表描述了页面、功能点和角色之间的关系。 P225

当有新用户时,只需要设置其所在的用户组,就会将用户组关联的权限赋予新用户。 P226

完整的RBAC模型理论称为RBAC96模型族,该模型对角色的继承关系、权限的约束关系等更复杂的话题进行了深入分析和指导。 P227

例如,针对订单列表页,数据范围可能是某个城市的所有订单,也有可能是某个账户下的所有订单,也可能是某几个账户下的所有订单。 P228

分销业务的组织机构树如图6-45所示,深灰色节点代表机构,浅灰色节点代表门店或账号,账号被赋予的角色在相应的虚线框中进行了标注。 P229

· “账号3”属于“上海机构”的子节点,被赋予“客户–采购员1”的角色,数据权限范围是“当前节点及其子节点”,因此“账号3”可以查询“上海机构”节点下的所有订单数据。 P230

接下来我们重点讲解BRD和PRD。 P232

实际上,很多需求都只是需求提出者的灵光一闪的想法,并没有经过严谨的思考。 P233

但是,随着公司规模扩大,规范的PRD管理是非常必要的,这可以让项目开展更加有序,大大方便产品经理和研发人员的沟通,让知识传播与传承更加准确有效。 P234

特别提醒,模板中有明确的版本变更记录表格,产品经理必须严格填写变更记录表,记录文档修订历史。 P235

如果没有标识清楚,多次收到修订文件的同事会分不清哪个文档是最新的,极有可能搞错版本,造成工作错误,引起很多不必要的麻烦。 P239

按照修订日期来标识文档的示例如图6-48所示,看起来同样很清爽。 P240

文档管理要做好规范命名、版本管理、存档管理,虽然略显烦琐,但却是必须重视、贯彻的工作。 P241

UML规范中定义了类图(Class Diagram)、用例图(Use Case Diagram)、对象图(Object Diagram)、时序图(Sequence Diagram)、协作图(Communication Diagram)、状态机图(State Machine Diagram)、活动图(Activity Diagram)、组件图(Component Diagram)、部署图(Deployment Diagram)等多种图形方式,每一种图形都用来从某个视角解决某类程序设计的抽象描述问题。 P242

即使没有听说过ER模型,你在工作中肯定已经接触过它。 P243

图6-50 机构和门店在UML格式下的ER图2如果没有Visio,也可以用PowerPoint来绘制UML标记风格的ER图,并且不用拘泥于形式,重点在于说清楚两个对象的对应关系,即连接线上的数字是重点。 P244

国际标准组织ISO(International Standard Organization)在1970年定义了流程图的基本符号规则,在实践中,为了便于不同背景的读者阅读理解,建议尽量采用简单的绘图规则,例如,只使用开始、结束、执行、判断这四种标记符号来绘制流程图,而不要引入其他更加复杂、高级的标记符号,以保证流程图容易理解。 P245

· 尝试调整泳道的顺序,以便保证流程看起来清晰干净,而不是交叉、缠绕在一起。 P246

通过研究状态之间所有可能的流转规则和逻辑,能够识别状态设计的合理性,并梳理清楚业务规则。 P247

图6-54 活动图示例6.8.5 用例图用例图(Use Case Diagram)从用户视角来描述系统的操作功能。 P248

在实际工作中,产品经理应该尽量使用简单的方式,让别人理解自己的设计和意图。 P249

接着介绍软件开发、程序设计的一些本质问题,帮助大家对技术体系形成基本认知;理解了这些内容,再有针对性地深入学习技术知识,会更加顺畅有效。 P251

老李:一名工作5年的RD,经验相对丰富,做事相对保守。 P252

”小王:“啥?这么简单的功能,要20人日,你在坑我吗!?”老李(有点生气):“什么叫坑你,我是实事求是地评估!”小王:“不就是配几个词,然后用户搜索的时候提示一下吗?怎么需要20人日?你给我讲讲凭什么,讲不清楚我就找你领导!”老李(愠怒):“爱找不找随便你,不过我跟你说清楚,实现你这个设计就需要20人日。 P254

这样做需要多久?”老李:“这样做的话,不需要设计数据库,只保存一个文本文件,前端控件也非常简单,预计前端开发需要2人日,后端开发需要1人日,测试需要0.5人日,总共3.5人日吧。 P255

如果知识库系统有类似百度统计那样的功能,就可以通过知识库系统来统计热词来源和搜索量。 P256

)小刘(思考中):嗯,实现这个需求需要增加热词搜索功能,需要有一个热词配置界面。 P257

”在本案例中,小刘自己对产品功能的实现复杂度有充分的判断,并且因为老李预估的水分太大,所以拿老杨稍微压了一下老李,老李最终重新给出合理的工时预估。 P258

懂技术的产品经理在设计产品方案时,能够在一定程度上预估技术实现的可行性和实现成本,或至少能具备基本的认知,知道什么时候、什么情况下需要和技术人员提前沟通讨论,从而保证产品设计合理可行,既能提升合作效率,也能赢得技术人员的尊重和信任。 P259

避免技术过度设计所谓技术过度设计,是指技术人员设计了没有必要的代码灵活性和复杂性,而后续的业务根本用不到这些特性,宝贵的时间和资源被浪费。 P260

如果产品经理懂技术,则可以感觉出有问题;否则,工时评估对产品经理来说就是一个纯黑盒操作,无法进行判断和把控。 P261

此时,如果产品经理对工程师的工作指指点点,会招来反感。 P262

遇到这种情况,产品经理一定要严肃地和工程师、领导进行沟通确认。 P263

7.4.1 具备基本的技术知识体系理解一门编程语言编程,对于没有接触过的人来讲,是一件神秘且高深的事情:满屏幕的代码像天书,肯定需要投入巨大的时间和精力来学习。 P264

例如,学习使用Python爬取网页内容进行数据分析;学习使用Excel VBA进行复杂数据处理。 P265

这些常识都是软件设计随时会用到的基本知识,不仅在技术方案设计中会涉及,在产品方案设计时也会涉及。 P266

7.4.2 了解程序设计的MVC范式编程语言种类繁多,无论采用哪种语言进行程序设计,都要遵循经典的软件工程设计模式——MVC模式。 P267

前端方向是升级迭代非常快的技术方向,例如针对移动端,有JavaScript、Flex、Objective-C、Kotlin等前端语言;针对PC端,前端语言也从曾经的HTML+JS+CSS,到流行一时的富客户端RIC(Rich Internet Client),再到ExtJS、Node.js等。 P268

数据层数据层代表底层的数据存储。 P269

软件领域的接口和我们生活中所使用的硬件设备的接口(例如USB接口、苹果的Lighting接口、3.5mm耳机接口等)类似,每种接口都有约定的格式和规范,只要在设计时遵循了约定和规范,就能够方便地进行信息交换。 P270

同步调用模式是最常见的接口调用形式。 P271

5.浏览器收到服务器返回的数据文件,弹出窗口,提示用户选择文件的保存位置,并执行文件下载操作。 P272

2.前端提示“下载任务已提交,请耐心等待。 P273

软件的设计应该像搭积木那样,通过自由拼接组装来实现复杂的功能模块,这样既能保证系统的灵活性,又能避免重复开发,降低成本。 P274

因此,公司决定开发一套“Passport管理前台”,给业务人员使用。 P275

新版的技术架构如图7-11所示,这依然是基于MVC模式的设计方案,只是对业务逻辑层(Passport账号管理服务)进行了接口封装。 P276

我们常说软件工程就是在造轮子(服务接口和系统模块),对于功能相同的轮子,大家共用一套就足够了,没有必要针对每个系统重复制造功能相同的轮子。 P277

图7-13 M公司技术架构对分销业务的支撑在技术体系中,有两个非常重要的概念在支撑着接口化、服务化的设计理念的落地,即SOA(Service Oriented Architecture,面向服务的架构体系)和微服务。 P278

理解技术架构对设计产品架构大有裨益。 P279

图7-14 分销平台客户模型ER图首先来看账号表,表7-1是账号表的表结构与数据示例,DS_PASSPORT是表名,这张数据表中有ID、ORG_ID、NAME、STATUS、CREATETIME五个字段。 P280

要理解代码的含义,需要查看数据字典(针对数据库表结构的说明文档,包括字段的说明以及字段值的解释),或代码表(简称码表,有的系统会设计),例如后面的表7-6就是本案例的码表。 P281

我们知道,组织机构和账号之间是一对多关系,在关系型数据库中,如何实现这种一对多的关系呢?我们让表7-1中的ORG_ID字段与表7-2的ID字段一一对应,这样两张表就被联系起来了,就可以描述一对多的关系了。 P282

· FATHER_NODE_ID字段:机构表描述的是整个业务机构管理的树形结构,如何描述树形结构这种数据结构呢?可以通过一张二维表来描述,需要在二维表中定义每一行数据的父节点,即每一个机构节点的父节点。 P283

门店表7-3中的ORG_ID字段对应的正是机构表7-2中的ID字段,可以看出,两个门店的ORG_ID字段都是10002,对应同一个机构“北京社区之星有限公司”。 P284

我们可以通过这样一张数据表来描述多对多关系。 P285

以上示例展示的都是存储在数据库中的数据,当这些数据在业务系统中呈现出来时,可能是样的效果呢?数据通过分销平台门店列表页面的呈现效果如图7-16所示。 P286

编写SQL查询语句,实际上就是基于对表结构的理解,组合关联不同的数据表,获取想要的数据。 P287

· 要理解数据库表结构:如果不了解表结构,即便掌握SQL语法,也不知道如何入手编写语句。 P288

网站通过一个个案例讲解了SQL中的每个概念和语法,并且提供了非常强大的在线练习功能,这对学习SQL至关重要。 P289

在产品开发及运营推广工作中,B端产品经理要从整体上管理进度、控制风险。 P290

需要说明的是,在很多创业公司,甚至是具备一定规模的公司和团队中,并没有项目管理团队及专职的项目经理,需要由公司的产品负责人来制订项目管理制度初稿,并负责项目管理。 P291

这种情况下,如何才能保证产品研发团队高效运转?如何保证软件产品能够按计划交付?如何让用户满意?要解决这些问题,就必须从作坊式的生产模式转变为标准化、专业化的生产模式。 P292

设计并优化项目管理制度公司发展到一定规模后,就需要制订项目管理制度并严格执行。 P294

针对这种客观情况,在制订项目管理制度时,可以考虑放宽敏捷开发的要求,而不是强制执行两周一迭代的常规策略,甚至可以不要求采取敏捷开发方式。 P295

同样地,如果没有项目经理,这项工作往往由产品经理来承担。 P296

8.3.1 B端项目管理面临的挑战B端项目管理经常面临如下两个挑战。 P297

这是一个很明确的需求,会涉及如下几个系统的修改:· 需要对这些客户进行标识,因此存储客户资料的客户主数据系统需要增加一个标记字段。 P298

· 公司级跨端项目:这类跨端项目级别高,领导的重视程度高,资源有保障,一般有独立或被隔离的资源支持,决策和推进会相对顺利很多。 P299

如果项目发起方都不知道项目收益和价值是什么,或者无法证明项目收益和价值,必然无法说服其他合作团队。 P300

保持强的推动力与执行力产品经理要负责推进整个项目,在面对困难和挫折时,要不气馁、不放弃,像“小强”一般战斗力十足。 P301

8.3.3 如何把控项目进度B端项目面临的第二个挑战是项目的周期长,复杂度高,变数大,项目进度不好把控。 P302

通过机制把控进度制订了详细的工作计划,明确了责任人、交付物、时间点,一切安排得井井有条,但这并不代表工作就能顺利开展,也不代表一切都会按计划执行,因为在项目开展的过程中,肯定会出现各种问题和意外,例如需求变更、方案调整、人员流失等。 P303

· 开每日站会:站会是敏捷开发中经典的工作方式,对于软件研发项目,在团队内部开每日站会的确是非常有效的工作机制。 P304

项目经理要利用项目日报或周报来争取关注度和资源,解决项目中遇到的问题。 P305

· 订单模块完成开发自测,负责人MM,截止日期NN。 P306

还要注意,项目的其他参与人员可能只负责把自己的工作做好,不会从整体上关心项目,这是可以理解的。 P307

过程中虽然遇到一些阻力,但是项目经理真心诚意地帮助技术负责人克服困难,最终成功解决问题,化解了项目风险,得到项目组所有同学的敬佩和信任。 P308

产品经理需要深刻理解三者的工作目标、工作方式,处理好协作关系,这样才能保证工作顺利开展。 P309

· 针对内部业务系统的产品运营方向,本章讨论的B端产品运营主要是针对这个方向的。 P310

产品经理也要对B端产品的推广负责,但很多时候产品经理需要运营人员的协助和支持。 P311

比较高效的问题解答、处理机制应该是层层过滤的:一线业务人员反馈问题后,首先由产品运营人员及时响应和跟进;如果发现是系统问题,则提交给产品经理,请他再次核实;如果确认是系统Bug,则由产品经理提交给研发人员。 P312

综上可以看出,产品运营人员的工作范畴较为宽泛,而且B端产品运营人员和产品经理需要相互配合,共同解决问题。 P313

· 职业方向不同:B端产品运营可以成长为某个细分领域的业务专家,例如CRM销售管理业务专家;C端产品运营可以成长为某个细分行业或产品方向(例如社交领域、电商领域)的运营专家。 P314

9.2.1 B端业务运营岗的管理模式介绍业务运营岗之前,首先要明确一下什么是业务部门。 P315

具体的组织架构图如图9-1所示。 P316

例如,假设分销业务的市场区域性差异极强,因此分公司业务运营部被赋予较高权限,可以直接制订区域销售策略,一方面分公司业务运营部向分公司经理汇报,协助执行分公司经理的经营策略;另一方面分公司业务运营部也要向总公司业务运营部虚线汇报,承接总公司业务运营部的部分策略落地工作。 P317

例如,在M公司分销业务中,各分公司提交的客户资料需要由总公司的业务运营部的专员进行核对审批;又如,某O2O分公司要开展一场优惠券形式的市场活动,如果发券金额超过一定额度,就需要由总公司的业务运营部审批;再例如,某公司销售部的一线人员想查询某客户的敏感信息,需要向业务运营部提交申请,业务运营部同意后才会提供相关数据。 P318

例如,销售提成方案、采购人员绩效考核方案、仓配人员绩效考核方案都会出自业务运营部。 P319

项目管理对于业务部门发起的业务项目或产研项目,业务运营部可能会安排专门的项目经理进行项目管理,推进项目落地。 P320

这种情况下,由专业的数据分析团队制作手工报表可以随时响应,效率更高。 P321

其中人际因素因人而异,产研文化取决于公司创始团队的背景,这两者很难通过一些动作或方案来改善。 P322

产品经理、业务运营人员、产品运营人员相关的组织架构设计有多种方案可选,各有优缺点,不同的方案适用于不同的公司文化和发展阶段,我们依次介绍如下。 P323

· 有利于从企业利益出发考虑问题:虽然业务线产品经理要为业务服务,但因为产品部是独立团队,所以产品经理有权利和义务在某些时刻跳出业务线,从客户利益或公司整体利益出发,对业务部说“不”,必要时将问题升级到CEO级别去处理。 P324

但是很多问题纯粹是业务线的内部问题,如果这类冲突都需要由CEO去处理,则效率太低。 P325

· 避免工作内容冲突:在两个团队设置工作内容相似的岗位,还会导致在工作开展过程中产生冲突。 P326

而且同为业务部成员,产品经理和业务负责人之间的距离也会更近,信任感更强。 P327

· 部分产品人无法接受向业务部汇报工作这样的安排:因为很多产品经理认为产品岗位应该具有非常高的权限和级别,能直接影响、改变业务部的工作,而不应该“受制于”业务部。 P328

这种方案的缺点如下:· 缺少牵制力:这种架构下,产品运营人员不能代表业务运营部发声,对产品经理的牵制也会减弱。 P329

但这种情况下,业务线的产品运营人员就不可能向产品经理汇报了,这就又和方案二相差无几,因此不对其做赘述。 P330

互联网公司取得成功的诀窍之一就是,频繁地调整组织结构,尝试各种安排,在各种调整中很可能实现破局,或者产生“鲶鱼效应”。 P331

如何识别、挖掘好需求?如何管理这些需求并安排迭代计划?这里面有很多技巧和最佳实践值得我们学习参考。 P332

需求的收集和管理是产品经理的一项基本工作内容。 P333

面对需求时,产品经理可以思考以下问题,帮助自己准确、迅速地判断需求的价值:· 这个需求背后的真正问题是什么?· 这个问题是否有简单快速的解法?· 这个问题的影响面有多大?如果只是个案,是否值得投入精力去研究解决?· 如果是共性问题,优先级和紧急程度如何?对于从C端产品转行的同学,这里提醒一点,C端的产品需求来自个体用户,而B的端产品需求来自组织和机构。 P334

如果公司对项目管理的过程没有明确的规范,或者缺少工具支撑,也可以通过Excel文件来进行需求管理。 P335

因为项目管理比较在意是否在计划外插入临时需求,所以我们对插入的需求(不论是技术需求还是业务需求)要做一下标记,标记的方法既可以是单独加一个字段,例如“是否是插入的需求”;也可以通过为“需求类型”增加“产品需求(插入)”“技术需求(插入)”两个选项来标记。 P336

· 优先级优先级是管理需求迭代计划的重要判断依据。 P337

· 迭代版本如果采用了敏捷开发模式,就需要标记需求排期开发时的迭代版本。 P338

· 状态状态用来描述需求的生命周期,状态值可以包括如下选项:待跟进、需求调研、PRD编写、待PRD评审、待技术评审、待排期、待开发、开发编码、待测试、测试验证、待验收、待上线、已上线、挂起、拒绝。 P339

· 前端开始日期/前端结束日期前端开发工作的开始日期和结束日期。 P340

认真填写模板中的各项内容,可以帮自己较好地分析需求跟进情况、研发效率、工作量投入等。 P341

本章所讲的迭代管理是指前者。 P342

图10-1 研发人力资源安排图10.2.2 迭代中的技术优化资源分配软件的代码需要不断地优化。 P343

构建的系统是一套全新的干净系统,没有任何历史包袱,因此,可以铆足劲儿开发业务功能,而不用太在意代码、架构的合理性,此时可以只预留10%的资源做技术优化,甚至不做技术优化。 P344

重构阶段业务继续发展且相对稳定,业务需求依然络绎不绝,但系统已濒临崩溃的边缘。 P345

不同阶段对两者投入的资源比例可参考表10-2。 P346

浅灰色背景是迭代1的准备阶段及执行过程,深灰色背景是迭代2的准备阶段及执行过程。 P347

然后,针对所选需求设计方案并编写PRD。 P348

5.上线(W4D5)集中上线是一种提升研发效率和运维效率的好方法。 P349

例如,涉及流程调整的需求,需要一次性实现完整功能集合,才能保证业务正常运作,而这个最小功能集合很可能无法在一个迭代周期内完成。 P350

必须先研究代码结构,做完技术方案设计,才能给出准确的工时和排期。 P351

· 传统软件产品非常复杂:在传统软件公司,研发的都是大型商业软件,或给客户定制的中小型系统。 P352

· 执行快——产生一个决策后,整个团队和组织都会集中资源高效执行落地,不论是业务团队的开疆拓土,还是产研团队的系统研发,都会迅速展开。 P353

作为产品经理,你需要思考如下问题:· 你是否有随时接受需求变更的勇气和心态?面对各种扑面而来的变更,你是否能够心平气和地分析问题和方案,而不是气愤地一口回绝已经让研发团队白忙活一个月的需求方?· 你是否允许存在瑕疵但可以快速支持业务的产品方案去抢占市场,而不会因为自己的“洁癖”及偏执导致业务错失良机?· 你是否会说服研发人员为了快速上线而暂时采用并不合理的设计方案,并在合适的时间窗口帮助研发团队顶住业务压力,给研发团队争取足够的时间来重构系统?如果产品经理和研发团队对上述问题的回答都是肯定的,那么这个团队就具备了践行敏捷文化的前提。 P354

为了解决客户的交通工具问题,先提供了滑板,然后依次提供了滑板车、自行车、摩托车,最后才提供小汽车。 P355

[1]点数也叫故事点数,是敏捷开发中的概念,指敏捷团队评估工作量的度量单位,一般取决于敏捷团队的实际研发经验。 P356

本章将介绍数据分析的思维框架,以及进行数据分析工作需要具备的知识结构。 P357

数据分析的方法论很多,从本质上讲,可以将数据分析的过程抽象为四个步骤(如图11-1所示),分别是明确主题、提出假设、验证假设、产生结论,其中提出假设、验证假设是数据分析工作中最复杂的部分,需要反复进行,才能得到正确的结论。 P358

分析人员要掌握好节奏和脉络,做到有的放矢,收放自如,分析过程既不能随意发散,也不能过于收敛。 P359

11.1.3 得出结论经过反复地提出假设、验证并修正假设,我们会逐渐发现现象背后的真正原因,得出可靠的结论便是水到渠成的事。 P360

接着,我们在Excel中对基础数据进行数据透视处理,观察分区域的销售额变化情况,看看能否发现什么,如图11-2所示。 P361

如果此时认为已取得结论,可能还不是很严谨。 P362

虽然河北的下降绝对值较小,只有37千元,但下降幅度达到88%。 P363

通过Excel数据透视功能,并结合对数据的可视化处理(数据条),可以让分析工作变得直观、高效、灵活,如图11-5所示。 P364

11.2.1 方法工具善于运用方法和工具,可以提升数据分析的效率,是做数据分析工作的基本功。 P365

· 正则表达式(Regular Expression):正则表达式是一种非常巧妙的、用来处理文本的逻辑公式,在某些时刻,使用正则表达式可以解燃眉之急。 P366

11.2.2 业务知识业务知识既包括行业知识、领域知识,也包括具体公司的商业模式、运营流程细节等。 P367

方法工具、业务知识、细心耐心是进行有效的数据分析工作的核心要素,三者缺一不可,如图11-6所示。 P368

统计学方面:《深入浅出统计学》。 P369

一份格式编排严谨、注重细节的报告,可以体现制作人的严谨态度和专业素养。 P370

因此,配有丰富、清晰图表的报告读起来会给人生动有趣感,讲解起来也容易吸引人的注意。 P371

标明数据来源可以体现数据的合理性、合规性、合法性。 P372

页面标题要么陈述主题,例如“2018年销售额回顾”,要么陈述结论,例如“2018年销售额持续增长”。 P373

经过调整,这一页报告看起来是不是清爽不少呢?图11-9 M公司销售业绩回顾(格式调整后)除此以外,图表编写中还经常出现缺少图例、缺少图表标题等问题。 P374

但是,如果你想对自己从事的产品领域有更加深刻的认识,想获得更广阔的职业发展空间,就必须学习、掌握企业级应用架构的搭建。 P376

最后的第15章将介绍企业的通用应用架构体系,并以三家不同业务阶段的互联网公司为例,带读者一起想象并绘制它们的企业级应用架构。 P377

企业级应用架构正是指企业的各个软件系统有机集成在一起的方式。 P379

例如,每一类企业经营管理中的业务问题都有成熟的软件解决方案:通过OA系统解决内部员工管理与协作问题;通过HRM系统解决HR业务管理问题;通过OCRM系统解决客户开发管理问题;通过SRM系统解决供应商管理问题,等等。 P380

理解企业如何运作在现代企业经营管理中,无论是纯线上业务的互联网公司,还是纯线下业务的传统企业,其经营管理和运作方式是相同的:都需要有售卖的产品或服务,都需要有销售团队进行售卖,都需要有客服团队进行服务,都需要有人力、法务、财务团队进行后勤支持。 P382

虽然不同企业在这些核心业务版块的运作细节不同,但是业务的本质是相同的,产品解决方案的大体思路是一致的。 P383

该如何解决这类问题呢?如果你学习过产品架构搭建的知识,就会知道借助主数据的设计思想,构建客户主数据、供应商主数据、商品主数据等,从而方便地解决这些信息孤岛问题。 P384

当你从公司整体业务的角度去思考时,这些疑问往往就会豁然开朗。 P385

无论是阿里、百度、美团这样的知名互联网企业,还是工商银行、中国联通、沃尔玛超市这样的传统巨头企业,企业级应用架构的建设思路、演变过程,在本质上都是类似的、相通的。 P387

接下来就让我们从企业级应用架构的角度来分析一下,钟先生的小门店是如何一步一步演变发展为成熟的M集团的。 P388

不过这个现象正在改变,越来越多的小微型企业认识到信息化能力的重要性,这也给各家SaaS公司带来了更多的机会,同时也是产业互联网的一个分支。 P390

不要小看钟先生设计的这三张表,实际上这三张表格已经是一个进销存管理软件的雏形了,也反映了一套电商平台的核心模块,即商品管理模块、订单管理模块、采购和库存管理模块。 P391

因为经营的货品更加丰富,日交易量成倍增长,因而有好几名员工需要同时做数据处理工作。 P392

实际上,电商平台的中后台模块和ERP的功能模块基本相同,只不过电商平台有更灵活的促销、营销管理功能、商品管理功能,以及丰富的C端前台。 P393

这样上述想法就都实现了!这时我们可以绘制出公司的第二张应用架构图,如图13-4所示。 P394

请注意,这里已经产生了应用架构设计的概念,公众号、ERP和CRM,这其中的每个系统都是为了解决某一大类的业务问题而存在的,各自有清晰的定位、分工和目标用户;每个系统内置若干模块,每个模块都是为了该大类业务问题下的某一小类问题而设计的。 P395

当企业规模达到一定复杂程度以后,必须有一整套软件系统来支撑其经营运转,否则管理会失控、混乱。 P396

· 成立法务部、人事部、财务部,作为中后台体系,支持公司正常的行政运转。 P397

通过数据仓库,可以实现打通销售数据和客户资料的全面分析。 P398

例如,对于销售额,销售部门可能有一套口径(没有剔除退货),采购部门也有一套口径(剔除了退货),如果定义不统一或不明确,几个部门之间沟通时就很容易产生歧义。 P399

图13-6 中型连锁超市的应用架构图有一点需要注意,如果希望数据仓库在企业中真正发挥作用,不仅需要实施软件系统,更重要的是公司层面要实现经营思路体系化、指标管理规范化,以及数据部门组织架构与业务部门合作流程合理化,同时还要提升全员数据化管理运营的理念和意识。 P400

13.2.3 建设OCRM系统支持企业客户业务随着公司规模的继续扩大,M公司决定在零售业务之外开发企业客户。 P401

)图13-7 开展企业客户业务后的组织架构图· 设立研发部:由于各部门经常有个性化的软件开发诉求,软件外包维护的成本高,效率低,公司决定招聘研发团队,正式走向自主研发之路,通过自研提高研发效率和质量,进一步加强信息技术对业务的支持和促进作用。 P402

方案二:在原有CRM系统的基础上自主开发OCRM模块,其优缺点如下。 P403

图13-8为了简化表述,只绘制了一个“客户信息”模块,但读者应该认识到该模块包含B端、C端两套客户模型。 P404

完整的CRM体系包括三个核心方向:· 帮助企业获取销售线索并转化为客户的销售管理CRM,即常说的OCRM(Operating CRM),用来支持企业的销售过程自动化(Sales Force Automation,SFA),包括销售线索和过程管理、统一客户视图、电话销售中心等模块。 P405

本章将介绍更加复杂的应用架构设计思路和实践。 P407

14.1.1 在线商城业务带来了互联网化管理M公司旗下已有多家中型连锁超市,并发展了面向企业客户的业务,业务线越来越丰富,且成立了若干控股子公司,M公司已升级为M集团,钟先生任集团CEO。 P408

因为电商部产品技术总监(以下简称“电商总监”)和公司CTO之间不存在汇报关系,而且电商总监希望快速推进项目,因此所有决策基本只是告知CTO。 P409

对于这个架构设计,CTO认为客户信息和账号的管理系统不应该重复建设,而应该统一规划管理。 P410

为了让客服人员能在CallCenter系统中查到公司的所有客户信息,只能在CallCenter系统中新增一套客户资料库,将另外两套客户资料库中的数据同步过来,此时的应用架构图如图14-2所示。 P411

为了快速上线电商系统,有一些应用架构遗留问题没有解决。 P412

CEO很生气,找到CTO和电商总监质问是怎么回事。 P413

调整后的客户资料系统架构如图14-4所示。 P414

但是,引入主数据管理会让应用架构变得更复杂,在实施初期,需要投入比较多的时间和资源。 P415

14.2.1 将通用功能抽象成基础服务M集团业务发展稳定,各个系统底层做过几次技术重构,性能更强健了。 P416

任何下游业务都可以直接接入集团的支付服务接口,实现线上支付业务,而不用重新和各家支付机构谈判、对接,并重复开发清结算及对账功能。 P417

同时,信息技术部也与时俱进,将需求管理部调整为产品部,培养并招聘产品经理,以便信息技术部能够和电商部、理财事业部的产品技术团队较好地沟通协作,并对业务产生有意义的影响。 P418

初步计划有自己的积分、货币体系,未来可以考虑设定汇率,和电商以及集团的积分、货币体系进行自由兑换。 P419

14.2.3 Passport与客户资料管理CTO和产品总监讨论后,认为上述架构图还存在一点问题:账号管理系统不应该重复开发。 P420

但是该客户可以拥有多个账号,给不同角色的人员使用。 P421

具体调整如下。 P422

· 仓配部门尝试独立经营管理,对外提供供应链整体解决方案,对内按照3PL(Third-Party Logistics,第三方物流服务公司)的模式提供服务支持,仓配部门和业务下游形成财务结算关系,对服务收费,保证品质。 P423

图14-10 抽象出公共服务后的应用架构图为了配合集团“中后台服务中心、前台独立事业部”的管理模式落地,也为了保证产品架构体系的运作效率进一步提升,产品部也做出了一系列调整:· 设立数据产品部,负责集团层面的DW和BI体系(各业务线产研团队可根据需要,在集团DW的基础上创建自己的数据集市(DM)和分析平台),以及集团大数据平台的建设工作。 P424

· 为了配合仓配部作为自负盈亏的独立机构运作,增强其业务响应能力,仓配产研团队统一汇报给仓配业务负责人。 P425

其中“大中台”,就是指Msg、Auth这一类基础服务、公共服务,而且阿里集团根据自身业务的特点,将订单中心、商品中心、评价体系等模块也做了下沉,将它们抽象成公共服务。 P426

本章将基于M集团的应用架构,进一步总结出企业通用的应用架构设计,并通过例子向大家展示这套架构是如何适用于不同发展阶段的互联网公司的。 P427

实际上,M集团的这套应用架构,已经可以代表一般企业的通用应用架构了。 P428

所有供企业外部客户使用的系统都在这一层,包括官网、普通用户或客户使用的C端系统。 P429

这类系统主要给其他应用系统提供基础服务能力支持。 P430

15.2.1 初创企业的应用架构畅想我们设想的第一家公司是一家规模相对较小、产品形态单一的初创型公司,主要做单一功能的工具类应用,大家可以类比墨迹天气、万年历这类工具类应用的公司。 P431

在公司经营之初,可能采用了市面上的DSP(需求方平台)来完成App的广告管理(当然也可能没有采用过)。 P432

至于WMS、TMS这类系统,由于公司目前没有开展电商业务,因而是不需要的;但是如果将来开始做自营电商业务,就可能会有自研的WMS、TMS出现了。 P433

这样的企业的应用架构会是怎样的呢?我们一起来推理。 P434

由于公司不涉及自营的实物买卖服务,所以不需要仓储体系,因此推测没有WMS。 P435

业务定位和边界要清晰一套应用系统是为了解决某一类业务问题而存在的,对应某一个业务模块。 P437

系统之间要实现数据的单向流转系统之间应尽量保证数据单向流转,确保数据流可回溯,这样才能保证数据的一致性和可追溯性。 P438

深入思考新系统与旧系统的关系前面讲M集团分销平台和架构演进的时候,我们看到系统中的某些模块复用了之前的系统模块,有的则是新建的。 P439

但是企业经营运转过程中,各部门是需要相互协作的,各个独立的、不关联的系统显然会阻隔业务部门之间的协作。 P440

图15-5 企业架构EA的四层架构· 业务架构(Business Architecture):关注组织架构、领域模型、业务需求、业务规则、业务流程等要素。 P441

另外,技术人员尤其是技术架构师,需要对EA中的某些模型和方法论有所理解。 P442

产品经理需要具备经营管理、企业运作、计算机科学、软件工程、项目管理、数据分析、交互设计等各方面的知识。 P443

good

标签