- 第 1 章写给-1 到 3 岁的产品经理
- 1.1 为什么偠做产品经理
- 1.2 我们到底是不是产品经理
- 入行之前，我是学生物嘚
- 入行头半年打杂的菜鸟
- 入行半年后，学习“怎么做”
- 入行一年开始问“做不做，做多少
- 入行三年小结：战略与修养
- 第 2 章一个需求的奮斗史
- 2.1.2 你真的了解用户吗
- 2.2 需求采集的大生产运动
- 2.2.1 定性地说：用户访谈
- 用户访谈的常见问题与对策
- 第┅“说”和“做”不一致的问题。
- 第二样本少，以偏概全的问题
- 第三，用户过于强势把我们往沟里带。
- 第四我们过于强势，把鼡户往沟里带
- 2.2.2 定量地说：调查问卷
- 调查问卷的常见问题与对策
- 第一，样本的偏差即样本与想了解的目标用户群体出现偏差。
- 第三问卷内容的细节问题。
- 2.2.3 定性地做：可用性测试
- 可用性测试的常见问题与对策
- 第一如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了
- 第二，总觉得可用性测试很专业所以干脆不做。
- 第三明确是测试产品，而不是测试用户
- 第四测试过程中，组织者该做的和不该做的
1】SNS全称 Social Networking Services，即社会性网络服务专指旨在帮助人们建立社会性网络的互联网应用服务。
苐 1 章写给-1 到 3 岁的产品经理
1.1 为什么要做产品经理
坏产品：无处不在的危险
好产品：从垃圾桶到洗手间
1.2 我们到底是不是产品经理
产品就是用来解决某个问题的东西
全世界的第一位产品经理
20 世纪二三十年代，宝洁第一次提出了产品经理的概念当时宝洁推出了一种佳美牌（Camay）香皂，但销售业绩较差名叫麦古利的年轻人在一次会议上提出：如果公司的销售经理把精力同时集中于 camay 香皂和 Ivory（宝洁的一种老牌香皂）那麼 Camay
的潜力就永远得不到充分发掘。幸运的麦古利赢得了宝洁高层的支持之后，每一个宝洁品牌都当做一个独立的事业在经营有专门的產品人员、销售人员给予支持，与其他品牌同时竞争
而麦古利就成了全世界的第一位产品经理负责 Camay：香皂的品牌建设、市场销售等几乎所有的事情，他的成功表现使宝洁认识到产品管理的巨大作用之后，宝洁便以“产品管理体系”重组公司体系这种管理形式为宝洁赢嘚了巨大的成功，也导致后来大部分消费性商品业者纷纷沿用和抄袭
传统意义的产品经理： 规规划产品的生命周期，负责产品的上市策畧、定价策略、整合营销策略、销售与分销策略等....总体感觉它们都偏重于讲述一个产品已经做好以后应该怎样管理，怎样营销偏重于市场、商业端，这类产品经理也可以叫做“品牌经理”或“产品市场经理”
第一，行业形态不同：成熟行业 VS.新兴行业
第二产品形态与荿本结构不同：实物 VS.虚拟物品。
第三生命周期不同：几年 VS.几个月。
第四贏利模式不同，单一卖产品赚钱 VS.多元贏利
第五，用户心态不哃：花钱买 VS.免费用
1.3 我真的想做，怎么入行
做产品的大前提是要喜欢做产品
想入行就要首先明确自己现在的位置,得充分利用已有的知识結构、资源，找到一条最近的入行之路
先在本职工作上找到与产品有关的事情做一些尝试，并且考虑先从产品经理周边的职位做起好在產品经理的职责范围什么都涉及这种事情总是能找到的。
比如你是做开发的那就经常要参与需求评审，不妨比别人多用点功每次都預先了解需求，多多思考然后在评审会上对需求提出自己的合理建议，时间长了大家都会觉得你很有想法做产品也许不错。关于职位可以从“需求分析师”切入，这有些像系统分析的工作比如业务逻辑、流程图，都是你已经很熟悉的可以在这个过程中慢慢培养商業的感觉，重点体会某个产品功能是为了满足商业上的什么需求而做的
又如做网站运营的人，有时候会要专门做些活动的页面通常是紦需求提给用户体验部门的同事，这样的事情其实就是在做一个小产品了你可以改变原来用 Word 随便写几句要求，甚至口述沟通的方式而昰把这个活动当做一个产品来做，自己练习写一下 BRD
PRD1?虽然这些文档对于一个小活动作用不大，但这个过程可以帮助自己在以后碰到更复雜的产品时心里会有点底。所以原来职责偏商业的同学可以先做“运营专员”，对已有的产品做一些推广策划类的工作增强自己对產品的理解，做一段时间后相信就能提出自己对产品改进的想法了。
而项目经理也比较好切入我工作过的团队就有很多同事是从项目經理直接转过来做产品经理的，因为多数的产品经理也要带项目所以找个项目经理来也算先得个便宜，不过也正如第 3.1 节里“产品经理 VS.项目经理”说到的这种转行有其特定的优勢和劣势
做过上面的这些事情后，至少面试的时候可以多点谈资最后给大家介绍一个很简单的辦法一一研究几十家公司的产品经理招聘广告。我一直觉得把研究结果做成一份漂亮的调研报告而后去应聘产品经理是个很靠谱的事，洏且我相信大家多半都很想读这样的一份报告
入行之前，我是学生物的
入行头半年打杂的菜鸟
入行半年后，学习“怎么做”
入行一年开始问“做不做，做多少
入行三年小结：战略与修养
业余时间自己的产品，一个网站一门课程。
第 2 章一个需求的奋斗史
发现一个间題然后设法将其转化为个任务来解决”。
2.1 从用户中来到用户中去
2.1.1 用户是需求之源
人类生活在地球上为什么会有各种各样的需求？那是洇为生活中存在太多的问题从而产生了不满意，而问题就是“理想与现实的差距”那么人类会很自然地产生“减少甚至消除这个差距”的愿望，这就产生了需求
一个很经典的例子，小明说“我需要买一个电钻”
大毛问：“为什么？”“我想在墙上打一个洞”“为什么？”
“我想把一幅画挂在墙上”“为什么？”
“因为这面墙显得太空旷了看着不舒服。”“为什么”
“因为太空旷就没有家的感党，不够温馨”“为什么？”“你烦不烦啊……”
“好吧这个电钻其实是你对马斯洛的需求层次理论中第二层“安全”和第三层“社会交往”的需要。你想让家里看起来更温馨从而产生安全感和归属感。
通过小明的故事我们发现，研究需求可以增强对用户的理解而理解用户，是产品经理最重要的素质之一
小结一下，需求的本质就是“问题”问题的本质就是“理想与现实的差距”。
用户是 User囿时也叫做终端用户，End User是使用产品的人；而客户是 Customer y 是购买产品的人、为产品付钱的人。
所以说优先满足哪些用户需要和产品的商业目標要结合起来考虑，简单说就是看KPI是什么值得注意的是，不要把 KPI 狭义地理解成一些数字可以把它想象成一种综合的指标，也可以包含愙户的满意、员工的开心等既然我们的产品目标是用户数、活跃用户数。
2.1.2 你真的了解用户吗
想了解用户光靠空想是不行的，他们是真實的是五花八门的，必须得真刀真枪地去研究他们
试着描述一下自己在用各种互联网应用的时候，是个什么样的用户
《贏在用户：Web 囚物角色创建和应用实践指南》
定性研究可以找出原因，偏向于了解；而定量研究可以发现现象偏向于证实。
第一轮听用户定性地说，确定产品方向做什么？随机抽样 40 个用户做访谈据此写出需求列表。
第二轮听用户定量地说，确定需求优先级先做什么投放了 20 万份调査问卷，确定了需求优先级的排序
第三轮，看用户定性地做要先做的那几个需求，应该怎么做一边设计，一边陆续找了 10 个用户來验证做可用性测试
第四轮，看用户定量地做根据产品的用户使用情况做数据分析，不断改进产品
当然，这是一个比较重要的产品所以在用户研究上投入了较多的时间与人力，更多的时候我们会视情况采取简化的方案。
2.2 需求采集的大生产运动
明确目标、选择采集方法、制定采集计划、执行采集、资料整理然后进入下一步的需求分析阶段。
2.2.1 定性地说：用户访谈
用户访谈的常见问题与对策
第一“說”和“做”不一致的问题。
第二样本少，以偏概全的问题
对于这个问题，我常用的几个对策如下首先，我们应该尽量识别出各种鈳能引起偏差的因素并在访谈的报告里标明，让读者了解然后，为了用尽可能少的样本得到尽可能正确的结论我会以增量的方式做訪谈。举个例子我会先访谈 5 个用户，得出基本结论然后再访谈 5
个，观察结论是否有改变如果有改变，就继续加大样本量或者思考問题是否合适？样本集是否合适如果没有改变，就停止继续访谈节省成本。
样本的选取其实属于概率与数理统计的范畴，想深入的哃学可以自行研究
第三，用户过于强势把我们往沟里带。
要解决这个问题需要时刻牢记访谈的目的。如果发现话题不对就赶紧往囸道上扳，若发现多次都扳不过来就可以考虑尽快结束了，用户很多不要在一个不合适的对象上花费太多时间。当然有时候用户侃嘚十分精彩，如果你不是很忙的话听听长长见识也可以，这个就自行把握吧
第四，我们过于强势把用户往沟里带。
这个问题的对策同样是牢记访谈的目的，并且管好自己的嘴
《软件观念革命：交互设计精髓》
-
避免一组固定的问题：固定的问题会让被访者产生被审問的感觉，我们应该准备好问题清单但清单只起一个引导作用，并不用照着读
-
首先关注目标，任务其次：比用户行为更重要的是行为褙后的原因多问问用户为什么这么做。
- 避免让用户成为设计师：听用户说但不要照着做，用户的解决方案通常短浅、片面
- 避免讨论技术：特别是碰到一些略懂技术的用户，不要与其纠缠产品的实现方式
-
鼓励讲故事：故事是最好的帮助设计师理解用户的方法
- 避免诱导性的问题：典型的诱导问题是“如果有××功能，你会使用吗？”一般来说用户会给出毫无意义的肯定答复
用户大会，是邀请产品的用戶到某一集中地点开会人数一般在几十人到几百人不等可以短时间内从多人处收集大量信息，是一种特别的用户访谈形式我在 2007 年 6 月组織过次阿里软件网店版的用户交流会。这种会耗费资源较多一般机会不多，所以要充分利用
会前最重要的是明确这次用户大会的目的囷意义，这在争取资源的时候会更有说服力比如：产品二期卖点确认，辅助运营决策；三期需求收集；现有产品用户体验改进等
时间：日期、几点、时长。要考虑淘宝卖家的空闲日子和时间段另外注意要把整个活动各项准备的时间点掐准，留余量
地点：场地、宣传鼡品、T 设备、礼物、食品饮料、桌椅。
工作人员：大家一起上人人有事做，分组分工注意产品、运营、开发人员的搭配，要有冗余
用戶：确定目标用户、数据提取、预约要充分考虑人数弹性；
嘉宾：相关老板、合作部门的同事，不管来不来邀请要发到。
材料：用户數据、产品介绍材料（测试环境确保当时可用静态 Demo 备用）、可用性测试材料。
各项备用方案的准备用户大会前两天开一次“确认会
辅助工作：场地布置（轻松一点，不要像开会) ; 引 导/拍照/服务/机动;进场签到(给礼品）；全程主持（进度控 制）；送客/收拾残局
产品介绍：重點是卖点介绍，与用户互动观察用户更关注哪些功能，辅助上线前的运营决策到底主推哪些卖点；
抽取部分用户做焦点小组 15) 的讨论，收集后续的需求产品三期开始启动；
同时抽取部分用户做可用性测试，帮助产品二期做最后的微调；
资料整理：卖点总结报告、需求收集报告、可用性测试报告
运营：本次活动在淘宝论坛发帖；内部邮件。
整个活动资料的整理归档,包括照片、各项材料/报告信息、用户数據等
一个三四小时的会，我们好几个人前后忙了有半个月从计划制定、资源申请、各种材料准备，到当天执行、之后的分析整理…不過这些辛苦都有了回报在短短几个小时内从三四十位用户那里获得了很多有价值的信息，比如确定了产品二期主推的 3 个卖点；明确了产品三期优先级最高的几个需求；与这些用户成为朋友将来可以作为产品的种子用户 161 等。这些都为今后的产品发展提供了指导
2.2.2 定量地说：调查问卷
调査问卷和用户访谈的提纲是有区别的：用户访谈的提纲通常是开放式问题，适用于我们心里还比较疑惑的时候去寻找产品的方向适合与较少的访谈对象进行深入的交流，而调査问卷通常封闭式问题比较多适合大用户量的信息收集，但不够深入一般只能获嘚某些明确问题的答案，调査问卷不是考试卷不适合安排问答题。用户访谈与调査问卷之间也有联系我们经常通过前者的开放式问题，为后者收集具体的封闭式问题
无论是网上还是线下，作答时间最好不要超过 10 分钟否则很多人看一眼就被吓跑了。开篇一般放一些简單的不需要思考的问题；很想知道的内容需要思考的，较敏感的问题般放在中间；而有关被访者个人信息的题目般放在问卷的最后以免应答者在回答这些问题时有所顾忌，进而影响其他答案
调查问卷的常见问题与对策
调査问卷一人一份，独立作答可消除“焦点小组”、“论坛发帖征集需求”等具有群体讨论性质的方法的弊端。这是因为用户有其特点——沉默与骑墙的总是大多数
《长尾理论》里说箌“沉默的大多数”，那么站出来的总是很少数而且往往是非典型的用户，不能保证其代表了目标用户的想法而
“骑墙的大多数”说嘚是，大多数人是没有明确观点的尤其在网络这样一个不用负责任的环境下，所以常见的情况就是开始表态的那几个人的观点引导了群體的观点随机的初始值决定了结果，这个时候你只有单独和跟风者交流才会发现他根本不是那么想的。
调査问卷的客观性、多份问卷の间的独立性可以有效避免上述问题，但其容易出现的问题在于
第一样本的偏差，即样本与想了解的目标用户群体出现偏差
之前我們谈到，用户访谈由于样本量的限制始终只能听到目标用户群体中很少部分用户的声音，而调査问卷可以更多地采样我们应该充分利鼡。所以调査问卷的样本选择，就有几个注意点: 尽可能覆盖目标群体中各种类型的用户比如性别、年龄段、行业收入等，要保证各种類型用户的样本比例接近全体的比例比如目标用户中男女比例为 7:3 那么我们的样本也应该保持这个比例。
但在实际工作中经常会因为各種原因没法做到样本选择的合理性，比如我们的产品全国销售但要做街头的拦截调査，出于成本考虑只能选择特定城市的目标用户；叒如利用网络做调査问卷，能在特定时间、特定页面上看到问卷的人已经是一种筛选；再如在各种场景下，愿意填写问卷的人也许与目标群体的整体也有不同，又是一种筛选
所以，在类似情况下得出结论的时候大家最好把这些潜在的筛选条件标明，让报告的读者知噵数据获得的方法与来源同时如果我们是报告的读者，也要一直带着问号去阅读里面的数据
还有一个小技巧，就是可以把目标群体的特征也定义成一系列问题放入问卷中，待我们回收问卷以后就可以通过这些问题评估作答者是否能代表目标群体了。如果发现了偏差我们也可以从回收的问卷中再筛选出一个接近目标群体的子集来分析。
样本量过少时采用百分比来分析是没有意义的。这是很多新人會犯的错误比如只问了 5 个人，3 个人选 A就在报告中说有 60%的用户选 A，这是很不严谨的因为如果换 5 个人再做一次，很可能就是 40%了而这样嘚数字百分比要具备稳定性才有价值。所以此时只能说“问了 5 个用户，有 3 个用户选
A”抛开严谨的统计理论不谈，要给出百分比答案的話至少得有大约 100 份的答案。
第三问卷内容的细节问题。
首先问题表述应无引导性，这点和用户访谈类似比如，不要问“你喜欢某個产品吗”这时用户可能会考虑到提问者的情感而回答“是”，正确的问法是“你是否喜欢某个产品”
答案的顺序，可能产生“顺序偏差”或“位置偏差”即被调査者选择的答案可能与该答案的排列位置有关。有研究表明对陈述性选项被调査者趋向于选第一个或最後一个答案，特别是第一个答案；而对一组数字如价格和打分，则趋向于取中间位置为了减少顺序偏差，可以准备几种形式的问卷烸种形式的问卷选项排列的顺序都不同。
因此对于重要的问卷，为了避免上述问题还有个通用的办法就是先进行小范围的试答，根据反馈修改后再大面积投放，这和互联网产品的灰度发布有着同样的理念
给大家举一个实例我为这本书的读后反馈设计了一份调査问卷，有兴趣的读者可以做下
问卷目的：收集本书的读者反馈总结得失，希望以后能做得更好
样本对象：本书读者，扩大到博客读者以及對产品经理感兴趣的人
调査渠道：网络，个人博客上发布
时间计划：本书上市后放出问卷，收集至少 3 个月后给出一份分析报告
问卷內容：不断优化，你真正看到的可能与下面有区别
同学你好，我是《人人都是产品经理》的作者苏杰这个问卷是为了…，作答大约需偠 2 分钟完全匿名，非常感谢
首先，是一些简单的问题帮助我对作答者进行分类。
你看过《人人都是产品经理》这本书吗单选
你看過 iamsujiep 的产品设计”这个博客吗？单选
你是怎么知道这个问卷的单选
通过书，通过博客其他网上渠道，其他线下渠道
然后是一些我最想知道的问题。
还是学生1 年以内，1 到 2 年3 到 5 年，6 到 10 年11 年及以上
你是几岁的产品经理？单选
产品经理其他产品相关（如需求分析、用户體验、交互设计、运营），商业相关（如市场、销售、服务）技术相关如开发、测试、架构、运维），各种管理岗位其他
互联网，软件其他 T 类，其他你的公司规模单选
10 人以下10 到 100 人，100 到 1000 人1000 人以上你工作中接触最多的主题？多选
用户需求，项目文档，流程战略，修养职场，其他
你希望我多说些什么主题多选
用户，需求项目，文档流程，战略修养，职场其他
你觉得我的优势在于？多選
用户需求，项目文档，流程战略，修养职场，其他
你觉得我的劣势在于多选
用户，需求项目，文档流程，战略修养，職场其他
接着，想了解一些你的情况
北京，上海杭州，深圳广州，其他
最后还有什么想说的？
2.2.3 定性地做：可用性测试
可用性测試是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题通常只能做少数几个用户的测试，看他们怎么做属于典型嘚定性研究。
它是 UGC理念的一种很漂亮的实践在目的明确的前提下，简单介绍一下主要过程
UGC: User Generated Content，用户产生内容UGC 其实并不是新概念，传统荇业的宜家（IKEA）早在 50 年前就有所行动让终端用户参与到产品的设计的各个环节中。
首先要招募测试用户招募测试用户的主要原则是，這些用户要能尽可能地代表将来真实的用户比如说，如果产品的主要用户是新手那么就应当选择一些对产品不熟悉的用户
然后是准备測试任务，测试的组织者在测试前需要准备好一系列要求用户完成的任务这些任务应当是一些实际使用中的典型任务
接下来的重头戏是測试过程。可用性测试的基本过程就是用户通过使用产品来完成所要求的任务同时组织者在一旁观察用户操作的全过程，并把发现的问題记录下来
测试结束后：组织者可以询问用户对于产品整体的主观看法或感觉另外，如果用户在测试的过程中没有完全把思考的过程说絀来此时也可以询问他们当时的想法，询问他们为什么做出那些操作
最后是研究和分析：在可用性测试结東之后组织者分析记录并产絀一份产品的可用性问题列表，并对问题的严重程度进行分级使得我们可以根据项目进度来选择哪些优先处理。
可用性测试的常见问题與对策
第一如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了
其实，可用性测试在产品的各个阶段都可以做在尚无任何成型的产品时，可以拿竟争对手的产品给用户做；在产品只有纸面原型的时候可以拿着手绘的产品，加上纸笔給用户做；在产品只有页面 Demo 的时候可以拿 Demo 给用户做；更多的时候，在产品已经可以运行以后可以拿真实的产品给用户做。不同阶段不哃做法从中都能发现相应的问题。
第二总觉得可用性测试很专业，所以干脆不做
可用性测试，听着很专业但收益又无法量化，所鉯对很多老板来说不太愿意在这个上面投入资源，经常因为项目时间过紧被略过我们知道，可用性测试通常来说做 5 个左右的用户オ可鉯发现大部分的共性问题前前后后的准备也耗时不少，但只做一个用户并且简化步骤，也比不做要好
对一个内部使用的用户管理平囼，我自己尝试过一次最轻量级的可用性测试表现为：一个同事，半个小时在我的座位上，简单的几个任务比如“将 XXX 用户的有效期增加年”，“将 YY 公司的状态设置为冻结”“査询 ZZZ 公司的员工数”等。结果发现了十几个问题效率很高。
第三明确是测试产品，而不昰测试用户
可用性测试要邀请用户来做测试人员我们在开始之前，应当明确地告诉用户这个测试的目的是发现软件产品中的问题，而鈈是要测试用户是否有能力来很好地使用软件
第四，测试过程中组织者该做的和不该做的。
刚开始的时候可以告知用户大概持续的時间，要做哪些事情让用户心中有数，轻松愉快地完成任务
可用性测试中，我们可以要求用户在使用产品的过程中采用一种名为“发聲思维”的方法即在使用产品的同时说出自己的思考过程，比如为了完成某个任务用户想先做什么，后做什么为什么要做某个动作等。
做测试的过程中千万不要有任何的引导与暗示而只是观察和记录....
结束之后，如有可能应该送个小礼品当然在邀请的时候就要告诉鼡户会有一些对他付出时间的补偿。尽快总结并且发给用户方面让用户感到他做了一件有意义的事，另一方面也是表示感谢建立长期囷谐的“用户参与产品设计”的氛围。最重要的这份总结要用于指导产品改进，这才是可用性测试的根本目的
改版在客观上会挑战用户現有的习惯所以必须慎之又慎。可用性测试就是一种很合适的方法来保证产品改版的安全性。
对于改版除了“可用性测试”要在足夠早的时候做以外，发布后也是有些方法改进的
比如先从部分次级页面改起，像“我的淘宝”历时多年的改版
再如新旧版本并存一段时間并允许用户自由选择，比如 2007 年的雅虎邮箱和新浪邮箱改版；
三如小面积试验选择一小批测试用户放出新版本，监测效果做用户调研，比如 Gmail 在发布某些新功能的时候；
四如傍上一个用户已经习惯的风格比如网店版的前身“高级店铺”升级到网店版 1.0 的时侯，讨论了很哆方案最终还是决定模仿“我的淘宝”的页面风格。
总之对于改版，对于升级我们要把“暴力革命”变成温柔和诺谐的“和平演变”。
2.2.4 定量地做：数据分析
...数据来说话看看用户到底是怎么做的，不论是考察目标用户全体、还是采样都完全可控，所谓“According to the data'是最难被驳倒的
数据分析时，根据不同的目的数据来源多种多样，常见的有用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等数据分析的方法，最简单的可以用
Excel复杂一点的可以用一些统计软件、数据库软件，或者直接自己写程序解决而最关键的就是對结果的解读，通常数据分析只能发现些现象和问题并不能了解原因，所以分析完成后通常会伴随着一些用户访谈听听用户怎么解释。
数据分析的常见问题与对策
第一过于学术，沉迷于科学研究”....实际生产环境就更注重综合的性价比了，所以我们日常的数据分析方法也就显得不那么严谨了我特指小步快跑的创业团队，他们可能不需要在每次分析前都去验证样本群体是否符合某种统计分布也可能鈈需要用人工神经网络”等“高科技手段”去预测产品将来的用户数，甚至给出“A>
B”的结论时也用不着做“显著性检验”一切的一切需偠的只是一种感觉种对数据的敏感，对商业的敏感
第二虽然数据不会主动骗人，但我们经常无意或有意地误读数据.无意地误读数据举個例子，对一个人群人们的身高用平均数来衡量是有意义的，因为我们知道身高属于典型的正态分布中间多两边少，所以一个平均值僦能了解群体的大致情况而对人们的收入，就不能用平均值来衡量了一个超级富豪和 1000 个零收入的人平均，很可能得出人均收入 100
万的荒謬结论这个问题的对策，是学习统计学的知识 努力提高自己的水平。
主动地误读数据是比较有趣的现象。在提取数据之前我们心Φ通常已经有一些结论了，无非是想验证它而抱着这点思想，就总能找到数据来证明自己已有的想法并且技术越娴熟的人越容易做到這点。对于这点我想一个简单的对策就是对数据保持中立的态度,尽量不要“为了迎合一个观点而去找数据”，减少利益牵扯比如为了證明老板的判断，或者为了保持自己之前拍脑袋的英明形象等你明白我的意思。
第三平时不烧香，临时抱佛脚这是一个很实际的问題，我们经常在做决策的时候才想起数据分析但忽然发现手头没有数据可分析。一次又一次地发生同样的情况…为了避免我们应该在產品设计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等这也算一种典型的非功能需求，这样做对产品的可持续发展非常必要
下面举个小例子，看看数据分析是如何转化为商业价值的整体的思路是：在对产品足够熟悉的基础上，先做出方向性的假设再提取相应的数据并分析，得到一些现象最好是之前没发现的现象，然后尝试解释接下来做用户调研修正解释，最终指导产品发展方向
案例：通过分析用户登陆日志，看到两个群体不同的登陆行为进行初步判断假设，然后进行用户研究证明假设，得出结论然后对相应的部分呢进行优化，提升真实的用户活跃度
2.2.5 需求采集人人有责
之前所述的各种方法，都是直接从鼡户那里得到需求我称之为一手需求，就像“生孩子”其实很多时侯，我们还会接受二手需求比如老板说要给用户做个××功能、销售人员说用户哪里用起来不顺等，这些需求和一手需求比起来就像“养孩子”。
有很多同学从一开始工作接触的就是已经存在的老产品需求始终堆积如山，如果碰上销售强势的产品那更是连响应销售提过来的需求都来不及，也许做了半年一年突然回想，发现自己连嫃正的用户都从来没接触过而是始终在满足销售的需求。个人感觉这种二手需求，或多或少有扭曲以销售为例，他们的考核指标决萣了会比较注重眼前希望产品的卖点越多越好，而之后用户用得如何就不那么关心了。比如我就经历过一些让人很抓狂的二手需求銷售希望产品增加一个功能这个功能在说服客户购买产品时有“临门脚”的作用；而用户买完以后，最好又别用这个功能以免增加服务蔀门的压力…所以在公司层面上看，我觉得产品部门至少应该和销售、服务等部门有平等的地位坚持不懈地从终端用户那里直接获得需求，才能保证产品的可持续发展
但二手需求毕竟是常态，我们经常接到的就是口头上的几句话或者一封邮件的几行说明，这中间理解嘚偏差只能靠我们主动的、反复的沟通来弥补那么有没有什么办法解决呢？下面我就介绍一种简单的二手需求采集工具一单项需求卡片
单项需求卡片的理念就是：产品的需求工作不只是需求分析人员的事，而是涉及产品的每个千系人的义务至少得参与“采集”的过程，理想的状态是产品的所有干系人都参加过“需求采集”的培训然后在日常工作中养成主动提交需求给产品人员的习惯，但实际很难做箌所以作为专业的需求分析人员，就应该尽量降低同事们比如销售、服务、技术人员提交需求的成本，也是节省我们自己的时间
一張单项需求卡片描述了一个用户的需求到底包含哪些内容，重点是描述用户场景谁在什么时间、地点产生了何种需求，先看一个模板洳表 2-3 所示。
实际情况的变化： 人们用它来提意见没写全等等。
需求采集并不是产品设计之前的工作，而是一个贯穿始终的过程；它并鈈是产品人员的事情而是所有人的责任；它没有特定的方法，不管白猫黑猫抓到老鼠就是好猫；它并不怕发现什么荒谬的需求，而是怕遗漏合理的需求…这才是需求采集的大生产运动
现场调查。和客户一起工作一段时间深度了解需求。
AB 测试基于大用户量比较合适，
自己提需求用户自己提需求
2.3 听用户的但不要照着做
2.3.1 明确我们存在的价值
用户需求 VS.产品需求
用户需求：用户自以为的需求，并且经常表達为用户的解决方案
产品需求：经过我们的分析，找到的真实需求并且表达为产品的解决方案。
需求分析：从用户提出的需求出发找到用户内心真正的渴望，再转化为产品需求的过过程
改变现状：开发新产品 降低理想：“打预防针，丑话说在前头” 转移需求：转移紸意力
某写字楼可能是因为建造得比较早考虑不周，电梯明显不够用每天中午吃饭的时候总是很挤，最上面几层的小白领们平均要等 20 汾钟才能下到 3 楼的餐厅吃饭于是抱怨很多，他们给物业提意见要求解决。物业公司找到了大毛大毛帮他们分析了一下。
改变现状對现有产品做一些改进，在这个案例中就是增加电梯数目或者加快电梯运行速度，但成本太高直接被否定
降低理想。告诉楼里的小白領们隔壁那个写字楼中午要等 40 分钟呢。俗话说“不患寡而患不均”人们更在意的是相对而不是绝对，这样确实可以减少抱怨但是一種低水平的满足需求，对产品美誉度没有帮助
转移需求。电梯门上贴一些锻炼身体的公益广告当然内容是说爬楼有益身体健康。有效部分用户走楼梯去餐厅了，但是刚吃过饭怎么办爬几十层楼要得阑尾炎的。最后采用了个看起来很傻的方案，在电梯门旁边安装一媔镜子让等待的人们可以整理一下仪表，或者搔首弄姿一番不至于那么无聊。
产品设计的最高境界一创造需求！
苹果公司的乔布斯鈳以说是创造需求的大师，但我不建议大家学这是需要天赋的，但这份天赋非常值得保护产品的进化和生物的进化一样，需要如基因突变一般的胡思乱想而且，有不少人只看到了乔布斯的“不照着做”没有看到他之前“听用户的过程。
更实际的我认为需求分析的過程其实也有创造需求的成分，当一个新人真的能力不足的时候不妨先做用户提出的需求，而不要自己去胡乱分析用户需求而对于一個团队来说，要尽量避免只有能力不足的需求分析人员”这种情况出现
把用户需求转化为产品需求
值得一提的是，用户需求与产品需求昰多对多的关系我们可能用多个功能来满足一个用户需求，也可能用一个功能来满足多个用户需求甚至是用几个产品需求来满足几个鼡户需求，其中并没有一一对应的关系
表 24 需求的基本属性
KANO 模型以东京理工大学教授狩野纪昭（Noriaki Kano）的名字命名，是一种对顾客需求或者说對绩效指标的分类通常在满意度评价工作前期作为辅助研究模型，KANO 模型的目的是通过对顾客的不同需求进行区分处理帮助企业找出提高企业顾客满意度的切入点。【需求分类】
表 2-6 需求的商业价值
商业价值或者叫商业优先级，是对上述几种商业价值指标的综合评判这┅条是整个需求列表中最核心的部分，这里的判断直接影响着产品未来的方向有时候我们还在列表里增加一列“商业价值描述”，通俗點就是这个需求的卖点是什么可以给用户提供什么价值对公司又有什么帮助。
如此重要的商业价值评估我们的做法是在需求讨论会上甴产品团队集体讨论，再叫上有必要的干系人比如销售、服务等。对于某个需求需求提交人是对它最熟悉的，提交人先基于自己对商業目标的理解做一番陈述主观定个级别，比如高中低然后大家讨论，所以在这个讨论会之前每个人都应该做好功课。
...加“某关键人粅的打分”一列但绝大多数实际操作中，我们都是直接把商业价值抽象为一个指标用“高、中、低”，或者“5、4
21”来衡量而具体讨論的时候，大家充分表达意见之后安全的做法是谁官大谁负责，俗称老板拍脑袋最终由会场上级别最高的人报个数字结東，这就是现實也是一种高效的办法。我曾经考虑过群体打分取均值等方式可是实施起来成本太高，很难推动也不是很有必要。
绝对不能因为某個需求的商业价值很大就马上去做也不能因为另一个需求的商业价值不大就不做。
首先简化为人力成本即工作量，其他资源的消耗仳如额外的硬件成本，我们会发现只有极少数的需求会有这样的问题不具有普遍性，所以碰到的时候都做特例处理
其次，我们把工作量再简化为开发量我经历的项目，各类人力资源有：产品、开发测试、服务等但一般情况下，团队里产品人员资源相对富裕测试资源可以调配，服务资源可以临时补充所以开发资源经常成为瓶颈。于是我们一般评估每个需求的开发工程师工作量来表征其实现难度，这背后的道理是以团队里的瓶颈资源为评估基准如表 2-7 所示，大家视自己团队的情况灵活应用
开发量是非评估不可的，我把它叫做“初评”允许误差，并且会要经验丰富的人来评估通常是技术经理，或者系统分析师、架构师他们做出简单的评估，并且靠不断的实踐来反复修正评估者通常估计自己做这个需求要多少时间，然后乘以一个系数这个系数大于 1,
反映着相应技术团队的平均技术能力。这裏的评估一般用“人天”作为单位某个需求需要“1 人天”意味着需要 1 个人做 1 个工作日。
相对于“初评”在项目启动之后，制定项目开發计划的时候还会有一次更精确的评估那时候需求怎么做已经知道、由哪位开发工程师来做也知道，所以可以推算出相对准确的工期笁期和工作量是有很大区别的，比如生个小孩需要 1 个女人 10 个月的时间，工作量可以说 10 人月”但 10 个女人 1 个月的时间，同样“10
人月”是绝對完成不了这个任务的不管几个人，工期都只能是 10 个月…这个话题在第 3 章还有机会慢慢谈
绝对不能因为某个需求的实现难度很小就马仩去做，也不能因为另一个需求的实现难度大就不做
性价比=商业价值÷实现难度（简化为开发量）
但是工作中对“性价比”的判断还是會经常有偏差，很实际的一个原因是自己经常和哪类人接触。2007 年下半年的工作中由于一直和工程师直接接触，经常听到他们抱怨某个需求太麻烦之类的所以综合考虑时有点倾向于做实现难度小的；而如果经常和销售、运营的同学一起开会，就会倾向于更多的考虑商业價值这点与大家共勉，时刻注意
2.4 活下来的永远是少数
2.4.1 永远忘不掉的那场战争
准备出发：把需求打个包
做项目，终极目标就是：多快好渻 即范围大、时间短、品质高、资源省。
敏捷方法：....有比较固定的项目时间专业点叫“迭代周期”，一般是 24 周然后有一个人员相对凅定的团队，意味着项目资源确定此外任何时候都要保证项目品质，最后能变的只能是量——项目范围
第一，“需求打包”最好打包類似的功能点
第二，需求依赖功能互相之间有依赖关系。那些只能先做的功能应该在产品需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做在这里评估工作量的时候不会考虑“谁来做”的问题，在正式立项鉯后组建团队的时候会重点考虑，当然长期来说为了避免这类风险，提升与平衡团队成员的能力是王道
第三需求的粒度大小问题。商业价值很高的功能如果细分的话，我们会发现其中也有价值相对低的部分所以需求的粒度应该尽量细，前提是细化引起的管理成本仩升在可接受的范围内举个生活中的例子帮助大家理解：大开间办公区域里的灯，不可能用一个开关控制也不可能每一个开关只控制┅盏灯。具体细到多少要根据具体情况具体分析。我们的经验是在需求列表里出现的任意一行工作量最好不要超过“5
2.4.2 别灰心，少做就昰多做
最爽就是“四两拨千斤”
2.5 心急吃不了热豆腐
-
- 第 3 章项目的坎坷一生
- 第一从生命周期的角度来看。
- 第二从具体要做的事情来看
- 第三，从产出物的角度来看
- 产品经理 VS项目经理
- 为什么让产品经理管项目
- 3.3 关键的青春期，又见需求
- 3.3.1 真的要写很多文檔
- 学一点 UML：类图、用例图
- 再学一点 UML：时序图、活动图及其他
- Demo 也要我们做吗
- 3.4 成长一步一个脚印
- 怕什么来什么，只能拥抱变囮
第 3 章项目的坎坷一生
项目：只会进行一次，包含多项互相关联嘚任务并且有绩效、时间、成本和范围限制的项工作。
第一从生命周期的角度来看。
产品周期长项目周期短。
产品只有不断完善产品直到被新产品替代。
第二从具体要做的事情来看
产品更多探索，创新和沟通
第三从产出物的角度来看。
产品可批量或者提供给夶量用户使用。项目是一次性的
项目产出物经过改造，成为更通用的产品有的产品可以进行”个性化定制“（即做项目）【？】
你找裁缝做一件衣服会当面沟通清楚需求。对于裁缝来说是接了一个项目做完了与你一手交钱一手交货，项目结项；而如果这个裁缝是一位设计师他做的衣服被某服装厂看中，最终做成流向市场的上万件成衣这就是做产品了，上市之后还会根据市场反馈不断修改，直臸不再流行这就需要进行产品的生命周期管理。
2. 产品经理 VS项目经理
对产品经理来说最重要的是判断力与创造力，产品经理决定做不做、做什么、做法“我要把它实现！。他是产生一个想多少保证方向正确
对项目经理来说，最重要的是执行力与控制力项目经理决定怎么做、谁来做、何时做，保证方法得当他是接到一个任务，“我要押它完成！”
3. 为什么让产品经理管项目
Kick Offi 是足球比赛开球的意思
1. 帅謌美女，我们需要你
几点可以降低团队组建的难度
一是我们启动的项目都是经过产品会议，大老板们认可的所以基本的资源有保证，泹资源充足的情况就比较难得了；
二是经常合作的都是相对固定的人沟通也比较顺畅，所以说 PD 新人不太适合做项目经理通常要和团队混到脸熟以后再说，这可不单是个人能力问题
在项目的组织结构中，项目经理并不是结构中的顶端我会组织一个“项目督导委员会”，这很有必要成员一般是项目成员的老板，甚至老板的老板他们的任务也很简单“背黑锅”和“买单”，因为权力越大责任越大。當项目因为种种原因出现重大变更的时候比如成本、时间、需求等，我会向他们提出申请获得批准后才执行变更，这也是项目经理对洎己和项目成员的保护而在整个项目过程中，各种资源的提供也需要靠他们除了人，还有很实在的项目经费有可能的话都尽量多要┅点，最好有富余但也要尽量省着用。整个项目期间各种信息会随时知会督导委员会成员，但大多数情况老板们无须有什么动作所鉯他们也乐于参与。
PD负责这个项目的需求，他们中的某个可能兼任项目经理；开发经理及其团队负责开发相关的任务，其中开发经理需要负责开发的时间计划与任务分配并全程掌控设计、编码直至上线的过程；测试经理及其团队，负责测试相关的任务；UE（用户体验团隊）对于互联网、软件类产品来说，负责产品给用户的展现比如交互效果、视觉效果等；服务团队，负责产品帮助的编写以及上线後的服务工作等；如果项目牵涉了其他产品，我们还会设置各种职能的接口人以协同工作；更加复杂的情况还会有其他角色出现，......
2. 别忘叻最初的约定
我们日常的项目如果是基于网页的软件，典型的项目周期在两周到一个月；大点项目最多不超过三四个月。
最重要要的┅件事情就是：再次评估“工作量”并推算出“工期”
常用的方法是“三点估算法”，即评估出最乐观的工作量、最悲观的工作量、最鈳能的工作量然后按下面的公式估算出工作
“工作量=(最乐观+最悲观+最可能)/3”
或“工作量=（最乐观+最悲观+最可能×4) /6“
这里的工作量粒度也會比初评的时候细，至少精确到“1 人天”短期项目甚至是 1 人小时，按照经验我们的 “1 人天”通常等价于 56“人小时”，而并不是按照一忝工作 8 小时计算因为每个人都很难保证持续高效，并且不被其他事情打断一个没人打搅的日子，能有 5
个小时高效的工作就已经很不錯了。
比如某个开发任务只需要工程师甲做“2 人天”但它需要等工程师乙“5 人天”的任务完成后才能开始，那么这两个任务就没法并行工期也就是“7 工作日”而不是“5 工作日”
周期：以“日”或“周”为单位，主要取决于项目时间的长短及变化的频率
渠道：会议、邮件等需要在成本和效率之间取得平衡。
发起者：一般由项目经理、开发经理测试经理主导相应的沟通
参与者：发起者确定参与者，不要遺漏项目边缘的同事
不管选择何种沟通方式，目的都是相同的目考为了项目成功一般来说，常做的项目通用的沟通方法有如下几种，
项目晨会：自项目进入开发阶段至发布日止开发经理每日召集相关人员，主要是 PD、开发人员、测试人员参
项目日报：自 Kick Off 起至发布日止项目经理每日发给项目的所有干系人，测试开始后以测试日报为主
评审会：相应 PD 召集需求评审；相应开发人员召集设计评审；相应测試人员召集 TC?评审；产品可用之后项目经理尽快召集功能评审，项目所有干系人参与评估
项目变更申请：项目发生重大变更项目经理与項目督导委员会沟通后确认变更。
发布预告及公告：项目经理在项目发布前两个工作日发预告给项目所有干系人项目发布成功后发公告給所有干系人。
4. 不可或缺的誓师大会
项目背景项目意义、目的与目标，需求、功能点概述项目组织架构，项目计划沟通计划。
5. 任何時候都要心中有“树”
做项目的目标无非是多快好省：范围大、时间短、品质高、资源省
上面所说的目标对比经典的项目 TRQ 项目时间（Time）、项目资源（Resource）、项目质量（Quality），几乎样一点小区别就是 Q（质量），我觉得把 Q 解释为“Quality+ Quantity”（品质+数量）更准确
综合一下我们做项目的夲质就是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡
产品模块级项目的 WBS 模板
随着做的项目越来越多，你应該一边做项目一边形成自己的 WBS 模板，......在实际工作中通常没有这么清晰的步骤，一般都是边计划边行动边修改。
3.3 关键的青春期又见需求
3.3.1 真的要写很多文档
BRD Business Requirements Document，商业需求文档这是产品生命周期中最早的文档，其内容涉及市场分析、销售策略、贏利预测等通常是给大老板们演示的 PPT，比较短小精炼没有产品细节...主要为了获得认可，争取资源
MRD，Market Requirements Document ,市场需求文档产品进入实施阶段，需要有细致的市场和竞爭对手分析：可能通过哪些功能来实现商业目的功能，非功能需求分为哪几块功能的优先级等等。产出物是产品的Feature List, 业务逻辑图等等昰要实现从商业目标到技术实现的转化。
以上两个是写给老板看的
FSD： Functional Specifications Document, 功能详细说明。出现技术内容确定产品界面，业务逻辑比如表格中的数字怎么对齐。像“概要设计”同时，硬件系统的设计数据库设计，表结构设计等工作也开始了这些是架构师，系统分析师編写的
不同企业写的不一样，但关键是清楚写文档的目的说清楚哪些事情。
1. 产品需求文档PRD
一个项目中多个PRD， 每个PRD包括逻辑相关的若幹功能点
修订历史：写清楚每次修订的日期，版本号说明，作者
项目概述：项目背景，意义目的，目标等等没有整个项目的说奣，也应该有这部分的需求说明
功能范围：本PRD的业务逻辑图，讲述系统中角色职责与周围系统的关系，全局商业规则等等
非功能需求：性能需求，数据监控的需求等等【可能就是埋点】
2. 学一点 UML：类图、用例图
类图，Class Diagram , 描述系统中出现的各个对象之间的关系以及和外蔀系统的关系。以了解该系统是做哪方面事情的
State Diagram , 表达系统中实体的状态转换，贯穿多个用例
【类似用户旅程图，流程图】
UC需求人员寫给开发人员的基本文档。
早期需求人员是细化scenarios中的分析来产生需求的
后来逐渐归纳为用例法。
一个用例可以是产品需求列表中的一行也可以多个用例满足一个产品需求。
用例的唯一标识：我们拿 PRD 小明下馆子”中的“点菜”为例其中唯一标识记为“UC_ ordermeal，这项我们经常偷懶不写关系并不大
用例名称：就是“点菜”了，用一个短语讲清楚这个 UC 是做什么的一个 UC 写一个任务，任务的粒度可以自行把握比如哃样是“增加、删除、修改订单”，在新人、新业务的情况下就最好分为三个用例详细描述；如果是“老人”老业务，也许用一个“管悝订单”的用例描述就足够了
业务描述：商业目标、用户目的等业务内容，说明为什么要做这个 UC例如，小明工作一周辛苦了周末晚仩会去吃一顿好的犒劳ー下自己。
需求描述：产品需求需要实现哪些功能点，这个 UC 要做什么去餐厅，点几个菜之后等烧好了吃掉
行為者：该用例的 Actor，小明
前置条件：触发这个用例的前提是什么？周末小明有空去餐厅等。
后置条件：用例完成后续动作是什么 服务員接受订单，去厨房等
其他说明：任何其他信息，针对这个 UC 的特殊说明没有就空着
界面描述：通常互联网、软件产品中界面描述会占佷大的篇幅，给出截图界面上各种元素的说明，并且会和 Demo 关联起来当然还有一种做法是单独写界面文档，然后与 UC 文档互相引用不过尛明的例子中并没有界面描述。
业务规则：整个用例的通用规则比如限制条件小明不吃辣、小明预算只有 100 元等。而界面元素或流程中的私有规则不适合写在这里
流程描述分主干、分支和异常三种，描述在这个用例发生的过程中由什么事件触发，系统与用户之间产生何種交互步骤这里尽量用时序图和活动图来替代文字描述，具体的例子下一节给出
用例语言：无歧义，完整一致，可测试
5. 再学一点 UML：时序图、活动图及其他
时序图：Sequence Diagram，也叫顺序图描述事物变化在时间维度上的先后顺序，善于表达对象的交互比如多个页面之间、多個角色之间。如图 3-11 所示就是小明点菜过程中点菜者、服务员、厨师三个角色之间的交互。【流程图】
活动图：Activity Diagram比较接近我们常说的流程图，描述各种动作如何引起系统变化善于表达泳道较多、分支较多的情况。如图 3-12 所示描述了点菜过程中，点菜者与服务员两个泳道各自的动作引起的系统变化
协作图：Colaboration Diagram，表达不同对象之间是如何互相影响的
如果团队里其他成员都看不懂 UML 图，且学习成本太高那一萣不要强推 UML，寻找合适自己的工具吧描述需求的原则很简单：把要做的事情跟受众说清楚！
产品 Demo，也经常被说成是产品原型、演示版、Mockup
对于某个产品功能的用例是否包含界面的描述，每个团队有自己的做法好坏难以评估，这取决于产品的特点、团队的习惯等我的建議是不妨再次应用做产品的思路，去问问这些文档的用户即团队里的开发工程师、测试工程师，按照他们喜欢的方式写就好了
但用例裏最多只能放 Demo 的截图，所以如果要表现更多交互和视觉的细节Demo 是必须独立存在的。
然后是线框图ppt做。
然后是视觉效果axure，比较真实的
7. 概要设计与详细设计
第一，不以写的东西是需求还是设计区分职责而以“业务”或“技术”区分。比如上例在业务上需要对“公司洺称”的长度做何限制由 PD 确定，而“公司名称”的数据在数据库里如何存储由工程师决定。
第二细枝末节的设计经常重复，PD 应该和开發工程师一起协商渐渐沉淀出产品规范。比如上例通过几次协商，我们确定了以后产品中出现的各种字段的各种限制规范下次再写 UC 嘚时候，只要引用规范即可省去了很多重复劳动
3.3.2 需求活在项目中
写作→评审→修改→评审
我做过的项目中，最重要的三种角色就是 PD、开發人员、测试人员所以派生出三次评审一一需求评审、设计评审、测试评审，它们按照项目阶段依次为：
需求评审是 PRD 评审、UC 评审、Demo 评審的统称。于需求的相把 PRD 和 UC 说给开发、测试听 Demo 评审则由 UE 的同学主讲。
PRD 通过以后PD 们会和 UE 的同学一起细化 UC 和 Demo，而开发的同学也会同步进行┅些开发前的准备工作比如细化和修正项目计划，部分系统的设计等
设计评审是在概要设计与详细设计完成之后进行，由开发工程师紦对需求的理解以设计文档的形式说给 PD、测试听
测试评审，俗称 TC 评审是在 TC 编写完成，测试开始执行之前进行由测试工程师把对需求嘚理解以 TC 的形式说给 PD、开发听
每一种评审都可能有多轮，会上没问题就快速地通过有小问题当场确认，大问题带回去原则是“改动较哆的话必须再次评审，异议不大可以通过”
3.4 成长，一步一个脚印
1. 开发阶段旁观者说
2. 测试阶段，大家一起上
4. 那一夜项目发布
会安排专門的代码版本管理员，通常用 SVN, 所以又叫 SVN 管理员负责项目每日的代码更新。
SQL (20 已经经过 DBA 确认无问题DBA 确认后，邮件通知到测试人员抄送给某经理
搜索引擎通过相关人员确认无问题。
因技术或时间原因造成无法修改的 Bug由测试、需求、开发三方一起研究是否能接受，如果有争議上报上级主管。
测试过程中如果因为技术无法实现造成的需求改动，PD 需要第一时间发送邮件到全组让所有人都知道，同时修改相應的 UC
测试人员在确认完“发布标准”中的各项之后，会发出邮件通知同意发布发布人员在没有收到通知前，不能自行发布
测试人员茬发布后，将做一轮生产环境的回归测试测试完成后发出一封邮件通知“生产环境已验证完成，发布成功”只有收到该邮件后，发布楿关成员才能撤离现场
5. 以终为始，项目小结
6. 怕什么来什么只能拥抱变化
变更事件，是指项目范围内需求的变化....后较大的变化。我们會制订些流程做控制不是为了限制变更，而是为了让每次变更都经过深思熟虑最怕发生的情况就是需求方举棋不定，来回反复流程會要求提出变更的人先和相关方确认，获得一致认可后再修改文档、邮件说明、即时通信群里吼一声…而过大的变化或过晚的变化，比洳到了发布前一天还在修改业务逻辑项目经理有权决定是拒绝，还是上报更大的老板定夺
搭车事件，是指项目范围的扩展一般来说，5 个开发工作日以下的零散小需求不参与产品会议讨论所以搭车事件总是存在但我们要尽量搭顺风车，找内容相关的项目；尽量早搭车在“需求冻结之后一般不要再提；作为项目经理，也要把好关不能因为随意让别人搭车导致团队长期、高负荷加班，这是得不偿失的
緊急事件这也总是难免，所以一般由较高层的老板确认后自上而下的推动不受常规流程的限制，越是高层确认的紧急事件越可以突破常规限制优先处理。
3.5 山寨级项目管理
计划与控制就是项目管理.
项目管理中的几个关键问题，它们是：文档管理、流程管理、敏捷方法
PD 做什么：这是对产品和团队的 PD 工作内容的一份总结，可以让新人快速了解自己的工作职责
用户体验规范：又细分为如下几个部分，这蔀分最好让负责用户体验的同事编写
交互规范：页面上各种控件的规范，如列表的默认排序、列表翻页控件的样式等；各种判断规则的規范包括字段的校验规范、出错信息反馈的规范等
视觉规范：如页面大小、字体字号、颜色编码等。
文案规范：如语言风格、语法模板、常用操作的标准说法等最常见的问题是，一个产品中同时出现“新增”、“新建”、“创建”多种同义词
通用原则：待补充，大家鈳以看到这份文档也是需要不断优化的
用户调研：这份模板说明了典型的用户调研前、中、后都要做什么，调査问卷、用户访谈提纲怎麼设计有哪几块内容。
产品需求列表（含需求管理流程）产品需求列表的模板需求管理文档的模板，需求状态变化的流程图等
产品信息架构：待补充，用来描述产品的页面或功能之间的关系比如网站地图、导航结构等，可以和负责用户体验的同学一起制作
只列出叻小团队常用的。
项目管理制度：原则性的东西比如产品会议制度，项目经理、开发经理、测试经理的权责利这里沿用了公司统一的淛度。
项目任务书：网上有很多模板小项目可以灵活变通，用 BRD 代替
Kick Off 的 PPT：之前已经说过。项目组织结构：这个模板我每次填几个名字就鈳以了没啥技术含量。
项目 WBS（可生成进度）：我用的是个叫“WBS Chart Pro'的小软件画的 WBS 图可以直接生成 Project 文件，就是说项目计划也有
项目日报周报:主要有今日/本周要 闻、明日/下周看点、当前问题、所需支持、项目进展等几项在第 3.4 节的“以终为始，项目小结”中给大家分享的本书项目周报用的就是这个模板。
项目发布预告与公告：大量的重复内容模板化为了省时间而已。
会议记录：大家都很痛恨没结果的会议囿了这份文档，多少能逼着每次会议都产出些内容比如会议决议、遗留问题与行动方案等。在第 5.3.2 节的“我们急需靠谱的会议”里我还会單独分享会议”这个话题
个人日报周报：用于团队分享每个人的工作情况。
另外还有很多文档比如编码规范，包含些编写代码的规矩、函数命名规则等对开发工作非常重要，但 PD 使用不多也就不含在内。
[这份模板博客可以下载]
产生文档版本管理的本质需求是多人合作协同办公。
概念：启动阶段关注商业规划 DCP1
方案：立项，项目执行层面的非关键成员加入关注规格、计划，DCP2
发布：项目团队解散，荿立LMT老人带新人做生命周期管理。
生命周期维护：DCP4
当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情就可以用流程这种形式固化、传承，后人在做这些事的时候起码不会太无助在这点上，规范、模板的作用也类似这就是团队的核心競争力 。
3.6 物竞天择适者生存
3.6.1 亲历过的特色项目
老板项目就是指老板突然跟你说，我们要做个什么什么然后你只有执行份儿的项目。
复習ー下我们做项目通常要在保证品质的前提下，在时间要求 T 人财物花费 R、项目范围 Q 三点上做平衡
T 是给死的。因此制定时间计划的时候給自己留一段救命的时间用来应对变化。
Q 是可变的排出各种功能的建议优先级和所耗的资源，好让老板知道刀该往哪里挥
R 是丰富的。......我碰到这种情况就用“有良知的职业杀手”的思路：只要不违背自己的价值观就尽心尽力地完成任务，否则据理力争，如果争论失敗要么调整自己的价值观，要么放弃这份工作
任何一个项目开始的时候，合作的多方必须要明确合作模式、划分权责利
训就是：在職场中，做任何事情除前面已说的权责利的划分外，还要权责利对等有权力的人、或者被授权的人，可以享受事成的好处也要担负夨败的损失，千万不能只是因为你有能力做某事就把任务接下来这样对谁都不好。
3.6.2 一路坎坷你我同行
三边”指的是：边计划、边行动、边修改。
造成“三边行动”的根本原因是在目标未清、
职责未明的情况下就仓促开始往下做细节结果常会因为在一些小事上扯皮导致項目不断地延期，即使最后勉强完成了也与最初的目标相去甚
“六拍”拍的是：脑门、肩膀、胸脯、桌子屁股、大腿。
大多数的软件项目都是失败的实际上，约 80%以上的项目都是不成功的或者是因为超过预算或延期未完或缺失功能，或者几种因素都有其中，30%的软件项目执行得十分糟糕以至于在完成之前就被取消了并且，问题出现得越早越早调整各方面的规划，损失越小
，有些项目虽然按时、保質保量的发布在项目的意义上是成功了，但是在产品的意义上也可能是失败的
- 第 4 章我的产品，我的团队
- 4.1 大产品大设计，大团队
- 时间の大：产品生命周期
- 空间之大：商业、产品、技术
- 我用五个层次来写书设计的“现实与浪漫”
- 4.2 游走于商业与技术之间
- 4.2.1 心思缜密的规化师
- PD 的絀身及其优劣势
- 4.2.2 激情四射的设计师
- 当交互设计遇到敏捷开发
- 4.2.3“阴险狡诈”的运营师
- 一次无意识的“事件十病毒营销”
- 4.4 技术团队，坚强后盾
- 4.5 容易被遗忘的角落
- 4.6 大家好才是真的好
- 4.6.2 虚无的无授权领导
- 产品经理应该是管理者吗
第 4 章我的产品我的团队
产品团队组成： 产品，体验运营。
商业团队：市场销售，服务
技术团队： 开发（架构编码），测试运维（数据库，服务器软件配置）
支撑团队： 老板，法务财政，行政
4.1 大产品大设计，大团队
所有和产品有关的事嘟是产品经揮的事
时间之大：产品生命周期
创新者（innovators)新鲜感强消费能力强，但是忠诚度不高需要新鲜的东西不断刺激。这批人都有 Geek 气質乐于探索。
早期追随者（Early Adopters)观念比较新但是需求目的性很强需要迅速能够解决其问题的产品。
早期主流用户（Early Majority）：是产品大规模产生商业价值的用户群他们是典型的实用主义者，也是生活中最常见的一批人偶尔被动地听到过新产品，但觉得正在使用的老产品也能解決问题就不会更换，但心中还是对新产品存在期待希望有机会试一下
晚期主流用户（Late Majority）：这部分主流用户和早期的区别也许是心态上嘚。早期主流用户对新产品有尝试的愿望而晚期主流用户对新产品心存抵触。他们直到老产品已经渐渐地出现明显的劣势才会很不情願地使用新产品。
空间之大：商业、产品、技术
上述三方面任何一个公司必然有它的强项和弱项，它不可能也没有必要在这三方面都很強一是因为构建“性价比团队”的考虑，二是因为都强的话互相压不住反而造成内耗所以更重要的是找到自己公司、或团队、或产品嘚那个突出的刀尖，也就是所谓公司的 DNA
Google， 技术主导工程师具有绝对话语权。
Apple 产品主导，设计与艺术
阿里巴巴 商业强势。
因此找工莋的时候需要调查清楚自己的职位在公司里是不是最受重视的是不是强势方。
这很重要！举个不是很现实的例子如果你在特种部队式嘚组织里，那么可以安心地做一个特种兵；但如果你进了塔利班或基地组织那就抓紧时间进入管理层！
上海的地铁一号线是由德国人设計的，看上去并没有什么特别的地方直到中国设计师设计的二号线投入运营，オ发现其中有那么多的细节被二号线忽略了结果二号线運营成本远远高于一号线。
上海地处华东地势平均高出海平面就那么有限的一点点，一到夏天雨水经常会使一些建筑物受困。德国的設计师就注意到了这一细节所以地铁一号线的每一个室外出口都设计了三级合阶，要进入地铁口必须踏上三级合阶然后再往下进入地鐵站。就是这三级合阶在下雨天可以阻挡雨水倒灌，从而减轻地铁的防洪压力事实上，一号线内的那些防汛设施几乎从来没有动用过；而地铁二号就因为缺了这几级台阶曾在大雨天被淹，造成巨大的经济损失
德国设计师根据地形、地势，在每一个地铁出口处都设计叻一个转弯这样做不是增加出入口的麻烦吗？不是增加了施工成本吗当二号线地铁投入使用后，人们才发现这一转弯的奥秘其实道悝很简单，如果你家里开着空调同时又开着门窗，你一定会心疼你每月多付的电费想想看，一条地铁增加点转弯出口省下了多少电，每天又省下了多少运营成本
我用五个层次来写书设计的“现实与浪漫”
1. 想当年，一个比一个猛
2. 从几个人到一家公司
如何设计各种职位让各种人（职员）与各种事（职责）互相匹配
3. 接口人存在的价值
4. 我身边的矩阵型组织
4.2 游走于商业与技术之间
4.2.1 心思缜密的规化师
PD 的出身及其优劣势
4.2.2 激情四射的设计师
用户体验部门职责划分：
1. 产品新首页诞生记
潜在用户=访客数×转化率
2. 当交互设计遇到敏捷开发
......谈论敏捷开发的時候说，我们说要快先发布再说，慢慢改；而交互设计的理念是精雕细琢慢工出细活。我们在纠结大师们也纠结过
Cooper 大爷认为子弹很貴，因此在每次开枪之前一定要精确地瞄准负责瞄准的人应该是专业的交互设计师。Cooper 大爷很适合做个狙击手点射的命中率几乎能够达箌 100%。
Beck 大师认为有了敏捷开发子弹变得很便宜，不需要瞄太准打不准就再放一枪，没什么大不了最终总能打中目标。Beck 大师很适合做一個机枪手机枪是不可以点射的，一般都是扫一片用密集的火力消灭敌人。
3. 信息展现设计的例子
4. 聊聊细节文案设计
低级阶段：错别字，病句错误标点。
中级阶段：用词不统一不准确。
高级阶段：语言风格不统一产品气质不统一。
4.2.3“阴险狡诈”的运营师
如果说规划師是产品的父母把产品生出来；设计师是产品的老师把产品教育好；那么运营师就算是产品的老板吧，他们要把产品卖出去让产品从“叫好”到叫座”，让更多的人愿意使用产品
这两年，网络上很多流行的人物、事件后来都被披露是网络推手所为，他们策划、制造話题运用病毒营销、事件营销等方法，让某些人获益“幕后黑手”、“无商不奸”、“阴险狡诈”等词反映了他们不怎么好的口碑。鈈过如果大家只想这些词中的积极因素倒是正好很贴切地描述了产品运营师。
数字在增长流氓营销，但是用户没有留住
2009 年春节，行動前的策划
定下原则：不花钱，只花时间；用户“质”重于“量”所以不在意流量，绝对不会在无关的高流量场合做推广；第一轮运營以 1 个月为周期KPI
定为可以体现高质量用户数的“RSS 订阅数”，1 月底约 200,2 月底争取达到 500
人人都是产品经理”必须以内容为王要保证原创的数量和质量，这些是核心竞争力所以描述春节期间有趣的事情的两周主要是积累材料，将 MSN Space 上已有的文章转移到新博客并且做了一些推广活动的预研，考察了几个相关网站、特定版面的人气情况初步判断各个推广渠道的优先级
春节后的第一周先做试探性推广，主要考虑到還有一些目标受众没有开始上班没有进入状态，全面出击定在 2 月 9 日开始的那一周这是因为考虑到工作的第二周大家不会很忙同时新年噺气象，又都很有激情互相学习讨论的氛围较好。
具体的推广渠道如下：（略）
执行到 2 月底的时候我做了个小结。【但是是怎么推广嘚呢】
回顾了 2 月的第一轮运营，只看我最关注的订阅数：推广进行到 2 月 14 日的时候订阅数就达到了 500, 所以后两周我取消了推广计划，保持靜默做个无推广的对比，到月底订阅数自然增长到 670
然后，根据第一轮的经验我制订了 3 月份运营计划，也是第二轮大面积推广的计划希望订阅数达到1500
以一周为单位分成 4 小轮推广，以 4 篇《产品经理值得…》系列原创文章为主打说实话有点标题党，不过内容应该还是很實在的它们分别是
第一周，《产品经理值得听的 13 个培训》谈谈参加过的培训；
第二周《产品经理值得看的 16 个博客》谈谈经常看的博客
苐三周，《产品经理值得交的 10
