《人人都是产品经理》读书笔记

1 继续

《那一年》

那一年，你正年轻
总觉得明天肯定会很美
那理想世界就像一道光芒
在你心里闪耀着
——许巍

2 人人都是产品经理

2.1 今日进程

章节：3-4全
主要内容：

• 关于Kick Off
• 需要写的一些文档
• 需要掌握的一些UML
• 测试与Bug
• 项目发布
• 项目管理：文档/流程/敏捷
• 最喜欢的案例分享

2.2 阅读收获

2.2.1 项目的坎坷一生

2.2.1.1 Kick Off

Kick Off： 项目启动会议。原指足球的中线开球，现在一般用作某件事的开始。

目的：

说明：
1、 项目背景，项目意义，目标：项目的阶段、环境，明确为什么要做这个项目，解决了什么问题。下决心，鼓舞士气。
2、 需求功能点描述：需求描述，怎么做。
3、 项目组织架构：让项目成员相互认识，明确有什么事找什么人。关键人物得到场，可以鼓舞士气，给予一定意见。目的使开发高效有序。
4、 项目计划：了解两个关键点——项目的时间点/里程碑；每个人在各个阶段需要做什么。
5、 沟通计划：提前约定沟通的时间，保证项目顺利进行。

产品模块级项目的WBS模板：

2.2.1.2 需要写的文档

BRD Business Requirements Document 商业需求文档
MRD Market Requirements Document 市场需求文档
PRD Product Requirements Document 产品需求文档
FSD Functional Specifications Document 功能详细说明

UML

作者以点菜为例，形象描述了各个图。

类图：Class Diagram，描述系统中出现的各个对象之间的关系，以及和外部系统的关系，是对业务领域的描述。

用例图：Use Case Diagram，描述各个用例之间的关系。用例包、用例和行为者之间的关系。

状态图：State Diagram，表达系统里实体的状态转换，贯穿多个用力。

时序图：Sequence Diagram，描述事物变化在时间维度上的先后顺序，善于表达对象的交互，比如多个页面之间、多个角色之间的交互。

活动图：Activity Diagram，表达不同对象之间是如何相互影响的。

协作图：Collaboration Diagram，表达不同对象之间是如何相互影响的。时序图关注交互过程中时间上的步骤，协作图关注的是对象间的关系。

测试
测试包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等。并形成文档。

Bug属性：

• 缺陷级别：描述Bug的严重性
• 所属产品、项目：利于筛选
• Bug名称：对Bug的简单说明
• Bug描述：出现Bug的情况，环境等

Bug状态流转图：

鼓励面对面交流，而不是系统内讨论，这是执行与效率问题。
项目发布之前，Bug的状态必须是Closed或Deferred。
需要用到SVN版本管理工具。

发布

项目发布工作内容：

发布计划的评审：发布计划要经过运维人员评审，包括检测软硬件的正常运行等；发布计划中要有“回滚方案”，即当发布不成功时，将产品退回原来的状态。

预发布：预发布环境会尽量模拟生产环境上的真实状态，比如数据库用的是同一个，测试人员再做一次最简单的回归测试，完成发布。

发布标准：

• SQL已经经过DBA确认无问题，DBA确认后，邮件通知到测试人员，抄送给某经理。
• 搜索引擎通过相关人员确认无问题。
• QC（质量控制）中的Bug全部Closed或Deferred
• 因技术或事件问题造成无法修改的Bug，由测试、需求、开发三方一起研究是否能接受，如果有争议，上报上级主管。
• 测试过程中，如果因为技术无法实现造成的需求改动，PD需要第一时间发送邮件到全组，让所有人都知道，同时修改相应的UC。

发布过程：

• 测试人员在确认完“发布标准”中的各项之后，会发出邮件通知同意发布，发布人员在没有收到通知前，不能自行发布。
• 测试人员在发布后，将做一轮生产环境的回归测试，测试完成后发出一封邮件邮件通知“生产环境已验证完成，发布成功”。只有收到该邮件后，发布相关成员才能撤离现场。
• 项目经理需要发出一封E-mail——“项目发布公告”。描述项目的过程，困难，对每一个人的感谢，内心感言，项目的意义等。

之后，写一份项目小结，。包括对项目中错误、问题进行分析，根据数据监控得到的反馈，以及商业目标是否达到等各种问题。
注意在项目中的日报和周报的记录，以便在事后能更好的分析项目完成的细节等问题，在下次改进。

项目管理

建立文档规范，总结开发流程，使用敏捷方法。
以上与互联网开发的规范，分布，迭代的特性相同，是将做任务的过程，一步步分发到各个团队、个人，保证项目在有序、持续的进行，不会因为有人因故误工而耽误项目的开发，也能在新人进入的时候，给予明确的目标，帮助其成长。

2.2.2 我的产品，我的团队

产品的一些性质

产品时间性质：产品与对应的市场、用户好像都是有生命的，他们都会从幼小发展到成熟，最终老去，不同时期的产品与市场、用户都有其特点，最佳的状态就是彼此之间完美的配合。

5种用户群体：创新者、早期追随者、早期主流用户、晚期主流用户、落伍者。

产品空间性质：产品不是由单一方面组成，主要由技术（稳定/性能/Bug…）、产品（功能完成度/交互流程/视觉传达…）、商业（定位/促销/渠道…）等方面组成。

产品设计性质:产品设计主要有5个层次，分别为战略层、范围层、结构层、框架层和表现层等。这是一个从抽象到具体的实现过程。

产品团队性质：职位越分越明，是为了对应的问题有专业的人解决，使得产品开发高效，产品能保质、有序、快速迭代。人的利己性会导致“在什么山头唱什么歌”，完善的公司组织结构会有利于团队的发展。

1、产品的时间和空间需要对实操的积累以及更多的阅读去感悟，每时每刻的反思，对工作中每一点的终结。

2、书中书：
产品生命周期书目：《公司进化论：伟大的企业如何持续创新》《跨越鸿沟》
产品设计书目：《设计心理学》《情感化设计》

产品与规划

概念图：思维导图/会议室讨论。主要是思维上的总结和整理，表达两种关系，分别是产品与外界的关系和产品内部的关系。内部形成共识。

信息架构：为外部而做，设计更合理方式，把信息传递给用户。由内向外的展现。

信息传递：字不如表，表不如图。

• 例子：

  
  
  普通

更直观

更形象

加了交互

产品与商业

不要因为对一件事不了解，就觉得其简单、不重要。

书目：《产品经理实战手册》，讲的是产品经理偏市场方面的工作。

好产品需要市场化。包括包装、定价、促销、销售和渠道等内容。

产品产生问题，需要从运营（流量）和用户研究（原因）两个方面处理，一个治标一个治本，需双管齐下。
解决产品的问题，还需要进行合理的数据分析，从现象到本质，再回归现象的解决方法。

产品与技术

交流可以建立在流程上，规则明确分工，理性。
交流避免情绪化，不是说服，而是交流。
交流以外，需要做好自己的本职工作，包括文档质量，试着了解一点技术。

个人与老板

从问到选择到判断。
需要自己不断的积累和反思，需要不断的交流和沟通。员工和老板不是对立的，有共同的目标，学会交流思考。

这是一个大图