本文档是根据《决胜B端》，学习B端业务在产品设计的流程操作；摘出其中B端业务设计的精彩处理操作，并随着作者的思路解决业务问题，以及认识不同处理场景或架构下的合作场景；为读者带来全面细致的B端业务了解和认识。

文档介绍

《决胜B端》概念画布_V1.0.pdf
决胜B端.pdf

关于本书

本文档基于《决胜B端—产品经理升级之路》，作者杨堃是VIPKID产品总监，在企业数字化转型、 应用架构设计、业务中台建设、CRM建设、数据仓库 与BI建设方面均有丰富经验。
本文档主要的目标是将原书中提到的各种B端产品概念和流程在完整统一的视图中展示出来，以帮助读者从整体的视角快速回顾各个知识点。
本文档包括了原书中的设计篇和管理篇部分，暂未包含进阶篇的内容，计划在下一个版本加入进来。

关于作者

《决胜B端—产品经理升级之路》试图提炼了互联网B端产品设计和管理的通用思路和方法，本书一共分为4篇。

• “概述篇”描述互联网行业的盈利模式及发展趋势，让读者对互联网产品领域建立全面认知，并阐明市场对B端产品经理的需求将持续旺盛。
• “设计篇”详细讲述B 端产品的设计，按照产品设计的实际流程，依次讲述业务调研、架构设计、功能模块设计、演进蓝图设计、业务数据建模、流程和角色设计、权限设计等一系列关键环节。
• “管理篇”讲述B端产品的管理，包括B端产品的项目管理、运营管理、迭代优化和数据分析，阐述了B端产品实施和运作过程中面临的一系列问题，包括复杂项目的推 进、产品经理和业务团队的合作、需求和迭代的计划编排等。
• “进阶篇”讲述企业级应用架构，从前面的单一产品建设扩展到体系化产品建设 ，旨在帮助读者从更宏观的 角度思考产品，站在企业经营管理和发展的视角，重新 审视互联网产品体系架构的设计原则和方法论。

全书贯穿了一个实践性很强的案例:在“设计篇”和 “管理篇”中，我们为一家成熟的集团企业搭建了一套完 整的分销业务平台，带领读者逐步设计、实现一个B端产品;在“进阶篇”中，讲述了这家集团企业是如何从小门店 一步步发展起来的，重点分析企业的应用架构体系随业 务发展的演进规律。
本书面向0到10岁的B端产品经理，以及所有对B端 产品建设感兴趣的读者。

一、项目背景和计划

1、案例说明

案例:M电商公司的渠道分销产品设计

1.背景

M集团是一家经营了十几年的成功企业，旗下拥有零售连锁超市、生鲜电商、金融理财多条业务线，业务发展良好，系统建设成熟。M公司是M集团下属的电商公司，成立5年，主营生鲜商品，以C端客户为 主，业务稳定。M公司在三个月前尝试开展分销业 务，成立销售团队，开发分销商合作伙伴。分销业务 的目标客户是大型的餐饮连锁集团，以及大型生鲜分销商等企业级客户。业务试点在北京、上海开展， 三个月以来业务发展迅速。目前分销业务月流水50 万元，以每月20%的增幅快速发展。但是，在高速发展中，若干流程、管理、风险问题越来越突出。

2.诉求

由于分销业务发展迅速，现急需配套的软件系统来 提升业务效率，控制经营风险。

3.评估

经管理层评估，公司决定投入研发资源建设软件系 统，支撑分销业务发展。项目期间CTO全力提供资 源支持。

4.目标

在2~3个月的时间内搭建一套分销业务平台，至少 支撑分销业务在未来2年内的高速发展，有效地提 升效率、控制经营风险。以上就是案例的大概背景。 之所以选择一家集团企业下属电商公司的分销业务 作为案例，是因为它非常有代表性:

• 首先，M集团是一家成熟集团，拥有完善的应用架构， 大家可以了解如何将新设计的产品与公司现有产品架 构融合。
• 其次，分销业务场景具备足够的复杂性，既要支持公 司对客户的运营管理，又要支持客户的自主管理，涉及 的系统具备比较全面的功能。
• 最后，分销业务模式涉及复杂的多层级子母账号管 理和组织机构管理，这是B端产品设计中的典型问题， 也是设计的难点。

此时了解完成以上基本情况之后，产品经理开始正式介入进行安排处理业务调研并进行梳理分析；产品经理需要根据自己的规划进行作出预期的项目介入计划处理；大致作出如下项目计划排期。

二、业务调研和梳理

1、业务调研

1.业务调研方法流程

1.明确调研目标

• 调研目标即调研的目的，有了明确的目标，工作才能朝正确的方向 开展，因此这一步非常关键。具体应该如何确定调研目标。

2.选取调研对象

• 对于B端业务调研，调研对象一般包括业务高管、业务经理、一线业务人员、合作伙伴高管、合作伙伴经理、合作伙伴一线人员等。
• 针对高管，可以了解业务战略定位、战略目标等信息;针对经理或 负责人，可以了解业务的管理思路、经营思路等信息;对于一线业务人 员，可以获取作业过程、操作细节等信息。
• 针对M公司，我们计划安排调研对象为:分销业务负责人1人，运 营专员1人，北京、上海业务主管各1人，一线销售人员2~3人，北京、 上海各选择一家分销客户。

3.调研方法

• 包括定性分析法和定量分析法，具体包括访谈、轮岗实习、问卷调研等方法。在实践中，需要结合具体情况选取合适的调研方 法，例如，某业务团队一共有10人，可以很方便地对每个人都进行访 谈，因此就没有必要准备调查问卷了;又如，某个项目预留的调研时间 非常紧迫，因而无法安排轮岗实习。
• 关于业务调研方法的具体介绍。
• 针对M公司，因为项目时间紧张，所以不打算安排轮岗实习;此 外，业务团队目前一共不到10人，因此直接通过一对一访谈以及全面的 数据分析，来摸清目前业务的现状、问题和规划。

4.执行调研计划

• 如果前面的准备工作做得足够充分、细致，那么具体执行时就会相 对顺利且有效。调研工作需要耐心，需要专注和投入，每天晚上结束后 还要整理素材或资料，保证获取的所有信息都能被及时准确地记录下 来。

5.总结归纳输出

• 业务调研的主要目的是掌握业务情况、诊断业务问题。调研结束 后，要产出一份详细的调研报告，总结业务现状和问题，并确定各个问 题的优先级，以便为后续的方案设计和实施路径提供决策支持。
• 需要注意，设计良好的B端系统能够规范流程、提升效率，但这不 代表所有的业务问题、管理问题都可以通过软件系统来解决。一个优秀 的团队用Excel也可以管理好业务，只是到一定规模后效率会变低(关 于这个话题本书后续章节还会探讨)。有了这样的基本认知，产品经理 在梳理问题时就要做出判断，哪些问题可以用软件系统提效，哪些问题 和软件系统无关，更适合用线下方式处理。

2.业务调研目的和分析框架

在开始业务调研之前，需要明确调研的目的，这样才能安排好调研 的计划和方法，让调研工作有效果、有价值。一般来讲，业务调研有两 个重要目的，一是梳理业务现状，二是总结业务问题。
那么，面对一项并不熟悉的复杂业务，该从何处切入呢?我们可以 参考典型的业务分析框架，如图4-2所示，我们按照它拆解并分析业 务，就可以分析得全面、透彻，梳理出现状，总结出问题。这个分析框 架也体现了一个业务在开展前自顶向下进行规划的思路。

1.战略层

• 业务调研首先要明确该项业务在公司中的战略定位，因为战略定位 会决定具体的经营策略，并最终影响产品方案设计。理解战略定位、战略计划，可以在产品方案设计的关键点上做出正确选择。
• 例如，某集团决定以独立品牌开启新业务，希望两个品牌之间隔离，不希望消费者认识到两个品牌同属一个集团。基于此战略定位，在 设计产品体系时，可以考虑重新搭建一套客户资料库，和公司已有客户 池隔离，两个品牌的用户账号体系也进行隔离，客户需要分别注册账号 来体验两边的服务。当然，这会在一定程度上影响两边业务人员做一些 离线的客户资料打通分析。
• 反之，如果集团希望消费者认识到两个品牌属于一个集团，那就是 完全不同的战略定位了，所做出的设计也会完全不同，需要采用一套账 户体系，以保证集团层面客户资料的唯一性，以及客户体验感知的一致 性和便利性。

• 1.使命

  • 翻译：公司为什么存在？项目为什么启用？
  • 解释：为组织内所有决策提供前提；描述一个持久且长愿为之努力的事实；为内外部人员提供指导；

• 2.愿景

  • 翻译：希望公司发展成什么样？
  • 解释：指导战略和组织的发展，同时描述一个鼓舞人心的事实，在一个特定的时期内实现，同时为内外人员提供指导；
  • 举例：阿里巴巴的使命：让天下没有难做的生意，愿景是让客户相会，工作和生活在阿里巴巴，并持续发展120年；
  • 举例：滴滴的使命：让出行更美好，愿景是成为全球最大的一站式移动出行平台；

• 3.使命+愿景=战略

  • 翻译：打败现有以及潜在的竞争者的计划；
  • 解释：列出一系列措施提供出产品或服务，创造高于成本的价值，描述公司战略选择的价值方案，跟随市场分析，消费者经验、试验而不断改善；

分析模型：
PEST分析模型
波特五力分析模型

1. GE模型

商业画布-Business canvas

1. 价值链模型
2. BCG矩阵

2.战术层
战术层是对战略层的认知进一步具象化的层级，可以从经营策略、管控模式两个方面开展分析。

• 经营策略
  • 经营策略，通俗来讲就是做买卖的思路，包括客群定位、定价策 略、营销策略、渠道管理策略、供应链管理策略等，这其中的每一个主 题都涉及庞大的知识体系，产品经理需要扩充各个领域的知识，最好对 这些版块都形成基本的认知，这会对工作的顺利开展有帮助。
  • 业务调研的目的之一是理解公司的经营策略，确保对产品的定位、 形态做出准确判断。
  • 例如，某流量巨头App对销售渠道做了这样的规划:针对一线城 市，计划开展大客户地推直销、中小客户电销直销;针对二三线城市， 计划开展代理商合作模式。有经验的产品经理应该敏感地意识到这几种 销售模式区别非常大:大客户地推直销业务重在线下销售过程管理，中 小客户电销业务重在电话作业流程管理，代理商合作业务重在业绩核算分析。三种业务模式的重点完全不同，需要建设的系统也不同，CRM 产品设计上一定要分别建设，不能糅在一个系统中。
• 管控模式
  • 管控模式是指集团对下属企业的集权、分权管理策略，也可以指总 公司对分公司的运营管理策略。不同的管控模式所需的配套管理系统当 然大不相同，因此这也是B端业务调研需要弄清楚的事项。
  • 例如，有些公司会把运营决策权下放到分公司，并提供足够的经费 支持;而有些公司会把运营决策权集中到总部，分公司只负责执行。系 统需要具备灵活的权限管理体系，随时支持管控模式的调整和变化。

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

• 管理层
  • 在明确了经营策略、管控模式等基本方针后，需要梳理组织架构关 系，以便对组织架构做出优化;还需要明确人力资源计划，从管理角度 保障上层策略的落地。这是业务调研的又一个目标。
• 运营层
  • 接下来就是明确具体业务流程、绩效管理、风险控制等更加细节的 规则，以便在实际运营中推进上层策略的落地。其中，梳理具体业务流 程[2]是理解并掌握业务的重要途径，同时也能理清楚人员、岗位、职责 的关系。流程合理会让管理和运营提效、风险可控，这也是B端产品的 重要业务价值之一;流程不合理，会导致成本增加、服务质量降低。
  • 还要留意一点，流程规范化是一把双刃剑，一方面可以规范管理，另一方面可能导致僵化死板，在梳理、设计互联网公司的业务流程时要 把握好尺度。

3.业务调研方法

1. 深度访谈

深度访谈是了解业务全貌的最快的手段。通过一对一面谈，可以直 面问题，迅速获得答案。在做深度访谈时，产品经理就像一个记者，要 在有限的访谈时间内，赢得访谈对象的信任、好感，获得有价值的信 息。深度访谈有以下注意事项。

• 准备好访谈大纲
  • 提前准备好访谈思路、大纲、问题，选好访谈对象，想清楚通过访 谈想要了解什么。如果事前没有做好准备，就好比记者采访前没有准备 好提纲，必然会导致对话内容发散、混乱，无法收集到足够多的有效信 息。典型的访谈大纲模板如图;

• 从高级别人员开始访谈
  • 从高级别人员开始访谈工作，按照从概览到局部、从全局到细节的 顺序研究业务，更容易把握整体调研工作的脉络和节奏。如果一开始就 陷入细节的汪洋大海，会导致抓不住关键问题。
• 提前研究访谈对象
  • 访谈前要从各种渠道了解访谈对象的背景，尤其针对高级别访谈对 象，了解得越充分、细致越好。比如，有些访谈对象可能在项目中是利 益受损方，如果提前不知道这个情况，可能会得到很多干扰信息，对决 策和判断产生影响。
• 和访谈对象保持联系
  • 访谈结束后，最好和访谈对象建立长期联系，尤其是一线业务人 员。人和人面对面聊过后，会产生基本的信任感和好感，要借助访谈的 机会，拉近和业务人员的距离。如果后续项目中遇到问题，想获取最真 实的一线反馈，可以联系之前的访谈对象，寻求帮助。

1. 轮岗实习

• 轮岗实习是指，产品经理深入一线，直接体验一线业务人员的具 体工作，这是深入了解业务的最好方法。
• 做产品经理，最忌讳的就是凭自己的主观感觉进行设计，脱离实 际。如何准确挖掘客户的真实需求?要么不断地和客户沟通、确认，要 么直接和客户一起工作，看看到底遇到了什么问题。
• 假设你是一家外卖公司的配送产品经理，负责设计配送员接单用的 App。如果你不了解配送员实际工作的复杂性与突发性，怎么能做好产 品设计?最好的办法就是，去做两周配送工作，理解真实工作场景，再 总结提炼问题，并设计解决方案。
• 深入一线是产品经理有别于传统需求分析师的重要特征之一。如果 不能深入一线，而只是被动地接受需求，产品经理的价值就会大打折 扣，产品经理的成就感和积极性也会越来越弱。只有投身于一线，才能 深刻地理解业务，做出正确的决策。产品经理要当一个冲在前线的人， 而不是在后方拍脑袋的人。

1. 调研问卷

• 线上的调研问卷是比较灵活的调研手段，既可以进行定性分析，也 可以进行定量分析，并且很容易推广。问卷的内容设计一定要谨慎，因 为一旦问卷发出，就无法修改问题了，如果辛辛苦苦收回了大量反馈， 却发现当初的问题设计不合理，是多么让人崩溃的事情。设计调研问卷 时要注意以下几点。
• 激励用户完成填写
  • 问卷调研首先要确保能够回收足够多的、有效的反馈结果。如果问 卷冗长、乏味，用户填写到一半很可能就离开了，因此要控制问卷的长 度。在问卷的开头部分，最好告知问卷设计的目的、预计占用的时间， 以便填写者有大概的心理预期。最好能带一些活动礼物，提高大家参与 的积极性。
• 控制好开放式和封闭式问题
  • 问卷中的开放式问题和封闭式问题的比例要合适。一般来讲，建议 大部分使用封闭式选择题，以便获取定量分析的数据支撑。在问卷结尾 可以留一到两个开放式问题，以保证调研对象可以自由表达想法。如果 开放式问题超过2个，你需要谨慎地思考每个开放式问题的意义是什 么，是否必须采用开放式。毕竟很少有人愿意花时间填写大段的文字。
• 避免诱导性问题
  • 在问卷设计中，要避免诱导式的提问，例如“我们要做一个更好的 个人管理功能，您会使用吗?”而要尽量采用中性描述，例如，“您使用 这款产品的体验如何?”
  • 也尽量不要设置非此即彼的问题，例如“您是否喜欢我们的产品 呢?”可以提供多个描述主观感受的选项供调研对象选择。注意，选项 要采用平均切分主观感受的描述，例如可以采用“非常喜欢”“喜欢”“一 般”“不喜欢”“非常不喜欢”这样的设计，而不能采用“非常喜欢”“较为喜 欢”“一般喜欢”“喜欢”“不喜欢”这样的设计，因为后者提供的五个选项中有四个都是“积极的”回应，显然有失公正性。
• 谨防“幸存者偏差”
  • 英军曾经对战斗结束后的飞机进行检查分析，发现机翼部位的弹孔 较多，因此判定机翼是战斗机交战中容易受到攻击的部位，从而决定加 强机翼装甲。但实际上，战斗中坠落的飞机大都是因为腹部受到了攻 击，腹部才是战斗机最薄弱的地方。幸存的战斗机对分析工作产生了误 导，这叫幸存者偏差。
• 在实际工作中经常存在“幸存者偏差”，例如，假设你需要收集业务 团队对某功能的评价，选择了在北京团队投放问卷，但实际上北京团队 很少使用该功能，因而得到的反馈无法反映真实的状况，价值不高。在 问卷调研工作中，要当心“幸存者偏差”，分析并选择合适的样本。

1. 数据分析

• 调研时，有必要掌握业务的关键过程指标和结果指标。
• 对于分销业务来说，过程指标包括新客户开户时长、订单处理时 长、分拣配送时长、销售拜访量、新销售线索进量、销售线索转化率 等;结果指标包括订单量、客单价、收入、成本、利润率等。
• 产品经理要像业务经理那样关心业务运行的各项数据，这样才能 了解业务现状，并进行业务诊断。

1. 行业研究

• 虽然B端产品和业务的竞品调研比较难做(4.4节会讲到)，但行业 研究依然要尽力而行，收集的信息越多，帮助越大。行业研究可采用如 下方式。研究针对业务相关领域的经典管理案例
• 尽管互联网创新灵活，有很多独特的业务模式，但现代企业经营管 理与业务运营的本质并没有变，总可以找到模式类似的经典管理案例进 行分析参考，例如供应链管理、渠道管理、定价策略，不论是理论还是 实操知识，都可以在网上获取大量参考资料。
• 研究市面上同类业务的商业软件特点
• 目前市面上大多数管理软件都有可以免费试用的SaaS版本，或具备 丰富的应用案例资料。例如，如果研究CRM，可以试用SalesForce、销 售易等;如果研究电商ERP，可以试用管家婆、商派等;如果研究报表 可视化，可以试用Oracle BIEE、IBM Cognos、Tableau、百度指数等。
• 实际上，企业经营管理所需的各类管理软件都能在市面上找到大量 成熟的商业软件产品，完全可以研究参考。

2、梳理业务现状

1.战略定位和目标

通过对M公司高层的访谈，我们确定M公司对分销业务的战略定位 是，扩充并尝试新销售渠道，发展高端零售的分销通路;战略目标是在 3年内打入主要一二线城市高端零售分销市场，并站稳脚跟，形成初步 竞争力。

2.经营策略

通过对业务负责人的访谈，我们了解到M公司对分销业务给出的经 营策略是，目标客户群体是大型的餐饮连锁集团，以及大型生鲜分销商 等企业级大客户;定价策略是能够基本覆盖采购、仓配成本加运营管理 成本，不追求利润率，甚至可以在一定范围内略微亏损，以快速占领市 场;供应链采用当前C端供应链体系，即现有的仓配服务。

3.管控模式

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

4.组织架构

通过对业务负责人的访谈，我们梳理出当前分销业务部基本的组织 架构图，如图4-5所示。分销业务部是独立运营的新事业部，负责人直 接向CEO汇报。分销业务部下属的运营部由分销业务部直管，支持北京 和上海分公司的运营工作，包括客户资料审核、报价管理、订单管理、 账期回款等，北京和上海分公司只安排了销售人员，负责开发客户。这是业务开展初期能够快速运转的一种团队结构安排。通过梳理组织架构 图可以理解人员结构和岗位设计，为系统的权限管理设计做好准备。

根据与分销业务部负责人沟通，分销业务的管控模式将进行如下调整:

• 计划北京和上海分公司各自成立运营部，自己直接管理运营工 作，不再由分销业务部统一管理。业务负责人希望通过这样的调整，将 决策权下放给分公司，让分公司实现更灵活的经营管理，提升效率。
• 随着分销业务的规模不断增大，风险控制的需求越来越凸显， 因而公司决定在分销业务部下面成立业务支持与风控部门，负责整体把 控运营执行情况，控制分公司运营风险。

图4-6是计划调整后的组织架构图，其中深灰色的节点为计划新增 加的业务单元。

5.业务流程

经过对业务负责人、业务运营人员、销售主管、销售人员以及分销 客户进行全面访谈，我们绘制出目前分销业务的手工作业流程，如图4- 7所示。图表采用了经典的泳道流程图，横轴代表相关的业务部门，纵 轴代表涉及的业务系统。这种方式可以清晰地描述业务在不同部门之间 如何流转，以及流转过程中涉及哪些业务系统。

从流程图中可以看出，目前分销业务的客户开发、签订合同、确认 售卖价格，都是在线下完成的，从提交订单开始走线上流程，完成后续 的生产配送。
对于业务人员来说，流程中最麻烦的就是下单环节。由于生鲜价格 实时变化，和客户签订的商务合同又要求在商品售价的基础上按一定折 扣出售，因此下单人员每次需要根据客户提报的采购清单拉取当天的商 品售价，按照该客户的折扣系数表换算售卖价格，再手工改价录入订单 系统。下单前还需要先确认客户账期[3]是否逾期，是否允许发货。
由于流程复杂，容易出错，目前一个运营专员只能维护5个左右的 客户，每日处理10笔订单，人效极低。
显然，业务人员在下单环节的工作非常烦琐，有待优化。

6.具体数据指标

3、总结业务问题

1.关键业务问题梳理

• 关键业务问题梳理

经过调研分析，目前分销业务存在如下业务问题。
· 生鲜实时变价，每次下单要根据折扣表手工计算价格，效率 低，易出错。
· 不能及时控制账期客户的回款进度和账期风险。
· 对账和开票工作复杂，需要处理大量数据表，容易出错。
· 因为没有实现客户的子母账号管理体系，所以无法实现客户总 部集采、大区集采、城市集采、门店自采等混合采购模式。
· 因为无法标识特殊客户的特殊订单，因此不支持特殊分拣、配 送要求，例如做不到针对某些特殊客户的订单提供蔬菜预加工和加急配送。

2.问题解决思路

• 问题解决思路

针对以上列举的业务问题，我们可以概要性地列出如下解决思路， 括号中注明了优先级。
· 实现客户自主下单(高优)。
· 实现系统自动定价(高优)。
· 支持客户多门店分别定价与下单(高优)。
· 实现对账报表(高优)。
· 运营人员聚焦参数设置、审核和异常问题跟进(高优)。
· 将运营工作下放到各城市分部(中优)。
· 支持账期和预付款模式(低优)。
· 系统实现账期风控(低优)。
我们将业务主流程优化确定为高优诉求，将小众功能、风控功能列 为低优诉求，经过探讨和业务人员达成一致，产品一期将聚焦高优诉求 的实现。
梳理清楚业务现状和问题，接下来，我们进入产品整体方案设计环 节。

接下来开始产品整体方案设计；进行核心流程梳理、产品定位、技术架构调整、功能模块、演进蓝图

三、产品设计方案

1、核心流程

从核心业务流程切入产品设计，是开展整个设计工作的非常好的起 点。核心业务流程代表业务的主干脉络，需要思考业务的各个参与方、 涉及的系统。
根据第4章对M公司的业务调研，我们总结出当前紧迫的业务诉求 包括客户自主下单、自动定价，以及支持客户对多门店分别定价与下 单。因此我们考虑调整业务流程，由运营人员将客户信息录入系统，客 户具备一个初始账号后，可以自主管理下属的多个门店和子账号。
因为M公司可能和客户总部签署了框架协议，具体合作关系又由客 户的下属分公司或门店分别谈判，所以价格系数表要针对每个门店分别 设置，以保证定价的灵活性。因此当客户创建新门店后，还需要由运营 人员设置一次价格系数表，之后，门店采购人员就可以通过关联的子账 号进行下单了。下单之后的环节保持之前的运作流程，不做改变。
综上，我们可以绘制出设计的跨部门核心业务流程图，如图5-1所 示。

经过和分销业务负责人沟通，因为目前销售人员数量有限，暂不需 要设计给分销业务销售人员使用的CRM系统，客户线索管理、客户资 质审批与合同签订审核，都可以继续保持线下运作。
因此，我们考虑将客户签约作为一个分界点，签约之前的环节依然 线下运作，而为签约之后的环节设计一套全新的系统，支持后续业务流 转。我们将这套系统暂且称为分销系统，将图5-1中的流程图略修改， 体现出包含新系统的新业务流程图，如图5-2所示。从图中可以清晰地 看出一套全新的业务系统对分销业务的支持，及其在主业务流程中的位 置。
通过对核心流程的梳理，以及明确其中哪些环节需要线上化支持， 分销系统的轮廓初现。
此时，我们暂时不需要深入细节，而要基于这个初现的轮廓，进一 步思考分销产品的顶层设计。

2、产品定位

产品定位是对产品概要性的总结和陈述，简明扼要地描述产品对业 务的支持范围，或总体的功能目标。产品定位要说清楚产品针对谁提供 什么支持。
通过对M公司分销业务的核心流程梳理，我们已经对分销系统在整 个系统中的位置有了初步判断，现在，我们进一步思考更精确的形态和 定位。
首先在分销业务中，客户需要一个快速下单的工具，可以提供一个 手机版商城C端。考虑到投入产出比，公司决定通过H5来实现，而不是 App。H5所写的网站具有独立域名，外网可访问。
其次，需要为客户提供一套方便操作的管理后台，因为涉及大量的 商品定价编辑、处理，账号、门店管理等功能，所以考虑PC版本实 现，暂不支持手机版。
最后，考虑到客户管理员和M公司管理人员的管理诉求不同，操作 功能和页面差异较大，所以决定将管理后台拆解为两个独立的系统:给 客户管理员使用的客户管理后台具备独立域名，外网可访问;给M公司 管理人员(和运营人员)使用的运营管理后台也具备独立域名，但仅限 内网访问。
经过以上分析，我们进一步将分销系统拆分为三个独立系统，每个 系统的定位不同:
· 分销商城前台(移动端，通过H5实现):为分销客户提供下单 功能。
· 客户管理后台(PC端):为分销客户提供子账号管理、门店管 理及业务辅助功能。
· 运营管理后台(PC端):为分销业务部门提供客户及商品定价 管理的业务支持功能。
设计业务系统时的常见问题是，为了省事，或者由于业务部门之间 边界模糊、权责界定不清晰，导致很多本应该独立的功能被糅合到一个 系统中，这样会造成将来管理的混乱，尤其是系统维护的混乱。理想情 况下，独立的业务部门应该由独立系统来支持工作。举例来说，假设M公司分销业务的运营人员和公司订单中心的运营 专员是同一拨人，你会考虑在订单系统上扩展功能，来支持分销业务 吗?

3、应用框架

所谓应用架构，是指公司所有产品和系统的整体结构和布局，我们 在“进阶篇”会详细讲述。任何公司的应用架构都不是随意设计的，有复 杂的设计思想蕴含在其中。
在设计一套新系统时，必须考虑如何和公司现有系统架构融合， 不同系统的模块之间如何衔接。这项工作复杂度较高，不仅需要有丰 富的电商架构经验，而且需要深刻理解业务特点和可能的演进方向，还 要熟悉公司目前的系统架构，这样才能快速提炼出相关问题。一般由产 品负责人和公司的架构师甚至CTO共同讨论确定。
M集团已经发展了多年，集团的软件体系结构非常成熟，这就意味 着在设计一套新的系统或产品时，完全可以复用现有的部分系统或模 块，从而快速实现新系统，提高系统建设效率，减少重复开发，更重要 的是，保证合理的整体系统架构。
对于新设计的分销平台，该如何和公司现有系统融合呢?
首先，M公司作为一家成熟的公司，之前已经有面向零售业务的C 端商城，用于支持个人客户线上购物。那么针对分销业务的客户，我们 是单独做一套C端商城，还是改造、复用现有的C端商城呢?经过分析 评估，个人客户和分销客户(属于企业客户)需要的功能差别较大，因 而两套商城的整体区别较大，如果通过对原有商城进行改造来支持分销 业务，需投入的工时会很多，甚至可能比新开发一套系统还要多，而且 还会影响主营业务系统的健壮性，因此公司最终决定做一套新的C端商城(分销商城前台)来支持分销业务。
其次，我们要思考的问题是如何维护、管理客户数据，是在分销平 台中独立管理，还是通过公司现有的客户资料管理模块管理?对于M公 司来讲，现有C端客户资料全部存储在客户主数据MDM(Master Data Management)系统中，我们认为无论是C端客户信息，还是分销业务的 B端客户信息，都是企业的核心资产，应该采用集团统一管理的方式， 因此决定通过改造现有客户主数据系统，支持分销业务的客户信息存储 和管理。
接着我们要思考如何管理客户账号体系。账号是用户登录系统的凭 证，对于企业来讲，账号和客户是两个概念，一个客户可能有多个账 号，但一个账号只会对应一个客户。比较成熟的企业都具备一套成熟的 用户管理中心(Passport)系统，实现统一账号管理。经过思考，我们 打算将现有Passport系统升级，从单一账号体系升级为子母账号体系， 支持分销渠道的企业客户账号管理。
然后我们考虑如何连接订单和仓配系统。公司已经有一套成熟的订 单中心，基于订单中心可以完成正逆向交易操作及财务处理，且目前已 经在支持分销业务手工下单模式的作业处理。因为分销业务售卖的商品 和C端业务售卖的商品来源是相同的，所以订单中心能够完美支持分销 业务，因此决定分销平台不单独开发订单中心，而直接把交易发送给现 有订单中心，由它作为桥梁，连接后续生产配送环节。这样就实现了分 销平台和仓配系统的完美解耦。
关于分销平台的商品管理，完全可以复用C端的商品中心，只需要 对价格模块做定制开发。
最后，我们考虑后端系统的权限管理，以及分销商城前台的支付问 题。由于M公司现有权限管理系统(Auth)与支付平台(Pay)都是基 于服务化建设思路实现的完善解决方案，因此可以作为基础服务快速支 持新系统，无须重复开发。
至此，我们梳理并确定了分销平台和公司现有架构的融合关系，确 定了系统的复用方案。我们将分销平台分为三个子系统，将其绘制到公 司整体应用架构图中，如图5-3所示。深灰色矩形是新增的系统，浅灰 色矩形是原平台中需要结合本次项目进行升级修改的系统，白色矩形是 原平台中不受影响的系统。关于这张架构图代表的含义、形成的原因、 分层的目的，在“进阶篇”会详细讲解。

4、功能模块

明确了应用架构，以及需要新建或改造的系统之后，我们需要进一 步细化，为每个系统设计功能模块。这个系统应用于哪些业务场景?用 户可能在系统中做的操作有哪些?通过思考这些问题来抽象出需要具备 的功能模块。产品经理设计的功能模块代表了其对业务本质诉求的理解
和提炼，蕴含了他对业务、系统未来发展的期望。
我们常说，系统建设要有规划、有节奏，实际上功能模块图就是一 幅完整的规划蓝图，能体现出系统的一二级导航菜单结构，是系统的骨 架。结合业务需求实现的每一个具体功能，都是在对骨架不断地填充血 肉，让它更真实、更立体、更丰富。
设计功能模块的常见问题是模块层次混乱，以及后来新增功能的随 意摆放，这都会造成用户使用系统时产生困惑，同时也会导致开发人员 编码设计的混乱。下面我们为分销业务设计功能模块。
通过自顶向下的分析思路，我们明确了分销业务的三个独立系统 (分销商城前台、分销客户管理后台、分销运营管理后台，见图5- 3)，以及三个系统与公司整体架构的融合关系。接下来，我们进一步 拆解设计，每个独立系统应该具备哪些功能或模块?我们把能想到的功 能集合，现在或未来可能需要的功能列表都列出来，这是一个产品做加 法的过程。
分销商城前台
分销商城前台即客户下单的H5工具，是一个经典的电商C端系统， 分销客户需要在上面完成下单购买操作，也需要完成自我管理(例如对 下属门店的管理，对发票、售后的管理)，因此主要包括购买流程和个 人中心两大部分。从购买流程的角度考虑，商城需要具备以下功能或模 块:首页、搜索、推荐、列表页、详情页、购物车、结算页、收银台。 个人中心要包括订单管理模块、账号管理模块、售后管理模块等;针对 分销业务的特殊诉求，还需要包括门店维护、对账管理等模块。分销商 城前台的功能模块如图5-4所示。

分销客户管理后台
分销客户管理后台是给分销客户管理员使用的管理后台，主要用来 管理下属门店和子账号;还需要随时了解下属门店和子账号的经营情 况，因而需要查询所有下属门店和子账号的数据;此外还需要进行统一 的财务管理。因此分销客户管理后台一共包括下面三个大模块，其功能 模块如图5-5所示。
· 客户管理模块，支持子账号管理与门店管理。 · 综合查询模块，实现所有可能的查询与信息检索诉求，包括门
店报表、订单查询、综合报表、售后查询。
· 财务管理模块，支持基本的发票管理、对账管理，以及分销业 务特有的预付款管理。

分销运营管理后台
分销运营管理后台是支持M公司分销业务的核心业务系统，同时也 是一套典型的电商管理后台。典型的电商管理后台需要具备商品定价管 理、财务管理、风控管理、运营管理、客户管理、报表管理几大模块， 另外，针对案例中的分销业务，还需要具备账期管理模块，其功能模块 如图5-6所示。
· 商品定价管理模块:一般支持商品管理、价格管理。根据5.3节 的分析，在M公司的分销业务中，其商品管理模块将完全复用C端业务
的商品中心;其价格管理将通过价格系数设置模块和门店报价管理模块 完成;商品的基本定价数据将从C端业务的价格中心获取，然后在分销 平台维护价格系数表和门店报价单，从而计算针对不同客户和门店的售 价。
· 财务管理和账期管理:基于前期业务调研，我们明确分销业务 要支持账期和预付款管理，所以相对应的账期回款监控、预付款管理都 是必备功能。
· 报表管理:报表管理模块将提供各类分析报表，实现对业务运 作情况的监控和诊断。
· 风控管理、运营管理:在这两个一级模块中还可以实现定价风 控、订单风控、CMS(内容管理)以及消息中心等，这里不再一一介 绍。

5、演进蓝图

通过绘制系统的功能模块图，可以明确业务和系统的规划脉络。将 能想到的功能集合都列出来，这是一个做加法的过程。但是我们不可能 一次实现全部功能，而要根据业务优先级，拆分成几期来完成，所以接 下来需要做减法:确认产品的功能规划与实现节奏，就是常说的演进蓝
图(Roadmap)。
在对M公司的业务调研中，我们不仅列出了需求，而且明确了需求 的优先级(参见4.5.2节)。根据优先级，以及前面绘制的分销平台三个 系统的完整功能模块(图5-4、图5-5、图5-6)，我们计划将分销平台分 为三期实现，其演进蓝图如图5-7所示。

一期项目聚焦解决最基本的业务流程线上化问题及核心痛点(例如 对账功能)，在图5-7中用白色矩形表示。一期项目要实现哪些功能? 有一个原则可以参考:凡是可以手工处理和解决的问题，都暂时不做系 统支持。例如，报表管理功能可以通过定期运行SQL语句实现;价格系 数设置功能的使用频率低，可以由RD在后台改数据库完成;缺少搜索、推荐功能并不会对客户下单的效率产生明显影响，因为根据调研， 目前每个客户维护的SKU数量最多也不过20个。
二期项目聚焦于解决部分特殊业务刚需的诉求。对于M公司的分销 业务，需要支持预付款模式、账期模式、发票管理，如果时间允许，还 可以实现报表查询的若干功能。在图5-7中用浅灰色矩形表示。
三期项目聚焦风险控制，并强化运营功能，在图5-7中用深灰色矩 形表示。一般来讲，很多互联网公司初期都会聚焦于业务本身，提升 GMV(成交总额)、验证可行性，不会太在意成本和风险控制。当业 务达到一定规模时，则必须引入系统风控机制，实现事前、事中、事后 的风险控制。
此外，基于本案例B2B业务的特点，我们在设计中并没有考虑太多 的C端功能。实际上C端功能只需要保证分销客户能够轻松下单，并做 一些简单的运营、通知即可。
随着设计的深入，以及业务的开展、变化，功能模块可能需要修正 和调整，但只要业务的本质模式没有变化，功能模块就不应该出现结构 性的改动。功能模块图和演进蓝图代表的是概要性方案，指明了整体的 产品方向，是后续细化设计的指引和准则。
设计软件产品时必须遵循自顶向下的设计思路，这是非常重要的， 相信大家已经有了初步的感觉。此外，在互联网产品圈中很流行的用户 体验五要素及其提出的五个设计层次(表现层、框架层、结构层、范围 层、战略层)，也是一种自顶向下、由粗到细的设计思路，感兴趣的读 者可自行查阅。

接下来进行开始完成细节方案设计

经过整体方案设计，B端产品的轮廓和结构变得越来越清晰了，我
们已经为细节方案设计做好了准备。
B端产品的细节方案设计包括业务数据建模、页面流转设计、界面 设计、权限设计等，这些都是产品经理的必修课，即便没有经历从0到1 的设计过程，也会在日常的迭代工作中经常接触。
本章将首先介绍业务数据建模，这是对业务进行抽象的过程，合理 的建模会让后续的功能设计水到渠成，而不合理的建模会导致后续设计 重复返工。接下来将通过梳理业务角色和业务流程，来确定系统需要的 页面，以及各页面之间如何流转。然后讲解产品经理需要具备的一些硬 技能，包括界面设计、报表设计、数据埋点设计、权限设计以及文档编 写和管理的相关问题。最后介绍软件设计中常用的一些绘图方法和模 型，通过图形来表达一些抽象设计概念，会让沟通变得更加简单。

6、数据建模

业务数据建模也叫实体建模、领域建模，或业务对象建模，是指
针对业务特点，归纳并设计对应的底层数据模型的过程。
B端产品进行细节设计的常见流程是，首先构建业务数据模型，然 后基于流程确定页面流转图，再着手每个页面的具体设计，同时提前规 划好系统用户角色，最后完成权限设计。
为什么产品细节方案设计要从业务数据建模开始呢?这是因为软件 系统的模块和功能实际上就是对现实世界的对象和规则的抽象。而软件系统设计的难点恰恰在于合理地总结客观世界的对象和关系，并实现 最基本的数据模型设计。只有总结并设计出正确的数据模型之后，才能 思路清晰地完成功能模块和操作交互的设计。
实际上，业务数据建模是数据库设计中最重要的部分，会影响数据 库表结构的设计，体现了设计者对业务本质的理解和认知。很多产品经 理常常忽略业务数据建模，只关注功能界面设计，最终陷入混乱的逻辑 中。一定要在设计细节方案之初就进行业务数据建模。
接下来，我们以M公司分销平台的客户模型设计为例，详细阐述业 务数据建模的思路。我们首先会设计一套理想版的客户模型结构，该模 型实现了B端常见的比较复杂的组织架构设计。但是理想版客户模型的 开发成本很高，为了降低开发的复杂度，我们会进一步演示如何在既满 足业务诉求，又并保证模型灵活性和扩展性的前提下，对模型进行精 简，得到一套简化版的客户模型结构。

设计理想版的分销业务客户模型
在业务数据建模工作开始之前，我们首先回顾一下客户诉求。在目 前的分销客户中，有比较大型的集团客户，下设若干机构、库房和门 店。调研时，集团客户有如下诉求:
· 上海分公司采用了中央仓库模式，客户从M公司采购商品后， 商品首先会被配送到中央仓库，再由客户自己从中央仓库向上海地区各 门店发货。因此上海分公司需要开通采购员账号，以实现在中央仓库系 统中下单。
· 广州天河区也采用了中央仓库模式，客户从M公司采购商品 后，商品首先会被配送到天河区中央仓库，再由客户自己从中央仓库向 天河区各门店发货。因此天河区需要开通采购员账号，以实现在天河中 央仓库系统中下单。· 广州其他区是门店自采模式，即门店采购员自行下单采购，商 品直接从M公司配送到门店，因此需要针对每个门店创建采购员账号。
· 广东省还需要一个高级别的采购员账号，能够帮广东各仓库和 门店代下单。
上述诉求是业务系统建设中非常典型和常见的树形组织机构管理诉 求。企业往往有多层级管理的需求，需要软件系统支持多层级业务体 系。多层级机构管理通常使用组织机构树呈现，M公司分销业务的组织 机构树如图6-1所示。

这是一个非常典型的多层级组织机构树，树中存在三种对象:
· 组织机构对象，图中用深灰色节点表示，用来描述客户的行政 管理层级结构。分销总部位于组织机构树的根节点上。
· 门店对象，图中用浅灰色节点表示，是下单的目标，是挂在某 个机构节点下的收货对象。在数据结构中称其为门店，实际上有可能是
小门店，也可能是中央仓。
· 账号对象，图中用白色节点表示，代表系统的用户。账号也挂 在某个机构节点下。在“分销总部”根节点下的账号，是分销业务后台的 管理员账号，可以管理整棵组织机构树中的所有数据，包括所有的门店 和账号。每个账号所管理的数据范畴(包括能给哪些门店下单、能查看 哪些门店的数据等)，是通过遍历其所在节点的所有子节点来确定的。
这个组织机构树究竟是如何支撑各种灵活的客户下单管理需求的 呢?我们在6.2.2节中会进一步分析。
每个组织机构(简称机构)对象都有一个“上级机构”字段，基于这 个字段，可以绘制出完整的组织机构树;每个账号或门店对象只能隶属 于一个机构节点;每个门店下可以维护多个收货人。我们将这几种对象 的关系通过数据建模ER图(ER图是一种经典的描述对象之间关系的规 范，6.8节会详细介绍)呈现出来，如图6-2所示。

ER图看似简单，但能够清楚地表达组织机构树中各种对象之间的 关系。实现了这样的模型，便可以描述集团客户的任意的复杂层级管理 诉求。业务数据建模的过程就是将业务对象及其之间的关系抽象出来 的过程，ER图呈现了业务数据建模的结果。

设计简化版的分销业务客户模型
完整的组织机构树的开发复杂度很高。产品经理和业务人员及客户 沟通后确认，一期暂不用支持复杂的行政层级管理，只需要为客户实现
若干子账号，让他们可以管理若干门店即可。因此，产品经理最终决定 采用一套简化版的客户模型来支持一期业务，不过这个简化版客户模型 完全可以在需要时升级为理想版的客户模型。
根据上述需求，我们对组织机构树做一些调整，如图6-3所示。

从图中可见，现在每个客户节点只有一个父节点(隶属于分销总 部);客户的所有账号和门店都挂在该客户节点之下;账号和门店的管 理关系不再需要通过遍历机构节点来获取，图中虚线箭头直接标明了它 们的归属关系。这样的设计将导致账号无法对不同层级的门店进行灵活 管理(像图6-1中那样)，但是会让代码开发简单很多，因为工程师不 需要处理一棵层级复杂的树形结构，也就不需要编写大量的递归算法， 这大大降低了开发难度。
在业务开展时，每个客户有一个管理员账号，可以创建并管理子账 号和门店，子账号可以设置为采购员角色，能够对关联的门店进行下单 操作。而分销业务的超级管理员角色挂在“分销总部”根节点下，依然可 以对所有客户的账号、门店进行全面控制管理。
根据上述规则对理想版客户模型进行简化，如图6-4所示。

仔细观察可以发现，该模型与图6-2中的模型相比，唯一的变化是 在账号和门店两个对象之间建立了关联关系。这样处理保持了模型的可 扩展性，将来需要实现全面的组织架构管理时，将账号、门店之间的对 应关系打断，在业务系统中实现遍历算法和组织机构树管理维护功能即 可，整个数据底层基本不需要调整。
请读者仔细思考并理解ER图中的对象模型，以及为什么这样的模 型能够描述出一棵完整的组织机构树。这个模型是B端产品设计中非常 典型的设计模型，组织机构树也是业务系统中最常见的数据模型。例 如，对于CRM系统，销售团队分为总部、大区、大组、小组，这就需 要用组织机构树来实现对销售团队的多层级管理，此外，团队成员能够 查看哪些客户数据、业绩报表，也需要依据组织机构树体现的管理范 围，来实现数据权限控制及汇总运算。
理清了账号、门店、机构和收货人之间的关系，实际上已经把分销 业务中最独特、最复杂的逻辑和规则都梳理清楚了，接下来进行页面和 功能设计时便会胸有成竹。如果没有梳理清楚这些关系，在做功能和界 面设计时必然会一头雾水、漏洞百出。

7、流程角色

通过业务数据建模，我们对业务的本质有了更深入的思考和沉淀，
对业务中要研究和分析的对象有了深刻的提炼。
接下来，我们开始着手设计业务的流程和角色。流程合理、角色清 晰是系统正确设计的前提和保障。遵循自顶向下的设计思路，我们首先 设计主干流程，在这个过程中可以进一步明确系统角色及业务岗位的安 排，然后基于主干流程图设计页面流转图，最终完成页面细节设计。

绘制分销业务流程图和角色
我们在第5章已经为M公司的分销业务绘制了粗粒度的核心业务流 程图，为了方便阅读，我们将它复制过来，如图6-6所示。现在，我们 要绘制创建客户与下单流程的跨职能分系统流程图。这需要仔细研究、 梳理业务流转的具体环节和步骤，区分不同的角色，描述不同角色在不 同子系统中需要完成的具体工作。

在流程梳理的过程中，必须谨慎思考各个环节在逻辑上的先后顺序 与依赖关系，例如，对于分销客户来讲，创建账号和创建门店的顺序是 怎样的?是一次性创建完成还是分别创建?什么时候维护价格系数表?
通过思考，我们梳理出如下不同角色。
分销业务在M公司内部包含如下几个角色。
· 分销–销售人员:M公司分销业务的销售人员，负责完成客户开 发与合约签订(目前继续采取线下作业的方式)。
· 分销–管理员:M公司分销业务总部的管理人员，主要负责审核 分公司提交的创建客户的申请，核查各分公司维护的价格系数表，并进行毛利核算。
· 分销–运营人员:M公司分销业务总部的业务运营人员，负责具 体的客户创建、维护、报价单维护等事务性工作。
分销业务客户包含如下几个角色。
· 客户–管理员:分销客户的管理员，维护并管理客户公司内的所 有子账号、门店。
· 客户–采购员:分销客户的采购人员，负责给门店下采购单、补货。
基于上述分析，我们绘制出更细致的业务流程图，如图6-7所示。

图6-7中的各个环节分析如下。
首先，分销业务的销售人员(角色为“分销-销售人员”)在线下开 发客户(即分销商)，将签约客户的合同交给运营人员(角色为“分销- 运营人员”)进行审核，这些都是没有系统支持的线下动作。
运营人员审核通过后，在分销运营管理后台创建客户以及客户管理 员账号(母账号，也叫根账号)，其中，客户的信息包括机构名称、营 业执照、税号等，客户管理员账号只是提供给客户的管理员使用的系统 账号。运营人员添加了客户和客户管理员账号后，必须由分销业务总部的 管理人员(角色名称为“分销-管理员”)在分销运营管理后台进行审 核，这是为了控制风险的必需环节。
营销客户的根账号(客户管理员账号)创建完毕后，由分销业务的 销售人员(角色为“分销-销售人员”)通知客户，此时客户可以使用客 户管理员账号登录分销客户管理后台，维护并管理具体的收货门店和子 账号(对应“客户-采购员”角色的账号)。
创建收货门店后，必须由“分销-运营人员”在分销运营管理后台针 对门店编辑报价表，只有设置了报价表，门店才能购买商品。
“客户-管理员”在分销客户管理后台将创建的子账号和门店进行关 联，从而让“客户-采购员”可以通过子账号登录分销商城前台，给关联 的门店进行下单操作。
除了新客户创建、下单流程，还有退货流程、对账流程，都需要一 一设计，设计方法与上面的介绍类似，此处不再展开讲述。
图6-7清晰地描述了从客户开发到下单的关键流程节点，以及不同 的角色在不同的子系统中各完成了哪些操作，最终完成整个流程。通过 跨职能分系统流程图，可以清晰地看出谁(操作角色)在哪儿(哪个 系统)做什么(完成什么工作)。无论是大型系统设计，还是某个具 体需求的设计，都应该绘制流程图来帮助自己梳理业务、理清思路。
需要注意的是，流程图在表述并行工作或异步工作时不是很方便。 从流程图6-7来看，似乎创建门店和创建子账号有先后关系，实际上两 者是可以同时进行的，而且需要等待“分销-运营人员”对门店设置报价 表并使其生效后，“客户-管理员”才能维护门店和子账号的关联关系。 关于异步任务或并行任务的呈现方式，我们会在6.8节进一步介绍。
关于角色还需要说明一点。角色在业务开展初期就已经存在，但是 在设计系统中的角色时，需要结合业务流程进一步梳理，并修正完善，以保证各角色的工作内容是明确且固定的，各角色之间尽量避免职责交 叉，这样才能保证团队成员分工明确，共同协作，达成业务目标。当角 色梳理清晰之后，公司会从管理角度设置不同的岗位，方便管理。
有时可能会出现一个岗位对应多个业务系统角色的情况，例如工作 人员A负责某电商运营岗工作，A在系统中被赋予“运营人员”的角色， 本职工作是设计并配置商品的促销方案。但老板也安排A在工作闲暇之 时协助订单专员做一些订单审核工作，因此A在系统中也被赋予“审单 员”的角色。这种安排相当于要求员工身兼两个岗位的工作，在一些规 模比较小的公司或业务开展初期的团队中，这种情况比较常见;在管理 步入正轨的公司中，这种情况很少见，如果在系统管理中发现某些员工 需要被赋予多个角色，最好和业务部门确认一下岗位的分工与定位是否 合理。

绘制分销业务的页面流转图

梳理完业务流程和角色，我们进行下一步的页面流转图设计。对于 系统设计来讲，业务流程图依然属于比较粗粒度的概要性设计，如何将 它与软件产品的页面设计对应起来呢?绘制页面流转图是一个很好的衔 接方式。
页面流转图描述的是，用户完成某项工作需要访问的页面及页面 跳转顺序。绘制页面流转图可以帮设计人员审视、思考系统中的页面设 计方案，包括系统中总共需要哪些页面，哪些页面可以重复使用，哪些 页面需要定制化开发。一般来讲，我们绘制页面流转图时，都是针对某 个单一角色绘制某个特定场景下的页面访问和跳转逻辑，从用户的视角 来梳理一遍所有相关页面，每到一个新页面时，都要思考:需要新做一 个页面，还是可以复用原有页面?最终整理出系统涉及的所有页面的初 稿。绘制页面流转图没有明确的形式要求，重点在于帮助设计人员在大 脑中构思页面设计思路，铅笔和白纸是最好的绘制工具。
我们以分销-运营人员创建客户和客户管理员账号，以及分销-管理 员审核客户这两个子流程为例，演示如何绘制页面流转图。
请你闭上眼睛，在脑海中思考，如果你的角色就是分销-运营人 员，需要创建客户和客户管理员账号，都需要访问哪些页面呢?
分销-运营人员首先需要登录系统，进入首页，因为要创建客户和 客户管理员账号，所以需要分别访问客户列表页与账号列表页，在列表 页中都有创建按钮，点击“创建客户”或“创建账号”按钮后，分别进入客 户创建/编辑页和账号创建/编辑页。

创建客户后，需要由分销-管理员进行账号审核。
分销-管理员同样要先登录系统，进入首页，因为要处理客户审核 工作，所以需要访问客户列表页。针对某个客户点击“审核”按钮，进入 客户审核页，在客户审核页中可以录入审核结果，并执行通过或拒绝操 作。
这里面有一个问题:分销-管理员和分销-运营人员都要访问客户列 表页，二者看到的客户列表页是否是同一个页面?我们从实际情况考 虑:管理人员可以对每一条客户信息进行查看明细、审核、删除的操 作，而运营人员只能查看客户信息的明细，可见二者查询客户列表的诉 求是类似的，只是操作的功能点不同，这样的差异点完全可以通过权限 配置实现(见6.6节)，而没必要开发两套客户列表页。
构思完页面访问操作的场景，我们开始绘制页面流转图，如图6-8 所示。图中对每个页面做了编号，如果两个流程中某一页面的编号相 同，则代表同一个页面，例如两个流程中都有“2.1 客户列表页”。

可见，页面流转图比业务流程图更加细致。在之前的业务流程图 中，关于分销-运营人员创建客户和创建客户管理员账号的操作，只是 通过一个矩形框就完成描述了，但是在页面流转图中，需要更加细致准 确地描述实现操作的具体步骤和对应的页面。
经过对业务流程、使用场景、页面流转的完整梳理，我们总结出在 分销业务后台(包括分销运营管理后台和分销客户管理后台)需要开发 的页面，如表6-1所示(此处只展示了部分页面)。仔细观察可以发 现，这些页面其实就是针对不同对象(客户、账号、门店、报价单等) 的增删改查页面。

从本质上讲，一套软件系统就是对不同数据对象的增删改查操作 的集合，这个特点在业务系统中更加显著。
当积累足够多经验后，页面的梳理和设计工作会变得得心应手，例 如，看到客户资料维护，就马上意识到需要有列表页、详情页、编辑 页、创建页这几个页面。
有一点需要注意:不是所有的页面都来自页面流转图，因为有些 页面是独立于总体流程之外的，例如报表页、对账查询页等，这些页面 源自对功能模块设计的思考。

8、界面报表

我们已经完成了功能模块设计、演进蓝图设计、业务数据建模、业 务流程梳理、角色梳理、页面流转梳理这一系列环节，已经细化到每个 操作需要访问哪些页面、总共有哪些页面，现在需要为每个页面设计具 体的交互功能了，即进行界面设计。
虽然在界面设计之前的流程很长，但只要你细心体会就会发现，我 们对整个业务形态和系统形态都已经了然于心，对整个项目和产品的掌控力越来越强。此时，界面设计已经是水到渠成之事。
界面设计的流程在团队分工明确、人力储备充足的情况下，在开发一套全新的B端业务系统时，界面设计的流程一般如下:
1.产品经理绘制线框图原型，表达软件中每个页面的设计需求。
2.UE设计师协助产品经理完善交互体验，并制作交互原型。
3.UI设计师基于交互原型进行美工设计，生成切图文件。
4.前端工程师拿到切图文件，进行前端开发，包括实现交互、动效等。
当一套业务系统上线后，后期迭代则基本不再需要UE和UI设计师的支持，前端工程师参考线框图就可以直接进行前端页面开发，因为前端工程师一般会采用现成的控件，例如按钮、文本框、下拉框、表格 等。这种情况下，产品经理相当于同时承担了交互设计师的职责，一定 要保证线框图排版整齐、重点突出。
6.3.2 线框图的绘制
产品经理需要将每个页面的排版样式、控件设计及交互效果，用通 俗易懂的形式表达出来，以方便其他同事快速理解。线框图(也叫原型 图)是一种很好的表现形式。绘制线框图的工具有很多，常见的有 Axure、Mockplus、墨刀、Visio等。
线框图的重点在于说清楚界面上的交互功能设计，而非UI效果。如 图6-9所示是通过Axure绘制的分销商城前台结算页的线框图示例，图中 呈现了结算页中的所有关键信息，包括收货信息、商品信息、购买数量 (可以编辑)，以及切换收货账号和提交订单按钮。通过这幅线框图， 已经可以清楚地看明白该页面需要具备的基本内容和交互效果了。

关于线框图的绘制方法，网上有大量的学习资料，读者可自行查阅并实践，本书不再展开。

尼尔森十大可用性原则

线框图需要反映出交互功能，因而在绘制的过程中需要考虑:用户 在这个页面上会进行哪些交互、怎样设计能达到最好的交互效果。虽然 互联网公司的分工越来越细致，有些公司甚至会给产品经理配交互设计师，但是大多数情况下，B端产品经理还是需要自己完成交互设计的。 因此，产品经理有必要投入精力来学习和练习交互设计。
交互设计领域有丰富的理论沉淀，最著名和经典的理论当属人机交 互大师雅各布·尼尔森(Jakob Nielsen)博士在1995提出的尼尔森十大可用性原则( Jakob Nielsen’s Ten Usability Heuristics )，该理论是针对PC 端交互设计提出的，但同时也适用于移动端交互设计。我们将结合具体 案例详细阐述这十条指导原则，产品经理在绘制线框图时要注意遵循这 些原则。

反馈原则(Visibility of system status)

系统应该在合理的时间、用正确的方式，向用户提示或反馈目前系统在做什么、发生了什么。
人机交互的基本原则是，让系统和用户之间保持良好的沟通和信息 传递。系统要告知用户发生了什么，预期是什么，如果系统不能及时向 用户反馈合适的信息，用户必然会感到失控和焦虑，不知道下一步要做 什么。
以下是遵循反馈原则的一些常见设计案例。

• 安装程序时显示进度条，并预估还需要多久结束。
• 上传文件时显示进度条，并提示预估剩余时间。
• 提交表单时，如果校验失败，则在填写有误的内容旁边提示错 误原因。
• 程序未响应时，系统会让用户选择是关闭程序还是等待程序响 应，如图6-10所示。

隐喻原则(Match between system and the real world)

• 系统要采用用户熟悉的语句、短语、符号来表达意思。遵循真实世界的认知、习惯，让信息的呈现更加自然，易于辨识和接受。
• 在人机交互设计中，程序的沟通和表达、功能的呈现，都要用最自 然的、用户容易理解的方式，避免采用计算机程序语言的表达方式。
• 设计时要采用符合真实世界认知的方式，让用户通过联想、类比等方法轻 松地理解程序想表达的含义。

例如，某音乐播放器App，功能按钮设计如图6-11所示，即便不做 说明，用户也很容易理解每个按钮是做什么用的。

回退原则(User control and freedom)

• 用户经常会不小心操作错误，需要有一个简单的功能，让程序迅 速恢复到错误发生之前的状态。
• 用户误操作的概率极高。对于误操作，软件系统应该尽量提供“撤销”“重做”或“反悔”的功能，让系统迅速返回错误发生之前的状态。

当然，不是所有操作都是可以“反悔”的，比如，你可以撤销一笔错误的订 单，但不能撤销一笔成功的转账交易。
以下是遵循回退原则的常见设计案例。

• 编辑类软件都提供撤销功能，例如Word、美图秀秀等。
• 点击删除或关闭按钮后，会让用户进行二次确认。
• 电商平台允许在一定的规则下取消订单。

一致原则(Consistency and standards)

同样的情景、环境下，用户进行相同的操作，结果应该一致;系统或平台的风格、体验也应该保持一致。
软件设计、产品设计中有很多约定俗成的规范，虽然没有明文规定，但大家都在遵守，因为用户已经习惯了这些规范。我们在进行设计 时，应该遵循惯例，并且保持系统的一致感，不要盲目地标新立异。
例如，在App底部的导航图标中，“首页”永远排在第一个，个人中 心(“我的”)永远排在最后。并且对于类似“首页”“购物车”“订单”等常 见按钮，不同App的设计样式都非常相似，图6-13展示了美团、去哪 儿、百度外卖三款App底部导航栏的设计，可以看到上述特点。如果你 特立独行地把个人中心放在第一个位置，或者采用奇怪的图标作为个人 中心的icon，用户使用时肯定会觉得别扭。

此外，在一个或多个系统中，要采用统一的设计风格。不论是图标 的选用，还是布局的规划，要保持整齐的一致性，这样用户容易理解， 并且容易习惯和适应。
例如，Office软件中包含的各个产品，其界面布局和设计风格就保 持了高度一致，如图6-14所示是Word(上)和PowerPoint(下)的界 面，可以看出，二者的“插入”一级菜单下所包含功能的排列顺序、布局 方式乃至图标图形，都是高度类似的。

防错原则(Error prevention)

系统要避免错误发生，这好过出错后再给提示。进行设计时，首先要考虑如何避免错误发生，其次再考虑如何检 查、校验异常。这样做一方面可以让问题更简单，另一方面可以让用户 避免或减少无谓操作。
例如，有些时候，为了防止用户重复提交或重复点击，第一次点击 按钮后就将按钮置灰，直到处理完成才恢复。
有时还会通过调整按钮顺序，避免用户误点。比如，对于很重要的操作，为了防止用户顺手误点，会将二次确认对话框中的“是”和“否”两 个按钮对调位置，模拟效果如图6-15所示。因为常见的对话框都 将“是”按钮放在第一个位置，所以用户在操作时，很容易产生条件反 射，顺手点击第一个按钮，然后才突然发现自己点错了。虽然看起来有 些别扭，但是很有效，因为多点一次要好过误删文件。这种设计在软件 卸载、App取消会员订阅等操作中也非常常见，只不过后两种情况下主 要是为了做一些心理暗示和引导，避免用户卸载或退订。

记忆原则(Recognition rather than recall)

• 让系统的相关信息在需要的时候显示出来，减轻用户的记忆负担。
• 计算机应该减轻人们的记忆负担，而不是相反。例如，当切换页面时，不应该让用户记住不同页面的内容，而应该在合适的地方积极地呈 现或提示之前的信息。

例如，几乎所有的App和PC端的搜索引擎都会记录用户的搜索历史 并呈现给用户，图6-16 是大众点评App的搜索页，可以看到上面的“搜 索发现”是推荐类功能，下面的“最近搜索”则是保留的用户最近使用过 的搜索关键词。

再例如，在所有的电商购物流程中，在用户提交订单后，都会出现 一个核对页面，让用户再次核对填写是否正确。这个设计非常有用，我 就经常在下单时忘了修改默认地址，再次核对时才发现。

灵活易用原则(Flexibility and efficiency of use)

系统的用户中，中级用户往往最多，初级和高级用户相对较少。
系统应为大多数人设计，同时兼顾少数人的需求，做到灵活易用。
灵活易用原则不仅是一个交互设计原则，也代表了一种软件产品设 计理念:系统既要做得简单、易用，让所有中级用户用起来得心应手; 也要提供必要的帮助，让刚入门的初级用户顺利上手;还需要支持灵活 的个性化定制，让高级用户能够以进阶的方式使用系统，充分发挥其价值。
让高级用户灵活定制的最典型的例子是各类软件和App的配置功 能，基本上所有软件都会提供定制化功能，从快捷键设置，到页面布局，再到自定义参数，软件系统会尽量提供全面的个性化设置功能，来满足不同用户的使用诉求和习惯。
例如图6-17所示是Word的自定义功能，提供了非常强大的配置能 力，用户可以对Word的UI实现颠覆性的重新设置。

简约设计原则(Aesthetic and minimalist design)

对话中不应该包含无关的或没必要的信息;增加或强化一些信息 就意味着弱化另一些信息。
重点太多，相当于没有重点。在视觉设计中，要掌握好“突出标 记”的度，以及内容的呈现方式。
例如，图6-18所示是一份停机通知示例，左图只突出了停机这件事
和停机时间，右图突出标记了更多内容，但是用户反而无法一下子抓住 真正的重点。

容错原则(Help users recognize， diagnose， and recover from errors)

错误信息应该用通俗易懂的语言说明，而不是只向用户提示错误代码;提示错误信息时要给出解决建议。
对于很多运行时错误或异常，计算机程序都会返回某个错误代码， 但是对于用户来讲，看到这些错误代码并不明白发生了什么，所以一定 要将错误代码转换成用户能看懂的语句，并告诉用户解决的建议。
访问网站时，如果页面不存在，服务器提供的标准错误提示是404 错误(如图6-19左图所示)，很多用户并不理解404是什么意思。图6-19 右图所示的页面就对此做了处理，将错误提示转换成用户能理解的表 述，而且给出了解决建议。

再例如，做得比较好的表单填写页面，对于不符合格式要求的内容 会立即进行提示，而不是等到用户提交时才去校验并提示错误;提示时 除了指出填写错误，还会说明规范的填写要求，以便用户理解错误原因 并做出修正。如图6-20所示的易邮箱注册页面就是这样，对于不符合格 式要求的邮件地址、密码、手机号码都直接给出了提示及说明，非常友 好。

帮助原则(Help and documentation)

对于一个设计良好的系统，用户往往不需要经过培训就能轻松上手使用，但是提供帮助文档依然是很有必要的。帮助信息应该易于检索，通过明确的步骤引导用户解决问题，并且不能太复杂。
现在的软件产品，尤其是C端产品普遍做了良好的交互设计，可以 帮助用户快速学习使用，而不用阅读、理解复杂的说明文档。
然而，B端产品的复杂性比C端产品高很多，因为B端产品蕴含很多 业务流程的规则，系统中的一个按钮可能代表了一个复杂的业务处理规 则，如果不了解整个业务场景和处理规则，是很难理解按钮的操作含义 的。
因此，对于B端产品，用户进行自助服务、自助操作的难度高很 多，B端产品的帮助文档依然有存在的必要。产品设计人员要尽量在前 端交互上做好引导提示，对于复杂的规则和逻辑，可以考虑通过帮助文 档来指导用户。

业务系统经常需要将某些信息汇集并呈现给用户，呈现的页面就是 列表页，我们在6.2.2节已经见过客户列表页、账号列表页等。列表页是 B端产品中最重要、最常见、最基本的元素，并且列表页的设计非常讲 究技巧，因而我们将列表页设计单独列出一节，详细阐述。产品经理在 工作中需要设计列表页上都呈现哪些内容，可以进行哪些交互，并且需 要将设计绘制成线框图，图6-21所示就是通过Axure绘制的分销运营管 理后台的报价管理列表页的线框图。

系统中有大量列表页需要设计开发，例如，在M公司的分销业务系 统中，仅“分销运营管理后台”这一个子系统，就需要实现客户列表页、 账号列表页、门店列表页、报价管理列表页等多个页面。
对于开发人员来讲，如果把所有的列表页一一开发出来，那简直可 谓纯体力劳动:没有很高的技术含量，但有大量的重复性开发工作，不 同的搜索项、不同的列表字段，都需要一遍遍核对、开发;经常需要调 整界面布局、增加搜索条件选项、调整默认字段排序，等等。因此，我 们通常不会采取这种方式。
我们可以对列表页进行高度抽象，因为在所有列表页上实现的不外 乎增删改查操作。观察成熟的列表页，可以发现其上面的元素主要包括 检索条件区域、结果列表区域、分页器(控制页码的小组件)等有限的 类型，因此只要实现一套高度灵活的前端控件，能够自定义配置所有内 容，就可以实现列表页的灵活定制。虽然实现这样一套灵活控件的周期 比较长，但是长远来看非常必要。
那么，该如何设计灵活的前端控件呢?一个好办法就是向成熟的优 秀软件学习。目前市面上绝大多数成熟的商业软件列表页的设计都非常灵活，支持完全个性化的列表页配置，产品经理完全可以学习借鉴。
我们先来看一看大名鼎鼎的项目管理软件JIRA是如何实现灵活的列 表页配置功能的，JIRA的列表页组件设计也是我见过的设计方案中最好 的。JIRA提供了一种叫作过滤器的功能，通过新增过滤器来配置一个全 新的列表页。过滤器的编辑页面提供了非常灵活的设置功能，如图6-22 所示。

首先，用户可以设置任意的查询条件。点击图6-22的中间虚线框中 的“更多”选项，可以显示JIRA中所有可能的搜索条件字段，勾选字段， 便可以将该字段增加为搜索条件。
其次，增加某个搜索条件之后，还可以设置它的默认搜索值，例如 可以对图6-22左侧虚线框中的“PRD开始日期”字段设置搜索默认值，从 图中也可以看到，JIRA的日历控件功能非常强大，可以进行各种时间检 索类型的设置，比如过去多久以内、多久之前、某个时间范围之间等， 非常灵活。
再次，用户可以设置任意的列表结果字段，图6-22右侧虚线框的下 拉选项显示了自定义列的设置，可以增加或删除任意需要在列表页中呈 现的字段，且字段顺序可以任意调整，也可以进行排序，并且将这些特性保存下来。
JIRA甚至还提供了一种检索语言JQL，以便让用户实现更加复杂的 检索诉求。点击图6-22中上部的“高级”选项，切换到JQL编辑视图，可 以看到设置好的查询条件已经按照JQL的格式呈现，如图6-23所示，用 户可以像写SQL语句一样继续编辑JQL语句。

JIRA还对列表页提供了一个特别赞的功能:批量操作功能，点击图 6-22右上角的“工具”选项，会显示如图6-24 所示的下拉选项，可以选择 当前页面数据，或所有查询出的数据，并进入批量操作界面。

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

设计批量操作功能时，很重要的一点是帮助用户快速选择操作对 象。JIRA在步骤1中让用户选择了需要批量处理的条目，在步骤2中让用 户再一次细化选择操作，这些细节设计非常贴心，值得我们思考借鉴。

报表设计

任何业务的开展和运转都需报表，报表是业务管理中不可缺少的工 具。一线业务人员需要通过报表来掌握自己的工作情况，并根据需要调 整工作节奏;一线主管需要通过报表来掌握团队的工作情况，和目标进 行对比，调整工作安排;分公司或总部分析人员需要通过报表进行详细 的数据分析，掌握业绩情况，并输出报告;高管需要通过报表掌握核心 指标的每日变化，以及公司整体的经营情况。
业务报表的核心价值是掌握事实、发现问题、分析原因、产生对 策。产品经理要和业务人员一起，关注完整的体系化指标建设，设计有 实用价值的报表。观察、分析问题的视角和思路是报表设计的核心， 绚丽的交互只是次要的外在。
6.4.1 报表设计与应用流程

应用流程

报表设计可能非常简单，也可能非常复杂。简单的情况是，业务人 员提交了报表需求，明确了报表表样，产品经理不用思考表格设计的思 路，只需要负责实现即可;复杂的情况是，产品经理要参与业务分析工 作，建立业务分析监控体系，并负责实现线上化。我们这里讲的是第二 种情况。
报表可能是一张简单的明细表，例如订单明细表、销售记录表，明 细表常常作为基础数据，帮助业务分析人员做进一步的复杂分析。报表也可能是一张复杂的汇总表，例如按区域的销售额汇总表、按产品类别 的销售额汇总表。从什么维度进行汇总?这里面蕴含了观察、监控业务的视角和思路，因而汇总表的设计具有较高的难度，需要产品经理和业 务人员、领导层等一起讨论决定，形成一套科学的指标体系，来准确、 有效地监控业务运转中的各种情况。
从业务的视角来看，一套完整的报表设计及其应用流程如图6-28 所 示，其中前三个环节是产品经理要直接负责的环节，后面三个环节是报 表用户使用报表的过程，产品经理需要理解用户使用报表的方式，和用 户持续沟通，不断优化报表设计。只有从用户使用报表和分析问题的 角度考虑，才能设计出优秀的报表产品。

构建分析体系

之所以设计报表，往往是因为需要针对某个业务主题或业务诉求进 行监控和分析。
构建分析体系之前，首先要明确分析目的，即需要通过分析发现哪 些方面的问题;然后思考该采用什么方法来识别、诊断这些问题，其中 可能的困难是什么。构建分析体系必须建立在对业务的深刻、准确理解 之上，并且要和一线管理团队多沟通，可能很多问题的分析框架和思路 已经被一线工作者发现并有效实践了，一定要善于发掘并参考、借鉴。
例如，我们需要监督并考核线下销售团队，该如何设计一套分析体 系来进行合理的评估、管理呢?可能的思路是对销售过程和销售结果两 个方向进行监控诊断，对于销售过程，重点在于判断销售人员的努力程 度，可以进一步拆解为电话拨打量、线下拜访量、客户线索录入量等; 对于销售结果，重点在于判断销售的业绩是否达标、利润率是否良好。 这就是在构建报表分析的框架和思路。

定义观察指标

理清了分析框架和思路，下一步要确定观察指标，设计具备明确业 务含义的指标来考量业务。一般会先从大的方面拆分出几方面的观察指 标，然后考虑是否将指标进一步拆解为二级指标，甚至三级指标，从而 在更精细的维度观察、分析业务，更准确地反映业务特征。
针对销售过程管理，我们设计的观察指标包括每日外呼电话量(又 可以进一步拆解出呼通电话量、拒接电话量)、每日电话通话时长(又 可以进一步拆解出手机通话时长、座机通话时长等)、每日拜访量(又 可以进一步拆解出有效拜访量、无效拜访量等，近30天内重复拜访量、 近N天内首次拜访量等)，通过这些指标来衡量销售人员是否足够努 力;针对销售结果管理，我们设计的观察指标包括签约客户数、月销售 额、毛利率，通过这些指标来衡量销售人员的最终销售结果。

设计呈现形式

确定了观察指标后，我们要思考以什么形式呈现这些指标，以便用 户能够准确、快速地理解、掌握指标以及变化特征。例如，是采用数据 表格还是柱状图呢?在这个环节，产品经理要和实际用户多讨论，寻找 最佳的呈现方式。报表的可视化呈现会在6.4.2和6.4.3节中详细讲述。
我曾经在设计报表时，非常不理解为什么业务用户对一些核心指标 的呈现要求是，希望简单地呈现当天的数值及其与昨日的环比变化，而 不是列出近期的变化折线图;也很难理解为什么业务用户希望将大量的 数据指标干巴巴地呈现出来，而不是用各种变化漏斗或趋势图来直观呈 现。
直到后来，自己有了一段创业并管理业务的经历，每天要看各种报 表，才体会到，作为一名业务管理人员，各种核心数据都是了然于心 的，看一眼当天的数字，就知道有什么异常。管理人员需要的只是干净 的界面和能够实时更新的准确数字，其他炫酷的交互效果并不需要。跟踪指标变化
管理要用数据说话，报表数据就是诊断和决策的依据。管理人员要 认真对待、分析报表中各种数字的变化、波动。如果只是走马观花地浏 览报表，看不出任何问题，报表就失去了意义。作为一名管理人员，必 须对数字非常敏感，能够快速地感知并解读数字背后的变化和问题，这 是出色的管理人员必须具备的素质。

分析变动原因

如果指标发生了明显的波动，需要跟进分析波动的原因，分析工作 可以由数据分析师完成。
业务团队最好每周分析上周数据走势、变化背后的原因，以便及 时、准确地掌握业务变化情况及原因。
跟进处理问题
分析出问题后，下一步当然是给相关部门或人员安排工作，解决问 题，这也是报表设计的初衷。

【资源推荐】 本节中提到的两个报表引擎的demo地址如下: http://demo.finereport.com http://demo.smartbi.com.cn
除此以外，强烈推荐大家研究学习BI软件Tableau，Tableau是目前 顶尖的数据可视化软件，功能强大，灵活易用，并且可以和公司系统进 行快速结合部署，是学习数据可视化的极佳材料。
报表设计的建议 报表设计是B端产品经理必须掌握的技能之一。针对报表设计，我们有如下建议。

报表设计

聚焦业务分析本身

业务分析思路才是报表设计的核心，产品经理要尽量参与分析体系 构建的过程，这是帮助自己进一步理解业务运行和管理机制的非常好的机会，不要把太多的精力投入在交互体验设计上。
6.4.1节提到过，根据工作性质不同，产品经理在报表设计过程中的 介入程度、工作内容会有很大差别:有些情况下，产品经理要负责建立 整个分析体系;有些情况下，产品经理只需负责后续开发。不论是何种 情况，产品经理都要尽量贴近业务，即便是被动地接受报表需求，也要 努力思考其背后的设计思路。

不要急于线上化

在业务团队中，新设计的报表一般都是由数据分析团队手工制作 的，需要在实践中随时优化修改。如果着急将这类报表线上化，有可能 会面临无数次返工。
试想，在一张新的管理报表试用期间，管理人员随时可能要求调整 个别指标，或调整格式。如果是线下的，马上就可以调整完毕，但如果 已经在系统中上线，就涉及开发、调试、上线，不能很快响应，影响工 作。
等新的报表在线下试用的过程中调试好各种问题后，再实现线上 化，是一个更好的选择。

上线后不要急于推广

报表研发面临的典型困难和挑战是对数据准确性的验证测试问题，
尤其是比较复杂的数据指标，运算过程复杂，验证测试困难:
· 如果是线下已有指标，则需要将线上系统计算的结果和线下计 算的数据对比，如果发现不同，分析其中的原因，但并不能认为线下手 工计算的、长期使用的数据就一定是正确的。
· 如果是线下没有的指标，测试工作就更加麻烦，只能非常谨慎 小心地手工模拟核算，再和系统计算的结果对比，需要足够的细心和耐 心。
鉴于此，报表上线后，应该谨慎、小心地进行一段时间的并行验 证，即将线上系统的计算数据和线下手工计算的数据进行核对、验证。 确定线上系统的计算数据准确无误后，再进行全面推广。否则，如果线 上系统计算出来的是错误数据，会导致业务决策出错。

理解掌握数据仓库原理

想要完成高阶的报表设计，以及针对企业整体经营分析的报表设 计，需要进入一个更加专业的领域，即数据仓库领域。
从企业的视角来看，广义的“报表”设计是一个非常庞大的体系化工 程。如何保证各个业务团队看到的都是同样口径的准确数据?如何保证 不同团队的人对同一份数据有同样的理解、在同一个频道对话?如何保 证企业数据得到“治理”，数据管理井井有条?如何保证软件工程能够提 供灵活的数据和工具，让分析团队能够快速高效、随时随地分析数据?
要解决这些问题，需要专业的技术人才运用专业工具进行企业级数 据、报表体系设计，构建一套合理的企业级数据、报表平台，这就要用 到数据仓库的知识。这是一个业务和技术高度交融的方向，产品人员必 须同时具备技术架构知识及业务知识，才能正确开展设计工作。
B端产品经理需要了解数据仓库的基本概念，包括掌握数据体系的 逻辑架构，理解数据集市、星形模型、数据立方体等基础概念，这对报 表设计十分有帮助。
【资源推荐】
学习数据仓库知识，推荐阅读韩家玮教授的经典著作《数据挖掘概 念与技术》，其中前3章详细讲述了数据仓库、数据集市、数据处理的 基础知识，值得每一位产品经理阅读。这本书的其余部分讲述的是数据 挖掘算法，如果你从事的是策略算法相关工作，也值得一读。

9、数据埋点

数据埋点设计是产品交互设计过程中必须同时进行的工作，数据埋点无论是对C端产品还是对B端产品来说都很重要:对于C端产品来讲，通过数据埋点可以分析用户行为，持续优化产品，如果没有数据埋点， C端产品运营就无从下手;对于B端产品来讲，数据埋点是考核产品使用程度的一个重要依据，也是业务用户行为分析、产品分析、产品改善的重要参考数据来源。
作为产品经理，有必要理解数据埋点的技术原理、埋点手段、各类 埋点工具的使用方式和特点，以及基于数据埋点的分析思路。

6.5.1 什么是数据埋点

数据埋点的历史和含义

在Web 1.0时代，网站设计人员及分析人员需要了解网站的访客数量、访客来源、页面访问情况等信息，从而优化网站结构和内容。例如，分析人员需要知道什么样的排版设计可以提高转化率，哪些版块内容比较吸引人、应该加大投入。
为了满足这些分析诉求，程序员可以自己开发一套数据监控平台，记录访客相关的所有数据，再开发一套报表呈现平台，让分析人员能够方便地进行数据观察和分析。
但是这样做的成本非常高，小公司根本没有实力做这些事情。然而，监控、分析访客的行为，研究站点的流量来源和走势，这是网站运营的刚需，尤其是在各类线上广告投放体系(例如SEO、 AdExchange)成熟之后，网站主更加需要功能强大的分析工具，帮助其优化网站、提升网站的转化率和商业价值。于是，各类专业的网站监控、流量分析的统计工具应运而生。知名的网站分析软件有国内的CNZZ(后来和友盟合并)、百度统计，国际 上有Adobe的Ominiture和大名鼎鼎的Google Analytics。
使用这些分析工具的方法非常简单，一般是将一小段唯一的 JavaScript代码片段注入网站的一个公共JavaScript文件(或公共的HTML 代码片段)即可，工作量非常小，部署非常方便。如果需要更加精细地 监控按钮点击等行为，则需要针对每一个交互事件插入更有针对性的代 码片段。这些在网站中注入分析工具提供的代码片段，以便网站分析 工具能够准确捕捉用户行为的工作，就叫数据埋点。移动端App的数据 埋点和Web端大同小异，也需要在App代码中“埋入”各种分析工具提供 的代码片段。

数据埋点的流程

数据埋点的流程一般包括申请分析网站账号、获取埋点代码片段、 将代码片段埋入网站或App、观察分析数据，如图6-34所示。以下流程 中的前三步一般都由研发人员负责，产品经理重点参与第四步，详见 6.5.3节。

常见的B端埋点工具简介

目前国内使用比较多的Web端埋点工具有Google Analytics(GA)、百度统计，移动端埋点工具有GrowingIO、诸葛IO、 神策。简单介绍如下。

Web端埋点工具

GA:功能强大、全面，遗憾的是国内访问GA站点很不稳定，经常 无法访问。更准确地说，GA在后台的数据采集(捕获)功能是非常稳 定的，可以正常使用，但是分析报表经常无法访问。
百度统计:和GA功能相似，支持各种分析诉求。百度统计和自家 的广告平台结合比较紧密，使用起来非常方便，容易上手。图6-35所示 是百度统计的工作台界面，由于工作台界面尺寸比较大，所以图片可能 看不清楚，大家可以扫描本书勒口处二维码查看大图。图6-36至图6-42 亦是如此。

移动端埋点工具

各家的移动端埋点工具的核心功能基本相似，有些强调私有化部署，有些强调无埋点技术，扩展功能上有所不同，但本质上区别不大。
如果不考虑数据安全性问题，建议Web版的B端产品部署百度统计，因为接入简单方便，而且足够做基本的统计分析。对于移动端的埋点软件，区别不大，根据偏好自行选用即可。

埋点工具的数据分析

完成埋点后，埋点软件就开始采集用户访问网站或使用App的各种 行为数据了，登录埋点工具管理后台，产品经理便可以查看、监控数据，进行各种有趣的分析，我们主要以GA为例进行介绍。GA是Google 的产品，功能极其强大，已经成为埋点分析领域的标杆，其他埋点工具 或多或少都参考了GA的设计理念。因此，只要理解GA的工作原理和使用方法，就很容易理解并使用其他埋点工具。
基本分析
通过埋点工具，可以让分析人员对网站的全体用户、分群用户、个 体用户的浏览行为进行全面、准确地监控和分析，从而优化站点内容， 提高留存率、转化率等。我们通过GA提供的demo账号来看一下相关功 能。
一张典型的GA分析报表如图6-38所示，这张报表呈现了网站页面 的访问情况，包括Pageviews(页面浏览量)、Unique Pageviews(页面 唯一身份浏览量)、Bounce Rate(跳出率)、Avg.Time on Page(平均 停留时长)等基本信息。左侧是菜单结构，右侧是数据表格及图形化呈 现。折线图可以更改成其他图表类型，还可以添加对比指标，可以通过 折线图上方的“+Add Segment”按钮来细分用户群组，观察不同用户群组 的访问行为。

GA功能强大，可以统计访客来源(运营商、渠道、通过搜索引擎 搜索等)、设备信息(浏览器、操作系统等)、访客属性(性别、年龄 等)、页面访问量、停留时长、流转去向、跨设备情况等一系列信息， 可以让分析人员从不同的维度观察流量特征。
除了基本分析，GA还提供了很多有意思的主题分析，我们继续来 看。

桑基图

桑基图(Sankey Diagram)也叫能量分流图，可以通过桑基图方便 地观察流量的流转情况。GA提供了强大的桑基图交互功能，可以对任 何流量分支进行标记、下钻，或者观察细分用户群体的流量特征。如图 6-39所示，GA通过桑基图对页面流进行观察，分析的起点是流量的来 源，包括Google、直接访问、邮箱等，来自不同渠道的流量会走向不同 的页面。通过桑基图，我们可以概要性地迅速观察用户的整体访问路径 和习惯，以及在哪些页面、什么情况下用户会中断访问。

Cohort分析图

Cohort分析(中文是群组分析、队列分析等，没有统一译法)是一 种经典的留存分析方法，如图6-40所示是GA提供的一组用户访问留存 的Cohort分析图，纵坐标代表新用户第一次访问的日期，横坐标代表当 日访问的新用户在第二天、第三天、第四天再次访问的百分比，可以看 到时间越往后衰减越严重。除了研究用户访问留存率，Cohort分析图还 可以用在复购分析的场景。

访客分析

客观分析全面的用户行为数据，是线上业务取得成功的重要因素之 一。用户在线上的每一个动作、行为，都可以被准确地捕获、记录，这 是线下世界无法企及的。例如，在线上环境，顾客看过哪些商铺、浏览 了哪些商品、对哪些商品关注的时间最久，等等，所有细节都可以被记 录，并进行充分挖掘，形成对用户兴趣、行为、爱好、特点的刻画，进 而提供相关的推荐和差异化推送服务。
GA可以准确记录每一个访客的所有行为，如图6-41所示，访客在 什么时间点做了什么事情，一目了然。这个功能对研究个体用户的浏览 行为有很大帮助，对研究B端业务用户的使用习惯，甚至是排查作弊操 作也帮助巨大。有很多埋点软件甚至还提供录屏功能，可以回放用户的 操作过程。
以上非常简单地介绍了GA的一小部分功能，这些只是GA强大功能 的“冰山一角”。建议大家通过免费的demo账号去体验、研究GA的功
能，不仅可以提升数据埋点的专业技能，还能提升数据分析、软件设计 的水平。

热力图

热力图(Heat Map)是一种通过标记页面不同区域的颜色深浅，来 呈现网页不同区域点击热度的图表，可以方便地观察页面中不同功能的 点击使用情况。
因为GA对热力图的处理不是很理想，所以针对热力图，我们选用 了国内分析工具易分析demo账号中提供的功能截图，如图6-42所示，建 议读者亲自使用易分析的demo账号感受一下彩色的热力图效果。

使用热力图可以非常方便地监控页面功能使用情况，例如，假设有 一个列表页，里面有十几项搜索选项，我们想观察这些搜索选项的使用 情况如何，有三种办法:
· 分析点击搜索按钮后的log中记录的query，通过识别query的传参 来统计搜索选项的使用情况。
· 对每一个搜索选项进行埋点监控，观察每个按钮控件的点击情
况。
· 使用热力图，观察页面上搜索选项区域的点击热力分布。 显然，第三种方法最简单、高效。
对于B端产品，我们可以通过热力图来观察功能页面中具体功能的 大概使用情况，而不用像C端产品那样对页面中每个按钮、每个文本框 进行埋点监控。
【资源推荐】 访问以下链接，可以直接体验GA以及易分析的demo账号。 GA:https://analytics.google.com/analytics/web/ 易分析:http://www.yeefx.cn/demo.show.php

10、权限管理

现在，我们已经完成了产品细节设计的大部分工作:我们设计好了 业务流程图和页面流转图，掌握了各个角色会进行哪些操作、访问哪些 页面，并完成了页面的详细设计。在6.2.2节的例子中，有一个小细节值 得注意:分销-管理员和分销-运营人员都需要访问客户列表页，只是要 进行的操作不同。对于这种情况，我们没有开发两套客户列表页，而是 在一套客户列表页上设计了不同的权限，非常方便地满足了不同角色的需求。
本节要讲述的就是权限设计，这是业务系统设计中一个非常重要 的环节，它反映了设计人员对整个业务体系中岗位和流程的理解。权 限设计的前提是合理的角色设计，在此基础上，只需要明确不同角色能 访问哪些页面、能看到哪些数据以及能做什么操作即可。在界面设计完 成后，就要做相关的权限设计了。软件系统的权限包含两部分:
· 功能权限，指各个角色可以操作的界面、按钮等，例如管理员 可以进行新增、删除、修改等操作;运营人员在同样的页面上只能使用 各种筛选条件查看数据，无法做更改。
· 数据权限，指各个角色在各页面中能看到的数据范围，例如分 公司管理员在订单查询页能看到分公司的所有订单，而区域主管在订单 查询页只能看到所在区域的订单。
下面我们就来看一下如何设计这两部分权限。
设计页面的功能时，要考虑页面中的各个功能点是否要做权限控 制。相应地，在每个页面的设计文档中，除了描述页面功能本身，还需 要描述系统中不同角色对页面中的各个功能点的访问权限。我们通常用 权限表来描述权限、角色的配置关系，这张表在产品设计阶段就需要准 备好。
我们来看权限表的示例，如表6-4所示。M公司分销运营管理后台 的部分功能页面、页面元素如表中左侧的三列(除序号外)所示，其 中，“一级导航”列代表页面所在的一级导航目录，如果系统存在二级导 航目录，则可以加入“二级导航”列;“页面”列代表某具体页面;“页面 元素”列代表某页面中需要实现权限控制的功能点。现在我们针对“分销-管理员”和“分销-运营人员”这两个角色梳理功能权限，见表6-4右侧 的两列，其中“√”表示可以访问或操作，“-”表示不可以访问或操作。

RBAC权限模型
在6.6.1节中，我们通过一张权限表描述了页面、功能点和角色之间 的关系。实际上，软件系统中典型的、完整的功能权限管理，除了页 面、功能点、角色，还涉及用户组、资源等概念。关于完整的功能权限 设计，最经典的理论是1995年由计算机科学家Ravi Sandhu提出的 RBAC(Role Based Access Control)模型，描述了一套用户、角色、权 限组的设计理念，在业务系统设计中被广泛采用。如果产品经理需要设 计功能权限管理系统或模块，就必须理解RBAC权限管理模型。
RBAC模型可以简单地抽象为ER图(图6-43，关于ER图的介绍详见 6.8.1节)，即每个用户都要被赋予一个或多个系统角色，每个系统角色都对应一个明确的权限集合，包括对菜单、页面元素等资源的访问和操 作权限。RBAC模型中还引入了用户组的概念，即如果用户较多，可以 对用户进行分组，将角色和用户组进行关联。当有新用户时，只需要设 置其所在的用户组，就会将用户组关联的权限赋予新用户。如果用户角 色需要批量调整，只需要调整用户组和角色的关联关系，而不用重新变 更每一个用户和角色的对应关系。

如果理解了RBAC的ER图的含义，就非常容易理解功能权限管理模 块的设计思路。在实践中，产品经理可以研究并参考成熟软件产品的功 能权限模块是如何设计的。例如，全球知名厂商SalesForce的CRM产品 Sales Cloud就遵循了经典的RBAC权限设计思路，实现了用户、角色、 权限组的管理;同时实现了更灵活的配置功能，可以对页面、视图甚至 排版布局等进行详细且全面的个性化定制。
图6-44呈现了Sales Cloud对基本角色属性的权限管理模块，可以看 到，除了页面、控件级别的设置，还可以对系统内的每个业务对象进行 读取、创建、编辑、删除等权限的控制，这里的业务对象包括业务机 会、个案、价格手册等，这些都是CRM系统中常见的业务对象，相当
于M公司分销平台中的机构、门店、报价单等业务对象。有兴趣的产品 经理可以对Sales Cloud的权限管理体系的功能进行深入研究，参考并应 用于实际的产品设计工作中。
完整的RBAC模型理论称为RBAC96模型族，该模型对角色的继承 关系、权限的约束关系等更复杂的话题进行了深入分析和指导。 RBAC96是对计算机系统权限管理的高度抽象模型，适用于任何业务系 统。如果对权限管理的理论有兴趣，可以继续深入研究RBAC96体系。

数据权限设计
角色在页面中能查到的数据范围，叫该角色的数据权限。所谓能查 到的数据范围，不是指能看到的数据字段，而是指能查出来的数据集 合。例如，针对订单列表页，数据范围可能是某个城市的所有订单，也 有可能是某个账户下的所有订单，也可能是某几个账户下的所有订单。
针对数据权限的控制，常见的实现方案如下。
· 方案一，通过组织机构树控制。该方案根据账号所在组织机构 树中的节点位置，来判断能够查询的数据范围。这种方式最复杂，但最 灵活，能够支持各种复杂的业务数据权限诉求。
· 方案二，通过客户地区控制。该方案根据账号所在区域来判断 允许查看的数据范围。这种方式简单、容易实现，但灵活性差，只能满 足非常初级的数据权限管理诉求。
我们重点介绍方案一。
假设我们实现了6.1.1节中的完整的组织机构树(图6-1)和理想版 的客户模型(图6-2)，如果系统能够实现通过读取这棵树上的节点来 实现数据权限的控制，那么数据权限的管理将变得十分灵活。
为了向大家解释如何通过组织机构树来实现灵活的数据权限管理， 我们创建一个新的客户-采购员角色来对比说明。我们把新创建的角色 称为“客户-采购员2”，原来的角色称为“客户-采购员1”。其中“客户-采 购员1”能够查询用户当前所在节点及其所有子节点上的数据，“客户-采 购员2”只能查询用户当前所在节点上的数据。分销业务的组织机构树如 图6-45所示，深灰色节点代表机构，浅灰色节点代表门店或账号，账号 被赋予的角色在相应的虚线框中进行了标注。与图6-1相比，我们对图 中的账号和门店编了号，而且“分销总部”下面新增了一个账号。根据这 些信息，我们足够判断每个角色所能查询的数据范围。

· “账号0”被赋予“分销-管理员”角色，是“分销总部”根节点的下属 节点，该账号处于整个分销业务顶层根节点的位置，且数据权限范围 是“当前节点及其子节点”，因此，在账号管理、门店管理、订单管理等 功能中，“账号0”可以检索出分销业务下的所有账号、门店、订单的信 息，并对其进行增删改查操作。
· “账号1”被赋予“分销–运营人员”角色，和“账号0”的数据权限范 围相同，但是页面上的功能权限略有不同，我们在6.2.1节中提到过。
· “客户1”是某个具体的分销业务客户，“账号2”是“客户1”的根账 号，被赋予“客户–管理员”角色，且数据权限范围是“当前节点及其子节 点”，这说明“账号2”可以查询并管理“客户1”下面的所有账号、门店数 据，并可以查询其中的所有订单数据。
· “账号3”属于“上海机构”的子节点，被赋予“客户–采购员1”的角 色，数据权限范围是“当前节点及其子节点”，因此“账号3”可以查询“上海机构”节点下的所有订单数据。
· “账号5”属于“广州”节点的子节点，被赋予“客户–采购员2”的角 色，该角色和其他角色不同，数据权限范围是“当前节点”，因此“账号 5”在订单页面只能查看同级别的门店订单，即“门店2”和“门店3”的订 单，但是看不到所在节点子节点下的门店订单，即看不到“天河”节点下 的“门店4”“门店5”的订单。
· “账号6”属于“天河”节点的子节点，被赋予“客户–采购员1”的角 色，数据权限范围是“当前节点及其子节点”，因此“账号6”可以查询“天 河”节点下所有门店的订单数据。
我们将以上所有账号能查询的门店的订单数据范围整理在表6-5 中。对于“账号4”，你能否判断出它能查看哪些门店的订单数据呢?如 果你能够理解这个案例中不同账号所管理的数据范围，那么说明你掌握 了业务系统数据权限管理体系的主要核心思想。

11、文档编写

产品设计工作会涉及一些文档，主要包括BRD(Business Requirement Document，商业需求文档)、PRD(Product Requirement Document，产品需求文档)和MRD(Market Requirement Document，市 场需求文档)，三者的编写时间、受众、编写目的和重点各不相同，具体见表6-6。

在B端产品领域，BRD一般由需求方填写，用于提交需求;PRD由 产品经理编写;MRD在B端产品中鲜有涉及。接下来我们重点讲解BRD 和PRD。
商业需求文档(BRD)的管理
在产品设计工作中，无论是研发还是产品经理，都喜欢“好需求”， 所谓好需求，是指具备业务价值的需求。好需求都来自业务真实的痛点 或问题，经过产品设计、开发实现后，能够帮助业务解决实际问题，带 来收益和价值。
产品设计的好坏，首先取决于需求的质量。如果需求质量不高，产 品设计再用心，也难以产生价值。实际上，很多需求都只是需求提出者 的灵光一闪的想法，并没有经过严谨的思考。对于B端产品，尤其是业 务系统，业务方一般都有需求管理团队，负责调研、整理业务需求，提 交给产品经理。产品经理首先需要对需求进行判断，如果发现需求质量 不高，就需要和业务方反复讨论，判断需求的真实性。
如果没有一些机制或手段，让需求提交者经过全面思考后再提交 需求，则可能会造成需求泛滥，需求质量低下，进而导致产品经理需 要耗费很多精力去鉴别这些需求的真实性和价值。要求需求管理团队以 正式BRD的形式提交需求，可以在一定程度上提高需求的质量，并且可 以作为正式备档文件留存，帮助项目组提高协作效率。
下面是一份比较完整的BRD模板，大家可以结合自己的工作参考使 用。

产品需求文档(PRD)的编写
在互联网公司，产品需求文档(PRD)由产品经理编写。不同公 司、团队、项目组对PRD的要求不同，有的比较严格，有的比较宽松， 甚至在有些创业团队中根本不需要PRD，在产品经理和研发人员的沟通 讨论过程中，功能就开发好了。但是，随着公司规模扩大，规范的PRD管理是非常必要的，这可以让项目开展更加有序，大大方便产品经理和 研发人员的沟通，让知识传播与传承更加准确有效。
编写PRD是产品经理需要掌握的一项基本功，产品经理需要在PRD 中用清晰、通俗的文字将复杂、抽象的软件设计思路和方案描述清楚。
下面是一份典型的B端产品PRD模板，包括背景描述、收益分析、 异常处理、权限管理等版块，产品经理按照这个大纲编写PRD，能避免 结构性的缺失和遗漏。我们在模板中对每一项内容该如何填写做了说 明，大家在实际工作中可以参考使用。特别提醒，模板中有明确的版本 变更记录表格，产品经理必须严格填写变更记录表，记录文档修订历 史。

还要强调一点，产品经理不必急于写PRD，而要完成模型设计、流 程设计、界面设计、权限设计等工作后，再编写PRD。否则，如果方案 还没有理清就开始编写文档，会思绪混乱，不断返工。

文档管理要点
在传统的软件工程项目中，文档管理是一件非常严肃、严谨的事 情，文档的命名规范、审核流程、分发规范都有明确的要求。在互联网 公司，文档管理的要求相对宽松很多，但这并不代表文档管理可以随意 而行。遵循良好的文档管理规则，能够让工作井井有条，利于掌握项目 进度，提升效率;反之，如果不遵循这些规则，会造成工作混乱、失 控、出错，甚至影响整体项目推进，

文档命名要遵循一致的规范
一般来讲，我们常常按如下格式对文档进行命名: 公司缩写+事业部+文档名称+版本号
例如， M公司分销业务运营管理后台PRDv1.0.docx
或者 M公司分销业务_运营管理后台PRD_v20190513.docx
注意，对于同一个公司或事业部，名字中的“公司缩写”“事业部”要 保持一致;“文档名称”要反映这个文档本身是做什么的;版本号有专门 的规范，见下文。

对文档进行版本管理
如果你要将某个修改后的文档发给别人，那么一定要给文档标记版 本。如果没有标识清楚，多次收到修订文件的同事会分不清哪个文档是 最新的，极有可能搞错版本，造成工作错误，引起很多不必要的麻烦。
文档的版本可以按照序列号的形式来标识。例如v1.0、v1.1，如果 遇到比较大的变化，还可以直接跳到v2.0或v3.0。这种方式有点类似软 件的版本管理，优点是可以看出版本的修订次数，或文档的“年龄”，例 如一个版本为v12.1的文档一定是一个很有历史的文档;缺点是无法一 眼看出文档的修订日期。按照序列号标识文档版本的示例如图6-47所 示。

文档的版本也可以按照修订日期来标识，例如v20190503、 v20190521。这种命名方式的好处是可以一眼看出文档的更改日期，缺 点是无法快速识别文档的修订次数。如果文档在同一天被修改分发了多 次，则还可以在日期后边追加序号，甚至时间，例如v20190503_01或者 v20190503_1623。按照修订日期来标识文档的示例如图6-48所示，看起 来同样很清爽。

值得一提的是，一旦选择了某个文档版本标识规则，就要统一按这
个规则命名，避免两套规则共存。
除了在名字上体现文档的版本，在文档内部也要保留修订历史。文 档的所有变更，包括变更人、原因、时间、内容，都需要记录。采用文 档版本控制软件是一种常见的做法，类似CVS、SVN这样的版本管理软 件能够帮助你保存所有的文档版本。但是我们不能完全依赖外部工具， 文档本身也应该记录修订历史，这一点非常重要，6.7.2节提供的PRD模 板中就体现了文档修订记录的内容。
将文档存档管理
文档是公司非常重要的知识资产，正式发布的文档务必上传到服务 器中存档，不能只保存在个人电脑中。即便公司或团队没有要求，产品 经理也要做好所有文档的线上备档、存储工作，以保证公司的知识资产安全。
在互联网公司，产品经理和研发工程师习惯将每一个版本的文档都 上传到Wiki系统中，实现文档的线上化存储，这是一种非常好的工作习 惯。
文档管理要做好规范命名、版本管理、存档管理，虽然略显烦琐， 但却是必须重视、贯彻的工作。

UML和常用图表
在软件设计中，有很多抽象的概念、思想很难用文字表达清楚，通 过图形、图表来描述却很容易让人理解。诞生于20世纪90年代的统一建 模语言UML(Unified Modeling Language)就是一种常用的图形化语 言，经过多年发展，目前已经是一套成熟的规范和标准，是软件工程师 做抽象设计时的有力工具。
UML规范中定义了类图(Class
Diagram)、对象图(Object
Diagram)、协作图(Communication
Machine Diagram)、活动图(Activity Diagram)、组件图(Component Diagram)、部署图(Deployment Diagram)等多种图形方式，每一种图 形都用来从某个视角解决某类程序设计的抽象描述问题。
产品经理，尤其是B端产品经理，必须掌握UML的相关知识，能够 通过UML来表达阐述自己的设计思路，方便和开发人员进行高效的沟 通。产品经理常用的UML图包括ER图(UML中的类图)、跨部门流程 图(使用频率最高)、状态机图;可能用到的UML图包括活动图、用 例图。接下来，我们逐一进行介绍。
绘制文中提到的UML图表，常见的单机软件有Visio(Windows系统中)、OmniGraffle(macOS系统中)，在线的绘图软件推荐 ProcessOn，这些软件上手都非常简单，读者可自行练习。

ER图
ER(Entity Relationship)图是一种描述实体对象(Entity)之间关 联关系(Relationship)的经典图表，由科学家Peter Chen于1976年发 明，最早被用于关系型数据库。
即使没有听说过ER模型，你在工作中肯定已经接触过它。例如， 我们在设计产品时，经常要讨论一些对象的对应关系，是一对多还是多 对多，这实际上就用到了ER模型。
在6.1.1节的客户模型设计中，我们已经通过ER图展示了客户建模 以及业务数据建模的方法。ER图的呈现方式很多，比较常用的是UML 的呈现方式，实际上就是采用UML中的类图(Class Diagram)所规定的 符号标记规范来进行描述和呈现。
图6-49是通过Visio绘制的类图，其中每一个大方框代表一个对象， 方框中的第一行描述对象名称;第二行描述对象中的数据字段，例如图 中“机构”对象有一个字段“上级机构”;最下面一行描述对象所具备的函 数，这是程序设计时用到的概念，产品经理可以不用关心，此处留空即 可。两个对象之间用实线连接，实线两端标上数字，用来描述它们之间 的对应关系，例如图6-49描述了机构和门店是1对多关系，即1个机构节 点可以对应0个到多个(0..*的含义)门店。

图6-50描述的机构和门店同样是1对多关系，但请注意此例中，1个 机构节点可以对应1个到多个(1..*的含义)门店，至少要对应1个门 店。

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

跨部门流程图
跨部门流程图是一种相对复杂的流程图，可以清晰准确地描述分 角色、跨系统的业务流程，跨部门流程图实际上是流程图的泳道化呈 现，每个职能部门在图中呈现出一条“泳道”的效果。严格来讲，流程 图、跨部门流程图不属于UML的范畴，尤其是流程图，拥有更加悠久 的历史，在各行各业均普遍使用。
国际标准组织ISO(International Standard Organization)在1970年定 义了流程图的基本符号规则，在实践中，为了便于不同背景的读者阅读 理解，建议尽量采用简单的绘图规则，例如，只使用开始、结束、执 行、判断这四种标记符号来绘制流程图，而不要引入其他更加复杂、高
级的标记符号，以保证流程图容易理解。 跨部门流程图的简单示意如图6-52所示，还可以参考图6-6和图6-
7。绘制跨部门流程图的要点如下。

· 开始、结束节点必须用专门的图形(多边形和椭圆形)来表
达，这样容易让阅读者较为轻松地识别开始和结束的位置。
· 每个流程只有一个开始节点，但可以有多个结束节点。
· 尝试调整泳道的顺序，以便保证流程看起来清晰干净，而不是 交叉、缠绕在一起。

状态机图
状态机图(State Machine Diagram)也叫有限状态机图(Finite State Machine Diagram)，是一种描述所有状态及状态之间流转规则
的图形。
在软件设计领域，“状态”在业务系统中无处不在:订单要有状态， 账号要有状态，门店要有状态，可以说任何对象都有状态。设计状态是 一件很有意思的事情，需要注意以下事项:
· 状态值必须是有限的集合，状态的所有枚举值(即状态值)必 须能够涵盖所有实际可能的情况。
· 状态值之间要互斥，不能出现二义性。
· 为了更准确细致地描述事物，状态还可以具备子状态，比如订 单状态“已取消”，可以定义对应的子状态“客户取消”“商家取消”“系统取 消”。
· 状态应该是能持续一定时长的，而不应该是很快就会结束的瞬 时态。例如，订单的状态可以是“待发货”“待评价”，但不能是“发货 中”“评价中”。
通过研究状态之间所有可能的流转规则和逻辑，能够识别状态设计 的合理性，并梳理清楚业务规则。如果用文字描述状态之间的轮转，会 非常不方便。通过状态机图，就可以非常好地解决这个问题。
图6-53是分销业务中“客户”这一对象的状态机图，可以看出，状态 机有一个开始节点和一个结束节点，圆角矩形中的内容代表状态值，从 图中可以看出，分销业务系统中的“客户”一共有四种状态，分别是“待 审核”“已生效”“未通过”“已停用”。

活动图
活动图(Activity Diagram)是流程图的一种，用来描述一系列过 程。活动图和流程图最大的区别是，活动图可以描述并发工作的执行过 程，而标准流程图的节点必须是顺序执行的，只有判断节点才能引出两 条分支。
在M公司的案例中，客户根账号(对应客户-管理员角色)被创建 后，客户-管理员下一步要创建子账号和门店，实际上这是两个可以并 行发生的动作，并没有先后顺序的要求，且门店和子账号都创建完毕 后，才可以对二者进行关联。这个逻辑在流程图中无法准确呈现，通过 活动图可以清晰地描述，如图6-54所示，“根账号生效”这个步骤的下一 步，产生了一个并行任务的分支，表示“创建门店”和“创建账号”这两件 事可以同时发生，接下来是一个分支合并，表示当“创建门店”“创建账 号”这两个事件都完成以后，流程可以继续往下走，执行“关联门店账 号”的操作，然后结束。

用例图
用例图(Use Case Diagram)从用户视角来描述系统的操作功 能。简单来讲就是某个角色或用户在不同场景下能做什么。图6-55是一 个简单的用例图。在实际工作中，用例图提供了一种较为生动的用户操 作场景的呈现形式，复杂的用例图基本很少用到，产品经理简单了解即 可。

以上介绍了产品经理常用的图表，产品经理绘制图形的主要目的是 说明清楚设计思路，这些图表可能给技术人员看，也可能给业务人员 看。在实际工作中，产品经理应该尽量使用简单的方式，让别人理解 自己的设计和意图。不建议使用过于复杂的UML规范，因为不是所有 人都具备UML知识，如果采用了复杂的UML标记体系来绘制图形，会 导致其他人看不懂，失去沟通的意义。
【资源推荐】
多看UML实例可以快速准确地理解各类图表。推荐学习网站 www.umldiagrams.org，该网站对UML进行了详细讲解，并且提供了丰 富的案例，是非常好的学习资源。

12、技术方案

13、项目管理与实施

B端产品的项目管理与实施工作
产品设计完成后，如何保证项目又快又好地交付?做好项目管理是 成功交付的必要条件。B端项目往往牵涉面广，经常出现跨端现象，面对这些复杂项目管理情况，该如何控制项目节奏，顺利推进执行?这需要项目负责人对项目管理体系有全面的了解，并掌握项目推进的要点和技巧。
需要说明的是，在很多创业公司，甚至是具备一定规模的公司和团 队中，并没有项目管理团队及专职的项目经理，需要由公司的产品负责 人来制订项目管理制度初稿，并负责项目管理。因此，产品经理有必要 全面理解并掌握项目管理工作的目标和内容。

为什么需要项目管理

当公司或团队规模较小时，工作随意而快捷:客户早上提了需求， 产品经理在黑板上写写画画，不必写正规的PRD，直接和研发人员沟通 就行;不必做回归测试，产品经理简单试试功能，晚上请研发工程师操 作，产品就能上线了;不需要运维部署，速度快，效率高。这种现象在 初创团队和创业公司中很常见，业务开展初期，问题多，想法多，市场 变化快，没有条条框框的约束，拼的就是速度!
随着公司规模变大，团队人数增多，作坊式工作方法不再适用:缺 少流程制度，会让多人协作变得混乱失控;没有统一优先级裁定，会让 跨部门项目引发争执;没有需求管理规范，会让业务部门抱怨产品研发部门配合不力，产品研发部门抱怨业务部门不靠谱，团队关系剑拔弩 张。这种情况下，如何才能保证产品研发团队高效运转?如何保证软件 产品能够按计划交付?如何让用户满意?要解决这些问题，就必须从作 坊式的生产模式转变为标准化、专业化的生产模式。
优秀的项目管理是互联网公司在复杂环境下保证软件开发按计划 推进、落地的关键，也是保障规模团队的产品研发效率和质量的核心要素。

互联网项目管理的工作重点
互联网公司的项目管理要确保公司产研项目高效开展、高质量交付，工作重点主要包括设计并优化项目管理制度和负责大中型项目的立 项实施。有些互联网公司会设项目管理办公室(PMO，Project Management Office)来负责这些工作，对于没有设置PMO的公司，就要 由产品负责人来扛起这些工作。
设计并优化项目管理制度
公司发展到一定规模后，就需要制订项目管理制度并严格执行。 PMO或产品负责人要结合公司的实际情况，设计符合公司诉求的项目管理制度，有两点需要注意:
· 这里是“公司发展到一定规模后”，而不是“产品研发团队发展到 一定规模后”，因为如果公司发展很快，即便产品研发团队规模很小 (采用了外包方式)，但是面临复杂的业务和爆发增长的需求时，依然 需要严格的项目管理制度来规范管理、控制风险。
· 项目管理的本质是不变的，方法和机制也与公司管理相类似， 但是需要专业的项目管理团队结合公司的业务特点和企业文化，对业界最佳实践做调整，制订符合公司特色的项目管理制度，这也是项目管理制度建设的难点和要点。有了合理的制度，再由专业人员进行项 目管理，这样才能让团队良性、高效运转，保障项目进展顺利。
例如，某公司C轮融资后业务发展非常快，但代码架构还处在A轮 融资时期的“一坨代码”“一套数据库”的阶段，各个团队负责的业务代码 彼此耦合，根本无法做到松耦合地独立开发、快速迭代。针对这种客观 情况，在制订项目管理制度时，可以考虑放宽敏捷开发的要求，而不是 强制执行两周一迭代的常规策略，甚至可以不要求采取敏捷开发方式。
再例如，针对需求采集和管理问题，公司一般会要求业务部门提交 需求时提供BRD(商业需求文档)，但在不同的公司中或不同阶段，是 否要强制业务部门提交BRD?这还需要综合评估公司的发展节奏、当前 的诉求以及管理层的意见，才能做出决策。
PMO或产品负责人要承担设计、修订项目管理制度的职责。合理 的规范制度应该既能约束产品研发团队的行为，也能保护产品研发团 队的权益。
此外，PMO或产品负责人要管理并维护项目管理软件，例如 JIRA、Teambition(图8-1)，以便产品研发团队能够通过软件来规范项 目管理过程，并获取足够的项目管理数据支撑。

负责大中型项目的立项实施
项目经理要保障大中型项目的成功落地，就必须理解业务，这样才 能在大中型项目管理中准确理解整体方案，以及各个团队负责的工作范 围。具体应该如何做?8.3节给出了建议。
同样地，如果没有项目经理，这项工作往往由产品经理来承担。

如何对B端产品做好项目管理与实施 工作
通过8.2节的介绍，我们对互联网的项目管理工作有了初步认识。 那么针对B端产品，如何做好项目管理以及项目实施工作呢?首先，我 们要了解B端产品项目管理面临的挑战。8.3.1 B端项目管理面临的挑战 B端项目管理经常面临如下两个挑战。
· 容易发生跨端(跨系统)现象:在团队规模小时，一个研发团队管理了所有的系统，或者所有的模块都在一个系统里，很少出现跨端现象。随着系统复杂度增加，子系统越来越多，分工越来越细，各个团 队负责各个业务线的不同系统。这种情况下，公司发起的跨端任务自然 会引起跨端现象;更常见的是，因为单个业务方的需求，导致多个业务系统都需要修改，产生跨端现象。跨端会带来各种困难，例如难以获得 其他团队的支持、难以取得整体的排期等。
· 项目周期长:当B端项目出现跨端现象，或者涉及流程改造等复 杂需求时，都会面临较长的项目周期。而项目周期拉长，就会导致存在 各种变数和不确定性，出现项目风险。
如何理解单个业务方需求而导致的多系统跨端协作问题呢?我们以 分销业务为例进行说明。假设分销业务想对某些客户购买的某类商品做 特殊包装处理。这是一个很明确的需求，会涉及如下几个系统的修改:
· 需要对这些客户进行标识，因此存储客户资料的客户主数据系 统需要增加一个标记字段。
· 分销运营管理后台要修改客户资料维护界面，支持字段的维护。
· 下单系统要识别标识的客户，在订单上打标记。
· 仓储系统要识别订单标记，对特殊商品走特殊处理流程(当 然，仓储系统也可以从“客户属性”字段识别特殊诉求，但是为了保证业 务的可扩展性，这里采用了通过订单来标识的方案。如果将来这些客户 又有一些订单需要按照特殊标准包装处理，则系统很容易实现支持。但 是大家也要意识到，为了这个潜在的“可扩展性”，有可能产生让订单系
统多做一次标识处理的“过度设计”)。 可见，针对这个特殊分拣需求，涉及客户主数据系统、分销运营管
理后台、订单中心、仓储系统、配送系统五个核心系统的修改。
如何协调并推动跨端协作
B端项目往往跨多条业务线、多个系统、多个研发团队，周期长、 复杂度高，而B端产品经理很多时候要直接承担项目管理工作。面对复 杂的B端项目，如何协调好各方、获得成功呢?
8.3.1节中已经介绍过，B端项目面临的第一个挑战是复杂的跨端问题，跨端项目从级别角度可以分为两类。
· 公司级跨端项目:这类跨端项目级别高，领导的重视程度高， 资源有保障，一般有独立或被隔离的资源支持，决策和推进会相对顺利 很多。
· 单方发起的非公司级的跨端项目:这类跨端项目一般由某个业 务线、业务团队发起，但是对其他团队有影响，或者需要其他团队配 合。这类项目的主要收益获得者一般是项目发起方，其他团队的收益不 大，因而推进难度很大。
作为产品经理，如何高效地推进非公司级别的跨端项目呢?可以从 如下方面进行尝试。
明确项目收益价值
任何项目都应该提前预估收益和投入产出比，从而判断是否有必要 推进项目。明确项目收益价值是对项目负责的做法，即便很多时候预估 的项目收益可能和实际偏差比较大，也是有必要的，因为:
· 项目收益作为一个目标，是引导项目组聚力前行的重要动力。
· 明确的项目收益预估是说服其他团队认可并配合项目的有力“武 器”。如果项目发起方都不知道项目收益和价值是什么，或者无法证明 项目收益和价值，必然无法说服其他合作团队。
· 明确的项目收益是决策层进行项目资源调拨时的重要参考依据。
因此，跨端项目推进的第一步就是明确项目收益价值。分析清楚收 益价值的前提是，对业务的诊断、分析尽可能全面客观，这样才能产生 有效的解决方案，并推算出预期的收益和价值。
找到KP并积极游说
多数互联网公司有一个特点:管理结构扁平，管理层级少，这样可 以提高沟通和决策的效率。很多时候，产品和项目不是自上而下发起 的，而是自下而上演进的[1]。这种文化特点让产品经理可以通过积极游 说的方式推动项目:很多时候产品经理需要像一名推销员那样，去各个 相关的团队“兜售”自己的方案和项目，可能基层团队之间一拍即合，合 作后产生“化学反应”，比先找领导沟通再传达还要快。
这种方式的关键是，产品经理要找到KP(Key Person，关键人 物)，并积极游说，获得支持。否则，可能苦口婆心沟通好久，以为获得了认可，取得了突破，结果对方来了一句:“我支持你，但我还得请示领导”，这就做无用功了。因此，不论是说服业务团队、产品团队还 是研发团队，都需要找到关键人物(决策人员)，针对正确的对象采 取“攻势”。
保持强的推动力与执行力
产品经理要负责推进整个项目，在面对困难和挫折时，要不气馁、 不放弃，像“小强”一般战斗力十足。所谓强推动力和执行力，其实就是 在合适的限度内，强力推动，保证执行效果。
例如，假设你需要对方反馈一个结论，但是对方总是不回复，可能是根本没有把这件事记在心上，也可能是对方故意拖延、不想配合，也 可能是真的忘记了。面对这种情况，你是闭月羞花般地每周催问一次， 还是穷追不舍地每天催问一次呢?如果你一周催一次，那么很可能永远 得不到反馈，因为对方会认为你自己都不重视;如果你每天催一次，虽然对方会很烦，但首先会把这件事印在脑海中，而且对承诺过的事情也不好推辞，最终“迫于压力”，给你想要的结论。
所以，通俗点儿说，强执行力和推动力就是指能够记着事儿，不忘事儿，上着发条追进度，盯过程，要结果。这样虽然可能会让某些伙伴有暂时的不舒服感，但只要是为了推动项目，为了要结果，为了有 价值，最终大家都会认可并赞扬这种积极的态度。
总之，跨端项目的执行和推进需要全力投入，既要有耐心，又要有 技巧。如果你有统筹管理跨端项目的机会，一定不要退缩，这是锻炼个 人综合能力的绝好机会。
8.3.3 如何把控项目进度 B端项目面临的第二个挑战是项目的周期长，复杂度高，变数大，
项目进度不好把控。如果做到以下几点，就能够较好地控制项目进度。
细化工作，明确交付
面对任何复杂的工作内容，我们首先需要理清脉络，制订计划，列 出行动的步骤，这样后期执行起来才能心中有数。同样，在项目管理 中，将工作细致拆解，并明确每一个细化事项的责任人、交付物、时间 点，保证对每一个细节的掌控，也就保证了对整个项目的掌控。在传统 项目管理中，细化工作有一个专业术语，叫工作分解结构(WBS， Work Breakdown Structure)，思路是一样的。
当然，细化工作有一个基本前提，即解决方案本身的设计是正确
的，如果大的设计方案有误，或解决问题的核心思路不对，做再细致的 工作拆解也是没有意义的。在思路正确的大前提下，细化工作就是自顶 向下的金字塔思维的实践，由粗到细，从全局到细节，拆解工作的同时 既能够产生更深入的思考，也能够随时审视整体方案。
在3.3节中，产品经理接受设计分销平台的任务后所列出的工作计 划甘特图，实际上就是在细化工作。
通过机制把控进度
制订了详细的工作计划，明确了责任人、交付物、时间点，一切安 排得井井有条，但这并不代表工作就能顺利开展，也不代表一切都会按 计划执行，因为在项目开展的过程中，肯定会出现各种问题和意外，例 如需求变更、方案调整、人员流失等。如果想及时发现并解决问题，就 需要设定一些项目机制，对项目进行监控和约束，确保项目有序推进。 以下是比较好的实践方案。· 开展定期会议(例会):定期将项目的各方参与人员聚在一 起，回顾上一次会议以来的进展、遇到的困难、下一次会议之前的计 划，这非常有必要。例会需要注意以下几点:
➢ 项目的各方核心参与人员必须准时出席会议，不能随意请假。
➢ 请参会各方在会议前整理好问题，这样讨论才会高效。
➢ 控制会议时间，不宜过长或过短。
➢ 例会一旦确定下来，就必须切实贯彻执行，不能三天打鱼两天 晒网。
➢ 例会不能太过僵化或形式主义，否则会让人厌烦，效果差。 ➢ 可以根据不同阶段的节奏对例会的周期做出调整，例如，项目
初期每周一次，项目中期两周一次，项目尾声每周两次。 · 开每日站会:站会是敏捷开发中经典的工作方式，对于软件研发项目，在团队内部开每日站会的确是非常有效的工作机制。
➢ 每日站会可以保证团队成员的到岗时间不会太离谱(站会的开 始时间不能太早，也不能太晚。对于国内大多数互联网公司的考勤要求 来说，十点半是比较合适的时间点)。
➢ 每日站会可以保证团队快速交流一下前一天遇到的问题和当天 要做的工作，快速识别问题，找出解决方案。
➢ 严格控制时间，不能太长，否则容易降低效率。
· 形成日报或周报:需要形成项目日报和周报，并发给项目的所 有相关人员。除了通报进度、进展情况，项目日报和周报还有一个重要 的作用，就是警示风险，让相关人员知晓，并推动责任人去解决问题。
编写内容清晰的项目日报或周报
前面提到的项目日报或周报是管理项目、通报进度的重要工具。一 份编写清晰、重点突出、简明扼要的项目日报或周报，能够让人产生深 刻印象，也能直接看出编写者的职业素养和专业性。
项目经理要利用项目日报或周报来争取关注度和资源，解决项目 中遇到的问题。项目日报或周报的编写务必严谨认真，下面以项目周报 为例来介绍编写思路和要点，项目日报与之类似。
· 本周进展:简明罗列本周的重要进展。
· 项目风险:一般会用红色加粗文字罗列遇到的项目风险和可能 的解决方案，可以@相关人员强调某些要求。对近期已经解除的风险， 可以保留描述，但用删除线划掉。
· 下周计划:简明罗列下周重点工作，以及每项工作的负责人和 要求完成时间。
· 整体进度:通过“甘特图”或其他形式说明整体项目计划和关键 里程碑，并标记目前项目完成度。
以上信息足够说明项目情况。以下是分销平台开发过程中的项目周 报案例，大家可以参考编写的思路及格式。
本周进展:
· 客户模块开发进度正常，已完成80%。
· 订单模块的开发完成50%，开发进度延期一周。
项目风险:
· (红色文字)订单模块没有按照计划完成开发自测，延期一 周，请@订单RD务必于下周一之前给出解决方案。
下周计划: · 客户模块完成开发自测，负责人XX，截止日期YY。 · 订单模块完成开发自测，负责人MM，截止日期NN。 整体进度:
· 整体项目进度70%，整体进度风险可控，以下是整体进度图(参 见图8-2)。

保持足够的责任心
图8-2 整体进度图
在把控项目进度时，团队的责任心，尤其是项目经理的责任心是 非常重要的影响因素。良好的项目管理制度可以在一定程度上保证项目可控，然而仅仅有制度约束还不够，因为制度只是提供了一种工具和方 法，如果团队成员没有足够的责任心，就无法将制度执行好、将工具利用好。例如，发出的周报可能无法清晰有效地呈现风险;即使呈现出风险，相关人员可能没有仔细阅读并识别问题;即使识别出了问题，可能没有人站出来追问并解决问题。
还要注意，项目的其他参与人员可能只负责把自己的工作做好，不会从整体上关心项目，这是可以理解的。如果项目经理的责任心不够强，那么当任何一个环节出问题时，就没有人能够从整体上解决问题、 推进项目，就会导致项目延期。所以项目经理的责任心是尤其重要的。 前面讲过，很多时候公司没有专门的项目经理，这时就需要产品经理负 起这份责任。
在我之前所在的公司中，有一个中型项目已经进行了一多半，其中有一位很重要的前端工程师是外包人员。本来进展还比较顺利，但是没 想到这位工程师和所在的外包公司产生了冲突，他因此萌生了离职的想 法，并且他只把这个想法告诉了项目组中和他关系较好的QA(测试人员)。
QA对这位前端工程师离职的事也没有太在意，只是和项目经理闲 聊时提了一下。如果项目经理觉得这是技术团队的事情，不用自己干 涉，那么此事的结果很可能就是外包工程师找好下家后直接离职，这必 然会对项目产生一定的影响(至少会导致延期半个月以上)。幸运的 是，这个项目的项目经理是一位非常负责、积极主动的女孩，她和大家 关系都非常好，经常找不同人聊天，沟通感情，看看有没有遇到困难。
项目经理得知这个信息后，马上给技术负责人、产品负责人反馈， 并且和技术负责人一起努力推动自己公司将外包的前端工程师直接招聘 过来。过程中虽然遇到一些阻力，但是项目经理真心诚意地帮助技术负 责人克服困难，最终成功解决问题，化解了项目风险，得到项目组所有 同学的敬佩和信任。
总之，在项目管理中，合理拆解并细化工作，制订良好的项目执行 机制，再加上足够的责任心，就可以对项目进度有较好的控制和掌握。

14、运营管理

B端产品的运营管理
B端产品上线后，需要开展运营推广工作，除了产品经理，运营推 广还会涉及产品运营人员和业务运营人员。而且，B端产品经理、产品 运营人员、业务运营人员三者的工作职责往往有很多交叉和重叠，这就 可能导致冲突，影响工作效率。产品经理需要深刻理解三者的工作目 标、工作方式，处理好协作关系，这样才能保证工作顺利开展。
本章将首先概述产品运营人员和业务运营人员要做的工作，然后重 点讲解B端产品经理应该如何与他们协作，如何解决可能面临的冲突， 共同推进B端产品的运营管理工作。
9.1 B端的产品运营岗 根据不同的产品类型，B端产品运营岗可以划分为以下几类:
· SaaS方向，该方向的运营岗位偏销售、BD职能，属于销售管理 和客户开发的范畴，不在我们的讨论范围内。
· 双边市场的供给端运营方向，例如商家运营、店铺运营，这种 运营岗位的工作内容和C端运营相似，我们不在此赘述。
· 针对内部业务系统的产品运营方向，本章讨论的B端产品运营主 要是针对这个方向的。
9.1.1 B端产品运营岗的工作内容 B端的产品运营岗位在行业内没有公认的定位或定义，但是既然是产品运营，肯定要围绕产品展开，而不是仅仅做纯粹的业务管理工作。
对于支持内部业务的B端产品运营岗，工作目标是通过挖掘B端产 品的能力(即对现有功能进行推广、协助完成产品的升级优化)，帮助 企业解决业务问题。其中，业务问题可能是营收增长问题，也可能是风 险控制问题。
B端产品运营岗位的工作内容主要包括产品功能推广培训、问题解 答处理、需求采集过滤、项目效果分析、业务诊断分析几个方面，我们 来分别介绍。
产品功能推广培训
B端产品的功能上线后，一方面要在线上进行推广宣传，例如消息 推送、公告通知等;另一方面，针对比较复杂的升级改造，还需要组织 业务团队进行现场培训。
产品经理也要对B端产品的推广负责，但很多时候产品经理需要运 营人员的协助和支持。比如，产品宣传时可以做一些吸引人的易拉宝， 摆在业务团队里进行曝光;也可以组织一些功能使用熟练度的考核比 赛，对于应用熟练的一线人员进行奖励。这些工作都需要由专门的产品 运营人员跟进。
问题解答处理
业务用户在使用系统的过程中，肯定会遇到各种各样的问题和困 惑，有时候是遇到了Bug，有时候是因为不理解规则，有时候是不知如 何操作，产品运营人员需要在线上对问题进行答疑处理，帮助用户解决 问题。
对于刚上线的系统或功能，产品经理可以组建试点用户群或热心用 户群，搜集问题并进行快速改善。但是，由于一线业务人员流动大、新 人多，因此业务人员在日常工作中仍会有各种各样的问题和困惑，这种 日常的针对业务全员的问题解答，必须由专门的产品运营团队负责，以
保证处理效率。产品运营人员首先要在第一时间解答问题，为业务用户 提供最快速有效的服务支持;另外，还需要经常归纳总结问题，把共性 问题提交给产品经理，以便进行系统优化，这样才能有效减少问题咨询 量。
比较高效的问题解答、处理机制应该是层层过滤的:一线业务人员 反馈问题后，首先由产品运营人员及时响应和跟进;如果发现是系统问 题，则提交给产品经理，请他再次核实;如果确认是系统Bug，则由产 品经理提交给研发人员。这样可以避免一线用户直接找研发人员，影响 研发工作。
需求采集过滤
产品运营人员和一线业务人员接触多，有更多的机会了解一线人员 的工作状况、感受，并收集一线业务人员的直接诉求。优秀的产品运营 人员能够识别并挖掘好需求(真正会产生影响的需求)，和产品经理一 起持续优化产品。反过来，产品经理收集需求的途径很多，其中很重要 的一个途径正是通过产品运营人员收集并提交需求。
项目效果分析
一般情况下，产品经理要对上线的功能进行持续的数据分析和观 察，这个工作也可以委托产品运营人员完成。有的时候，公司会直接安 排产品运营人员作为中立方，独立考核项目效果和收益，给出客观分 析。
业务诊断分析
高阶的产品运营人员还要和产品经理、业务团队一起诊断业务，分 析问题，提出解决方案，并推动解决方案落地执行。
综上可以看出，产品运营人员的工作范畴较为宽泛，而且B端产品 运营人员和产品经理需要相互配合，共同解决问题。

B端的业务运营岗
在B端产品工作中，业务运营部是B端产品经理打交道最多的业务 方。本节将详细讲解业务运营岗在企业中的管理模式和工作内容。9.2.1 B端业务运营岗的管理模式
介绍业务运营岗之前，首先要明确一下什么是业务部门。在一个典 型的、成熟的公司组织架构中，类似财务、法务、人力这些支持部门， 常常被归类为职能部门或中后台部门，主要目的是保证企业的行政运 转;而销售部、仓配部、采购部、客服部等部门，需要围绕核心业务开 展工作，直接承担企业经营的业务目标，被称为业务部门。
业务部门一般会分为两部分，一部分是执行具体工作的一线业务单 元，往往按地域划分;另一部分是业务体系内部支撑一线业务单元运作 的业务运营部，是整个业务线的管理中枢和支持中心。下面我们以M公 司为例来看看业务运营部在公司组织架构中的可能位置。
M公司的主要业务部门包括采购部、仓配业务部(简称仓配部)， 以及新成立的分销业务部。采购部和仓配部按照地域，各分为华东、华 北两个大区;分销业务部是新成立的部门，目前只在北京、上海开展业 务，因此下设北京、上海两家分公司。每个业务部门下都设了业务运营 部，要承担各自业务线的管理指挥和工作支持的职责，因此一般直接向 公司总部的业务负责人汇报。具体的组织架构图如图9-1所示。

假设M公司分销业务发展迅速，团队扩张快，部门建设健全，则公 司的组织架构图可能调整为图9-2所示的样子(除分销业务部之外的部 门未展开):在分销业务部下属的业务运营部下设培训考核、流程运 营、绩效管理等三级部门(分销业务部属于一级部门，其下属的业务运 营部属于二级部门);各家分公司(图中只展示了北京分公司)为了经 营管理方便，也下设自己的业务运营部，负责分公司相关的数据分析、 培训考核工作。

此时，分公司的业务运营部直接向分公司经理汇报，不再向分销业 务部下属的业务运营部汇报。有些情况下，分公司的业务运营部也可能 虚线汇报给公司总部，实线汇报给分公司经理[1]。例如，假设分销业务 的市场区域性差异极强，因此分公司业务运营部被赋予较高权限，可以 直接制订区域销售策略，一方面分公司业务运营部向分公司经理汇报， 协助执行分公司经理的经营策略;另一方面分公司业务运营部也要向总 公司业务运营部虚线汇报，承接总公司业务运营部的部分策略落地工 作。
需要注意的是，在互联网公司的业务管理中，任何管理架构都可能 多次调整，以便为业务提供更大的帮助和价值。

B端业务运营岗的工作内容 业务运营岗具体负责哪些工作?虽然不同业务部门(例如采购部、销售部、仓配部、客服部)的工作内容大不相同，但它们下属的业务运 营部的工作职能却有共通性，主要包括如下内容。
业务支持
在业务工作开展中，会有审批、核对、检验这类工作诉求，这些事 务性工作非常繁杂，是业务运营岗的重要工作内容。
例如，在M公司分销业务中，各分公司提交的客户资料需要由总公 司的业务运营部的专员进行核对审批;又如，某O2O分公司要开展一场 优惠券形式的市场活动，如果发券金额超过一定额度，就需要由总公司 的业务运营部审批;再例如，某公司销售部的一线人员想查询某客户的 敏感信息，需要向业务运营部提交申请，业务运营部同意后才会提供相 关数据。
流程管理
业务部门内部的流程机制、业务部门与其他部门之间的流程机制， 都需要不断地优化、调整，以适应最新的业务安排。业务运营部要负责 流程的设计、执行、监督、优化，保证分支机构管理的规范性和可控 性。
策略制订
业务部门有时需要制订策略，例如促销策略、定价策略、供应商返 点策略、仓储排班策略等，这些工作一般会交由其下属的业务运营部完 成。
绩效考核制度制订
一般情况下，一线业务的考核制度、KPI会采取自顶向下的设计思 路，由管理人员根据业务情况、业务规划，给出方向性的规定或调整思 路，由业务运营人员细化方案并进行预测，最终由业务负责人确认后实 施执行。例如，销售提成方案、采购人员绩效考核方案、仓配人员绩效
考核方案都会出自业务运营部。 培训考核
公司及业务部门的制度、政策、活动的宣贯传达，以及新人的培训 等工作，需要由专门的培训部负责。信息的传递是非常容易失真的，一 条简单的政策从公司总部层层传递到一线时，有可能已经被完全曲解。 因此，对于非常重要的政策、制度、活动，有必要对骨干成员，甚至业 务全员进行培训，并组织相关的考试来强化学习效果，这些工作都需要 由培训团队承接执行。
有些公司将培训部作为一级部门独立管理，有些则将培训部归于业 务部下属的二级部门，还有一些会将培训部归于业务运营部下属的三级 部门。
系统运营
业务部门还需要负责业务系统相关的新功能落地、推广，系统使用 的问题解答、问题收集、提出优化建议等工作。为此，业务部门常常会 设立自己的产品运营岗，也叫系统运营岗。
项目管理
对于业务部门发起的业务项目或产研项目，业务运营部可能会安排 专门的项目经理进行项目管理，推进项目落地。
例如，某在线教育公司的教研部(是业务部)发起了一个项目，研 发并上线一套新的小型课程体系。现在系统功能已经稳定，教研部下属 的业务运营部安排了专门的项目经理来负责协调教材编写、教材上线、 老师招募、老师培训考核、目标学员挑选、定向投放匹配等一系列工作 的安排和执行。
合规质检 违规、违法操作在任何团队都有可能发生。这些操作有可能是利益
的驱使造成的，也可能是工作偷懒或无意的失误。业务部门下属的业务 运营部常常会设置质检或品控团队，负责内部的监察和治理。销售人员 恶意挖客户、采购人员收回扣、客服人员话术不规范，这些都可能在管 辖范围之内。
除了业务部门内部的合规质检部门，公司一般还会设置集团层面的 风控、质检、安全部门，进行独立监察工作，这对企业的健康经营管理 至关重要。
数据分析
业务部门下属的业务运营部常常会安排专门的数据分析团队制作手 工报表，定时发送给相关的领导或业务群。之所以不直接制作线上报 表，是因为业务领导要看的指标往往是灵活多变的，需要根据领导的要 求制作实时数据报表。这种情况下，由专业的数据分析团队制作手工报 表可以随时响应，效率更高。此外，数据分析团队还会做一些专题性的 业务分析工作。

产品经理、产品运营人员、业务运营 人员如何高效协作
随着互联网公司业务模式越来越重，产品经理和产品运营人员、业 务运营人员的合作关系问题、权责分配问题越来越突出。如何体系化地 解决三者的合作问题，推进协同共赢?如何让产品经理专心聚焦于创新 和业务本身?
影响合作关系的因素很多，主要包括人际因素、产研文化、组织架 构。其中人际因素因人而异，产研文化取决于公司创始团队的背景，这 两者很难通过一些动作或方案来改善。此处，我们重点谈一下组织架构问题，这是解决合作关系问题最有效、可操作性最强的办法。同时，在 探讨组织架构的过程中，大家也可以更加深刻地理解三者之间配合问题 的成因和本质。
调整组织架构改善合作关系
组织架构决定了汇报关系，进而决定了绩效考核方式。汇报关系、 绩效考核方式会影响人做事的动机、行事的方式，以及个人和团队的利 益。通过调整组织架构，可以把一股力量拆成互斥的几股，也可以把几 股互相较劲的力量凝聚成一股。
合理的组织架构可以正向地引导组织和业务朝好的方向发展，不合 理的组织架构会造成各种问题。组织架构需要根据业务发展情况随时调 整变化，没有最好的组织架构，只有最适应当前阶段的组织架构。通过 调整组织架构，绑定利益共同体，可以解决很多业务管理问题。
产品经理、业务运营人员、产品运营人员相关的组织架构设计有多 种方案可选，各有优缺点，不同的方案适用于不同的公司文化和发展阶 段，我们依次介绍如下。
方案一
产品部和业务部平级，产品经理和产品运营人员统一归产品部管 理。其中，A业务部下属的业务运营部下面，还设置了系统运营部;产 品运营部向A业务线产品部直接汇报，见图9-3。这种管理架构是互联网 公司里比较常见的组织架构，产品经理和产品运营人员同属一个部门， 且产品运营人员汇报给对应业务线的产品负责人。

这种方案的优点如下:
· 能够统一调度研发资源，避免浪费:产品负责人对需求进行统 筹管理，综合评估需求的投入成本和预期收益，进行比较客观的可行性 分析，能够较好地保护并利用研发资源。因为和业务部没有隶属关系， 在处理一些问题时，可以对业务部形成一定的牵制，便于充分探讨，避 免研发资源的无谓浪费。
· 有利于从企业利益出发考虑问题:虽然业务线产品经理要为业 务服务，但因为产品部是独立团队，所以产品经理有权利和义务在某些 时刻跳出业务线，从客户利益或公司整体利益出发，对业务部说“不”， 必要时将问题升级到CEO级别去处理。
· 产品经理和产品运营人员相互补位:产品经理和产品运营人员 需要向同一个产品负责人汇报工作，比较容易将工作职责界定清楚，双 方可以较好地配合，形成协同效果，深入挖掘并发挥产品的价值。
这种方案的缺点如下:
· 距离业务有一定距离:由于业务线产品经理属于独立的产品 部，和相关的业务部难免有一定距离，业务线产品经理可能没有机会参 加业务部的核心决策会议、业务例会，也就无法在第一时间参与分析、获知关键决策。
· 容易与业务运营部下属的系统运营部产生冲突:如图9-3所示， 产品部下面设置了产品运营部，业务运营部下面设置了系统运营部。假 如有新功能上线，谁负责推广、培训、宣传、分析呢?再比如，产品经 理发现了业务流程的风险问题，提出了优化方案，业务运营人员是否同 意并安排并改进落实呢?
· 缺少决策人:假设业务运营人员(属于业务部)和产品经理、 产品运营人员(属于产品部)产生了冲突，如果业务部负责人和产品部 负责人无法对事情达成一致，就需要升级到CEO级别。但是很多问题纯 粹是业务线的内部问题，如果这类冲突都需要由CEO去处理，则效率太 低。
方案二
在方案二中，之前的产品运营部和系统运营部被合并为产品运营 部，统一归属到业务运营部下面，如图9-4所示。产品运营部的首要职 能是落地、推广产品以及答疑解惑，而这也是业务运营部支持业务团队 的核心工作之一，因此客观来讲，将产品运营部划归业务运营部，这样 的组织架构在业务模式较重的创业公司很常见。

这种方案的优点如下:
· 控制人力成本:在方案一中，在两个团队设置工作内容相似的 岗位，是对人力成本的浪费。通过将冗余的岗位合并，可以让工作更高 效，节约成本。
· 避免工作内容冲突:在两个团队设置工作内容相似的岗位，还 会导致在工作开展过程中产生冲突。解决办法有两个，一是合并团队， 二是更细致地界定工作边界，例如，业务部的系统运营人员只负责问题 解答，产品部的产品运营人员只负责工作推广……然而，这么细致的划 分实在没有必要。
这种方案的缺点如下:
· 产品部的权利被弱化:产品运营人员不再归属产品部，那么推 广产品、收集需求、反馈常见问题和一线声音等工作，就不再是产品负 责人能够直接安排的了，并且产品经理也无法得到最及时高效的信息反 馈了。
方案三
在方案三中，业务线产品部被划归到相应业务部下面，业务线产品 经理直接向业务部的负责人汇报。这种组织架构在成熟的纯互联网公司 中比较少见，但是在业务模式较重的创业公司或独角兽公司中正在被尝 试。
产品经理向业务部的负责人汇报，估计多数产品经理都会对此感到 诧异，然而这却是一种缓解产研和业务矛盾、发挥产品能力的可能方 案。

这种方案的优点如下:
· 更加贴近业务:作为业务部的一员，并且是核心成员之一，不 论是业务例会，还是重点问题诊断分析，产品经理都会直接参与其中， 与各个相关方共同讨论决策。而且同为业务部成员，产品经理和业务负 责人之间的距离也会更近，信任感更强。
· 更容易推动方案落地:将业务线产品经理划归业务部后，从业 务问题提出、诊断到方案设计再到解决方案落地，从职能架构上来讲， 都是在业务部内部发生的，因而更容易推动落地。
这种方案的缺点如下:
· 判断和决策带有倾向性:产品经理隶属业务部，由于汇报关系 改变，很多情况下，产品经理做判断时会向业务线倾斜，客观的、批判 性的思考相对减少。
· 缺少全局观:产品经理隶属业务部，这还容易导致某业务线的 产品经理只着眼于业务线本身，不关注企业级的全局架构，容易导致整 体架构中存在短视的设计，以后再纠正代价巨大。· 不能最大限度地发挥产品经理的价值:在该架构中，产品运营 人员直接向业务运营部的负责人汇报，这导致产品经理的价值无法最大 限度地发挥出来，因为产品经理对系统的控制权和运营权依然是割裂 的，无法形成合力来挖掘价值。
· 部分产品人无法接受向业务部汇报工作这样的安排:因为很多 产品经理认为产品岗位应该具有非常高的权限和级别，能直接影响、改 变业务部的工作，而不应该“受制于”业务部。但是市场环境在发生变 化，对于企业来讲，减少内耗、促进发展才是重点，产品经理也要适应 变化，及时调整。
方案四
方案四对方案三略微调整，产品运营部被划为A业务线产品部下面 的三级部门，产品运营人员从业务运营部抽出，直接向产品经理汇报。 这种安排相当于业务线进一步给产品经理授权，将系统相关的工作全部 交给产品经理来管理，如图9-6所示。

这种方案的优点如下: · 充分授权发挥产品经理的价值:产品运营人员直接向产品经理
汇报，不仅是岗位管理关系的调整，也代表着将产品相关的工作全盘授 权给产品经理来管理、安排、控制。从功能方案的设计、实施，到意见 反馈、效果分析、持续优化，一套完整的产品方案都由产品经理操盘管 理，让一名优秀的产品经理能够尽情发挥才能。
这种方案的缺点如下:
· 缺少牵制力:这种架构下，产品运营人员不能代表业务运营部 发声，对产品经理的牵制也会减弱。这一方面能让产品经理更好地发挥 才能，另一方面也可能导致“一言堂”。很多时候，一些牵制力和干扰力 可以帮助产品经理思辨，并做出更深刻的思考和判断。
方案五
和方案四相比，方案五中的A业务线产品部需要做双线汇报，实线 汇报给相应业务部，虚线汇报给产品部，如图9-7所示。方案五还有一 种变体，即A业务线产品部实线汇报给产品部，虚线汇报给相应业务 部。但这种情况下，业务线的产品运营人员就不可能向产品经理汇报 了，这就又和方案二相差无几，因此不对其做赘述。

这种方案的优点如下:
· 企业架构设计得到一定保证:双线汇报关系促使产品经理在设 计方案时遵循产品部的整体架构规划设计，避免只关注局部而无视全局 的问题。
这种方案的缺点如下:
· 效率可能略有损失:因为受到产品部的全局架构的约束，在处 理一些局部问题时可能羁绊较多，无法采取只对业务线有利的快速方 案，损失一些时效性。
以上列举了产品经理和业务运营人员、产品运营人员合作的几种可 能的组织架构，不同的组织架构对产品经理、产品运营人员、业务运营 人员三者的合作关系会产生直接影响。调整组织架构和管理关系是解决 协作问题的一个非常有效的手段，很多时候，面临团队的低效、猜疑、 冲突，可能略微调一下组织结构就解决问题了。互联网公司取得成功的 诀窍之一就是，频繁地调整组织结构，尝试各种安排，在各种调整中 很可能实现破局，或者产生“鲶鱼效应”。
不同的管理架构适用于不同的企业文化、业务阶段。互联网人要接 受变化，不拘泥于形式，勇于突破自我进行各种大胆尝试，要知道，业 务发展才是硬道理。

15、迭代管理

B端产品的迭代优化
产品上线并进行了全面推广，对业务产生了明显帮助，产品经理会 感到满满的成就感。但是产品经理的工作还没有结束，还需要不断挖掘 新需求，并对产品进行持续的迭代升级，让产品变得更加成熟、强大。 如何识别、挖掘好需求?如何管理这些需求并安排迭代计划?这里面有 很多技巧和最佳实践值得我们学习参考。
本章就来介绍产品需求管理和迭代管理的方法和技巧。
10.1 B端产品的需求管理
产品投产后，还需要不断收集、挖掘新的需求，进行持续的升级迭 代，以完善系统功能或优化业务流程。如何持续获取有价值的需求?如 何对需求排优先级并实现之?此时，需求的收集和管理工作就显得非常 重要。
需求的收集和管理是产品经理的一项基本工作内容。不要轻视看似 烦琐的需求管理工作，对业务和产品的理解正是在这些工作中逐渐形成 的;而确认需求的优先级、确认迭代工作的计划安排，更能培养对业务 的准确判断力。
10.1.1 需求的收集
B端产品的需求来源十分广泛，包括一线用户、产品运营人员、业 务运营人员、业务领导等的反馈，需求内容也非常丰富，包括交互体验优化、业务调整要求、业务管理要求等，而能采集需求的手段也丰富多 样，包括一对一面谈、问卷调研、轮岗实习，等等。
需求收集的要点之一是，通过各种渠道全面、迅速地收集建议，而 且，无论是否采纳，都要给出反馈，例如意见是否采纳、预期的解决时 间等，这样才能形成持续的良性互动。
收集到需求后，产品经理不应该简单被动地接受、执行，而要识别 需求背后的真实问题、判断需求的价值，这很考验产品经理的判断能 力。在日常工作中，产品经理要勤于思考，尽可能地理解业务，以提升 自己的判断能力。面对需求时，产品经理可以思考以下问题，帮助自己 准确、迅速地判断需求的价值:
· 这个需求背后的真正问题是什么?
· 这个问题是否有简单快速的解法?
· 这个问题的影响面有多大?如果只是个案，是否值得投入精力 去研究解决?
· 如果是共性问题，优先级和紧急程度如何?
对于从C端产品转行的同学，这里提醒一点，C端的产品需求来自 个体用户，而B的端产品需求来自组织和机构。C端和B端的需求的产 生背景和动机完全不同，前者是为了解决用户痛点，而后者是为了解 决业务问题。因此，C端产品的需求分析方法论(例如广泛采用的 KANO模型)并不适用于B端产品。
10.1.2 需求池管理
对于收集到的需求，经过初步判断、过滤后，要放入需求池进行管 理跟进。
从记录在案开始，到实施上线，需求要经历完整的研发管理周期。 可以通过一套项目管理软件(例如JIRA、Teambition)对需求进行管 理，按照公司统一的项目管理规范来实现。如果公司对项目管理的过程 没有明确的规范，或者缺少工具支撑，也可以通过Excel文件来进行需 求管理。
对于需求池和迭代计划，可以对它们分开管理维护，也可以合并在 一起管理维护，需要根据公司的现状和要求灵活处理。不论是合并管理 还是分开管理，主要目的都是实现清晰准确的需求管理、迭代计划管 理，并做到项目进度透明。
通过一套设计合理的Excel模板，完全可以把需求和迭代工作管理 得井井有条。我在工作中整理了一套比较全面的需求、迭代管理模板， 在这里分享给大家，大家可以直接使用，也可以借鉴其中的一些思路， 融入自己所在团队的工作中。
需求池管理的模板
为了准确地管理需求内容、跟进执行情况、进行全面的项目管理分 析(例如分析研发的工作量、研发效率、业务需求的满足效率等)，一 套完整的需求池管理模板应该具备很多字段。下面分享我整理的一个比 较完整的需求池管理模板，并对每个字段进行具体说明。
· 业务线 描述需求所在业务线(或对应的系统)，例如CRM系统或客服系
统等。 · 需求类型
需求类型包括以下可选项:
产品需求、产品需求(插入)、技术需求、技术需求(插入)、线 上Bug
以上五个选项可以较好地区分业务需求、技术需求、线上Bug。因 为项目管理比较在意是否在计划外插入临时需求，所以我们对插入的需 求(不论是技术需求还是业务需求)要做一下标记，标记的方法既可以 是单独加一个字段，例如“是否是插入的需求”;也可以通过为“需求类 型”增加“产品需求(插入)”“技术需求(插入)”两个选项来标记。
· 主题
需求的一句话概述。
· 内容
需求的具体描述。
· 来源
需求的提出者，比如来自一线的某员工，或业务运营部某同事。
· 需求提出日期
收到需求的日期。有些公司会要求产研团队提高需求响应速度，可 能会通过上线日期和需求提出日期的时间差来进行考核评估。
· 优先级
优先级是管理需求迭代计划的重要判断依据。优先级应该是一个客 观的评估，可以和业务人员一起商定一个都认同的标准，作为优先级的 判断依据。
例如，给销售人员使用的OCRM系统的目标整体上可以归为三方 面，即提升业绩、规避风险、提高效率。可以将OCRM系统的需求池优 先级定义为五档，举例来说，能够帮助全员提升业绩或规避业务风险的 需求，我们认为是重要并且紧急的，将优先级定义为Highest;针对个别 人员提高效率的需求(例如优化某管理员的某个低频操作)，我们认为 是不重要且不紧急的，将优先级定义为Lowest，中间还可以分出High、 Median和Low三级，含义见表10-1。

以上是定义优先级的一种可能方案，针对不同的业务特点、不同的 发展阶段，优先级定义的原则是不尽相同的。作为B端产品经理，一定 要和业务方在原则上达成一致，客观地定义优先级并作为排期依据，否 则非常容易起摩擦。
· 迭代版本 如果采用了敏捷开发模式，就需要标记需求排期开发时的迭代版
本。
· 业务负责人
涉及业务规则调整、流程变更及核心功能变化的B端产品，需要有 业务部门相关负责人确认并一同推进。因此针对每个需求或项目，必须 指定一名业务负责人，作为业务代表一起参与。
· 产品经理 负责跟进并管理需求。 · 研发负责人
研发负责人一定是研发的整体负责人，而不应该分成后端负责人、 前端负责人，因为那样很可能导致两者各自负责自己的工作，但是对于 技术实现的整体方案和进度没有把控，相当于没有技术负责人。
· 测试负责人如果研发负责人全权管理研发、测试工作，则不需要单独指定测试 负责人。否则，要明确安排测试负责人，对质量结果和进度负责。
· 状态
状态用来描述需求的生命周期，状态值可以包括如下选项:
待跟进、需求调研、PRD编写、待PRD评审、待技术评审、待排 期、待开发、开发编码、待测试、测试验证、待验收、待上线、已上 线、挂起、拒绝。
这些状态值较好地覆盖了从需求采集到上线的完整生命周期，仔细 观察后可以发现，这些状态的设计符合我们在6.8.3节介绍状态机图时提 出的建议，即状态应该是能持续足够时长的，不应该是很快就结束的 (所以我们没有定义“需求评审中”这种状态，因为需求评审只需要开几 个小时的会议就可以完成，没有必要在开会前改一下需求状态，开会后 再次修改)。
· 计划上线日期 计划上线日期是在技术评审结束后，研发负责人确定工时和资源投
入后给出的目标上线日期。 · 实际上线日期
实际上线日期是系统的真正上线时间。通过对比实际上线日期和计 划上线日期，可以统计项目的延期情况，并进一步分析延期原因。
· 前端开始日期/前端结束日期
前端开发工作的开始日期和结束日期。
注意，工期和工时是两个完全不同的概念，工期是指开发时长，工 时是指工作量。例如，为了开发某功能，安排了2名研发人员，从9月1 日开始开发，到9月5日提测，则工期是5天，工时是10人日。如果这两 名研发人员并不是同时介入的，其中一名研发人员是9月1日介入的，另
一名在9月3日才介入，到9月7日提测，则整体工期是7天，但工时依然 是10人日。
· 前端研发工作量(人日) 即前端开发工作预计投入的总工时。在敏捷开发中，可能通过基于
经验的“点数[1]”来评估工时。 此外，后端开发及测试的开始时间、结束时间、工作量，这些字段
的含义与前面所讲的类似，不再赘述。 · 发版计划
在移动端产品中，需求上线可能涉及发版，即需要发布新的客户 端，因此要在表格中记录发版的版本号。
通过需求池统一评判需求优先级，管理并安排迭代计划，是产品经 理最重要的日常工作之一。合理运用上述模板，可以帮助产品经理将需 求和项目管理得井井有条。认真填写模板中的各项内容，可以帮自己较 好地分析需求跟进情况、研发效率、工作量投入等。
如果某个需求涉及跨端或跨团队开发，则需要按照子项目将模板进 一步细化，例如每个子项目要安排各自的研发负责人、产品负责人，有 各自的工时、工期等，然后再填写具体字段。
10.2 B端产品的迭代管理
收集需求后，产品经理要根据优先级进行需求跟进和方案设计;方 案设计完成后，便进入开发、迭代环节。广义上的迭代管理是指软件的 持续优化、升级计划;狭义的迭代管理是敏捷开发中的一种模式。本章 所讲的迭代管理是指前者。在进行迭代管理时，要充分利用研发资源， 要正确认识技术优化所需的资源，另外，采用合适的迭代模式对软件的
升级研发效率至关重要。
10.2.1 迭代中的研发资源管理
在迭代优化过程中，产品经理要充分调动并利用研发资源，通过对 人员的合理调配，保障不同项目之间无缝衔接，避免因为时间窗口不匹 配导致研发资源闲置。
如何准确管理研发人力呢?有一种很简单实用的办法，也是传统项 目管理中常用的办法，即制作一张研发人力资源安排图(如图10-1所 示)，通过这张图可以清晰地看出每个研发人员在不同需求、项目上的 时间投入规划，并据此安排后续的工作。
在工作中，研发人员、产品经理、业务人员之间总会有这样的争 执:为什么没有排期?你们在做什么?人力都铺在哪儿了?如果有这样 一张图来清楚地呈现研发人员的工作安排，就可以避免这些争执。因 此，维护好这张研发人力资源安排图，也是对研发人员的一种保护， 避免他们“蒙受”工作不饱和的怀疑和指责。

迭代中的技术优化资源分配
软件的代码需要不断地优化。如果软件升级迭代过程中只做产品功 能需求，而不做技术优化，随着功能的积累，软件系统会变得越来越脆 弱，运行速度会越来越慢，甚至频繁宕机。因此，在日常的迭代升级 中，必须给技术优化预留足够的资源。
应该投入多少资源做技术优化?这个问题在产品经理和研发负责人 之间似乎很难达成一致。研发负责人想多投入一些资源优化系统，而产 品经理则认为应该首先解决业务需求。如何平衡业务需求和技术优化之 间的资源分配问题呢?
从大的方面来说，这和系统所处的阶段有很大关系，不同阶段资源 分配的思路完全不同。结合业务发展周期，我们将系统建设归纳为四个 阶段，分别是初创阶段、瓶颈阶段、重构阶段、稳定阶段。
初创阶段
在初创阶段，业务还处于探索试错期，业务本身不一定能成功。在 这个阶段，系统从无到有地构建起来，研发团队要开足马力支持业务， 本阶段的重点在于“活下去”。构建的系统是一套全新的干净系统，没有 任何历史包袱，因此，可以铆足劲儿开发业务功能，而不用太在意代 码、架构的合理性，此时可以只预留10%的资源做技术优化，甚至不做 技术优化。只要研发团队的水平靠得住，一套全新的系统在全力运转的 状态下对业务支持一年的时间，应该是绰绰有余的，而一年正好是验证 业务是否能够存活下去的关键时间点。
瓶颈阶段
经过一年的探索，证明了方向是正确的，业务取得了初步成果，并 继续保持高速发展。业务对新功能的渴望持续且强劲，产品研发团队依 然开足马力，但此时系统已经显现出疲态，“技术债”问题出现:曾经的 设计缺陷、硬编码、架构不合理等问题逐渐凸显出来，系统三天两头出 问题，Bug繁出，稳定性差，与此同时，业务需求继续井喷!
对于产品研发来说，一半的资源被修复Bug和迫在眉睫的技术优化 占用，另一半资源被难以维护的老代码拖住。产品研发团队既不能痛快 地满足业务需求，也不能爽快地一次性解决系统结构问题。此阶段可能 会持续1年到1.5年的时间，可谓整个产品研发团队的“噩梦时期”。
重构阶段
业务继续发展且相对稳定，业务需求依然络绎不绝，但系统已濒临 崩溃的边缘。所有人都明白，偿还技术债的终极时刻来临了:公司层面 决定，业务需求给技术重构让路，留给研发团队充足的时间重构系统， 一次性解决历史问题。此阶段可能会安排80%的资源做技术优化重构工 作，包括代码解耦、拆库拆表、中间件升级、接口化、服务化等。
对于瓶颈阶段和重构阶段分别持续多久、在什么时候发生，这个问 题很难准确回答，取决于业务情况、系统状况、技术团队的话语权等因 素。
此外，也有“边开飞机边换引擎”的成功案例，即在不影响业务的情 况下，持续升级系统，开发新功能的同时完成系统重构，但难度相对较 大。需要结合具体的系统架构和实际情况来判断采取什么方案。
稳定阶段
该阶段业务发展稳定，系统运行平稳，Bug少，不宕机。业务需求 依然不停地提出，但此时研发工作显得井井有条。即便如此，依然需要 预留10%到20%的研发资源持续做技术优化，这是保证系统持续稳定的 秘诀。
综上所述，业务需求和技术优化的研发资源分配，要根据业务发展 和系统建设的阶段来合理安排。不同阶段对两者投入的资源比例可参考 表10-2。

典型的双周迭代模式
软件工程是一件计划性极强的工作，不随意改变需求和计划，是确 保功能高质量按期交付的前提。瀑布模式在传统的软件开发中被广泛采 用，该模式对需求变更有很严格的管理，开发周期往往也很长。然而在 互联网环境下，市场环境瞬息万变，软件的开发模式既要能够快速响应 市场并上线试错，又能保障开发节奏和交付质量。
敏捷开发的理念和方法论在一定程度上满足了以上诉求。在实践 中，多数公司和团队都会结合瀑布模式对敏捷模式做一些调整，来进 行研发管理，而不是严格按照敏捷方法论管理项目。其中使用最广泛的 模式就是双周迭代模式。
所谓双周迭代，即两周完成一个迭代周期，其中，一个迭代周期是 指从软件开发到上线的时间。图10-2通过甘特图的形式描述了包括两轮 迭代(迭代1和迭代2)的双周迭代运作过程，其中W代表周，W1代表 第1周;D代表天，D1代表第1天，以此类推。浅灰色背景是迭代1的准 备阶段及执行过程，深灰色背景是迭代2的准备阶段及执行过程。

接下来，我们详细讲解双周迭代的过程，因为它是著名的敏捷迭代 模式Scrum模式的变体，所以在讲述过程中，我们会对比介绍Scrum模 式(图10-3)中的对应概念，以便读者体会二者的异同。

一个典型的双周迭代过程如下。
1.挑选需求并编写PRD(W1D1~W2D4)
在迭代1的开发工作启动之前，产品经理(在Scrum中叫PO， Product Owner)首先要从需求池(需求池在Scrum中叫Product Backlog，具体的需求项叫PBI，Product Backlog Item)中挑选需求，这
需要产品经理和研发负责人一起沟通，根据需求复杂度和研发产能来挑 选最需要满足的需求。然后，针对所选需求设计方案并编写PRD。
2.评审(W2D5)
PRD编写完成后，进入迭代1启动前的评审环节，评审环节要和需 求方再次确认设计方案，并且给研发人员讲解产品设计方案，评审时， 可以对需求范围再次进行讨论和调整。在Scrum中，评审工作叫Sprint Planning，进入迭代计划的需求清单叫Sprint Backlog。
3.技术方案设计(W2D5~W3D1)
评审结束后，研发人员要根据PRD进行技术方案设计，有的技术方 案可能需要讨论几天才能确定下来。同时，产品经理开始做迭代2的准 备工作。
4.开发实施与测试(W3D2~W4D4)
技术方案确定后，正式进入迭代1的开发和测试环节，对于研发人 员来说，这是最紧张的阶段，这一阶段在Scrum中叫Sprint(冲刺)。在 这个阶段，产品经理和研发团队每天都要召开简短的站会(Scrum中的 Daily Scrum)，以同步信息，并快速澄清疑问、进行决策。
5.上线(W4D5)
集中上线是一种提升研发效率和运维效率的好方法。所谓集中上 线，是指将一系列功能点打包并一次性上线，而不是每做完一个功能点 就进行一次上线。迭代1的功能上线的这天，正好是迭代2的评审日，研 发人员可能白天要进行迭代2的评审工作，晚上要配合运维人员上线迭 代1的功能。同时产品经理最好和QA一起做线上功能验收，集中打包上 线的交付物(在Scrum中叫Potentially Releasable Increment，即在一个 Sprint中完成的产品增量)。
在上线之前，Scrum中还会有Sprint Review Meeting，产品经理和研
发人员一起再次核对功能开发情况。一个迭代结束后，Scrum流程中还 有Sprint Retrospective，对迭代进行总结。
以上是常见的双周迭代的产品开发流程，在研发人员开发一个迭代 的功能时，产品经理开始下一个迭代的功能设计，工作交替进行，这样 能保证设计工作和开发工作无缝衔接，在一个合理的时间周期内快速实 现软件产品的升级迭代。
10.2.4 双周迭代模式的局限性 双周迭代模式可以较好地控制产品研发节奏，被广泛采用，但是，
双周迭代模式也有局限性，具体表现在如下几点。
无法保证最小功能集合可以在一个迭代周期内实现
如果需求很复杂，产品功能被分成几期来做，其中某一期的最小功 能集合依然比较复杂，则可能无法在一个迭代内完成它。例如，涉及流 程调整的需求，需要一次性实现完整功能集合，才能保证业务正常运 作，而这个最小功能集合很可能无法在一个迭代周期内完成。而且，软 件工程和流水线作业不同，无法简单地通过加人数的方式来缩短工期。
跨端项目协同非常复杂，研发节奏互相依赖
B端项目经常发生跨端现象，因此开发排期要进行多个团队的整体 统筹协调，这就很难保证按照某一方的迭代节奏来安排。
关于多个团队之间的大范围项目协作，尽管有一些规模化敏捷的方 法论被提出，但是可操作性普遍不强，因而实际工作中，大家一般还是 采用比较传统的方式:把一堆人拉到一起，共同商议方案，再各自回去 排期，然后统一定一个大联调时间和最终上线时间。
很难准确预估工作量投入
在B端产品开发中，如果是一些简单的小需求，研发人员可能会直 接给出工时预估。但是对于B端的复杂系统，如果想让研发人员看过产 品方案后就快速准确地预估工作量，从而决定一个迭代周期内的工作内 容，这基本不太现实。必须先研究代码结构，做完技术方案设计，才能 给出准确的工时和排期。
针对双周迭代的局限性，在B端产品的迭代中要结合实际情况，对 迭代流程做灵活变通。例如，针对复杂跨端项目，可以按照项目机制来 推进，而非迭代机制;又如，针对部分需求，上线时间可以灵活调整， 而不用等待统一发布;再如，可以不采用双周迭代模式，只保证每周固 定时间评审需求，需求之间的开发、上线节奏互不相关。
10.2.5 选择合适的迭代模式
双周迭代模式被很多公司采用，不过我们也看到它有一些局限性。 因此在必要时，还需要团队通过摸索和磨合，找到瀑布模式和敏捷模式 的恰当结合点，设计适合自己的模式、流程，从而提高效率。
产品经理要理解瀑布模式和敏捷模式的背景和特点，要辩证地看待 它们，这样才能找到两者结合的最佳方案。我们先来了解这两种模式。
瀑布模式的历史背景
瀑布模式将软件生命周期划分为几个基本活动，并且规定只能按照 自上而下的固定次序逐步执行完成。这一模式有它产生和存在的背景。
· 传统软件产品非常复杂:在传统软件公司，研发的都是大型商 业软件，或给客户定制的中小型系统。这些软件产品功能非常复杂，开 发过程需要被规范地管理。稳定、成熟的IT管理体系(如ITIL体系)能 够在很大程度上保证企业软件体系的架构合理性、系统稳定性，保证IT 资源被充分利用。而这些成熟的IT管理体系一般都是遵循瀑布模式的。
· 传统企业没有快速迭代的诉求:传统企业的业务模式稳定，很 少发生变革。而且对于企业来说，通过信息化对业务流程重构是大事 件，对于软件的使用或更新都要经过充分探讨和慎重决策，决定后就一 步步执行下去，尽量不要反复，对于需求变更、方案变更更会严格控 制。
由此可见，传统的瀑布模式是适应曾经的市场环境和市场需求的， 也是适应传统企业和传统软件公司的诉求的。并不是瀑布模式导致传 统企业的软件开发节奏变慢，而是曾经的业务客观环境不需要软件开 发节奏变快。不可否认的是，瀑布模式会导致IT组织机能僵化，信息技 术能力无法被充分释放，对市场环境响应太慢，这在互联网时代下是无 法跟上市场节奏的。
但是我们也不能完全摒弃瀑布模式，瀑布模式的核心环节是“需求 分析”“方案设计”“开发编码”“验收上线”，这几个环节是软件工程的必 经环节，任何模式都难以绕过。
敏捷开发是一种理念
互联网公司的重要特点之一就是，速度快:
· 决策快——很可能经过半个月的分析评估就决定尝试开辟一条 新业务线。
· 执行快——产生一个决策后，整个团队和组织都会集中资源高 效执行落地，不论是业务团队的开疆拓土，还是产研团队的系统研发， 都会迅速展开。
· 变化快——可能尝试了半年的新业务说停就停了，之前的资源 投入全部成为沉没成本。
互联网公司这种“快”文化，深深根植于互联网人的思维模式中。互 联网人敢于试错，不会因为成本风险而限制各种尝试和探索;同时也讲 究技巧方法，将试错成本降到最低。在快速开展业务的过程中，抓住稍
纵即逝的市场机会才是头等要事，在瞬息万变、竞争严峻的市场环境中 生存下来才是重中之重。
而敏捷开发的核心思路是将复杂需求分解成小块需求，采用较短的 开发周期，按节奏开发，按需发布，逐步迭代实现，因而非常适合在互 联网公司推广。本质上讲，敏捷模式是容纳并拥抱新时期快速变化的 市场环境和商业特征的一种理念。只有认可敏捷模式的理念，才能很 好地实践它。
作为产品经理，你需要思考如下问题:
· 你是否有随时接受需求变更的勇气和心态?面对各种扑面而来 的变更，你是否能够心平气和地分析问题和方案，而不是气愤地一口回 绝已经让研发团队白忙活一个月的需求方?
· 你是否允许存在瑕疵但可以快速支持业务的产品方案去抢占市 场，而不会因为自己的“洁癖”及偏执导致业务错失良机?
· 你是否会说服研发人员为了快速上线而暂时采用并不合理的设 计方案，并在合适的时间窗口帮助研发团队顶住业务压力，给研发团队 争取足够的时间来重构系统?
如果产品经理和研发团队对上述问题的回答都是肯定的，那么这个 团队就具备了践行敏捷文化的前提。
图10-4是一张流传广泛的关于瀑布模式和敏捷模式的卡通图，来自 《硝烟中的Scrum和XP》一书。作者Henrik Kniberg是一位敏捷模式的实 践者。这张图形象生动地描述了瀑布模式和敏捷模式在理念与实践上的 区别。

客户需要代步工具，在瀑布模式中，小汽车被一步一步造出来，工 期长，交付物复杂，用较长的时间一次性给出了较好的解决方案，中间 的所有交付物，比如轮子和车身，都是最终成品的一部分，但是中间的 交付物并不能满足客户的出行需求。
在敏捷模式中，实现思路完全不同。为了解决客户的交通工具问 题，先提供了滑板，然后依次提供了滑板车、自行车、摩托车，最后才 提供小汽车。一开始就满足了客户的出行需求，虽然不是理想方案，但 却可以使用，然后逐步优化，最终也造出了小汽车。
敏捷模式试错速度快，试错成本低，在步骤1和步骤2就已经可以判 断方案是否有效。而在瀑布模式中，直到步骤5才能判断方案是否有 效。但是敏捷模式的迭代成本高，每一次迭代都会将之前的工作废弃， 例如改用了自行车，滑板车就白做了;改用了摩托车，自行车就白做 了。因此迭代过程中需要不停地重构老系统。
合适的才是最好的
无论是敏捷开发，还是瀑布开发，都有自身的优点和缺点。找到这 两种模式的恰当结合点，设计适合自己团队的模式、流程，帮助产品研 发团队提升效率、支持业务是关键。

16、数据分析

B端产品的数据分析

通过数据支持决策，是互联网企业在激烈的市场竞争中快速试错、 纠正方向、取得成功的不二法门，互联网人必须具备以数据驱动业务决 策的意识和习惯。对于产品经理来说，无论是业务问题诊断，还是项目 效果分析，都需要通过数据分析来进行论证和判断，因而数据分析能力 是产品经理的必备技能之一。
本章将介绍数据分析的思维框架，以及进行数据分析工作需要具备 的知识结构。首先通过实际案例带大家感受数据分析的过程;然后介绍 数据分析的要点，包括需要掌握的知识体系;最后结合案例介绍数据分 析报告的撰写要点，这是数据分析结果外化的重要工作。

数据分析的流程

B端产品从决策、设计到落地、运营，整个流程都需要全面的数据 支持和数据驱动。各个环节要分析的数据不同，得到的结论也不同，但 是数据分析的思路和本质是相同的，B端产品经理要理解并掌握数据分 析工作的特点和要点。
数据分析的方法论很多，从本质上讲，可以将数据分析的过程抽象 为四个步骤(如图11-1所示)，分别是明确主题、提出假设、验证假设、产生结论，其中提出假设、验证假设是数据分析工作中最复杂的部 分，需要反复进行，才能得到正确的结论。

明确主题

图11-1 数据分析的四个步骤
任何数据分析工作都需要有一个明确的主题，即数据分析工作的目 的或目标。如果没有明确的主题，数据分析工作就会随意发散，无法聚 焦。主题可以是封闭的，例如“XXX项目的YYY指标能否符合预期”， 也可以是发散的，例如“目前公司供需匹配的矛盾和问题是什么”。
明确的主题是整个数据分析过程的焦点。数据分析过程本身就是 一次脑洞大开的探索，很有可能在分析过程中发现很多新的有趣的主 题，以及值得深入探索的话题。分析人员要掌握好节奏和脉络，做到 有的放矢，收放自如，分析过程既不能随意发散，也不能过于收敛。
有时分析主题比较宽泛，则需要将其细化，分解成一些更加明确的 主题。例如“目前公司供需匹配的情况如何”，这个主题更像局外人的随 口一问，如果遇到这样的主题，要尽量将其细化、明确，例如分解 成“目前供给方和需求方的现状各是怎样的”“匹配率如何”“匹配遇到的 问题有哪些”“业务管理有何困难”“如何解决业务管理的困难”，等等。 可以看出，这更像是一次完整的业务诊断，在一个大的话题下细分分析 方向，进行全面的研究诊断。

提出假设、验证假设

明确了分析主题后，接下来进入数据分析环节。面对庞大的数据海洋，该从哪里入手开展分析工作呢?该从哪些角度拆解研究呢?如果无 从下手，可以先提出某些假设，有了假设，就有了数据分析的思路，基 于假设去观察、研究数据，判断、验证假设是否正确，在此过程中便会 对数据的洞察越来越深刻，产生更加清晰的想法和思路，提出新的假 设，从而进一步探查数据，如此往复，离问题真相越来越近。
实际上，数据分析的过程就是不停地提出假设、验证并修正假设， 最终获取真相的过程。不要担心提出的假设是错误的，这远好过没有假 设，因为没有假设就没有切入点，分析工作会更加束手无策，理不出头 绪。

得出结论

经过反复地提出假设、验证并修正假设，我们会逐渐发现现象背后
的真正原因，得出可靠的结论便是水到渠成的事。 接下来，我们通过案例让大家进一步体会数据分析的过程。
11.1.4 案例:M公司零售业务销售额下降的数据 分析
M公司的零售业务在2018年前4个月的销售额持续增长，势头良 好，但是5月份的销售额却出现了一定程度的下降，具体数据如表11-1 所示，现在需要分析销售额下降的原因。

想分析销售额下降原因，首先要拿到比较细粒度的基础数据，以便 从各个角度进行数据探查。因此，我们调取了近三个月(3月至5月)的 最细粒度的订单数据，作为本次分析工作的基础数据。
在刚开始分析时，我们并没有特别好的思路，不知从何入手，不妨 大胆提出假设:可能是某个区域的销售额下降导致整体销售额下降。接 着，我们在Excel中对基础数据进行数据透视处理，观察分区域的销售 额变化情况，看看能否发现什么，如图11-2所示。除了使用Excel的数据 透视表功能，我们还用到了Excel的数据条渐变填充功能，这样可以非 常直观地通过数据条的长短快速观察单元格数字的大小。

通过观察可以发现，北京和河北5月份的销售额均有下降，其中北 京的下降额度最大，因此猜测北京地区销售额下降是全国销售额下降的 首要因素。为什么北京的销售额会下降呢?是整体的下降，还是某个品 类的下降?为了进一步分析，我们对各区域的数据进一步按照品类分 组，来观察销售额变化情况，如图11-3所示。

通过仔细观察发现，北京的蔬菜品类5月份的销售额明显下降，从 423千元下降到40千元，降幅达90%，而海鲜和水果品类销售额基本稳 定。
全国5月份的销售额比4月份整体下降362千元，北京地区仅蔬菜品 类的销售额就下降了383千元，因此基本可以确定销售额下降主要是因 为北京地区蔬菜品类销售额下降导致的。
如果此时认为已取得结论，可能还不是很严谨。图11-2还反映出河 北的销售额也有所下降。我们大胆猜测:全国的蔬菜品类是否因为某些 原因出现了整体下降呢?为了回答这个问题，我们再次制作分品类分区 域的销售额数据透视表，如图11-4所示。

仔细观察后发现，全国范围内海鲜品类销售额稳定，水果品类销售 额持续上升，蔬菜品类5月份的销售额明显下降。进一步观察蔬菜品类 的分区域销售额变化情况，发现上海和深圳的蔬菜品类销售额是增长 的，只有北京和河北两地的蔬菜品类销售额明显下降。虽然河北的下降 绝对值较小，只有37千元，但下降幅度达到88%。
考虑到北京和河北两地相连，我们猜测两地蔬菜品类销售额明显下 降可能是相同的原因导致的。因此我们询问了华北地区采购员，得知5 月份蔬菜品类的华北地区供应商货品质量大面积出现问题，导致严重退 货。华北地区供应商正是北京和河北客户采购商品的供应商。
至此，我们得到了明确的分析结论:华北地区蔬菜品类供应商的货 品出现严重质量问题，导致北京、河北区域蔬菜品类销售额骤减，进而 导致全国销售额下降。
通过这个简单的数据分析案例，希望读者对数据分析中提出假设、 验证假设的过程有了初步的认识。在分析过程中，我们不断地从各个维 度(时间、地区、品类)对数据进行观察，在需要的时候进行数据下钻(例子中从区域下钻到销售品类，也可能进一步对蔬菜品类下钻到具体 的二级品类)。通过Excel数据透视功能，并结合对数据的可视化处理 (数据条)，可以让分析工作变得直观、高效、灵活，如图11-5所示。

实际上，一套BI软件产品的重要功能之一，就是实现类似Excel数 据透视表的功能，可以让分析人员从各个维度探查数据。而数据仓库 (Data Warehouse)要做的事情，就是对各种明细数据提前按照各种维 度加工计算好，等待BI的多维度探查和展示。这其中的工作主要由数据 产品经理来负责，本书不展开讲述。

数据分析的要点

做好数据分析工作需要三个核心要素，分别是方法工具、业务知识、细心耐心，三者缺一不可。具备细心耐心，持续练习方法工具的 使用，长期积累业务知识，便可以让数据分析工作越来越得心应手。

方法工具

善于运用方法和工具，可以提升数据分析的效率，是做数据分析工 作的基本功。如11.1.4节销售额分析的案例所示，因为应用了Excel数据 透视功能，所以数据分析工作变得快捷有效，否则可能要花费大量的时 间来处理数据。
作为互联网产品人，至少应该掌握并熟练使用以下数据分析相关的 方法或工具。

• 统计学:掌握基本统计学常识，帮助自己判断、认识数据特 点。例如，要理解方差、均值、中位数、众数等概念。
• Excel:Excel具备各种强大功能，足以作为初级、中级数据分析 工作者的首选甚至唯一工具。
• SQL:掌握SQL可以快速提取原始数据，并完成数据预处理。
• 数据可视化:在工作实践中，多数情况下都是通过观察图表来 发现、识别问题的，采用合适的图表形式，可以让分析更直观、高效， 例如通过瀑布图、直方图、桑基图等观察数据特征和变化情况。
• 计算机数据基础:有的时候我们需要对原始数据进行一些编码 处理，这就需要理解一些编码基础知识，例如什么是ASCII、UTF-8、 UTF-16、Unicode，如何通过UltraEdit等软件进行编码处理(例如，有 时在Linux环境下运行SQL语句，导出的数据需要进行编码转换才能在 Windows环境下使用，如果自己不会处理，就需要每次都求助于人); 此外还要了解计算机常见的数据存储格式，例如CSV、JSON、XML 等。
• 正则表达式(Regular Expression):正则表达式是一种非常巧妙 的、用来处理文本的逻辑公式，在某些时刻，使用正则表达式可以解燃 眉之急。
• 数据分析方法论:基于不同的分析诉求，有很多成熟且经典的 数据分析方法论，例如分析C端产品的获客增长模型AARRR、分析客户 消费行为特征的RFM模型、分析留存率的COHORT模型，这些方法论 中蕴含了成熟的分析思路和手段，是针对各种确定的分析场景的最佳实 践。

产品经理掌握了以上知识点，就足够完成较为专业的数据分析工作 了，11.2节最后推荐了两本经典的参考书，读者可以根据需要学习。除 此以外，更高阶的数据分析技能和知识还包括Python、SPSS、ETL、数 据仓库等，适合专业的数据分析师学习。

业务知识

业务知识既包括行业知识、领域知识，也包括具体公司的商业模式、运营流程细节等。业务知识是数据分析的灵魂，是指引数据分析过程朝着正确方向前进的明灯。如果不具备业务知识，即使对各种方法论 和工具都很熟悉，分析工作也会无从下手。
当我们面对一个问题时，很多时候会毫无头绪，往往需要以模糊的 感觉和猜测开始分析。然而，只有具备丰富的业务知识，才能产生正确 的“模糊的感觉”。业务知识甚至能在难以捉摸或难以定夺之时，给你带 来神奇的“第六感”，在潜意识中指引你做出正确的判断。
因此，产品经理还需要补充各种业务知识，例如销售知识、供应链 知识、仓储知识等，需要产品经理根据所处行业选择并学习。

细心耐心

数据分析的过程可能是有趣的、富有挑战和成就感的，因为你需要 充分调动脑细胞，进行各种思维激荡，发现真相后会欣喜异常;也可能
是无趣的、徒劳的甚至令人沮丧的，因为你可能耗费了心血、精力、时 间，最后没有得到有价值的结论，感觉一无所获。因此，做数据分析需 要有足够的细心和耐心，能够在遇到挑战、困难、阻碍时不气馁，坚持 下去，这样才能取得成果。
方法工具、业务知识、细心耐心是进行有效的数据分析工作的核心 要素，三者缺一不可，如图11-6所示。

如果只具备方法工具和业务知识，但缺少细心耐心的特质，那么在
分析过程中遇到困难或暂时的失败时，就容易半途而废。
如果只具备方法工具和细心耐心，但缺少业务知识，那么在做数据 分析时将会理不清头绪，无从下手。
如果只具备业务知识和细心耐心，但不会使用方法工具，那么数据 分析工作将会效率低下。例如，如果不知道Excel的VLOOKUP函数的存 在，处理关联数据时就会痛不欲生。
数据分析是一项博大精深、充满挑战和趣味的工作，是产品经理、 产品运营人员必须掌握的技能，值得大家投入精力持续地学习、实践。

【资源推荐】
数据分析相关的学习资料非常多，在此给大家分享两本有趣的经典 入门书籍。

• 统计学方面:《深入浅出统计学》。统计学作为一门专业性很强的 课程，一般的教材往往很枯燥，而本书通俗易懂，趣味性强，且内容丰 富。
• 数据分析思路方面:《深入浅出数据分析》。这本书可谓数据分析 入门的必读书籍，讲述了数据分析的工具和技巧，而且通过一个案例帮 读者培养数据分析的思路和思维方式。

  数据分析报告

  经过反复分析、验证，真正的原因或结论终于浮出水面，我们需要 制作数据分析报告，把这一成果呈现给领导或同事，此时，如果因为报 告太粗糙而掩盖了数据分析的价值，岂不十分遗憾!因此，学习如何 制作优秀的数据分析报告是很有必要的。
  一份逻辑清晰、简明扼要的报告，可以让阅读者轻松、准确地理解 并掌握报告内容。一份格式编排严谨、注重细节的报告，可以体现制作 人的严谨态度和专业素养。

报告的编写思路

数据分析报告的常见结构和逻辑论证的结构相似，一般按照“总分 总”的形式编写，包括提出论点、进行论证、陈述总结三部分，如图11- 7所示。

• 提出论点:报告的开篇要简明介绍背景，以及分析的结论，让 人产生兴趣并继续关注下去。如果一开始就介绍分析的细节，估计阅读 的人或听众都会摸不着头脑，一会儿就昏昏欲睡。
• 进行论证:论证过程要有数据支撑，并且数据的呈现一定要专 业又易读。人们都喜欢看简明易懂的数据图表，而不喜欢读复杂的数学 推演。因此，配有丰富、清晰图表的报告读起来会给人生动有趣感，讲 解起来也容易吸引人的注意。
• 陈述总结:再次阐述并强调结论，加深阅读者或听众的印象。 无论是向上级汇报工作，还是给同事分享材料，按照上述结构编写

数据分析报告都是比较有效的方法。

报告的排版美化

通过对报告进行排版及美化，可以让重点更加突出，阅读更加轻 松;如果格式细节处理得当，可以让报告显得更加专业，给人留下深刻 印象。下面我们通过一个案例给大家展示数据分析报告排版中的常见问 题。
图11-8是M公司2018年业务回顾报告中的一页，对2018年的销售业 绩进行了总结。但是这页报告存在不少格式问题，你能找出来吗?

这页报告中存在以下格式问题，在实际编写报告时，无论是用PPT还是用Word，都需要十分注意这些问题。

• 没有数据来源:这就像食品包装上没有产地和成分，会导致阅 读者无法判断结论的可信性。标明数据来源可以体现数据的合理性、合 规性、合法性。
• 没有标记坐标轴含义:图中没有标记坐标轴含义，阅读者需要 猜测横纵轴数据的含义。
• 没有标记单位:两张图表的纵坐标呈现的是收入，但是却没有 标明单位(如“元”或“万元”等)，阅读者难以理解收入到底是多少。
• 数字格式不规范:对于纵坐标的收入数据，两幅图都没有采用 千分符;小数部分的格式也不规范，左图不含小数位，右图却包含2位 小数，但都是0，没有意义。

这页报告中还存在如下排版问题。

• 标题不清晰:报告的每一页都要有明确的主题；例如本例中这一页是在总结2018年的销售业绩情况，但是页面标题却是笼统的“业务回顾(四)”，也就是简单地在报告标题后加了序号，无法让读者一下 子明白这一页的核心主题。页面标题是读者第一眼看到的内容，必须利用好。页面标题要么陈述主题，例如“2018年销售额回顾”，要么陈述结论，例如“2018年销售额持续增长”。
• 没有陈述总结:每一页报告都应该有一句总结性陈述，让读者 清晰地知道这一页想表达的观点究竟是什么。
• 不同图表的分析被糅在一起:这一页有两张图表，两者的重要 信息被糅在一起表述，读起来主次不清。如果需要陈述图表体现出的重 要信息，最好在每张图表上方(或下方)呈现各自的信息。
• 太多的居中对齐:在制作报告时，新手往往很喜欢用居中对齐 的方式，认为这样很美观。实际上在《写给大家看的设计书》(The Non Designer’s Design Book)一书中，作者最不赞同使用的对齐方式就 是居中对齐，因为居中对齐让信息元素无法整齐地“分组”，让版式显得凌乱。

综上所述，我们对这一页报告进行重新编排，效果如图11-9所示。 我们修正了图表的若干格式问题，提炼总结了结论，在每张图上方陈述 了图表体现的重要信息，并且采用了左对齐的排版方式，等等。此外， 我们还对Excel默认生成的折线图格式进行了处理，调整了网格线，以 及数据条的间距。经过调整，这一页报告看起来是不是清爽不少呢?

除此以外，图表编写中还经常出现缺少图例、缺少图表标题等问 题。制作图表特别讲究格式的细节处理，但往往被大多数人忽视。格式 细节处理不当，首先会造成阅读不便，甚至影响理解;其次会让图表显 得业余、不专业，进而让人怀疑图表制作者的专业性。

【资源推荐】

漂亮的图表可以让报告看起来专业且赏心悦目，遗憾的是，Excel 默认生成的图表在美观方面总是略有欠缺。这里推荐国内Excel图表制 作专家刘万祥的著作《Excel图表之道》，书中详细且清晰地讲解了如 何制作商务范儿的专业图表。通过学习和练习，相信你绘制的图表会更 加美观和专业，成为令人眼前一亮的加分项。