人人都是产品经理
第1章 写给-1到3岁的产品经理
为什么要做产品经理
-
坏产品：无处不在的危险
- 产品的用户总是分为新手、专家和中间用户
- 产品功能的改进方向：让用户更加省心
好产品：改变生活、改变世界
我们到底是不是产品经理
-
产品究竟是什么
-
产品就是用来解决某个问题的东西
可以是有型实物或无形服务
-
解决问题：满足人们的需求进而产生价值
- 价值不仅给产品的使用者，还要给产品的创造者
-
并不是所有的产品都是商品，也有公益性、非盈利的产品
-
工作中的产品绝大多数都是在用户目标及公司商业目标中寻找平衡
- 只考虑用户，公司无法盈利
- 只考虑盈利，用户留不住
-
-
-
产品经理的由来
-
第一个产品经理
-
美国保洁公司
- 有专人对一个产品负责
-
-
出现原因
-
适应公司发展需要
-
随着企业规模增大和产品的增多，无法适应部门组织机构
- 产生的产品管理的矩阵式组织
-
-
-
-
互联网公司产品经理的招聘要求
侧重产品“从无到有、从有到优的过程”
-
涉及内容
- 产品规划
- 数据分析
- 用户研究
- 需求分析
- 功能设计
- 项目管理
- 敏捷方法
-
互联网软件行业的产品经理概念
-
与传统产品经理概念的区别
-
行业形态
-
传统行业
-
成熟行业
- 市场成熟、产品定型
- 用户成熟、熟悉产品
-
-
互联网软件行业
-
新兴行业
-
产品变化速度快
- 用户看什么都是新的
- 需要产品推陈出新、先入为主、占领用户主导用户习惯
-
-
-
-
产品形态与成本结构
-
传统行业
-
实物
- 考虑打通整个供应链
-
-
互联网软件行业
-
虚拟物品
- 团队规模小
- 成本更多花费在研发过程
-
-
-
生命周期
-
传统行业
- 研发周期长，几年以上
-
互联网软件行业
-
研发周期短，几个月左右
-
推崇敏捷方法
- 产品经理兼顾项目管理
-
-
-
-
赢利模式
-
传统行业
- 单一卖产品赚钱
-
互联网软件行业
产品大部分免费
-
赢利与用户数相关
- 重视用户研究、数据分析工作
- 赢利问题有相关团队负责
-
-
用户心态
-
传统行业
-
花钱用
- 即使不爽也凑合着用
-
-
互联网软件行业
-
免费用
-
稍有不爽就去试用新产品
-
更重视用户体验
- 产品经理涉及交互设计、视觉设计、文案设计
-
-
-
-
-
-
非典型产品经理
- 职责交给几个人，很少有全能型（除非事业部总经理或CEO）
-
一线员工眼中的管理
-
在资源不足的情况下把事情做成
- 信息不足以决策
- 时间不足以安排周密的计划
- 人员不足以支持工作的强度和难度
- 资金不足以调配
-
-
我真的想做，怎么入行
-
确定自己真正喜欢
- 从产品设计中思考问题背后的本质
- 思考如何设计才能平衡用户目标和商业目标
-
找到自己的位置
-
面试官考察方面
- 是否有激情、是否机灵好学、逻辑思维是否清晰、沟通表达是否顺畅
-
-
可行切入点
尝试做与产品有关的事情
-
从产品经理周边的职位做起
-
开发
- 预先了解需求，在需求评审会上提出自己的建议
- 可从需求分析师入手，不断培养商业感觉
-
运营
- 尝试把活动做成产品
- 练习写BRD、PRD
项目经理
-
研究公司招聘广告并做成一份调研报告
一个产品经理的-1到3岁
-
负责产品的各个方面
- 获得能力的全面提升
- 经常碰到全新的挑战
- 需要提高的能力很多
-
入行头半年
-
打杂的菜鸟
- 熟悉需求分析相关的基本知识和技能
- 了解产品的各个方面，功能、用户、技术等
- 认识团队里的同事和即将合作部门的同事
-
-
入行半年后
-
学习怎么做
- 提升对用户和对需求的理解
- 负责某些模块，但缺乏整个产品层面的权衡认识和能力
- 写产品需求文档、配合用户体验部门做demo、跟进开发、测试、发布的过程
-
-
入行一年
-
开始问做不做、做多少
负责较多模块直至所有功能
-
探索做哪些功能
- 做用户研究
-
-
入行两年
-
项目与团队
- 了解周边团队做什么并施加影响
- 制定规范、流程，将手头的工作分出去
-
-
入行三年
-
战略与修养
-
出色产品经理的基本修养
- 爱生活、有理想、会思考、能沟通
-
-
第2章 一个需求的奋斗史
从用户中来到用户中去（用户研究）
-
用户是需求之源
-
人类为什么有需求
-
需求的本质
-
马斯洛的需求层次理论
- 生理需求
- 安全需求
- 社交需求
- 尊重需求
- 自我实现需求
理想与现实的差距，人们产生“减少甚至消除这种差距”的愿望，所以产生了需求
-
-
-
用户与客户
用户是使用产品的人
客户是购买产品的人
-
广义用户是所有与产品有关的人
- 广义用户是需求之源
-
以用户为中心的思想
-
中小型公司
- 需求很大来源不是终端用户而是老板
- 老板的阅历多，会抓住商机创造价值
- 老板的观点有时比产品经理更合理
-
创业公司
- 没有精力去做用户研究
- 老板凭经验拍脑袋
-
-
不要试图满足所有用户
- 要区别对待广义用户，对狭义的终端用户也不能一视同仁
- 需求太多时要进行优先级评估和需求管理
- 一些用户自己提的需求都是互相矛盾的，所以做不到听到什么需求就做什么功能
- 产品刚起步时要把池子做大，做一些大众功能满足一般用户的需求
- 产品充分占据市场时要从已有的用户身上深挖用户价值
- 也可按照其他维度划分出优先满足的需求如性别、地域、年龄段等
-
-
你真的了解用户吗
-
体会真正的用户
- 真实的用户五花八门，必须真刀真枪去研究他们
-
描述用户
产品经理可能只是老板的一杆枪，指哪打哪
-
创建Persona（人物角色）
- 新人进入团队可以迅速了解用户和产品
- 老板可迅速进入状态
-
用户研究
-
用户研究是前提不是附属内容，必须在做产品的过程中随时纳入计划
-
《赢在用户：Web人物角色创建于应用实践指南》
-
用户的说和做
- 说表现了目标和观点，做反映了行为
- 用户的说和做经常是不一致的，但两反面都很重要
-
定性与定量
- 定性研究可以找出原因，偏向于了解；定量研究可以发现现象，偏向于证实。
-
-
例子
-
第一轮 听用户定性地说
-
确定产品方向
- 抽样用户做访谈
-
-
第二轮 听用户定量地说
-
确定需求优先级
- 投放调查问卷
-
-
第三轮 看用户定性地做
-
设计需求怎么做
- 找用户做可用性测试
-
-
第四轮 看用户定量地做
-
数据分析
- 根据用户使用情况做数据分析对产品进行改进
-
-
-
目标：实实在在的把用户当做需求之源
-
-
需求采集的大生产运动（需求采集）
-
需求采集的过程
- 明确目标
- 选择采集方法
- 制定采集计划
- 执行采集
- 资料整理
- 需求分析
-
需求采集方法
-
定性地说：用户访谈
-
常见问题及对策
-
说和做不一致的问题
让用户说和做同时进行
-
区分用户说的事实与观点
- 描述过程的话可信度高一些
- 我觉得、我认为的话不可全信
-
样本少，以偏概全
选择样本要尽量随机
识别出可引起偏差的因素并在访谈报告里表明
-
以增量的形式做访谈
- 先选择少量样本进行访谈，得出基本结论，再访谈少量样本，观察结论是否改变。有改变就增大样本量，没有改变就停止访谈。
-
用户过于强势，带偏话题
- 要时刻牢记访谈目的，及时纠偏
-
我们过于强势
- 牢记访谈目的，管好自己的嘴
-
-
用户大会：邀请产品的用户集中开会，短时间获取大量信息
明确目的
-
资源确定
- 时间、地点、工作人员、用户、嘉宾、材料、备用方案
-
现场执行
-
辅助工作
- 场地布置、进场前导、主持、送客
主流程
-
-
结束收尾
- 资料整理、运营
-
-
定量地说：调查问卷
-
与访谈的区别
- 访谈提纲通常是开放式问题，适用于寻找产品方向，很深入；调查问卷封闭式问题比较富哦，大规模收集信息但不够深入
-
注意事项
- 作答时间不要超过十分钟
- 开篇放置简单问题，需要思考和敏感问题放中间，个人信息放最后
-
常见问题与对策
-
样本与想了解的用户群体出现偏差
- 样本选择尽量覆盖目标群体各种类型的用户
- 保证各种类型用户样本比例接近全体比例
- 若没法做到样本选择的合理性，在结论处进行标明
- 将目标群体的特征定义成问题，若有偏差可以筛选出接近目标群体的子集进行分析
-
样本过少
- 避免使用百分比分析，使用百分比答案至少要有100份样本
-
问卷内容的细节问题
- 问题表述应无引导性
- 准备不同问卷，每种问卷选项排列顺序都不相同
- 先进行小范围试答，根据反馈修改后再大面积投放
-
-
-
定性地做：可用性测试
-
主要过程
-
招募测试用户
- 原则是尽可能代表未来真实的用户
-
准备测试任务
- 在实际使用中的一些典型任务
-
测试过程
- 观察者记录用户完成所要求的任务的过程
-
测试结束
- 询问用户对产品的整体看法和感觉
- 询问用户某些操作的原因
-
研究和分析
- 做出一份产品的可用性列表
- 对问题的严重程度进行分级
-
-
常见问题与对策
-
可用性测试做的太晚
-
可用性测试在各个阶段都可以做
-
无任何成型产品
- 拿竞品给用户做
-
只有纸面原型
- 拿着手绘产品给用户做
-
只有页面demo
- 拿着demo给用户做
-
产品可以运行
- 拿真实的产品给用户做
-
-
-
认为可用性测试太专业所以不做
- 让同事操作几个任务，即可发现问题
-
明确是测试产品而不是用户
- 提前告知用户是发现产品中的问题
- 减轻用户压力
-
测试过程中组织者该做与不该做的
- 开始时告知用户持续时间，让用户心中有数
- 测试时要求用户在使用产品的同时说出自己的思考过程
- 做测试时不要给任何的引导和指示，只做观察和记录；用户行为和预想不一样是可以提问；实在进行不下去时给予提示
- 结束之后送小礼品。给予补偿的事在邀请时就提出来。尽快总结，将报告发给用户。
-
-
产品发布后改进的方法
- 先从部分次级页面改起
- 新旧版本并存一段时间，让用户自行选择
- 给一小批测试用户放出新版本做小面积实验
- 使用用户已经习惯的风格
-
-
定量地做：数据分析
-
过程
-
数据来源
- 产品日志
- 管理系统的信息
- 网页访问情况的统计信息
-
分析方法
- Excel、统计软件、数据库软件或自己编写程序
解读结果
用户访谈
-
-
常见问题与对策
-
过于学术，沉迷科学研究
- 不需要花费太多成本来做数据分析
-
误读数据
- 不要为了迎合一个观点去找数据
-
临时抱佛脚
-
产品设计时把数据分析的需求加进去
- 记录某个按钮的点击次数
- 统计每个用户的登录频率
-
-
-
-
需求采集人人有责
-
二手需求采集工具-单项需求卡片
-
内容
- 需求描述
- 需求编号
- 来源
- 场景
-
-
尽可能多的收集
贯穿始终的过程
-
有特点的需求采集方法
-
现场调查
- 和客户一起工作一段时间，深度了解需求
-
AB测试
- 挑选少量用户分别测试不同内容，根据分析结果再决定产品方向
-
日记研究
-
研究别人写的产品分析体会
- 注意写这种日记的往往是同行而不是主流用户
-
-
卡片分类法
- 把各种需求写在便利贴上，让用户一起讨论并完成分类
自己提需求
-
-
-
听用户的但不要照着做（需求分析）
-
明确我们存在的价值
-
用户需求和产品需求
-
概念
- 用户需求是用户自以为的需求，并且经常表达为用户的解决方案
- 产品需求是经过我们的分析，找到的真实需求，并且表达为产品的解决方案
- 需求分析是从用户提出的需求出发，找到用户内心真实的渴望，再转化为产品需求的过程
-
需求分析的过程
- 分-总-分
-
-
满足需求的三种方式
- 改变现状
- 降低理想
- 转移需求
-
创造需求
- 产品设计的最高境界
- 典型场景：老板或开发突发奇想
- 要脚踏实地
-
-
给需求做一次DNA检测
-
把用户需求转化为产品需求
-
过程
- 采集的需求非常多
- 团队举行头脑风暴，了解用户需求。每个人分一块转化为产品需求
- 过滤掉不靠谱的需求
-
关系
- 多对多
-
-
确定需求的基本属性
编号
-
提交人
- 解释需求的来源，并有义务充分理解原始的用户需求
提交时间
-
模块
- 产品的模块数在5±2个比较合理
- 超过7个要重新划分或增加二级模块
-
名称
- 简介的短语描述需求
-
描述
- 具体解释名称里功能的意思
-
提出者
- 用户需求的提出者
提出时间
-
Bug编号
- 一些Bug也视为需求
-
需求的种类
-
分类
新增功能
功能改进
体验提升
Bug修复
内部需求
-
非功能需求
- 性能
- 可培训
- 可维护
- 可扩展
-
层次
- 基础
- 扩展（期望需求）
- 增值（兴奋需求）
对需求的种类区分并不绝对
-
-
分析需求的商业价值
-
衡量指标
- 重要性
- 紧急度
- 持续时间
是需求列表中最核心的部分，对其的判断直接影响产品未来的方向
-
商业价值描述
- 需求的卖点
- 可以给用户提供什么价值
- 对公司有什么帮助
-
给商业价值抽象成一个指标
- 领导决定
- 打分取均值成本较高
-
-
初评需求的实现难度
-
衡量指标
-
工作量
-
开发量
- 必须评估
- 允许误差
- 评估人必须经验丰富，通常是技术经理、系统分析师、架构师
-
-
-
-
分析需求的性价比
-
评估
- 商业价值➗实现难度（开发量）
不能只根据需求的难度大小去做
-
-
活下来的永远是少数（需求筛选）
-
人力资源互相争夺
-
两种组织结构
-
按产品线划分
- 对产品有利，产品经理权利更大、资源有保证
- 各种职能的员工沟通顺畅
-
按职能线划分
- 对多个产品间资源共享有利
- 产品规划决策层面更高，单个产品发展速度降低
-
-
-
把需求打个包
-
注意点
-
最好打包类似功能点
- 通过可视化的业务逻辑图方便给人讲解
-
功能互相之间有依赖关系
- 经常存在功能和人力资源之间的依赖关系
-
需求的粒度应相对细
- 工作量最好不要超过5人天
-
-
产品会议
- 老板们给各个产品分配资源并纠偏
-
商业需求文档BRD
-
包含内容
-
项目背景
- 解决了什么问题
- 列出数据说明项目的必要性
-
商业价值
- 分析项目的价值
- 说在点子上
- 预测相关数字的变化
-
功能需求描述
-
描述打包需求
- 用功能列表形式表达
- 画出业务逻辑关系
-
故意加入让老板砍的需求
- 让老板不好意思再砍
-
非功能需求描述
资源评估
风险和对策
-
-
-
-
别灰心，少做就是多做
- 要看重功能的质量而不是数量，哪怕功能不多
- 选择性价比更高的做法
- 尽可能多的采集需求，有了大局观后尽可能多的放弃
心急吃不了热豆腐（需求管理）
需求的状态
-
需求管理的附加值
-
统计每个提交人的需求数量
- 反映每个人的工作情况
-
统计提交时间、发布时间等信息
- 看出产品发展速度
-
统计每个模块的需求数量
- 看出用户的兴趣，指导产品发展方向
-
统计每个分类的需求数量
- 看出产品是在做新功能还是老公能优化，了解产品发展阶段
统计需求的商业价值、性价比变化
-
第3章 项目的坎坷一生
从产品到项目
-
定义
- 项目：只会进行一次，包含多项互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。
-
产品与项目的比较
-
生命周期
-
产品生命周期相对较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程。
- 产品结束是不存在的
项目生命周期较短，通常在项目开始以前就有明确的其实和结束时间，通过验收表示其生命周期结束了。
-
-
具体做的事情
- 产品负责人需根据各种内外部信息的变化修正自己的判断，给出适宜的创新。
- 项目开始时就有明确的目标，注重计划与控制
-
产出物
- 产品可批量生产提供大量用户，相对通用；通常用有限的资源满足更多需求。
- 项目只进行一次，每次都是定制的、个性化的需求，产出物也比较个性化。
-
-
产品经理与项目经理
-
定义
-
产品经理靠想。做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润
- 关注的是产品的生命周期、产品是否能赚钱。
- 必须能规划整个产品的架构和发展路线，确定产品的定位和受众，能预计产品的真正价值和收益。
-
项目经理靠做。把事情做正确，在时间、成本和资源约束的条件下完成目标。
- 按照目标完成任务就是成功的
-
-
-
产品经理兼任项目经理
-
兼任
- 对需求管理方便，但总增加新的需求导致项目经常无法按期完成
-
不兼任
- 项目经理倾向于简化项目，用户体验不好
-
一切从Kick Off开始（团队组建）
-
组建团队
-
项目的组织结构
-
项目督导委员会
-
成员一般是项目成员的老板及其老板
- 背黑锅、买单
-
-
项目经理
- 统筹管理整个项目
-
PD、开发经理、测试经理、UE、服务团队、各团队的职能接口人
- PD负责项目的需求，某一个可能兼任项目经理。
- 开发经理负责开发相关的任务、开发的时间计划与任务分配，并全程掌控设计、编码直至上线的过程。
- 测试经理负责测试相关的任务。
- UE（用户体验团队）负责产品给用户的展现，比如交互效果、视觉效果等。
- 服务团队负责产品帮助的编写以及上线后的服务工作等。
- 各职能接口人负责牵扯其他产品的协同工作
工程师
-
-
-
项目计划
-
日常项目时间
-
基于网页的软件
- 两周到一个月
-
大一点项目
- 最多不超过三四个月
-
-
评估工作量推算工期
开发经理分配开发任务
-
工程师评估自己工作量
-
公式
- （最乐观+最悲观+最可能）/3
- （最乐观+最悲观+最可能*4）/6
-
-
工作量精确至1人天
- 1人天通常等价于5~6人小时
-
开发经理汇总工作量并推算出工期
- 考虑其他时间因素影响例如例会
- 没法并行的任务需要叠加工期
-
-
沟通
-
沟通方式
-
周期
- 以日、周为单位，取决于项目时间长短及变化频率
-
渠道
- 会议、邮件等，需要在成本和效率之间保持平衡
-
发起者
- 一般由项目经理、开发经理、测试经理主导相应的沟通
-
参与者
- 发起者确定参与者，不要遗漏项目边缘的同事
-
-
沟通方法
-
项目晨会
- 开发经理召集相关人员PD、开发、测试参加
-
项目日报
- 自kickoff起，项目经理每日发给项目所有干系人
-
评审会
- PD召集需求评审，开发召集设计评审，测试召集TC评审，产品可用后项目经理召集功能评审，项目所有干系人参与评估
-
项目变更申请
- 当项目发生重大变更时，项目经理与项目督导委员会沟通后确认变更
-
发布预告及公告
- 项目经理在项目发布前两个工作日发预告给所有感谢人，项目发布成功后发公告给所有干系人
-
-
-
kickoff会议
-
时长
- 15分钟
-
内容
项目背景
项目意义、目的与目标
需求、功能点概述
项目组织架构
-
项目计划
- 项目时间点与里程碑
- 各个时段需要的资源
沟通计划
-
-
项目管理
-
本质
- 保证项目质量的前提下，在时间要求、人财物花费、项目范围三点上做平衡。
-
WBS模板
- 一边做项目，一边形成自己的WBS模板
-
关键的青春期，又见需求（需求开发）
-
文档
-
文档类型
-
BRD商业需求文档
- 产品生命周期中最早的文档
- 内容涉及市场分析、销售策略、赢利预测等
- 通过PPT给大老板展示，没有产品细节
- 为了获得认可，争取资源
-
MRD市场需求文档
- 产品实施阶段
- 通过什么功能实现商业目的，功能、非功能需求有哪几块，功能优先级等
- 常见产出物有Feature List、业务逻辑图等
- 从商业目标到技术实现的关键转化文档
-
PRD产品需求文档
- 对产品功能的进一步细化
- 包含整体说明、用例说明、产品Demo等
- 对产品功能做具体描述
-
FSD功能详细说明
- 比较像用例文档
- 会出现很多技术的内容，要确定好产品界面、业务逻辑的细节
-
-
PRD的详细说明
-
文档结构
-
总体说明
-
修订历史
- 写清楚每次的修订日期、版本号、说明和作者，便与追溯
-
项目概述
- 描述项目的背景、意义、目的、目标等，描述业务领域知识，可参考kickoff中PPT的内容。
-
功能范围
- 业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规划等
-
用户范围
- 对涉及的角色、系统做简单说明
-
词汇表
- 对设计的专有词汇、术语、缩写等进行说明
-
非功能需求
- 如性能需求、数据监控需求等
其他说明
-
-
UC（用例文档）部分
-
整体说明
对所有用例进行说明
给出用例的可视化表示
说明各个用例之间的关系
-
表示方法
- 类图
- 用例图（最关键）
- 状态图
-
正文
- 用例文档
-
对单个用例的说明注释
- 视觉层面的描述通过demo表达
- 界面细节，引用界面规范文档
- 交互细节引用交互规范文档（出错提示的方式等）
- 文案细节引用文案规范文档（各种提示方案等）
-
-
-
-
UML
-
类图
- 描述系统中出现的各个对象之间的关系，以及和外部系统的关系，即对业务领域描述
-
用例图
- 描述各个用例之间的关系
-
状态图
- 表达系统里实体的状态转换，贯穿多个用例
-
-
用例文档UC
-
主要内容
-
概述
用例的唯一标识
用例名称
-
业务描述
- 商业目标
- 用户目的
需求描述
行为者
前置条件
后置条件
其他说明
-
主体
-
界面描述
- 给出截图，界面上各种元素的说明
-
业务规则
- 用例的通用规则
-
流程描述
- 分主干、分支和异常三种
-
-
-
-
UML
-
时序图
- 描述事物变化在时间上的先后顺序，善于表达对象的交互
-
活动图
- 接近流程图，描述各种动作如何引起系统变化
-
协作图
- 表达不同对象之间如何相互影响
-
构件图
- 表述软件实施
-
部署图
- 描述硬件结构
-
-
Demo
- 用例中放demo截图
- 若要表现更多交互和视觉细节，必须存在demo
- demo会经历从低保真到高保真的过程
-
概要设计与详细设计
- 不以写的东西是需求还是设计群职责，而以“技术”和“业务”区分
- PD与开发一起写生沉淀出产品规范，避免细枝末节的数据经常重复
-
-
需求活在项目中（需求评审）
-
评审
-
需求评审
- PRD评审、UC评审、demo评审的统称，需求相应部分完成之后进行评审会上PD把PRD和UC说给开发测试听，Demo主要由UE主讲
- 一般做完比较大粒度PRD后进行评审，以尽早发现问题
- UC和Demo做完后都要进行评审
-
设计评审
- 概要设计和详细设计完成之后进行
- 开发工程师把对需求的理解以设计文档的形式说给PD、测试
-
测试评审
- 测试开始执行之前进行
- 测试工程师把对需求的理解以TC的形式说给PD、开发听
-
-
需求的生老病死
-
项目开始之前
- 产品团队分析需求的商业价值的需求讨论会、多个产品间的产品会议上，活下来的需求会确定需求负责人，状态变为“需求中”
-
项目中的需求阶段
- 项目启动后，PD对需求的开发召集需求评审会，确认后状态变为“开发中”
-
需求阶段之后
- 组织功能评审会，若功能上线，需求状态变为“已发布”
-
客户反馈问题或有更好解决方案
- 视为一个新需求或Bug，重新进入阶段
-
-
成长，一步一个脚印
-
开发阶段
- 开发经理会带着普通工程师一起设计，若涉及数据库和硬件系统也会带上运维人员
- 设计完成之后，会组织一次设计评审，审核工程师对需求的理解
- 评审通过之后进入编码阶段。编码完成后，可进行代码评审工作。
- 工程师对自己的代码进行单元测试，自测后从开发环境提交到测试环境。
- 项目的主体部分提交测试之后，开发完成。
-
测试阶段
- 设计和编码时，测试工程师细化和调整侧四季花，完成TC编写的任务
- TC编写完成，测试经理组织TC评审，确认大家对需求的理解是否一致
- TC评审通过，待开发提交测试以后，测试迅速进行冒烟测试，以确认软件基本功能正常。
- 正式开始测试的同时，PD组织产品功能评审。
- 此阶段，PD准备商业相关工作，面向用户的功能、卖点介绍的文档。
-
BUG
-
描述
- 缺陷级别
- 所属产品、项目
- Bug名称
- Bug描述
-
-
项目发布
-
代码更新
- SVN管理员负责项目每日代码更新
-
发布评审
- 需要运维人员确认
- 系统改动比较大的项目要分模块分步骤发布
-
预发布
- 预发布环境尽量模拟生产环境上的真实状态
-
发布
- 填写发布申请单
线上验证
-
-
项目小结
产品经理发布“项目发布报告”
-
写一份项目小结
- 心得体会
- 遇到的问题及解决方案
- 资源评估是否合理
- 根据数据监控得出了什么结果
-
拥抱变化
- 变更事件
- 搭车事件
- 紧急事件
山寨级项目管理
-
文档管理
-
建立自己的文档规范
-
文档类型
-
需求规范类
-
PD做什么
- 对产品和团队PD工作内容的总结，让新人快速了解工作职责
-
用户体验规范
- 交互规范
- 视觉规范
- 文案规范
通用规则
-
-
需求管理类
- 用户调研
- 产品需求列表
- 产品信息架构
-
流程管理类
- 日常发布流程
- 变更事件流程
-
项目管理类
- 项目管理制度
- 项目任务书
- KIckoff的PPT
- 项目组织结构
- 项目呀WBS（可生成进度）
- 项目日报周报
- 项目发布预告与公告
-
日常工作类
- 会议记录
- 个人日报周报
-
-
-
模板的作用
- 让经常看同类文档的人提高效率
- 让写文档的新人可以快速上手
- 让写作者不会漏考虑某些内容
-
多人协作与版本管理
- 产生文档管理的本质需求是多人合作、协同办公
-
-
流程管理
-
流程的本质目的
- 将项目过程进行固化，与规范、模板的作用类似，这就是团队的竞争力
-
评审会议
-
产品会议
- 必须有，决定产品方向
-
Kick Off会议
- 最好开一下，鼓舞士气
-
需求评审
- 分PRD/UC/Demo评审，任意两个或三个都可合并
-
设计评审
- 开发能力很强可忽略
- 可让开发讲述需求，PD提问
-
TC评审
- 重要性仅次于需求评审，纯技术，商业团队可不参加
-
功能评审
- 项目干系人都参与
-
发布评审
- 开发经理决定是否需要
-
-
商业评审与技术评审
-
商业评审决定做不做，是产品会议与功能评审
-
三个决定
- 项目继续
- 重新定向
- 项目终止
-
-
技术评审决定怎么做，是需求、设计、TC、发布评审
-
三个决定
- 项目继续
- 有风险的继续
- 必须解决某问题后再继续
-
-
-
-
敏捷方法
-
特点
-
有计划，更要拥抱变化
- 项目计划要不断修正，强行遵守没有意义。计划一开始就要留有一些弹性
迭代周期内尽量不加业务
-
集中工作，小步快跑
- 项目迭代周期较短，一般为两到四周
- 每日小于20分钟的站立晨会，每个人只说三个问题，昨天做了什么？今天要做什么？遇到什么问题，怎么解决需要什么帮助？
持续细化需求，强调测试
不断发布，今早交付
-
-
项目中的敏捷沟通
- 建立项目的邮件列表
- 每日站立晨会
- 项目看板
-
物竞天择适者生存
-
几个特色项目
- 老板项目
- 封闭项目
- 外包项目
第4章 我的产品，我的团队
大产品，大设计，大团队
-
产品之大
-
时间：产品的生命周期
不同时期的产品与市场。用户都有其特点，最佳状态就是彼此之间完美配合
-
五种群体
-
创新者
- 新鲜感强，消费能力强，但忠诚度不高，需要新鲜的东西（新技术）不断刺激。
- 产品刚上市或未上市的主流用户。
- 经常提出意见和建议。
-
早期追随者
- 观念较新，需求目的性很强，需要迅速解决其问题的产品。不会马上试用，忠诚度较高。
- 会从需求角度提很多想法。
-
早期主流用户
- 典型的实用主义者，产品大规模产生商业价值的用户群，生活中最常见的人群
- 产品要做的简单易用
-
晚期主流用户
- 与早期的区别是心态上的。对新产品心存抵触
- 如果营销和创新做得好，可在投入较少的情况下获得大量回报
-
落伍者
- 最优一批用户，附加值很低
-
现实中的阶段有的可能很长有的可能很短，或同时处于多个阶段。
不管处于什么阶段，都要明确目前的市场与用户，再决定做什么产品，什么功能满足其需求。
-
-
空间：商业、产品、技术
-
方面
-
商业
- 主要由公司里的市场、销售、服务部门来考虑，他们决定产品的销售渠道、价格策略和服务方式
-
产品
- 狭义的产品部门包括产品设计、用户体验、产品运营等部门来考虑，他们决定了产品的功能范围、交互功能、视觉表现、运营手段的结果
-
技术
- 主要由开发、测试、运维等部门考虑，他们决定了产品的稳定性、性能、Bug数量等特性
-
任何一个公司在这三方面都有它的强项和弱项，不可能也没必要三个方面都很强。一是构建性价比团队考虑，二是如果都强互相压不住反而造成内耗。
-
-
-
设计之大
-
产品设计的五个层次
-
战略层
- 明确商业目标和用户需求，找准方向，重点是解决两者间的冲突，找到平衡点。
-
范围层
- 明确做多少，软件类产品确定功能范围，网站类产品确定内容范围。
-
结构层
- 考虑产品的各个部分互相之间是什么关系，软件类产品主要做交互设计，网站类产品主要做信息架构。
-
框架层
- 软件类产品做界面设计，网站类产品做导航设计
-
表现层
- 包含视觉设计和内容的优化，决定最终产品的气质
-
-
设计目标的三个层次
-
本能水平设计
- 基础，产品要有用
-
行为水平设计
保证，产品要能用
-
三个原则
- 反馈
- 容错
- 简化
-
反思水平设计
- 升华，用的爽
-
-
-
团队之大
设计职位，降低用人单位与求职者两边的沟通成本。
设置接口人
-
矩阵型组织
- 职能型组织和项目型组织的融合
- 横向是产品线、业务线，对客户负责；纵向是资源线、行政线，为了资源共享。
- 双领导：产品经理管事，部门经理管人，不能兼任
游走于商业与技术之间
-
心思缜密的规划师（狭义的产品团队）
-
概念设计与信息架构
-
产品概念图
思维导图或会议室讨论
在需求采集之后，需求筛选之前
-
表达重点
-
产品与外界的关系
- 产品与上下级系统、并列系统的关系
-
产品与内部的关系
- 产品模块之间的关系
-
-
-
-
激情四射的设计师（用户体验部门）
-
职责
-
用户研究员
- 一般没有专人来做，PD充当
-
交互设计师
- 负责人机交互界面、用户操作流程的设计，必须要了解很多商业的内容，理解功能的商业价值
-
视觉设计师
- 负责视觉设计，即用户第一眼看到的效果
-
前端工程师
- 运用前端技术进行Web页面的开发
-
-
交互设计与敏捷开发
- 交互设计的理念是精雕细琢，敏捷开发推崇做的要快
- 交互设计适合传统领域、成熟公司，时间充裕的；敏捷开发适合新兴行业、创业公司，时间紧迫的。
-
信息展现
- 数据可视化
-
文案设计
-
文案问题的级别
- 低级阶段：错别字、病句、错误标点
- 中级阶段：用词不统一、不准确
- 高级阶段：语言风格不统一、产品气质不统一
-
-
-
“阴险狡诈”的运营师
-
产品与运营
- 没有运营，产品走不出去，只能慢慢消亡；运营只能把人带来，把人留住要靠产品。
- 运营担负着商业指标，急一些看到结果
-
商业团队，冲锋陷阵
-
好产品还需市场化
定价与促销
-
销售与渠道
- 通过渠道销售的产品，新增或改动功能的时候，要考虑渠道内管理人员及渠道商的培训成本
- 选择渠道销售，说明对互联网的应用能力不足，要转变相应设计思路
- 渠道终端用户一般是企业，要考虑与个人用户的区别
- 渠道政策都要有相应的系统支撑
-
产品的版本细分
做功能区分，打细分市场
-
为了促进销售，利用消费者心理，纯策略性地做出“炮灰版”
- 在原版本基础上，添加鸡肋功能做一个价格高出很多的“高价炮灰”
- 删掉核心功能做一个价格稍低的“低价炮灰”
-
水平营销
- 创新思维
技术团队，坚强后盾
-
工程师、技术人员
-
分类
-
编码设计
- 软件架构师、系统分析师、开发工程师、开发经理
-
数据库设计
- 数据库管理员
-
测试设计
-
测试工程师、测试经理
- 功能测试
- 性能测试
-
-
软件配置管理员
- 用SVN管理代码、软件版本的变更、每日构建等
-
系统管理员
- 硬件管理
-
QA质量保证
- 流程管理、文档管理，常与测试归属于同一个部门
-
-
风格
-
技术痴迷者
- 技术攻坚的主力
- 少数没有责任心
-
实用主义者
- 工作有一段时间的经验者，做事求稳
- 少数不思进取
-
-
-
如何与工程师合作
- 工程师看重流程
- 沟通中避免情绪化，争论过程中要考虑吧产品怎么做更好而不是说服对方
- PD要不断提高自我修养
容易被遗忘的角落
-
老板
- 要把老板当做最好的资源
-
法务
- 搞定产品中一切与政策法规相关的问题
-
财务
- 特别照顾付费产品
-
行政与IT
- 负责办公资源的正常运转
大家好才是真的好
-
所谓团队文化
- “不正经”和死气沉沉
-
虚无的无授权领导
-
产品经理应该是管理者吗
-
优势
-
管理岗位利于拥有话语权
- 产品经理最大的激励是成就感
管理岗位利于获取信息
管理岗位利于争取资源
-
-
劣势
管理岗位有很多行政工作
-
管理岗位会让人脱离群众
- 容易忽视别人意见
- 官民之间的天然隔阂
-
奖励或送礼的不敌并不是给对方最大的效用，而是要对方更开心，感激和记住你。
-
第5章 别让灵魂跟不上脚步
触及产品的灵魂
-
产品经理的三层境界
- 产品帮助我们
- 产品与我们互相帮助
- 我们帮助产品
-
价值观
价值观是与个人对周围客观事物的意义、重要性的总评价和总看法
价值观体系是对诸事物的看法和评价在心目中的主次、轻重的排列次序
-
企业的价值观是企业决策者对企业性质、目标、经营方式的取向做出的选择，是员工所接受的共同观念，是长期积淀的产物。
- 企业做事的基本指导原则
-
战略
-
取决于
-
使命
- 为什么存在，要做什么事情
-
愿景
- 希望成为什么
-
-
表现于
- 团队文化
- 价值观
-
培养大局观
可行性分析三部曲（产品战略的具体制定）
-
我们在哪儿
-
市场扫描
针对整个行业
-
PEST分析机会与威胁
- 政治法律环境
- 经济人口环境
- 社会文化环境
- 技术环境
-
竞品分析
-
￥APPEALS分析法
- 通常作为指导方阵
-
实战做法
- 上网搜
- 看行业分析报告
- 请咨询公司
-
-
自我剖析
-
SWOT分析
- 优势劣势机会威胁
-
-
-
我们去哪儿
-
宏观用户需求
- 细分市场
-
-
我们怎么去
- 产品预研
做吧，准备出发
-
敢问路在何方
-
产品路标规划
- 是一个产品乃至产品线层面上长期的时间规划，路标规划上最小的单位，可能是产品的一个版本或相关的一个重大活动，细化之后都要通过好几个项目来实现。
-
-
低头走路，抬头看天
-
正式会议
开会和做一个产品是一样的，不要试图在一个会议中解决很多问题
-
会议前做好准备工作，不要漏人不要叫闲人
- 大会决定小事，小会决定大事
提前1-3天告知关键人物，会钱确定其是否能到会
做好会议记录
战略会议
-
KPI，KPI，KPI
-
SMART原则
- 具体
- 可度量
- 可实现
- 实性
- 有时限
权衡多个目标
第6章 产品经理的自我修养
爱生活，才会爱产品
- 充满动力
有理想，就不会变咸鱼
-
目标明确
- 做事应内驱不是外驱
- 成功在自己手中
- 建设个人品牌
会思考，活到老学到老
-
方法得当
-
学校里没教的东西
- 教知识不教思维
- 教解题不教选题
- 教努力不教取巧
- 教受教不教施教
-
能沟通，在什么山头唱什么歌
-
团结前进
充分沟通是不存在的
沟通不是为了说服，而是为了更好的认识世界
-
职场中的点对点沟通
-
IM
- 成本最低，不紧急不重要
-
电话
- 成本始终，紧急不重要
-
面谈
- 成本最高，紧急且重要
-
email
- 成本适中，重要不紧急
-
-
职场中的群体沟通
- IM群
- 电话会议或视频会议
- 会议
- 群体邮件
附录：它山之石可以攻玉
产品经理的主要职责
- 市场调研
- 产品定义与设计
- 项目管理
- 产品宣介
- 产品市场推广
- 产品生命周期管理
产品经理的核心技能
- 沟通能力
- 无授权领导能力
- 学习能力
- 商业敏感度
- 热爱产品
- 注重细节，追求完美
- 日常产品管理能力
XMind: ZEN - Trial Version
