“人人都是产品经理”它既是一个书名又是整个行业最知名的“金句”，相信作为产品经理的小伙伴对它都不会陌生。09年初，时任阿里产品经理的苏杰提出了这个对行业影响深远的概念，十多年来，它帮助了成千上万的人成为了优秀的产品经理。

       那么一个刚入行的小白该如何一步一步地成为一名优秀的产品经理呢？让我们来更加详细地了解一下吧。

01

产品经理的职责

        产品经理的工作需要贯穿于整个软件项目周期，想要明确产品经理的职责，首先要了解软件产品的开发流程，以及开发团队中各个岗位的工作内容，才能在项目的各个阶段更好地行使自己的职权，完成自己的工作，形成更默契的团队配合，保证团队的良性运转、项目的正常推进。

        产品经理是整个项目团队的工作先锋，在产品准备阶段要广泛地调研和了解需求，确定产品设计案，并向技术团队准确传达，为开发和测试工作打下良好的基础。

02

需求分析与管理

        需求是产品经理在工作中经常接触的一个词语，其来源于用户的痛点。我们必须弄清楚究竟什么是需求，需求有哪些类型，才能走好产品设计的第一步。

        从心理学来讲，需求是由个体在生理或心理上感到某种欠缺而力求获得满足的一种内心状态，

它是个体进行各种活动的基本动力。从产品角度来讲，需求是某一类用户在某些特定的场景下产生的期望，是用户遇到的问题。

        从产品角度来讲，需求是某一类用户在某些特定的场景下产生的期望，是用户遇到的问题。例如，25 岁的白领小王，公司离家很远，下班后没有时间准备晚饭，希望到家后能很快吃上晚饭。



        需求的来源除外部用户外，还可以来自公司老板、市场部门、运营部门、财务部门等，也可以通过数据分析发现用户的需求。

        但有一点需要注意，我们经常挂在嘴边的“想要做一个某某功能”“某某功能如果改成这样就更好了”等说法并不是需求，而是为了满足需求的一种解决方案（或功能），功能不等于需求！

        当用户或客户在向我们提出需求时，要注意判断他们提出的究竟是需求还是功能。很多时候他们提出的所谓“需求”其实是经过了自己加工的一种“解决方案”，并不是他们遇到的根本问题。前文白领小王的例子中，小王的需求是：在下班后减少等待时间，尽快吃上晚饭。那么，外卖软件的解决方案是：提供人工切换收货地址、选择送达时间两项功能，在公司提前点餐送到家中，到家后可以直接吃饭。如果用户不想点外卖，那么回家途中的线下商家可以提供半成品商品，买回家后省去备菜的环节，经过几分钟的炒制即可成菜，也能实现减少等待时间的期望，这也是一种不错的解决方案。这就说明，同一个需求可以有若干个解决方案供用户选择。

        下面再分享一个经典的例子来说明需求和解决方案之间的关系。

        20 世纪初，张三想从甲地到乙地，提出“我想要一匹更快的千里马”。那么，“千里马”是他的需求吗？显然不是，张三的核心需求是更快地到达目的地，“千里马”是他提出的解决方案，而这种解决方案受人们认知的影响，并不一定是最优的，在当时人们的认知中，他只能想到“千里马”。后来人们开始研究制造汽车，显然“汽车”这个解决方案更优秀，随着科技的发展，又出现了高铁、飞机等解决方案。

03

流程图：梳理业务逻辑

        流程，是指特定主体为了满足特定需求而进行的有特定逻辑关系的一系列操作过程。流程图，

就是用图形、图示的方式表达流程。

    产品经理拿到需求后立刻进行界面原型设计，容易遗漏一些细节，出现业务漏洞，影响产品的正常使用。在进行需求评审时，开发人员、测试人员、设计师会经常地提出疑问，如果产品经理总是考虑不清楚，无法回答，会显得不够专业，容易失去其他成员的信任。

        我们要明白一点，产品设计并不等同于原型设计，它的本质是流程设计，具体表现形式就是流程图。利用流程图，可以督促、辅助我们对业务逻辑进行梳理，查漏补缺。在需求评审时，也可以对照流程图对团队成员进行讲解，有助于他们对需求的理解。

        流程图按照颗粒度和使用场景一般可以分为业务流程图、任务流程图和页面流程图，下面简述一下业务流程图。

        业务流程图的第一类使用者是产品经理自己，用来梳理逻辑、理清思路，这种情况下业务流程图没有过多的绘制要求。第二类使用者是项目经理、运营人员或其他业务人员，他们首要关心的是自己在现实世界中需要做什么工作，而不是具体的功能实现和技术细节。第三类使用者是技术人员，他们却是要关注细节，关注每一个流程分支的处理，但在初始阶段，我们要让技术人员把自己当成非专业人士，先理解业务，然后思考技术细节，从宏观到微观逐步进行。

        综上所述，业务流程图的颗粒度相对而言比较大，不在意细节，重点表明“人需要做什么”，而不是“计算机需要做什么”。

        下面是一张堂食点餐业务流程图，图中混入了“开台”“关台”和“提交菜品”，这几个节点是软件功能维度的节点。“开台”“关台”是软件系统中定义的概念；“提交菜品”只是软件系统中点菜环节的一个小步骤，对于消费者来说，他需要做的事就是“点菜”。



        在绘制业务流程图时，先思考业务的起点和终点是什么，业务涉及哪些角色，每个角色涉及的事务有哪些，事务之间的先后顺序是什么。

04

结构图：为设计做准备

        功能结构图可以理解为一种图形版的产品功能清单，把产品功能通过组织化的形式进行展示。不仅是产品经理和技术人员，很多非专业人士也可以通过功能结构图对产品有一个宏观的认知。

        功能结构图就是把产品功能按照从属关系，逐级拆分成若干层级的子功能，形成图表。图表中的根节点一般为产品名称，从根节点产生的分支中，每个节点都是一个功能模块或功能点。以51CTO学堂 App 为例，它的一级功能模块整理如下。



   功能结构图有如下重要作用。

       （1）功能结构图主要在界面原型设计之前进行绘制，帮助产品经理思考产品的各项功能，尽可能确保功能模块可以覆盖所有的业务场景，为下一步产品架构设计、绘制界面原型、撰写 PRD文档做好准备。在完成界面原型设计后，检查事先绘制的功能结构图是否需要修改，然后插入PRD 文档中。

        （2）对其他竞品的功能结构进行拆解，与我们的产品进行对比参考。也可以对已有产品的功能结构进行整理，用于分析、反思、复盘。

        （3）帮助团队成员快速对产品功能有一个整体的认识，对粗略估算开发和测试工期是一个重要的参考。

05

产品界面原型设计

        界面原型是把抽象的想法和需求转换为直观表达产品设计框架的模型，可以体现产品的设计理念、业务逻辑、功能交互和视觉样式，是产品经理、交互设计师与项目负责人、技术工程师、老板、客户沟通的最好工具。

        按照界面原型在页面交互和视觉样式上与真实产品的相似程度，把界面原型划分为低保真原型和高保真原型，原型的保真度越高，越接近真实产品。

        低保真原型又称为线框图，在视觉样式方面，只需把页面上的各种文本、按钮和表单等组件进行简单排列即可，不要过度关注样式问题，例如，组件之间的距离、尺寸和颜色等，这样可以降低原型的制作成本。在交互动作方面，一般只需做出页面跳转链接、弹出层等基础效果，也可以使用箭头把原型缩略图连接起来，形成页面流程图。



        高保真原型会尽可能贴近真实产品的视觉样式和交互动作。在视觉样式方面，界面原型与视觉设计稿保持高度一致。 在交互动作方面，要制作出详细的交互效果，例如，不同状态下显示的内容、页面切换方式和异常流程的处理等。



06

UML图：产品经理必学

        UML 全称是 Unified Modeling Language，是一种通用的图形化建模语言，诞生之初是给研发人员使用的，但也适合架构师、产品经理、系统分析师等角色使用。UML 中包括十余种图，产品经理借助这些 UML图，可以更好地梳理逻辑、提升沟通效率。下面简单介绍一下用例图。

        用例图从用户视角出发，描述不同场景下的业务模型，真正做到以用户为中心分析需求、设计产品，多用于业务建模、需求建模。

       



        用例图是用户与系统交互的最简单的表示形式，从外部用户的视角观察系统的功能模型图，以图形的方式表明“系统做什么”，成为“系统的蓝图”，帮助项目干系人理解系统的功能边界。上图是在线学习课堂的学员用例图。

07

PRD文档

PRD 文档（Product Requirement Document，产品需求文档）中详细描述了产品的功能技术指标，主要阅读对象有开发人员、测试人员、项目经理和设计师等。PRD文档的作用如下：

（1）PRD 文档作为软件开发、编写测试用例、验收上线的主要依据，所以要对产品的逻辑细节和功能细节进行详细的描述，例如，每个字段的含义、数据类型、输入限制、输出条件等。

（2）撰写 PRD 文档可以方便产品经理梳理业务细节。单纯地绘制界面原型，有些业务细节可能考虑得不周到，当静下心来撰写 PRD 文档时，会发现一些新的流程分支，可以在一定程度上减少设计漏洞。

（3）团队其他成员对需求的理解是通过产品经理“讲出来”的，而不是“看文档”，对开发和测试人员来说，PRD 文档的作用更多的是在开发和测试中进行细节的查阅。

（4）存档记录，便于后期查阅，防止遗忘。当出现人员交接时，也更加方便。

（5）某个产品版本一旦评审通过，原则上要极力减少修改，通过正式文档来约束产品经理、

市场人员、老板、客户，不要频繁修改需求。

08

软件测试知识

        软件被开发出来后，难免会出现缺陷，必须经过严格的软件测试才能上线，主要由专业的软件测试工程师来完成，而一些中小型团队没有专业的软件测试工程师，需要产品经理担任测试工作。

        完成功能开发之后，正式提交测试之前，需要先由产品经理进行初步的验收，验收通过后才会转交到测试工程师手中，进行覆盖率更广的测试。

        基于以上原因，产品经理也要掌握一些简单的软件测试技能。

        按测试手段可以将软件测试划分为：

        （1）黑盒测试与白盒测试。

        （2）静态测试与动态测试。

        （3）手工测试与自动化测试。



        当由团队内部成员进行的测试全部完成后，开始着手把软件交付给客户。客户正式使用软件之前，对软件进行最后一次质量检测。验收测试以客户 / 用户为核心，项目经理、产品经理、开发工程师、测试工程师等项目组成员提供辅助工作，目的是确保交付的软件与客户要求的功能和性能指标保持一致。

        验收测试的过程中，需要注意以下内容。

        （1）客户 / 用户不关心软件内部的实现逻辑，所以采用黑盒测试的方法。

        （2）主要邀请客户方的负责人和曾经对接需求的人员进行验收测试，不要把所有的用户全都邀请过来。

        （3）准备较为真实的数据进行测试，保证验收测试的效果。

        （4）验收测试也要给客户准备测试用例，但不需要把用例库中的所有测试用例全部拿来使用，重点准备客户关心的、核心功能的测试用例，次要功能的测试用例可以适当弱化。

        （5）测试用例可以适当反映软件的亮点，以吸引客户的兴趣，为软件增色。

        （6）如果验收测试没有一次通过，则准确记录问题点，并与已经商定的需求规格说明书做对比，确实需要进一步完善的，约定修改时间，再次验收。

        （7）如果验收测试通过，双方签署验收通过报告。

作者简介

狄睿鑫，曾任河北师范大学移动物联网研究院产品经理，拥有多年一线产品经理从业经验，现51CTO学堂特级讲师，企业培训讲师，线上学员人数达到80余万人，发布的Axure RP系列课程和产品经理方法论课程被中国联通等多家大型企业选为内部培训课程使用。