《人人都是产品经理》读书笔记3
之前提到产品立项之前会有需求的采集、分析和筛选，需求的采集主要从定性与定量，说与做四个维度进行，需求分析需要将用户需求转化为产品需求，确定需求基本属性、分析商业价值，编写BRD，评价实现难度和计算性价比，通过产品会议确定产品进度和状态。之前的都是准备工作，如果产品会议通过，进入立项开发阶段，那么项目就算正式起飞了，也就是项目的管理。
图1 项目管理
1 产品与项目
1.1 产品和项目的区别
- 产品周期长；项目周期短
产品是有一个比较长的生命周期，从产品开始规划到产品下线消亡，有一段较长的时间；而项目周期较短，项目规划一般子很短的时间完成。 - 产品应对各种变化；项目有计划性
在产品的整个生命周期，需要适应内外界的各种变化，应对各种需求，以不断满足用户需求和产品需求；项目有计划性，一般是一个一个的任务。 - 产品是通用的；项目是定制的，特定场合用
产品一般是给大量用户使用，相对比较通用；而项目由于周期短和其华兴，一般是为了满足特定的用户和需求。 -
∑ni项目=产品⟶产品线（版块、模块、增值服务⋅⋅⋅）
产品的形成是通过一个个项目实现，但是不是简单的累积，否则会臃肿不堪，四不像的怪物。当产品比较大的时候，产品需要升级成为产品线。
1.2 产品经理和项目经理的区别
产品经理（PD，product manager），负责整个产品的规划，关注整个产品生命周期，为产品的战略、发展路线做规划。
项目经理（PD，project manager），对项目负责，参照项目计划对项目进行管理。
苏杰在《人人都是产品经理》中讲产品经理靠想，是内部驱动，而项目经理靠做，是外部驱动。
2 项目启动
2.1 项目组织结构
项目组织中有很多角色，负责不同的内容，主要有：
项目经理：对整个项目进行负责；
PD：负责项目的需求，可能担任项目经理；
开发经理：开发相关任务，负责时间计划和任务分配；
测试经理：负责测试的相关人物；
UE：负责用户体验，如交互效果、视觉效果等；
服务团队：产品帮助编写，以及上线后的服务工作
项目督导委员会：不需要做实际的事情，表层次的任务是督导所有人有序完成项目，其实也可以保护项目负责人，当任务变动较大时，向他们提出申请，他们同意后任务继续，同时也让“干活儿”的人知道有领导盯着，更加认真卖力。
图2.1 项目组织结构图（图片取自 苏杰·《人人都是产品经理》）
2.2 誓师大会
大多数学校有高考前百日誓师大会，项目启动也需要，可以鼓舞士气，明确任务。誓师大会一般会介绍的内容有：
- 项目背景
- 项目意义、目的与目标
- 需求、功能点描述
- 项目组织架构
让项目组成员相互认识，明确大家各自的分工，有问题可以相互沟通交流。 - 项目计划
- 沟通计划
2.3 项目目标
多 快 好 省：范围大、时间短、品质高、资源省。
经典的项目TQR：项目时间（Time）、项目资源（Resource）、项目质量（Quality）
工作分解结构（WBS，Work Breakdown Structure），自顶向下（top-down）的任务分解结构。
图2.2 WBS模板
3 需求： 文档和画图
产品从抽象到具体主要包括BRD、MRD、 PRD、FSD。
3.1 PRD，Business Requirement Document，产品需求文档
PRD分为三部分，其一是对产品的总体说明，其二是UC（use case）部分的说明，其三是对单个UC的说明。产品的总体说明包括：
- 修订历史：修订日期、版本号、说明和作者；
- 项目概述：项目背景、意义、目的和目标等；
- 功能范围：业务逻辑图，系统中角色的职责，和周边系统的关系，全局的商业规则；
- 用户范围
- 词汇表：专有词汇和术语；
- 非功能需求：如性能需求、数据监控需求等。
- 其他说明
UC部分整体说明一般有类图、用例图、状态图等方法，说明用例之间的额关系，然后是用例的正文。
最后，单个UC的说明一般是一些注释。
图3.1 BRD模板和结构示意图（图片来自苏杰·《人人都是产品经理》
3.2 UML：类图、用例图、状态图
- 1 类图
类图，class diagram，描述系统各个对象以及和外部系统的关系，是对业务领域的描述。
图3.2 类图
- 2 用例图
用例图，Use Case Diagram，描述各个用例之间的关系，比如include或者extend。
图3.3 用例图
- 3 状态图
状态图，State Diagram，表达系统里实体装填转换，贯穿多个用例。
图3.4 状态图
4 时序图
时序图，Sequence Diagram，也叫顺序图，描述事物变化在时间维度上的先后顺序，善于表达对象的交互，比如多个页面之间，多个角色之间。
3.5 时序图5 活动图
活动图，Activity Diagram，和流程图相似，描述各种动作引起系统变化，善于表达永道较多，分支较多的情况。
图3.6 活动图
- 协作图
协作图，Collaboration Diagram，表达不同对象如何相互影响，和时序图可以等价转换。
图3.7 协作图（图片来自网络）
3.3 用例文档，UC
以小倩选课为例，
概述：
用例的唯一标识：UC_courese
用例名称:选课
业务描述：小倩在期末未下学期选择要上的课程
需求描述：上课的需求，获取学分，学习知识
行为者：小倩
前置条件：选课系统开放
后置条件：系统分配课程
其他说明：
UC主体：
界面描述：教务网站选课描述
业务规则：通识课最多选2门
流程描述：
······
| UC_<用例名称>：<用例ID> | |||||
|---|---|---|---|---|---|
| 用例概述 | |||||
| 业务描述 | <商业目标，用户目的等业务内容> | ||||
| 需求描述 | <产品需求，需要实现哪些功能点> | ||||
| 行为者 | <该用例的Actor> | ||||
| 前置条件 | <Pre-Conditions> | ||||
| 后置条件 | <Post-Conditions> | ||||
| 其他说明 | <任何其他的说明信息等> | ||||
| 界面描述 | |||||
| UI示意图：<页面名称> | |||||
| <demo截图1> | |||||
| <截图说明1>（给出demo的文件的地址） | |||||
| 界面元素——表单：<表单名称> | |||||
| 名称 | 类型|长度 | 必填 | 默认值 | 规则 | |
| √ | |||||
| 界面元素—–列表：<列表名称> | |||||
| 名称 | 类型|长度 | 排序 | 规则 | ||
| 界面元素——按钮 | |||||
| 名称 | 规则 | ||||
| 界面元素——<其他>；<通用描述> | |||||
| 名称 | <······> | 规则 | |||
| 业务规则 | |||||
| 序号 | 规则 | ||||
| 1 | （UC通用规则写在这里，流程中某步的私有规则写在流程中） | ||||
| 流程描述 | |||||
| 流程1（ 主流程）<流程名称> | |||||
| 触发事件：<触发事件> | |||||
| 时序图 or 活动图（尽量用图表达，下面的文字描述可选） | |||||
| 步骤 | 用户 | 系统 | 规则 | ||
| 1 | |||||
| 2 | |||||
| 分支流程1-1 | |||||
| 1 | |||||
3.4 Demo
Demo, Demonstration，产品原型，示例，演示版，一般经历从低保真到高保真的过程，低保真非常抽象，之后逐渐具体到高保真，和实际产品越来越接近。常用到Photoshop，Axure，Dreamweaver制作页面。
如图，低保真可能只是简单手稿，之后不断具体和修饰，成为最终的版本。
图3.8 demo演化过程比喻（图片来自网络）
3.5 评审
项目最重要的三个角色是PD、开发人员、测试人员，对应着三次评审，需求评审、设计评审、测试评审，评审会议组织者由QA担任。
- 需求评审
是对PRD评审、UC评审、Demo评审的统称，一般PD讲PRD和UC，UE主讲Demo。
图3.9 需求评审 - 设计评审
开发工程师以设计文档的形式说给PD、测试。 - 测试评审
测试工程师对需求理解以TC形式说给PD，开发听。
评审会议组织者由QA担任。
QA:Quality Assurance,质量保证人员，负责质量保证相关工作。
3.6 需求的完整流程
按照项目的进展程度分为三个阶段：
- 项目开始之前-（需求中）
PD在产品会议和需求讨论会上分析需求的商业价值 - 项目中的需求阶段-（开发中）
PD在需求评审会上收集意见，不断修改需求。 - 项目中的需求阶段之后-（已发布）
组织功能评审会，确认其功能是否是想要的。
图3.10 需求流程（图片来自苏杰（人人都是产品经理）
4 开发、测试、发布和总结
4.1 开发和测试
开发：设计——>设计评审——>编码——>单元测试
单元测试：自测环节，测试完没问题，再把代码从开发环境提交到测试环境。
测试：TC编写——>TC评审——>冒烟测试——>功能评审+（UAT）——>测试
**冒烟测试：**Smoke Test，因为耗时短，仅需要一袋烟时间而名。
**UAT：**User Acceptance Test，用户接受度测试。
测试过程除了功能测试，还有性能测试，比如访问压力测试。测试过程可以不断发现“Bug”，发布之前叫做缺陷，发布之后叫做故障。
4.2 Bug
bug一般有缺陷级别（severity），所属产品、项目，Bug名称，Bug描述等关键信息。
- Bug级别
| 缺陷种类 | 缺陷级别 | 详细说明 |
|---|---|---|
| 功能缺陷 | Urgent(V级） | 1. 操作系统无法正常使用，四级，出现致命错误 |
| 2. 数据丢失 | ||
| 3. 被测试系统频繁崩溃，程序出错，使功能不能继续使用 | ||
| 4. 性能与需求不一致 | ||
| 5. 系统资源引发性能问题 | ||
| 6. 系统配置引发错误 | ||
| 7. 安全性问题 | ||
| Very High（IV级） | 1. 功能与需求不一致，或功能未实现 | |
| 2. 功能有错误，影响使用 | ||
| 3. 数据传输有错误 | ||
| 4. 安装与卸载问题 | ||
| High（III级） | 1. 功能有错误，但不影响使用 | |
| 2. 界面错误 | ||
| 3. 边界条件出错 | ||
| Medium（II级） | 1. 界面设计不规范 | |
| 2. 消息、提示不准确 | ||
| 3. 交互不友好 | ||
| 需求缺陷 | Low（I级） | 1. 软件设计有问题 |
| 2. 文档不完整或不准确 | ||
| 3. 需求冻结后，描述不清楚的地方 |
- 所属产品、项目
- Bug名称
- Bug描述
图3.11 Bug状态流转图（图片取自苏杰（人人都是产品经理）
4.3 发布
- 发布：发布评审——>预发布——>发布——>线上验证
4.4 总结
- 项目发布公告
项目发布之后的公告，回顾项目艰辛，对项目参与者的感谢，为团队争取精神和物质的奖励。 - 项目小结
项目心得体会，碰到的问题、原因和解决方法，合理与不合理的地方，收获 - 项目周报/日报
| 项目名称： | |||||
|---|---|---|---|---|---|
| 总体状况： | |||||
| 本周/今日要闻 | 1. | ||||
| 下周/明日 | 1. | ||||
| 当前问题与解决方案 | |||||
| 问题 | 描述 | 紧急度 | 解决期限 | 解决方案 | 备注 |
| — | |||||
| 项目进度 | |||||
| 任务 | 描述 | 完成率 | 计划完成 | 实际完成 | 备注 |
| — | |||||
| — | |||||
| — | |||||
| — | |||||
| — | |||||
| — | |||||
| 里程碑 | |||||
| 任务 | 描述 | 完成率 | 计划完成 | 实际完成 | 备注 |
| — | |||||
| — | |||||
| — | |||||
| — | |||||
| — | |||||
| — | |||||
5 项目管理总结
5.1 文档
图5.1 PD常用文档（图片来自苏杰《人人都是产品经理》）
5.2 工具
- 协作和版本工具
- windows共享文件夹（有人打开文档，其他人无法编辑）
- Google Docs
- Office live
- SVN 集中式版本管理
- Github 分布式版本管理
- WIki
- 文档工具
- word
- Excel（VBA）
- PowerPoint
- Visio，画图工具
- Outlook，邮件管理
- Project，开发计划和测试计划
- MindManager、FreeMind、XMind ，思维导图软件
VBA:VIsual Basic for Application，一种自动化语言，可以使常用的程序自动化。
5.3 评审
图5.2 评审
5.4 敏捷
敏捷方法：渐进式的开发模式
6 总结
图 6.1 项目总计（图片来自苏杰《人人都是产品经理》）
扫一扫
1627
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
