人人都是产品经理
2020-02-16 11:13:06 0 举报AI智能生成
登录查看完整内容
人人都是产品经理 思维导图
作者其他创作
大纲/内容
产品经理
第四章 我的产品，我的团队
4.1 大产品，大设计，大团队
4.1.1 产品之大
时间之大：产品生命周期
空间之大
商业：主要由市场，销售，服务部门考虑，他们决定了产品的销售渠道，价格策略，促销策略，服务方式等
产品：产品设计，用户体验，产品运营等部门负责，他们决定产品功能范围，交互流程，视觉表现，运营手段等
技术：主要由开发，测试，运维部门考虑，他们决定了产品的稳定性，性能，Bug数量等
4.1.2 设计之大
产品设计的五个层次
战略层
商业目标：目标赚的钱越多越好
用户需求：用户则想花的钱越少越好，找准价值切入点
范围层
确定内容范围：先做好需求的采集，分析，筛选，管理，开发工作
信息：先“尽可能多的收集”，再“尽可能多的放弃”
防止遗漏任何“有价值的”需求
结构层
信息架构&交互设计：产品各部分之间是什么关系
框架层
界面设计：软件产品：用户真正能看到的东西
导航设计：网站：用户真正能看到的东西
信息设计：界面设计和导航设计都是信息设计
表现层
视觉设计：配色，字体，字号等
我用五个层次来写书
第一轮 搭建框架：以“章”为单位精确到最细的一级目录的，本书是四级，我会在每个目录标题下至少写两三句话说明这一段的主要内容与核心观点，保证章节的整体思路畅通。
第二轮 填充文字：把两年多来积累的文字切入符合主题小节里，补写缺少的内容。这一轮尽量不考虑文字细节，先把想说的都说出来，保证码字的速度。随着实践的进行，我发现这一轮不用动脑子，所以充分利用比较零散的时间完成。
第三轮 理顺逻辑：按顺序通读文章，重点关注段落，句子间逻辑的顺畅。这一轮主要的工作是调整段落，句子的位置，剪过来切过去；增加过渡句；删除废话等。我在这里会耗费极大的精力，经常把一句话反复在几段文字中倒腾。
第四轮 调整风格:关注语言的味道一致，增加例子，对话等，找轻松活泼，聊天的感觉；增删改图表，比如把某些文字用图表表达；突出本书特色，将不出彩的内容简化，添加有特点内容。当然，我做这一步的时候，还是有些细节商未完成，比如有的图表需要重画，有的图是照片，需要补拍，或者有的例子觉得不好，先占个位置等有灵感之后再换掉。
第五轮 后期制作:完成四轮以后，才是初稿。我会先给编辑同学，听听意见，编辑也会把初稿发给前辈和同行评审，然后我会继续和编辑同学一起做从框架到细节的各种改造，大到整节的增删改，小到格式调整，图表调整，病句错别字等，以及很多我到出版后才能了解的事情。同步的，其他章节也开始从第一轮写起，并行请进。
设计的“实现与浪漫”
推荐Donald Norman大师（诺大师）的两本书《设计心理学》，《感情化设计》
诺大师把设计的目标分为三个层次
本能水平设计：纯生理的视觉冲击
行为水平设计：产品功能，与用户与产品交互层面的设计；
反思水平设计：诺大师思想的有一次升华，通过《感情化设计》一书，把纯心理需求也纳入了产品设计的考虑范围。
基础原则
反馈： 动作前的可预测，动作中的积极响应，动作后的可评估。
容错：一些貌似多余的强制性的设计，不可逆操作可以后悔，如：电脑USB接口的“防呆”设计
简化：充分利用用户已有的知识，利用心智模型，利用标准化
默念：我们是实现的设计师，不是浪漫的艺术家
4.1.3 团队之大
想当年，一个比一个猛(每个人都是全能战士)
从几个人到一家公司（产生了分工越来越细）
接口人存在的价值（部门与部门之间对接，一般会让相关部门比较资深的同学担任）
我身边的矩阵型组织
子主题
4.2 游走于商务与技术之间
4.2.1 心思缜密的规划师
从概念设计到信息架构
产出概念图应该是在需求采集之后，需求筛选之前，我们需要通过概念图来理清思路，找出到底应该“做什么”，并将这些打算做的需求整合为一个合理的系统
画概念图的两种方法：
一，在思维导图生画出概念图，整理用户需求，打上标记，把相关的需求连几条线
二，找个会议室，用马克笔在白板上画出自己对将来产品概念的想法，完全不要受拘束，然后大家一起讨论改进，这样手绘的概念图很酷，画完了拍下来，存到电脑上，有必要的话客园重新画成更漂亮的电子版。
概念设计是为内部而做的，为了团队沟通，便于大家对产品形成共识，所以，完成概念设计之后，才可以开始信息架构的工作
PD的出身及其优略势
PD团队的成员有做开发的，测试的，有做市场，销售的，团队组成也应该尽量丰富，这样可以优缺互补
4.2.2 激情四射的设计师
用户体验部门各种职责的细分
用户研究员：利用各种方法进行用户研究，给产品决策提供建议
交互设计师：负责人机交互界面，用户操作流程的设计
视觉设计师：简称“美工”，主要做视觉设计，即用户的第一眼看到的效果，如“配色”，“字体字号”
前端工程师：运用前端技术进行Web页面开发，实现产品体验的良好传达
产品新首页诞生记
当交互设计遇到敏捷开发
举个栗子：狙击手(求稳)和机枪手（求快）
交互设计与敏捷开发如果能够结合起来，就能以更少的成本交付用户满意的产品
信息展现设计的例子
数据表格化
突出重点信息
数据可视化
”字不如表，表不如图“
聊聊细节，文案设计
设计师是一群追求完美的人，文案问题分为三个级别：
低级阶段：错别字，病句，错误标点
比如：“登录”写成“登陆”
中级阶段：用词不统一，不准确
比如：“创建”与“新建”，其实结果都是一个意思--New，用哪个本无所谓，但是在同一产品中不统一的话，会给人不专业额感觉
高级阶段：语言风格不统一，产品气质不统一
比如：开发工程师的专业和前台的感情丰富
4.2.3 “阴险狡诈”的运营师
产品与运营的战与和
个人博客运营实例
史玉柱《脑白金推广计划》
《产品经理值得听的13个培训》
《产品经理值得看的16个博客》
《产品经理值得交的10个朋友》
《产品经理值得读的12本书》
一次无意识的“事件+病毒营销”
李开复老师来到浙大演讲，喝到用洗脚盘泡的咖啡，李开复老师发现真相后幽默的发了微博，李开复的微博当时排名很高，我的微博也得到意外的流量
4.3 商务团队，冲锋陷阵
4.3.1 好产品还需要市场化
定价与促销
销售与渠道
另一种产品版本细分策略
开阔视野的水平营销
4.3.2 我们还能做什么
治标的运营活动
治本的用户研究
算出来的服务策略
4.4 技术团队，坚强后盾
外行眼中的技术分工
QA：理性，冷静，挑剔，完美主义
有这样两种工程师
技术痴迷者
实用主义者
稳字当头
如何与工程师合作
按流程执行
沟通：说服对方
提高自我修养
4.5 容易被遗忘的角落
我们最关键的--公司高层，老板
最好的资源：老板
不要怕老板，或者仇视老板，而要把老板当作最好的资源，”利用“他们促成自己不断成长。
当老板主动给找你问事情的时候就是他开始担心的时候
主动找老板汇报工作，三个阶段:
让老板做问答题：什么资料都没有给老板，老板会是很累的
让老板做选择提：自己先收集背景资料，然后选出几种可行的解决方案
让老板做判断题：每次呈上自己的方案以后，又会加上自己的选择，我觉得方案最好，因为。。。。
默默奉献着的团队
法务团队
使用协议怎么写，付费协议怎么写，敏感词等等
申请软件著作权，商标，专利等
财务团队
钱如何在用户，经销商，厂商之间流转
退款如何处理等
行政与IT
后勤团队
4.6 大家好才是真的好
4.6.1 所谓团队文化
团队文化 的三五事
4.6.2 虚无的无授权领导
管理 VS 领导
管理更像科学，领导更像艺术
管理靠的是权力，领导靠的是魅力
管理者强调稳定，领导者喜欢冒险
管理者依法治人，领导者以德服人
管理的对象是行为，领导的对象是思维
管理管正确的做事，领导管做正确的事
管理是一步一个脚印，领导是不走寻常路
管理者注重短期目标，领导者注重长期发展
管理者是职业经理人，领导者是企业家和创业者
管理是汽车的制动系统，领导是汽车的驱动系统
管理是告诉团队怎么做，领导是告诉团队为什么做
管理对人的影响由外而内，领导给人的力量由内而外
管理让团队能完成这些事，领导让团队喜欢做这些事
产品经理因该是管理者么
产品经理必须是一个好的领导者，那么，为什么不给我们一个管理职位呢？
从优略势的对比中寻找现象背后的本质
优势在于
管理岗位利于拥有话语权
管理岗位利于获取信息
管理岗位利于争取资源
劣势在于
管理岗位有很多行政工作，这些工作会占据产品经理大量的时间
管理岗位会让人脱离群众
如何让团队更开心
《赠送礼物和激励员工的艺术》
大中之效不如小中之大
比如：送一条1000快的围巾效果好于送一件1200快的衣服
有用的不如无用的
最好的礼物应该是吃不掉，用不掉，送不掉，也扔不掉的东西
如：有纪念意义的水晶奖杯
需要的不如想要的
舍不得买或者想买却不好意思买的东西（如：5星级酒店1000快一顿的高档餐卷）
有选择不如无选择
最好不要让接受奖励的人自己选择，不然的话他会有”我放弃了另一种选择的感觉，患得患失反而不开心“经典反例：奖励团队”海南游“或者每人”现金2000元“
小奖不如没奖
晚说不如早说
在期待的过程中，让员工的快乐最大化，从而增强奖励的效果；
让朋友在期待的 过程中提前享受到礼物所带来的欢愉
一次送不如两次送
如果你打算给别人两件礼物的话，那么最好分两次给，因为快乐也是边际效用递减的
好消息分两次说，坏消息要一起说
大的好消息与小的坏消息一起说，小的好消息与大的坏消息分开说
公开不如不公开
工资体系最好还是不公开的好
涨工资不如发奖金
涨工资不如发奖金给员工带来的快乐大
同时，发奖金有比较大的回旋余地
跟着我，有肉吃
想要”我的产品好“，就要对”我的团队好“
没事多与同事聊天
主题：魔方计划项目团队活动
第五章 别让灵魂跟不上脚步
5.1 触及产品的灵魂
以价值观为根基
价值观是评价社会成员用来评价行为，食物，以及从各种可能的目标中选择自己的合意目标准则
价值观是指一个人对周围事物的意义，重要性的总评价和总看法
战略是怎么练成
价值观（Value）
阿里巴巴的价值观：
客户第一
团队合作
拥抱变化
诚信
激情
敬业
使命（Mission），我们为什么而存在，要做什么
愿景（Vision），我们希望成为什么
培养大局观
经常与高手讨论
更广阔的视野看待问题
跳出手段直接考虑目的
例如：非目标用户，也许是一个新的市场机会
5.2 可行性分析三部曲
5.2.1 我们在哪儿
“我们在哪里”是应该最先考虑的，但是很容易被忽悠，我们习惯于一开始就定目标，但是在不知道现在在哪儿的情况下，定的目的地其实都是非理性的
从市场扫描开始
方法：PEST分析
政治法律环境（Political Factors）
国际关系
政治干预
方针政策
政治局势
国体以政体
经济人口环境（Economic Factors）
宏观经济政策
经济基础结构
国家经济形势
经济发展水平
城市化程度
存储与信贷
消费结构
收入水平
人口变化
社会文化环境（Social Factors）
风俗习惯
审美观念
宗教信仰
价值观念
语言文字
教育水平
真实的竞争对手分析
“小的成功靠朋友，大的成功靠对手”
上网搜，狂搜与要做的东西相似的产品
看行业报告
深刻的自我剖析
针对公司有什么行业积累，技术积累，有哪些缺点，不足等，想清楚“这件事为什么是我们来做”
常用的分析方法：SWOT分析
优势（Strength）:有激情，不在乎薪水
劣势（Weakness）:没经验，短期内做不出贡献
机会（Opportunity）:重视人才贮备的公司越来越多
威胁（Threats）:大多数情况下，公司更喜欢能直接上岗的员工
5.2.2 我们去哪儿
明确了“我们在哪儿”这个起点之后，下一步就要考虑“我们去哪儿”，目的地在哪里？
宏观上的用户需求
说的是某一个目标用户群体面临的问题是什么，并不涉及具体的产品或功能，也可以视为在选择细分市场和目标用户
物流平台的案例
涉及四大利益相关方：
政府：想要数据，特别是监控特殊行业，如危险品运输；
我们：想搭个平台，终极目标是将物流全部信息化
工商企业：是“物流”这个商品的需求
物流企业：是产业链的核心
物流
5.2.3 我们怎么去
用什么产品满足需求？产品的核心竞争力是什么？
一次真实的产品预研
收集，整理，理解各种信息
包括产品用户，公司本身(自己的产品，对方的产品)，整个市场(竞争对手)
5.3 做吧，准备出发
5.3.1 敢问路在何方
产品路标规划
一切尽在掌握
大事清楚，小事糊涂
例如：写文章要”酿“几个月
5.3.2 低头走路，抬头看天
我们急需靠谱的会议
正式的会议
每个参与者最好带着问题参加
会议记录，如果想不出什么值得记录的，就反过来想这个会议是否有必要开了
会议记录模板
仰望战略会议
高层定向，中层分解，基层执行
围绕13个问题可以分为四个部分
第一部分
1. 上次会议讨论的重点问题是什么？
2. 关于这些问题我们达成了那些一致意见？
3. 上次会议中那些问题由于缺乏信息考证，具有不确定性因素等原因而未能解决？
4. 上次会议那些执行计划通过了？对于这些执行计划我们有哪些主要设想？
第二部分
5. 自上次讨论会后外部发生了那些主要变化？
6. 自上次讨论会议后采取了哪些重要行动？以及这些执行战略和财政产生的影响？
7. 上次会议后我们收集了一些参考信息，根据这些信息考虑是否要对初设想的执行计划做出调整？
第三部分
8. 我们今天讨论的重点是什么？
9. 你们提议的执行计划是什么？最初设想和决定的理由？
10. 我们怎样实现这些设想和确定减少潜在的不确定因素？
11. 今天要讨论和做出的决定是什么？
第四部分
12. 从上一轮的战略回顾中我们学到什么？怎样在下一轮中学到更多？
13. 怎样改进战略回顾会议和会议进行方式？
5.4 KPI，KPI，KPI！
KPI
KPI，即Key Performance Indicators，关键业绩指标它是在分解企业战略目标的基础上，分析并建立各子目标与主要业务的联系之后提出的。
KPI是企业目标的具体表现，所以不一定是常见的营收，利润，用户数，也可以是酷虎投诉率，员工满意度，社会贡献等。
SMART，并不smart
S 代表具体（Specific）指绩效考核要切中特定的工作指标，不能笼统
M 代表可度量（Measurable）指绩效指标是数理化或者行为化的，验证这些绩效指标的数据或信息是可以获得的
A 代表可实现（Attainable）指绩效指标在付出努力的情况下可以实现，避免设立过高或过低的目标
R代表实现性（Realistic）指绩效指标是实实在在的，可以证明和观察
T 代表有时限（Time bound）注重完成绩效指标的特定期限
多个目标间的权衡
产品设计
用户体验
商业利益
短期目标
长期目标
达摩克利斯之剑
用户数，活跃度
用户数，使用率，活跃度
5.5 本书的源头活水
第六章 产品经理的自我修养
6.1 爱生活，才会爱产品
一个人只有拥有积极、乐观、向上的人生态度，内心才会有爱，才会去积极发现生活中的每，才会有好奇心和创造力，才会愿意研究生活中的产品，才会爱上做产品这样一件改变世界的事情
我总是跟门过不去
这个门是斜着的、、、
又如：旅游景点，进来顺畅，出口故意设计了很多弯弯绕绕，两边都是商店、、、、
乱谈餐馆的菜单
菜单没特色
菜单可以针对特定人群细分
也可以针对特定时间细分
用户创意无限
MSN不停上线下线，电脑右下角会不断浮出你的签名
Windows系统的使用习惯
6.2 有理想，就不会变咸鱼
成功在自己手中
个人品牌建设
个人名片设计实例
用户需求：通过个人名片展现个人特色，具体为3点
真实感：公司名片把人符号化，而个人名片通过爱好、经历、专长，展现出有血有肉的人
亲切感：公司名片隔阂商务场合把对方当客户，而个人名片把对方当朋友
专业感：由名片做介质，推导出“我设计产品很靠谱”
正面：我是谁，在哪儿做什么，怎么联系
反面：标签云（Tag Cloud）是设计理念的几种体现，大中小三级字号，突出轻松的关键字，兴趣爱好，因为给名片的人都是初次相识，方便迅速找到话题，同时标签云的设计不失“业内人士”的味道
我的理想之路
6.3 会思考，活到老学到老
学校历没教的东西
第一 教知识不教思维
第二 教解题不教选题
第三 教努力不教取巧
第四 教受教不教施教
只有方法，没有答案
文档、流程、工具、软件、组织架构等都是支撑，核心的还是产品，要满足哪个市场，那些人，要做什么，怎么做，这些东西想清楚了，支撑的东西自然会浮出水面
好好学习，天天向上
6.4 能沟通，在什么山头唱什么歌
我的沟通理念
理论上严格意义的“充分沟通”是不存在的
沟通不是为了说服，而是为了更好的认识世界
职场中的点对点沟通
IM：成本最低，适合不紧急不重要沟通
电话：成本适中，适合紧急不重要的沟通
面谈：成本最高，适合紧急且重要的沟通
E-mail：成本适中，适合重要不紧急的沟通
职场中的全体沟通
IM群：适合时效性强，但并不是很重要的信息传达
电话会议或视频会议：合适参与人比较难凑齐到一起的场景
会议：最常见的群体沟通方式
群体邮件：适用与比较重要但不紧急的事件，可以留下文字证据如：日报、发布通知
“土老板”破冰必杀技
找出对方感兴趣的、熟悉的、擅长的、自己也懂一点的话题，从而成功破冰
如：老板用笔记本、屋里摆的奖杯、数码设备，各类专业运动器材等
他们必然各不相同，我们也必须“在什么山头唱什么歌”
6.5 产品经理主义
好电影是怎么做出来的
产品经理看“春晚”
无可救药的职业病
解决问题的通用思路
计划一次旅行，用思维导图
开一个网店要做哪些事，用流程图
举办一场婚礼，用甘特图
修改这本书里的图片，用列表
人人都是产品经理
虽然不是每个人都能以产品经理为业，但在我看来，产品经理是一类人，他的做事思路与方法可以解决很多实际的生活问题，只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动一批人，将这个任务完成，并持续不断的以主人翁的心态去跟踪，维护这个产物，那么你就是产品经理。至少，以你已经是自己的产品经理
附录：它山之石，可以攻玉
别人眼中的产品经理
产品经理的主要职责
1. 市场调研
2. 产品定义及设计
3. 项目管理
4. 产品宣传
5. 产品市场推广
6.产品生命周期管理
产品经理的核心技能
1. 沟通能力
2. 无授权领导能力
3. 学习能力
4. 商业敏感度
5. 热爱产品
6.注重细节，追求完美
7. 日常产品管理能力
各种有用的信息
一些值得看的博客
UCDChina：“以用户为中心的设计”圣地，国内的交互设计师、用户体验师基本都在里面
人月神话：主要是项目管理、CMMI、PMP、产品管理相关的内容
刘未鹏IMind Hacks：高质量，思维方法的分享在业内超级有名
褪墨：教你如何做时间管理
左岸读书：各种各样的知识
一些值得读的图书
产品
《产品经理实战手册》
《产品经理的第一本书》
《产品经理的第二本书》
市场营销
《水平营销》
《市场营销》
《用户体验的要素》
用户研究
《赢在用户》
《一目了然》
《点石成金》
《胜于言传》
设计的实现与浪漫
《设计心理学》
《感情化设计》
交互设计
《软件观念革命：交互设计精髓》
《交互设计之路》
《GUI设计禁忌》
《可用性工程》
企业管理类
《公司进化论》
《跨越鸿沟》
全书就说一张图，把复杂的道理说简单
《罗伯特议事规则》
开会的规则
项目管理
《软件工程》
逻辑思维能力
UML相关的书，推荐《UML基础、案例与实践》
敏捷方法
《敏捷估计与规划》
《敏捷迭代开发：管理者指南》
其他
科学修养，思维方法，心理学类：《决策与判断》、《学会提问-批判性思维指南》、《黑天鹅》、《美第奇效应》、《社会性动物》、《统计数字会撒谎》
人文历史：《中国历代政治得失》、《激荡三十年》、《常识》、《大败局》
新经济系列：《长尾理论》、《世界是平的》、《维基经济学》、《未来是湿的》、《众包》、《轻公司》
精神力量：《影响力》、《把时间当作朋友》、《当下的力量》、《少有人走的路》、《遇见未知的自己》
https://www.douban.com/
一些值得听的培训
必须★★★★★：《成功的产品经理》
需求相关★★★★：《需求工程》、《需求管理》
《项目管理》★★★★
《流程管理》★★★
营销相关★★★：《网络营销》、《市场营销》
思维方法相关★★★：《问题分析与解决》、《六顶思考帽》、《结构化思维》
软技巧相关★★：《高效沟通》
第一章\t写给-1 到3 岁的产品经理
1.1 为什么要做产品经理
1.2 我们到底是不是产品经理
产品经理概念的进化
第一，行业形态不同：成熟行业VS.新兴行业。
第二，产品形态与成本结构不同：实物VS.虚拟物品。
第三，生命周期不同：几年VS.几个月。
第四，盈利模式不同，单一卖产品赚钱VS.多元盈利。
第五，用户心态不同：花钱买VS.免费用。
1.3 我真的想做，怎么入行
先在本职工作上找到与产品有关的事情做一些尝试，并且考虑先从产品经理周边的职位做起
1.4 一个产品经理的-1到3岁
第二章\t一个需求的奋斗史
2.1 从用户中来到用户中去
2.2 需求采集的大生产运动
定性地说：用户访谈
第一，“说”和“做”不一致的问题
第二，样本少，以偏概全的问题。
第三，用户过于强势，把我们往沟里带。
第四，我们过于强势，把用户往沟里带。
定量地说：调查问卷
第一，样本的偏差，即样本与想了解的目标用户群体出现偏差。
第二，样本过少的问题。
第三，问卷内容的细节问题。
定性地做：可用性测试
第一，如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了。
第二，总觉得可用性测试很专业，所以干脆不做。
第三，明确是测试产品，而不是测试用户。
第四，测试过程中，组织者该做的和不该做的。
定量地做：数据分析
第一，过于学术，沉迷于“科学研究”。
第二，虽然数据不会主动骗人，但我们经常无意或有意地误读数据。
第三，平时不烧香，临时抱佛脚。
需求采集
现场调查
AB 测试
日记研究
卡片分类法
自己提需求
2.3 听用户的但不要照着做
2.3.1 明确我们存在的价值
一个是用户需求，一个是产品需求。而这中间的转化过程，就是这节的主题——需求分析。
用户需求：用户自以为的需求，并且经常表达为用户的解决方案。
产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。
需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程。
伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西
创造需求：产品设计的最高境界
2.3.2 给需求做一次DNA 检测
把用户需求转化为产品需求
确定需求的基本属性
编号 需求的顺序号，唯一性标识
提交人(*) 需求的录入PD，负责解释需求
提交时间 需求的录入时间，辅助信息
模块(*) 根据产品的模块划分
名称(*) 用简洁的短语描述需求
描述(*) 需求描述：无歧义、完整性、一致性、可测试等
提出者 即需求的原始提出者，有疑惑时便于追溯
提出时间 原始需求的获得时间，辅助信息
Bug 编号 将一些Bug 视为需求，统一管理
需求种类
分类： \t新增功能、功能改进、体验提升、Bug 修复、内部需求等
层次：\t基础、扩展（期望需求）、增值（兴奋需求）
分析需求的商业价值
重要性： 重要程度，辅助确定商业价值
紧急度： 紧急程度，辅助确定商业价值
持续时间： 持续时间，辅助确定商业价值
商业价值(*)： 商业优先级，不考虑实现难度，群体决策
初评需求的实现难度
开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的人来评估，通常是技术经理，或者系统分析师、架构师
性价比啊性价比
性价比 = 商业价值÷实现难度（简化为开发量）
2.4 活下来的永远是少数
2.4.1 永远忘不掉的那场战争
第一，“需求打包”最好打包类似的功能点。
第二，需求依赖，功能互相之间有依赖关系。
第三，需求的粒度大小问题
战场：产品会议
武器：商业需求文档
BRD 怎么写，都包含哪些内容
项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。
商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字化，提出这个项目的商业目标。
功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。
非功能需求描述：提一下重要的非功能需求，如果有的话。
资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。
风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。
2.4.2 别灰心，少做就是多做
情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。
最爽就是“四两拨千斤”
尽可能多地放弃
第三章\t项目的坎坷一生
3.1 从产品到项目
做产品VS做项目
第一，从生命周期的角度来看
做产品：生命周期较长，关注整个产品的规划-制造-维护-到最后的消亡
做项目：有特定的目标，有明确的开始时间和结束时间，通过验收表示项目周期结束
第二，从具体要做的事情来看
做产品：过程需要不断的探索和判断、创新
做项目：有明确的目标，更注重计划和控制
第三、从产出物的角度来看
产品：有通用性，可以批量生产供大量用户使用
项目：个性化定制，只进行一次
产品经理VS项目经理
产品经理：靠想。产品经理是做正确的事，所做的产品是否符合市场的需要，是否给公司带来利润对产品经理来说，重要的的判断力和创造力
项目经理：靠做。项目经理需要把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标对项目经理来说，重要的是执行力和控制力
为什么让产品经理管项目
产品经理，需要增加功能或者特性来满足用户需要求
项目经理，需要尽量少的改动，以在既定的时间内完成项目进度
3.2 一切从Kick Off开始
团队建设
项目计划
典型项目周期在2周到一个月，大点的项目不超过三四个月
沟通
项目晨会、项目日报、评审会、项目变更申请、发布预告及公告
不可或缺的誓师大会
OK通常在15分钟左右的时间，15分钟内表达一下几点信息：
项目背景：我们在哪里？说过去，我们在项目之前的“悲惨境地”，明确为什么要做这个项目，以让听众为终极目标痛下决心
项目意义、目标和目的：我们要去哪里？说将来，做项目之前的美好前景，解决什么问题就算成功了，让听众为终极目标“面带桃花”
需求、功能点描述：我怎么去？说现在，我们用什么方法促使“过去”到“将来”的转变
项目组织框架：目的是让项目成员相互认识，明确有什么事应找谁。关键人物都要到场，必要时老板们也要多多参与
项目计划：第一，项目的时间点和里程碑第二，各个项目阶段所需的物质资源和人力资源
沟通计划：在项目开始就先预约好，免得过多的麻烦
任何时候都要心中有“树”
做项目无非是“多快好省”：范围大、时间短、品质高、资源省，我们要做到这4点的平衡，所以任何时候心中都要有这棵树
3.3 关键的青春又见需求
3.3.1 真的要写很多文档
BRD：商业需求文档。这是产品生命周期中最早的文档，其内容涉及市场分析、销售策略、盈利预测等，通常是给大老板们演示的PPT，也就比较短小精炼，没有产品细节，有点像创业者给投资人看的商业计划，主要为了获得认可，争取资源。
MRD：市场需要文档。获取老板们的支持后，产品进入实施阶段，需要写出MRD，要有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需要分哪几块，功能的优先级等等。实际工作中，PD在这个阶段常见的产出物有产品的Featuer List、业务逻辑图等，这是从商业目标到技术实现的关键转化文档。
PRD：产品需要文档。产品功能的进一步细化，是PD新人写的最多的文档，也就是“需求开发”的过程。文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体描述。
FSD：产品详细说明。产品界面、业务逻辑
学一点UML：类图、用例图、状态图。
类图：描述系统中出现的各个对象之间的关系，以及和外部系统的关系，这是对业务领域的描述
用例图：描述各个用例之间的关系
状态图：表达系统里实体的状态转换
用例文档，UC
再学点时序图、活动图、协作图等
Demo也要我们做吗
产品demo也成为产品原型、演示版
demo最好由用户体验部门主导，简称UE部门，做这个事的人也许叫用户体验师、视觉设计师、交互设计师，也可以叫美工
3.3.2 需求活在项目中
需求评审、设计评审、测试评审
3.4 成才 一步一个脚印
开发阶段，旁观者说（开发阶段包括设计、设计评审、编码、单元测试）
测试阶段，大家一起上（测试阶段包括TC编写、TC评审、冒烟测试、功能评审、测试）
Bug眼中的项目
项目发布
发布评审-预发布-发布-线上验证
以始为终、项目小结
写一封E-mail“项目发布公告”，项目的种种艰辛，感谢参数者的努力，可以放上最新产品的图片、海报等
怕什么来什么，只能拥抱变化
3.5 山寨级项目管理
3.5.1文档只是手段
建立自己的文档规范
PD 常用的文档模板
需求规范类：
PD做什么：这是对产品和团队的PD工作内容的一份总结，可以让新人快速了解自己的工作职责
用户体验规范：
交互规范
视觉规范
文案规范
需求管理类：
用户调研：用户调研前，中，后都要做什么
产品需求列表（含管理流程）
产品信息架构
流程管理类：
日常发布流程
变更事件流程
项目管理类：
项目管理制度
项目任务书
BRD
Kick OFF前面有写到
项目组织结构
项目WBS(进度)
项目日报周报
项目发布预告和公告
日常工作类：
会议记录
个人日报周报
模块作用知多少
多人协作和版本管理
玩转Office
Word：做结构稍复杂的文档
Excel：写结构文档很好用
PowerPoint（PPT）：尽量减少文字，最好只有图片的超大的数字
Visio：绝大多数的图都能画
OutLook：邮件工具，当邮件多时才能真正发挥作用
Project：复杂项目 任务 资源 关系计划安排
Access：当作简单的数据库管理工具（在数据达到Excel打不开的时候很管用）
3.5.2流程也只是手段
概念：启动阶段
方案：立项
开发：控制过程
验证：测试
发布：生命周期管理
维护
3.5.3敏捷更是手段
有计划，更要拥抱变化
迭代周期内尽量不增加任务
集中工作，小步快跑
晨会 每人只能说3个问题：
昨天做了什么？
今天要做什么？
碰到了什么问题，打算如何解决，需要什么帮助？
持续细化需求，强调测试
不断发布，尽早交付
项目中的敏捷沟通
外包团队的敏捷尝试
进度不好控制
即使沟通
遵循少即是多原则
3.6 物竞天择 适者生存
3.6.1 亲历过的特色项目
如何做好“老板项目”
复习一下：做项目通常要在保证质量的前提下，在事件要求T，人财物花费R，项目范围Q三点上做平衡
老板项目通常“T”已经定死
T 是给死的。可以试着商量一下，通常每一级领导都会给自己留一小段时间做缓冲，我们做项目的是时候也要给自己留一段，这些都是最后救命用的
Q是可变的。
R是丰富的。
密码行动，封闭开发
好处：交流方便，参与者更投入，没有外人打扰
缺点：环境差，容易让人疲倦，压抑
开发外包？项目外包？
3.6.2 一路坎坷，你我同行
三边六拍
三边
边计划
边行动
边修改
六拍
拍脑门（决策）
拍肩膀（信任）
拍胸脯（承诺）
拍桌子（骂娘）
拍屁股（走人）
拍大腿（后悔）
几个项目的成败
大多数的软件项目都是失败的，80%以上的项目都是不成功的，1.超过预算或者延期，2.未完成，3.缺少功能，
问题出现越早，越早调整，损失越少
一次只有七天的战斗
1 项目进展汇报
2 项目进展汇报
3 项目进展汇报
4 项目进展汇报
“项目的坎坷一生”详图
0 条评论
回复 删除
下一页
