《人人都是产品经理》摘录（1-3章）
自序
1. 不是每个人都能以产品经理为业，但在我看来，产品经理是一类人，他的做事思路与方法可以解决很多实际的生活问题。只要你能够发现问题并描述清楚，转化为一个需求，进而转化为一个任务，争取到支持，发动起一批人，将这个任务完成，并持续不断以主人翁的心态去跟踪、维护这个产物，那么，你就是产品经理。至少，你已经是自己的产品经理，这才是“人人都是产品经理”的真谛。
写在正文之前
(无)
我与本书的局限性
1. 产品经理做的事情，不似技术那般严谨，很多偏“艺术”的思维方式、做事方法必然只在特定环境下才适用。
为什么会有这本书
(无)
本书的产品与定位
(无)
本书的风格与特色
(无)
第一章 写给-1到3岁的产品经理
1.1 为什么要做产品经理
坏产品：无处不在的危险
好产品：从垃圾桶到洗手间
1.2 我们到底是不是产品经理
产品究竟是什么
产品经理横空出世
他们真是招产品经理吗
产品经理概念的进化
非典型产品经理
一线员工眼中的管理
你已经是产品经理
1.3 我真的想做，怎么入行
产品经理的招聘广告
真的想？你确定吗
找到自己的位置
几个可能的入行切入点
1.4 一个产品经理的-1到3岁
入行之前，我是学生物的
入行头半年，打杂的菜鸟
入行半年后，学习“怎么做”
入行一年，开始问“做不做，做多少”
入行两年，项目与团队
入行三年小结：战略与修养
1.1 为什么要做产品经理
1. 我们为什么要做产品经理？因为，好产品能改变世界，坏产品也能，而我们身边已经有太多的坏产品了，就像下一个标题说的，它们就是“无处不在的危险”。世界需要我们——好的产品经理——来拯救！
坏产品：无处不在的危险
2. Don't Make me Think【1】中一书说，Web的设计“不要让用户思考”，其实生活中更需要这样。这块石头上的指示，虽然仔细看可以弄明白，但是绝大多数用户却不会仔细阅读。
3. 花哨的视觉效果妨碍了用户，以至于妨害了我们的原始目标。有曰：给尸体做美容，给河马涂口红。
4. 看过一篇文章，说在西方，路上经常看到残疾人，而在中国却很少，于是很疑惑，难道西方的残疾人比例比较高？看到这条盲道，也许可以给我们一些提醒，我们的残疾人没事儿敢出来溜达吗？不管是铺盲道的问题，还是架电线杆的问题，用户眼中只会认为是产品有问题。
好产品：从垃圾桶到洗手间
5. 三组垃圾桶，让我们看到了产品功能的持续改进过程，其改进的方向是：让用户更加省心。
1.2 我们到底是不是产品经理
产品究竟是什么
1. 产品的狭义概念：被生产出的物品；产品的广义概念：可以满足人们需求的载体。
2. 我的理解则更直白一点：产品就是用来解决某个问题的东西。
3. 产品这个东西，可以是有形的实物，也可以是无形的服务，多种多样。而解决问题其实就意味着满足人们的需求，这样才能产生价值。这个价值不仅要给产品的使用者，也要给产品的创造者。这本书里谈到的主要是一类产品——商品，并不是所有的产品都要变成商品，公益性、非营利的产品也随处可见。但我们工作中所做的产品，绝大多数都是在人们的需求，即用户目标和公司的商业目标之间寻找平衡。只考虑用户，公司无法赢利，必然死掉；只考虑商业，光想着公司得好处，用户留不住，公司也会死掉。 所以在这本书里我们说产品是什么，产品就是要同时解决用户的问题和公司的问题，一个都不能少！
产品经理横空出世
4. 由此可见，产品经理的出现是为了适应公司发展的需要。随着企业越来越大，产品越来越多，越来越复杂，原来按职能划分部门的组织结构已经无法适应，所以出现了产品管理的矩阵型组织，而此时产品经理的主要职责是规划产品的生命周期，负责产品的上市策略、定价策略、整合营销策略、销售与分销策略等。
5. 上述框架下的产品经理，我把其称之为“传统意义的产品经理”
他们真是招产品经理吗
6. 说到这里，也许在互联网、软件公司中做产品经理的朋友要跳起来了：好像之前产品经理要做的那些事情已经另有分工，由运营部门、市场部门的同事负责啊！为了进一步验证互联网、软件行业的产品经理确实和传统行业的产品经理不同
7. “产品经理”这个概念，确实已经和旧有的产品经理概念不一样了。它更多地侧重产品本身“从无到有”、“从有到优”的过程，更多地涉及了“产品规划、数据分析、用户研究、需求分析、功能设计、项目管理、敏捷方法”等内容，而不是如传统的产品经理那样，去做已经有了产品之后需要做的诸如管理产品、推广和营销产品的事情。
产品经理概念的进化
8. 我们有必要来讨论一下互联网、软件的产品经理与传统意义的产品经理为什么会有这些差异？而
9. 第一，行业形态不同：成熟行业VS.新兴行业。 传统行业经过几十年乃至上百年的摸爬滚打，市场已经成熟，产品基本定型，通常只有渐变式的创新，很难有重大突破。另一方面，用户也已经成熟，对产品相当熟悉，也已经形成比较固定的使用习惯，较难改变。所以对于这样的市场和用户，公司会偏重营销类创新，
10. 而互联网、软件行业是新兴行业，新兴市场，三天一小变，五天一大变，产品本身在不断取得突破，用户看什么都是新的，所以产品需要推陈出新，尽力先入为主，占领用户，主导用户习惯，这就导致了产品工作的重头戏在前期，从无到有，从有到优，偏重研发类创新。 因此，互联网、软件行业的产品经理更重视产品功能本身的规划，需要“对市场发展趋势有敏锐的洞察力和创新意识及良好的分析、研判能力”，要能不断改进产品，要“深入了解业务，挖掘用户的多种需求，不断推出有竞争力的产品”，“制定所负责产品线的发展蓝图和实施路线图”。
11. 第二，产品形态与成本结构不同：实物VS.虚拟物品。 传统行业的产品多为实物，所以有采购、仓储、物流等分工，产品研发出来以后，还有大量的制造成本，这也使得传统行业的产品经理有相当多的工作是需要考虑如何把整个供应链打通，怎样销售、分销、促销等。而互联网、软件产品多为虚拟物品，公司相对而言显得较“轻”，不管是团队，还是成本花费，都更加集中在产品研发的过程中。
12. 一个常见的互联网产品，很可能只是由几个人或十几个人、几十个人的团队所做，而用户却是上百万、上千万，甚至亿量级，这在传统行业不可想象。虚拟物品的复制成本极低，所以重点资源会投入在产品本身，较少考虑实体经济里供应链上下游的事情。于是，对产品经理来说，需求分析、设计的细节尤为重要，必须亲自把握，可能一个细节的改进就能增加上万的用户，杠杆效应也十分明显
13. 第三，生命周期不同：几年VS.几个月。
14. 于是，我们推崇敏捷方法，传统行业的精雕细琢不适用了，我们要快，这也是为了顺应新兴市场的需要，而且船小好掉头，有问题也能够快速地改，再发布一次升级就行，不像传统行业改起来那么麻烦，问题产品只能“召回”……所以，虽然互联网、软件的项目更加不可控，但项目过程本身看起来并没有传统行业那么复杂，更接近“艺术”而不是“技术”，要依靠丰富的经验，于是产品经理也经常兼顾项目管理，这样自己可以在项目完成度和产品质量之间做平衡，对产品无疑也是一件好事。
15. 第四，赢利模式不同，单一卖产品赚钱VS.多元赢利。
16. 传统行业的赢利模式多为通过卖产品赚钱，或是直销，或是通过渠道分销，总之是靠产品本身的价值来赚取利润，而互联网、软件产品有很多产品本身是免费的，一部分产品甚至几年内都不考虑赚钱的问题，可想而知，对做这种产品的产品经理，要求肯定不同。而另外一些能赚钱的产品，也有着更多元的赢利模式，比如免费给用户使用，但利用用户的注意力赚取第三方的广告费等。 赢利模式的差异造成了产品为谁做的差异，传统行业多是为付钱的客户做，值得注意的是，很多情况下客户只是买产品的人并不是用产品的人，也许搞定几个大客户，就3年不愁吃穿。 而互联网、软件产品大多是为使用产品的终端用户所做，而且通常是面对海量的用户，用户数多了，自然就能赢利。所以，互联网、软件行业的产品经理会更重视用户研究、数据分析等工作，要“负责用户研究，把握用户需求，实现用户需求”，而赢利的事情反倒不用直接去管，会有另外的团队负责。
17. 第五，用户心态不同：花钱买VS.免费用。 传统行业产品的用户知道，东西是买来的，花了钱的，所以有点不爽的地方也就凑合着用，不至于把产品扔了立刻去再买个新的。而互联网、软件产品就不同，大多数都是免费的，每类产品雷同的还很多，所以只要这个产品用得稍稍有点不爽，用户马上就能很方便地找到另外一个试试。 于是，互联网、软件产品更重视用户体验，相应的，出现了很多产品经理会涉及的工作内容，如交互设计、视觉设计、文案设计等。举个例子，有时候为了确定两个按钮是上下分布好，还是左右分布好，我们有可能做大量的用户实验。在互联网、软件行业中，产品经理能真正体会到“用户是上帝”的感觉，辛辛苦苦做一个产品，给用户免费用，还要尽量让用户免费用得比付费的都爽。
18. 小结一下，以上五点相互之间也是紧密联系、相辅相成的，共同造就了传统行业与互联网、软件行业的产品经理的差异。比如为了给用户极致的体验，我们需要做很多数据分析，而数据分析的基础在于互联网、软件产品的虚拟特性，可以大量地记录用户的各种行为数据，这是传统行业很难做到的。又如正因为是新兴市场，所以产品不成熟、用户不成熟，于是产品的生命周期缩短，需求变化快，项目中不可控的因素增多，使得敏捷方法备受推崇。
非典型产品经理
19. 这是因为，不单是传统意义的产品经理，就算是新概念下的产品经理的职责，也通常分给几个人或几个部门做。很少出现全能型产品经理，就算全能，也会因为个人精力所限，在某个时间段只会专注某方面的工作
20. 产品经理制度仍需要不断修正，并指明了三大变化方向：产品管理团队【7】、事业单位经理的任用、更专业取向。其中，产品管理团队顾名思义是用团队的力量来代替单一的产品经理；而任用事业单位经理的制度则是从项目管理团队的概念发展出来的，把产品强调为一个事业单位，也就是我们经常说的事业部，而产品经理也就摇身一变成为了事业部的总经理，区别在于总经理有了更大的权力；更专业取向则可以用下面这段摘录的文字说明，这也比较像我个人的一段经历。
21. 由于企业分派给产品经理的责任越来越多，有的公司开始质疑——对产品经理一个人来说，这样的负担是不是已经难以负荷。结果造成现在出现缩减产品经理的责任，让他更为专业化的趋势。至于要求产品经理专注的方向，则因公司或行业类别而不同…… 有时高科技企业会采取类似的做法，让产品经理专心处理产品在工程和技术方面的问题，而把大部分营销决定交给另外的职能单位来负责。在这种情况下，产品经理可能会变成产品技术/应用方面的专家，他最主要的工作就是支援、协助销售人员，至于了解市场和从市场了解产品利益等工作，则另有他人代劳。像这样把营销功能和产品开发活动分开来处理的做法也有风险：产品经理将失去和顾客间的联系，而且会因为对产品太过熟悉，以致丧失判断上的客观性。 不管企业想用怎样的专业取向，以便产品经理更容易地管理他的工作，很重要的一点是，请记住这个职位当初是为何而设——想要更了解产品与它面临的竞争情况，最终目的是要满足顾客的需求。
一线员工眼中的管理
22. 既然产品经理这个职位中有个“经理”二字，似乎多少就有点管理的味道。而按管理大师德鲁克的说法（我很认同）： 管理并不是公司的管理层，如总裁、总监、经理们才需要掌握的技能，而是每个人必备的生存技能，只是每个人可以掌控的资源不同，所以需要管理的对象也不同。当资源充分的时候，我们会觉得“正确地做事很重要”，事实也确实如此，比如被分派了某个重要任务时，我们的目标就是做好这件事。而一旦资源出现了瓶颈，“做正确的事”就立刻变得更重要了。比如同时有3个人要请你吃明天的晚饭（当然这种好事非常难得），这时候的资源，即你的时间不够了，你就需要迅速判断和谁吃饭更有价值，谁的请客可以推到后天或下周……OK，你会管理自己的时间吗？
23. 管理的能力，其实就是“在资源不足的情况下把事情做成”的能力
24. 第一，信息不足以决策。时间有限，能力有限，每次决策前不可能掌握所有信息，做决定时总是很头疼，我估计是“拍脑袋”拍得太多的原因。 第二，时间不足以安排周密的计划。总是接到3个月、1个月，甚至1个礼拜完成某项目的命令，每次都让我们张大嘴巴说不出话来，应承下来后如何计划？不过一次又一次的实践表明，办法总比困难多。 第三，人员不足以支持工作强度和难度。不但时间不足，人员也不足，就算数量足，能力够不够？能力够了，团队士气高不高？哪个公司不加班，又有多少公司有加班工资？但还得完成任务，难不难？难！ 第四，资金不足以自由调配。俗话说钱要花在刀刃上，买机器要钱，招人要钱，产品推广要钱，而花这些钱的前提是公司还得赚钱，每一分钱都恨不得掰成两半用。 以上四点还可以推广到生活中的各方各面，凡是资源，总归不足——这是常态！既然不足，就需要学会分配资源、管理资源。比如说自己的时间、衣橱、工资……其实，你已经每天都在做了，不是吗？所以——
你已经是产品经理
(无)
1.3 我真的想做，怎么入行
产品经理的招聘广告
（无）
真的想？你确定吗？
25. 当你对一个产品感兴趣的时候，回想一下脑中萦绕的问题是站在用户的角度，还是站在产品经理的角度。通常，用户会去想怎么用这个产品，才能带给自己更大的好处，产生更大的效用；而产品经理则习惯于绕过表象，从背后看问题的本质，思考怎么设计这个产品才能更好地平衡用户目标与商业目标。
找到自己的位置
26. 技术相对而言好学一点，可以速成，但是商业感觉没个三五年是磨不出来的。
几个可能的入行切入点
（无）
1.4 一个产品经理的-1到3岁
入行之前，我是学生物的
（无）
入行头半年，打杂的菜鸟
（无）
入行半年后，学习“怎么做”
（无）
入行一年，开始问“做不做，做多少”
用户与需求
入行两年，项目与团队
最简单的项目管理
最简单的团队构成
入行三年小结：战略与修养
全书的结构图示
产品经理的生态系统
第2章 一个需求的奋斗史
2.1 从用户中来到用户中去
2.1.1 用户是需求之源
人类为什么有需求
用户VS.客户
以用户为中心的思想
不要试图满足所有用户
2.1.2 你真的了解用户吗
体会真正的用户
试着描述用户
聊聊用户研究
2.2 需求采集的大生产运动
2.2.1 定性地说：用户访谈
用户访谈的常见问题与对策
记一次用户大会
2.2.2 定量地说：调查问卷
调查问卷的常见问题与对策
设计一份实际的问卷
2.2.3 定性地做：可用性测试
可用性测试的常见问题与对策
产品改版的一次冒险
2.2.4 定量地做：数据分析
数据分析的常见问题与对策
日志分析的商业价值
2.2.5 需求采集人人有责
生孩子与养孩子
单项需求卡片
尽可能多地采集
2.3 听用户的但不要照着做
2.3.1 明确我们存在的价值
用户需求VS.产品需求
满足需求的三种方式
也谈创造需求
2.3.2 给需求做一次DNA检测
把用户需求转化为产品需求
确定需求的基本属性
需求种类知多少
分析需求的商业价值
初评需求的实现难度
性价比啊性价比
2.4 活下来的永远是少数
2.4.1 永远忘不掉的那场战争
准备出发：把需求打个包
战场：产品会议
武器：商业需求文档
2.4.2 别灰心，少做就是多做
最爽就是“四两拨千斤”
尽可能多地放弃
2.5 心急吃不了热豆腐
一个需求的生老病死
需求管理的附加值
和需求一起奋斗
1. 本章将从“需求采集”开始，一直讲到“确定某个项目的需求范围”为止，从需求被发现到决定实现，这就是一个需求的奋斗史
2. “从用户中来到用户中去”，做任何产品都是一个端到端的过程，端即用户，所以“用户是需求之源”，我们要拥有“以用户为中心的思想”，不断“体会真正的用户”
3. 然后我带着大家发起“需求采集的大生产运动”，与用户接触的过程就是需求采集的过程，我们来看看几种常用的需求采集方法，如“数据分析”、“调查问卷”、“用户访谈”等。并且希望大家意识到“需求采集人人有责”，从而“尽可能多地采集”。
4. 用户说了很多需求，产品经理要“听用户的但不要照着做”，必须“明确我们存在的价值”是“把用户需求转化为产品需求”，这一过程即需求分析过程。产品经理要通过“给需求做一次DNA检测”，来“确定需求的基本属性”、“分析需求的商业价值”、“初评需求的实现难度”，从而计算出需求的“性价比”。
5. 资源总是有限的，所以我们只能做那些性价比高的事情，通过残酷的需求筛选，“活下来的永远是少数”。看看“永远忘不掉的那场战争”，给自己打打气，“别灰心，少做就是多做”，我们要有意识的“尽可能多地放弃”。
6. 最后，是需求管理的话题。任何东西多了都需要管理，做产品更是“心急吃不了热豆腐”。这里与大家聊聊“一个需求的生老病死”，“需求管理的附加值”。再次回顾需求的奋斗史，也回顾我自己“和需求一起奋斗”的第一年。
2.1 从用户中来到用户中去
2.1.1 用户是需求之源
人类为什么有需求
7. “食色性也”，“食”是为了生存，保证个体延续，“色”是为了繁衍，保证种族延续，这是生物（包括人）的本性，即最基本的需求。
8. 马斯洛的需求层次理论：此理论将人的需求划分为五个层次，由低到高，并分别是：生理需求、安全需求、社交需求、尊重需求、自我实现需求。
9. 人类生活在地球上，为什么会有各种各样的需求？那是因为生活中存在太多的问题，从而产生了不满意，而问题就是“理想与现实的差距”，那么人类会很自然地产生“减少甚至消除这个差距”的愿望，这就产生了需求。我们之所以做一个产品，肯定是为了解决某些问题，满足某些需求，而这些需求深挖到底，多问几个为什么，总可以归结到马斯洛说的那几个层次里。
10. 研究需求可以增强对用户的理解，而理解用户，是产品经理最重要的素质之一。
11. 需求的本质就是“问题”，问题的本质就是“理想与现实的差距”。作为产品经理，我们每天都在设法满足用户的需求，其实就是在解决各种各样的问题【4】，而解决这些问题的方法与思路，对任何人都有帮助，而任何人也都多少知道一点
用户VS.客户
12. 用户与客户，这两个词在中文里似乎很容易混淆，换作英文会稍微清晰一些，用户是User，有时也叫做终端用户，End User，是使用产品的人；而客户是Customer，是购买产品的人、为产品付钱的人。
13. 比如你觉得新浪的免费邮箱用得不爽了，忍不住付费买了新浪VIP邮箱，这时候你既是新浪的用户、也是客户。又如某天你在路边的超市买了一瓶娃哈哈矿泉水，这时你是娃哈哈的终端用户，是超市的客户，同时超市是娃哈哈的客户。
14. 我们平时也经常不去刻意区分这些概念，而是统一用“用户”这个词来代表“广义用户”，它指的是所有和产品有关的人，或者叫产品干系人，除了终端用户、各种客户，还包括你所在的公司里与这款产品有关的老板、销售人员、服务人员、技术人员等。但我们一定要做到心中有数，不同的用户有重要程度之分，我们必须、也只能有所偏重。
15. 某著名的电子商务网站建设服务提供商的演示文档里有这样一句明确的话——“相比您的需求，我们可能更重视您的用户的需求”。对此服务提供商来说，他在“您”（他的客户）与“您的用户”（客户网站的终端用户）之间，做出了明确的取舍，即优先满足产品使用者的需求，而不是付钱者的需求。
以用户为中心的思想
16. 对于中小型公司，需求的一个很大来源不是终端用户，而是老板——一种广义用户。一般来说，在这类公司中，老板反而是最接近业务、最了解用户的，加之老板的经验阅历又超过我们，所以他高屋建瓴、高瞻远瞩，会抓住一些商机，他觉得这些商机能够创造价值，很多时候比产品经理的观点更合理，这时候老板肩负起了部分产品经理的职责，起到了采集用户需求并分析、筛选的作用。创业阶段的公司是没有太多时间和精力“从用户中来到用户中去”的，一来一去可能公司都关门了，研究清楚了又怎样？因此有时一个问题和需求的诞生，就是靠老板凭经验拍脑袋。这种情况下，我们应该本着实用主义的思路，绝对不能一开始就想着“造反”——“我要见终端用户，我听用户的，不听你的”，而是要尽可能地帮助老板明确问题和需求的价值，为其决定方向提出参考建议，或协助其实现目标
17. 所谓“酒肉穿肠过，佛祖心中留”，这样，我们便同时拥有了“以用户为中心的思想”和“以老板为中心的行动”（或者说“以实际情况考虑如何行动”）。以老板这种广义用户为中心，在小团队里其实反而是一种较优的实践。
不要试图满足所有用户
18. 不仅要区别对待广义用户，对于狭义的终端用户，我们也无法一视同仁。
19. 试图满足所有用户的需求是一个灾难，那会让产品变成一个臃肿不堪，谁都不满意的四不像。
20. 我们无法满足所有用户的需求。那么我们应该优先照顾哪些人？
21. 腾讯CEO马化腾说应该关注核心用户的需求。 我做过的一款产品刚起步的时候，老板跟我说先满足大量的一般用户的需求。 矛盾？谁错了？其实谁都没有错，我是这么考虑的，腾讯的产品已经充分占据了市场，拥有霸主地位，所以用户数不可能再有爆发式增长，于是只能考虑从已有的用户身上深挖用户价值，而最有价值的一批用户无疑是核心用户；而我做的那款产品刚起步，没什么用户，急需把池子做大，所以我们会先做一些大众功能，满足一般用户的需求，让用户数先爆炸起来。 所以说，优先满足哪些用户需要和产品的商业目标要结合起来考虑，简单说就是看KPI【6】是什么
22. 这并不是说核心用户不重要，而是产品的不同阶段，目标自然不同。
23. 当然，你也可以从其他维度划分出优先满足的用户，如男女、地域、年龄段等，其中的道理都是相通的——我们无须满足所有用户的需求。
2.1.2 你真的了解用户吗
24. “装不装用户”的问题，我的想法是，如果你做的东西确实是自己平时就会用的，那么可以试着装一下，不过要记住你装的用户只能代表一部分用户，而对于自己不怎么用的产品，千万别去臆测用户的情况。 真正的用户，他们想的，他们做的，你真的了解吗？
体会真正的用户
25. 想了解用户，光靠空想是不行的，他们是真实的，是五花八门的，必须得真刀真枪地去研究他们。
试着描述用户
26. 我们的老板也只不过是一杆枪，你我就是一颗子弹而已”。当工具的滋味是不好受的，特别是当产品经理很有想法的时候，所以我们要争取主动，不过是在诸多限制下“带着镣铐跳舞”。
聊聊用户研究
27. 横向，用户的说和做。怎么说表现了目标和观点，怎么做反映了行为，用户怎么说和怎么做经常是不一致的。
28. 纵向，定性与定量。定性研究可以找出原因，偏向于了解；而定量研究可以发现现象，偏向于证实。
29. 第一轮，听用户定性地说，确定产品方向，做什么？随机抽样40个用户做访谈，据此写出需求列表。 第二轮，听用户定量地说，确定需求优先级，先做什么？投放了20万份调查问卷，确定了需求优先级的排序。 第三轮，看用户定性地做，要先做的那几个需求，应该怎么做？一边设计，一边陆续找了10个用户来验证，做可用性测试。 第四轮，看用户定量地做，根据产品的用户使用情况做数据分析，不断改进产品。 当然，这是一个比较重要的产品，所以在用户研究上投入了较多的时间与人力，更多的时候，我们会视情况采取简化的方案。
30. 坚决杜绝“经组织研究决定，用户需要一个××功能”这类事情发生，要实实在在地把用户当做需求之源。
2.2 需求采集的大生产运动
31. 但这些用户研究，或者说需求采集的过程，都会有如下几步：明确目标、选择采集方法、制定采集计划、执行采集、资料整理，然后进入下一步的需求分析阶段。
2.2.1 定性地说：用户访谈
用户访谈通常采用访谈者与被访者一对一聊天的形式，一批次用户访谈的样本比较少，一般是几个到几十个，但在每个用户身上花的时间比较多，通常为几十分钟到几个小时，围绕着几个特定的话题，我们问，用户答，用户说，我们听，这是一种典型的定性研究。
用户访谈的常见问题与对策
32. 第一，“说”和“做”不一致的问题
33. 用户倒不是想故意欺骗我们，而可能是：他们被问了自己也没仔细想过的问题，又不想回答不知道，就在现场编造了一个看似有理有据的理由，或者他们有讨好访谈者的心理，会回答他们觉得你希望听到的答案，而不是自己真正的想法【12】。
34. 第二，样本少，以偏概全的问题。 选择样本的时候需要多加注意，尽量做到随机
35. 第三，用户过于强势，把我们往沟里带。要解决这个问题，需要时刻牢记访谈的目的。如果发现话题不对，就赶紧往正道上扳，若发现多次都扳不过来，就可以考虑尽快结束了
36. 第四，我们过于强势，把用户往沟里带。这个问题的对策，同样是牢记访谈的目的，并且管好自己的嘴。
记一次用户大会
（无）
2.2.2 定量地说：调查问卷
37. 同样是听用户怎么说，常见的定量研究方法是——调查问卷。 调查问卷和用户访谈的提纲是有区别的：用户访谈的提纲通常是开放式问题【17】，适用于我们心里还比较疑惑的时候去寻找产品的方向，适合与较少的访谈对象进行深入的交流；而调查问卷通常封闭式问题比较多，适合大用户量的信息收集，但不够深入，一般只能获得某些明确问题的答案，
38. 开篇一般放一些简单的不需要思考的问题；很想知道的内容，需要思考的，较敏感的问题一般放在中间；而有关被访者个人信息的题目一般放在问卷的最后，以免应答者在回答这些问题时有所顾忌，进而影响其他答案。
调查问卷的常见问题与对策
39. 调查问卷一人一份，独立作答，可消除“焦点小组”、“论坛发帖征集需求”等具有群体讨论性质的方法的弊端。这是因为用户有其特点——沉默与骑墙的总是大多数。
40. 《长尾理论》里说到“沉默的大多数”，那么站出来的总是很少数，而且往往是非典型的用户，不能保证其代表了目标用户的想法；而“骑墙的大多数”说的是，大多数人是没有明确观点的，尤其在网络这样一个不用负责任的环境下，所以常见的情况就是开始表态的那几个人的观点引导了群体的观点，随机的初始值决定了结果，这个时候你只有单独和跟风者交流，才会发现他根本不是那么想的。 调查问卷的客观性、多份问卷之间的独立性，可以有效避免上述问题
设计一份实际的问卷
（无）
2.2.3 定性地做：可用性测试
41. 可用性测试是指通过让实际用户使用产品或原型方法来发现界面设计中的可用性问题，通常只能做少数几个用户的测试，看他们怎么做，属于典型的定性研究。
可用性测试的常见问题与对策
42. 第一，如果可用性测试做得太晚（往往在产品将要上线的时候），这时发现问题也于事无补了。
43. 第二，总觉得可用性测试很专业，所以干脆不做。
44. 第三，明确是测试产品，而不是测试用户。
45. 第四，测试过程中，组织者该做的和不该做的。
46. 做测试的过程中千万不要有任何的引导与暗示，而只是观察和记录，因为任何引导都可能使得原本可以发现的问题无法暴露。用户行为和预想的不一样时，可以提问，实在进行不下去的时候，给予提示。记住，一切的错都是产品和我们的错，用户绝对没有错。
产品改版的一次冒险
（无）
2.2.4 定量地做：数据分析
47. 数据分析时，根据不同的目的，数据来源多种多样，常见的有用户使用产品的日志、客户管理系统里的信息、网页访问情况的统计信息等。数据分析的方法，最简单的可以用Excel，复杂一点的可以用一些统计软件、数据库软件，或者直接自己写程序解决。而最关键的就是对结果的解读，通常数据分析只能发现一些现象和问题，并不能了解原因，所以分析完成后通常会伴随着一些用户访谈，听听用户怎么解释。
数据分析的常见问题与对策
48. 第一，过于学术，沉迷于“科学研究”。但实际生产环境就更注重综合的性价比了，所以我们日常的数据分析方法也就显得不那么严谨了，
49. 第二，虽然数据不会主动骗人，但我们经常无意或有意地误读数据。
50. 举个例子，对一个人群，人们的身高用平均数来衡量是有意义的，因为我们知道身高属于典型的正态分布，中间多两边少，所以一个平均值就能了解群体的大致情况，而对人们的收入，就不能用平均值来衡量了，一个超级富豪和1000个零收入的人一平均，很可能得出人均收入100万的荒谬结论。
51. 第三，平时不烧香，临时抱佛脚。 这是一个很实际的问题，我们经常在做决策的时候才想起数据分析，但忽然发现手头没有数据可分析。一次又一次地发生同样的情况……为了避免，我们应该在产品设计的时候就把数据分析的需求加进去，比如记录每个按钮的点击次数、统计每个用户的登录频率等
日志分析的商业价值
52. 在对产品足够熟悉的基础上，先做出方向性的假设，再提取相应的数据并分析，得到一些现象，最好是之前没发现的现象，然后尝试解释，接下来做用户调研修正解释，最终指导产品发展方向。
53. 每家大约要1000元人民币，不算不知道，确实挺贵的……这还只是很简单的调研，所以用户研究的成本真的很高，很多小公司都能省则省，我们很无奈，老板也很无奈，以后在抱怨老板没用户研究意识的时候，也需要体谅一下他们的难处。
2.2.5 需求采集人人有责
生孩子与养孩子
54. 之前所述的各种方法，都是直接从用户那里得到需求，我称之为一手需求，就像“生孩子”。其实很多时候，我们还会接受二手需求，比如老板说要给用户做个××功能、销售人员说用户哪里用起来不顺等，这些需求和一手需求比起来，就像“养孩子”。
55. “生孩子”，更多的时候发生于新产品诞生前，这时候外部没有用户，内部没有运营、销售、服务等，所以对于需求而言，更多的是产品人员驱动，去主动采集需求，比较常见的就是直接去潜在的目标用户那里采集。这个从无到有的过程，个人觉得发挥的空间最大，是最有成就感的。
56. 而“养孩子”，通常是产品已经运行了一段时间以后，用户也有了，公司内部也多了很多相关的人员，比如销售和服务。虽然产品部门与用户的直接接触变少，但多了很多间接来源，即与终端用户接触的干系人，他们会向你反馈很多需求，而用户也开始主动提出需求了。
57. 对比一下，生孩子的时候，我们去主动“拉”需求的比例较高，需求都是直接从用户那里得到的，有点“进攻”的感觉，而孩子生出来以后，就不再是你一个人的孩子了，必然是大家一起养，所以我们需要照顾的各方各面也会更多，我们会收到很多“推”过来的需求，比较像“防守”的感觉。
58. 下面我就介绍一种简单的二手需求采集工具——单项需求卡片
单项需求卡片
59. 一张单项需求卡片描述了一个用户的需求到底包含哪些内容，重点是描述用户场景，谁在什么时间、地点产生了何种需求，
尽可能多地采集
60. 现场调查。说简单一点就是打入“敌人”内部
61. AB测试。基于大用户量比较合适，比如有一个按钮不知道是放在页面的左边好，还是右边好，而我们有10万个用户，那就先随机挑选少量的用户发布这个按钮，1000个人放左边，另外1000个人放右边，然后过一段时间分析结果，再决定剩下的98％用户该怎么办。
62. 日记研究。互联网新兴的个人应用比较适合，某个新产品出来以后，很多业内的朋友都会去尝试，然后写一些使用体会，但作为产品设计者在看这些日记的时候，要明白日记的作者往往是同行，而不是主流用户。
63. 自己提需求。
2.3 听用户的但不要照着做
64. 有的用户很“危险”，在提意见的同时还说你们应该做成什么样子，这时候产品经理一定要头脑清醒，用户提的解决方案往往是站在自己的立场上考虑的。
65. 有时候，用户给出的做法存在明显的逻辑矛盾
66. 我们是产品经理、产品设计师，最终怎么做应该由我们决定。
2.3.1 明确我们存在的价值
67. 对同一个问题，这两套解决方案的区别就是，一个是用户需求，一个是产品需求。而这中间的转化过程，就是这节的主题——需求分析。
用户需求VS.产品需求
68. 用户需求：用户自以为的需求，并且经常表达为用户的解决方案。 产品需求：经过我们的分析，找到的真实需求，并且表达为产品的解决方案。 需求分析：从用户提出的需求出发，找到用户内心真正的渴望，再转化为产品需求的过程【24】。
69. 技术分析是“树干——树枝——树叶”的任务分解过程，
70. 而真实情况是，需求分析是“首先：树叶——树枝——树干，其次：树干——树枝——树叶”的分析过程，所以说完整的需求分析是一个“分-总-分”的过程。一方面不能漏掉提炼用户需求的这个过程，目的是透过现象看本质，另一方面也不能停在本质上，试想如果做到“树干”就结束，后端的执行人员可能还是不知道要做什么东西，所以我们还要继续把树干再重新分解成树枝、树叶。
71. 伟大的需求分析师，可以无视用户想要的东西，去探究他内心真正的渴望，再给出更好的解决方案，或者说是用户真正需要的东西，这就是本节标题的意思——我们存在的价值。
72. 说到这里有必要提一下，销售人员经常说：“用户是为想要的东西买单，而不是需要的”，用我们上面分析翻译一下，其实是“用户是为自己提出的解决方案买单，而不是我们的解决方案”。是不是很纠结？那我们还分析个什么劲啊，直接做用户要我们做的得了。 其实这是短期利益和长期利益的权衡，如果是一锤子买卖，卖出以后又不用售后，那么采用实用主义，不妨用户要什么就给他什么，这样他掏钱最爽快
73. 希望用户长期使用的，并且后续的服务也是我们来做，所以为了长期利益，我们就有必要找到用户的真实需求，然后给他真正合适的产品了，哪怕这个过程不那么讨好
满足需求的三种方式
74. 需求来源于理想与现实的差距，那么减小这个差距就有三种方式： 改变现状。是我们最常用的，去开发某种产品，但也是最笨的办法。 降低理想。不要忽视精神的力量，什么“打预防针”、“丑话说在前头”这类句子想必大家都经常听到。 转移需求。因为人类的注意力是有限的，所以引导用户去关注其他事物，他就会觉得这个差距没那么可憎了。我们也可以说，人的行为是需求驱动的，想改变人的行为，可以寻找更强烈的需求展现给他，而让他不再纠结于原来的需求。
也谈创造需求
75. 我们能不能再开阔一点？不劳用户的大驾，直接达到产品设计的最高境界——创造需求！ 工作中典型的场景，就是老板或者产品人员的突发奇想，这些灵感在潜意识里都有一定的依据，是基于对用户、市场、产品的充分理解，也有过不少案例，这些需求最终获得了用户的认可，但更多地被证明是过于天马行空。
76. 苹果公司的乔布斯，可以说是创造需求的大师
2.3.2 给需求做一次DNA检测
把用户需求转化为产品需求
77. 把用户需求转化为产品需求 检测的第一步就是“需求转化”，现在我们有很多用户需求，可能记录在“单项需求卡片”里，可能记录在Excel里，
78. 当然，在一个团队里，还是建议大家统一一种记录用户需求的形式。
网点版的一部分用户需求
79. 现在我们就要发挥出“我们存在的价值”，在这个阶段，团队经常举行头脑风暴【25】，大家天马行空地讨论一番之后，对用户提出的需求有了比较全面的了解，对用户的内心世界有了比较统一的认识，对我们的解决方案也有了一些不成熟的想法，然后通常每个人分一块，去把它们都转化为产品需求，最后记录在一起。
产品需求的列表
确定需求的基本属性
需求的基本属性
80. 用户需求与产品需求是多对多的关系，我们可能用多个功能来满足一个用户需求，也可能用一个功能来满足多个用户需求，甚至是用几个产品需求来满足几个用户需求，其中并没有一一对应的关系。
81. 对任何产品来说，只要需求采集的工夫做足了，你就会发现上面这个产品需求列表行数超多，所以在需求转化过程中，我们也会做一轮筛选，把明显不靠谱的用户需求直接过滤掉，不计入上述列表，当然，是否“明显不靠谱”就要由你来把握了
确定需求的基本属性
82. 编号
83. 提交人
84. 提交时间
85. 模块
86. 名称
87. 描述
88. 提出者
89. 提出时间
90. Bug编号
需求种类知多少
91. 分类：可以分为“新增功能、功能改进、体验提升、Bug修复、内部需求”等。
92. 层次：把需求分成“基础、扩展（期望需求）、增值（兴奋需求）”三层，
分析需求的商业价值
93. 重要性：可以参考时间管理里“重要与紧急”的概念。这里的重要度又可细分为满足后“一般”到“非常高兴”；未实现“略感遗憾”到“非常懊恼
94. 紧急度：在时间维度上判断这个需求是否迫切，紧急不重要的需求通常表现为解决了短期的问题，如果熬过去没做，对长期影响不大；或者解决了局部的问题，如果不做对于大多数用户没有影响。
95. 持续时间：需求是有生命的，有的长寿有的短寿，比如迎合过年过节的运营活动需求，一般就比较短寿。试想8月我们录入了一个国庆的主题运营活动，如果到了9月底还没有资源做，那一年内也就不用再考虑这个需求了。
96. 商业价值，或者叫商业优先级，是对上述几种商业价值指标的综合评判。这一条是整个需求列表中最核心的部分，这里的判断直接影响着产品未来的方向。有时候我们还在列表里增加一列“商业价值描述”，通俗点就是这个需求的卖点是什么，可以给用户提供什么价值，对公司又有什么帮助。 如此重要的商业价值评估，我们的做法是在需求讨论会上由产品团队集体讨论，再叫上有必要的干系人，比如销售、服务等。对于某个需求，需求提交人是对它最熟悉的，提交人先基于自己对商业目标的理解，做一番陈述，主观定个级别，比如高中低。然后大家讨论，所以在这个讨论会之前，每个人都应该做好功课。
初评需求的实现难度
97. 绝对不能因为某个需求的商业价值很大就马上去做，也不能因为另一个需求的商业价值不大就不做。
98. 但实现难度这个词太难量化
99. 先简化为人力成本
100. 首先简化为人力成本，即工作量
101. 其次，我们把工作量再简化为开发量
102. 开发量是非评估不可的，我把它叫做“初评”，允许误差，并且会要经验丰富的人来评估，通常是技术经理，或者系统分析师、架构师。他们做出简单的评估，并且靠不断的实践来反复修正
103. 相对于“初评”，在项目启动之后，制定项目开发计划的时候还会有一次更精确的评估，那时候需求怎么做已经知道、由哪位开发工程师来做也知道，所以可以推算出相对准确的工期
性价比啊性价比
104. 绝对不能因为某个需求的实现难度很小就马上去做，也不能因为另一个需求的实现难度大就不做。
105. 性价比＝商业价值÷实现难度（简化为开发量） 现在可以做决定了，我们把产品需求列表按照“性价比”一列从大到小排序，先做排在上面的就可以了
2.4 活下来的永远是少数
106. 我们争夺的是下个月的人力资源，即总是不够用的开发工程师、测试工程师等。战场就是闻之色变的产品会议，而我们手上的武器，则是精心准备的商业需求文档。 这个过程，就是需求筛选，如图2-16所示，也有个很传神的说法：需求PK。
2.4.1 永远忘不掉的那场战争
107. 按产品线划分的团队对产品本身是有利的，产品经理权力更大，可以按照自己的想法做，资源有保证，产品规划不容易被动改变。此外，各种职能的员工之间沟通顺畅，单线领导，开发的领导、测试的领导等都对产品经理负责。 按职能线划分的团队对多个产品间的资源共享有利，可以让资源流向更需要的地方，保证对核心产品的投入，但是效率不高，由于产品规划的决策需要在更高层面上敲定，单个产品的发展速度会有所降低。此外，资源战争可以把“鲶鱼效应【28】”从产品内部扩大到公司层面，使产品经理和设计师们更抓狂地为产品的发展而苦苦思索，这是一件好事。
108. 两种组织结构，给我“一攻一守”的感觉，产品在创业期的时候，需要全速发展，必然是产品线结构，产品经理带头往前冲。而当公司里有多个产品慢慢成熟之后，就多用职能线来更充分地利用资源，因为在成熟的产品团队中，要做的事情通常比创业时期少，或者说没那么急，那么各种资源就显得有富裕，可以更加稳扎稳打，所以按职能线划分以实现资源共享，同时还可以促进不同产品团队之间的互相学习，让员工的个人能力得到更多的提升。
准备出发：把需求打个包
109. 我们把产品需求列表按照“性价比”从大到小排序过了么？从上往下看，每一行后面都还对应着一个“工作量”，现在我们只要做一个简单的加法，一行又一行地从上到下依次纳入项目，能做多少，一目了然，我们把这个动作叫“需求打包”，而对这些需求的整体描述，也就是商业需求文档里的功能说明了。 当然，这只是一个基准，可变因素很多。我们每次产品会议都要准备好几个项目让大老板们选，每个项目也有可能在产品会议上被砍掉部分需求
110. 第一，“需求打包”最好打包类似的功能点。是否类似取决于需求的基本属性，这是“确定需求的基本属性”那一节里做的事情。一般来说业务上逻辑关系密切的需求才会包含在一个项目里，这也很好理解，否则就是一个纯粹修修补补的“小需求项目”了。实际操作中打包多大，更多的是取决于这一点。更好的方式是，需求在打包以后，通过业务逻辑图的方式可视化，可以更直观地给别人讲解。
111. 第二，需求依赖，功能互相之间有依赖关系。那些只能先做的功能，应该在产品需求列表里注明；功能与人力资源之间的依赖关系也会经常存在，比如有些功能只能由团队里的特定成员来做。
112. 第三，需求的粒度大小问题。商业价值很高的功能，如果细分的话，我们会发现其中也有价值相对低的部分，所以需求的粒度应该尽量细，前提是细化引起的管理成本上升在可接受的范围内，举个生活中的例子帮助大家理解：大开间办公区域里的灯，不可能用一个开关控制，也不可能每一个开关只控制一盏灯。具体细到多少，要根据具体情况具体分析。我们的经验是，在需求列表里出现的任意一行，工作量最好不要超过“5人天”。
战场：产品会议
113. 我们会拿出准备好的商业需求文档，每个产品都会拿出三五个，占满2～3倍的潜在资源。这里说的潜在资源，是指相对固定的开发、测试人员，因为技术人员有对产品的熟悉问题，所以在短时间内，不可能太多的人同时转去做其他产品，这也就意味着潜在的人力资源数量是在一个值附近做微小浮动的，所以我们也可以认为，在一定程度上，资源的争夺是以产品间的争夺为辅，产品内多个项目的争夺为主。很有意思的是，这三五个商业需求文档通常是产品团队里不同的人做出来的，所以内部也会争夺得你死我活。
武器：商业需求文档
114. 我们刚刚把需求打好包，接下来就要描述一下这个包了，这就是商业需求文档，Business Requirement Document，简称BRD，它也是我们参加资源争夺战的武器。
115. ——BRD怎么写，都包含哪些内容。 项目背景：我们在哪里？为什么要做这个项目，解决什么问题，可以列出一些数据说明项目的必要性。 商业价值：我们去哪里？最关键的重点！大老板们最感兴趣的，做了这个项目以后有什么价值，一定要说在点子上。一般我们还会预测一下相关数字的变化，提出这个项目的商业目标。 功能需求描述：我们怎么去？通过做哪些事情来达到目标，把打好包的需求描述一下，可以用功能列表的形式表达，但最好能画出业务逻辑关系。当然我们也经常会搞点技巧性的东西，比如故意加入一些让老板砍的需求，希望老板砍完之后心有愧疚不好意思再砍我们真正想做的东西，这有点类似谈判技巧里的玩意，大家可以试试，但不要在这上面太花心思了。 非功能需求描述：提一下重要的非功能需求，如果有的话。 资源评估：第二个重点！大老板们要看成本，他们在了解达成项目的目标需要多大的花费以后，才能做出决策。 风险和对策：有的项目会有一些潜在风险，这个时候不妨抛给老板们看一下，并且给出自己的对策，说不定你觉得是很大的麻烦，在老板那里一句话就可以搞定。而且由于信息的不对称，我们无法了解某些功能是否会与公司将来的战略冲突，这时候提出来也是让老板们把一下关。 从BRD中的“商业价值”、“资源评估”两个重点中大家可能也发现了，其实本质上大老板们也是在追求那个词——性价比。大家都希望花费最少的资源获得最大的商业价值。
116. BRD转化为项目也并非一一对应，很可能老板会把多个BRD合并为一个项目，或者把一个BRD拆成多个项目，或者直接砍碎了再重新组合，这都无所谓，不管怎么说，产品会议开完以后，我们终于确定了接下来一段时间要做哪些需求了，准备启动项目，迎接新的开始。
2.4.2 别灰心，少做就是多做
117. 情愿把一半的功能做到尽可能完美也不要把全部功能都做成半吊子。越来越觉得当发现一个功能可有可无的时候，甚至只要是没有强烈的理由要做的时候，要明确的选择：不做！现在我们可以自我安慰了——少做就是多做！
最爽就是“四两拨千斤”
118. 我们应该在动手前先找找有没有成本低，收效大的解决方案！
尽可能多地放弃
119. 我说“尽可能多地采集”，这里，我又说“尽可能多地放弃”，看似矛盾，其实正反映了我们对事物的认识过程，只有在收集阶段没有遗漏，才可能完整地看到事物的全貌，有了大局观，在放弃的时候才知道孰重孰轻，也更下得了手。
2.5 心急吃不了热豆腐
120. 没有产品是生下来就完美的，一天又一天，一月又一月，我们的产品反复地经历着需求采集、需求分析、需求筛选的过程，不断进化。我们不要想一口吃个胖子，很多案例表明，追求一步到位的产品经常像陷入沼泽的巨兽，挣扎着一步步走向死亡，用户甚至根本都不知道它曾经存在过。 在这个过程中，需求会越来越多，永远做不完，就像工作永远做不完一样。而我们要做的事情是，在资源限制下找到最有价值的需求，然后把它做好。那么，新的问题产生了，我们得找个办法把越来越多的需求管理起来。
一个需求的生老病死
121. 需求状态。通常有“待讨论”、“拒绝”、“暂缓”、“需求中”、“开发中”、“已完成”几个状态，可按照实际情况有所增减，比如管理的粒度细一点，还可以增加“测试中”。 负责PD。在需求状态变为“需求中”时指定，最可能是此需求的提交人，在需求的整个生命周期中，此人要从头到尾跟进，是这个需求的主人。 开发工程师。在需求状态变为“开发中”时指定，负责这个需求的技术实现，以及将来可能的故障解决。其他比如测试负责人，项目经理，大家可以按需要决定是否填写。 项目名称。辅助信息，在需求进入“开发中”时确定，用来筛选某个项目的需求。 发布时间。辅助信息，在需求状态变为“已发布”时填写，用来查看某段时间发布的需求。 备注。其他任何信息都可以写在这里，如：需求被拒绝的理由，需求被暂缓的理由和重启条件，其他相关文档，等等。
一个需求的DNA
122. 我们每次“需求讨论会”讨论的，自然是状态为“待讨论”的需求了——所有的需求由提交人录入列表，初始状态都标为“待讨论”。“商业价值”讨论确定的时候，它们的状态一定要变化，或是进入“需求中”，意味着要继续“初评工作量”，“计算性价比”，甚至进行“需求打包”并做成BRD了；或是被“拒绝”，拒绝的需求是被认为对产品的商业目标在相当长时间里没有价值的，不那么明显的最好在备注里注明拒绝理由；或是“暂缓”，暂缓的需求是“有价值，但是现在不做”的，通常要表明重启的条件，常见的有“3个月后再拿出来讨论”、“某相关产品实现某功能后再拿出来讨论”等。 而产品会议上通过的需求，状态会变成“开发中”，正式进入项目，项目发布，这个需求的状态又变成“已发布”。产品会议上没通过的需求，连同“需求中”但未被打包的需求，状态可以转移到“暂缓”，并备注说明情况。
需求管理的附加值
123. 统计每个“提交人”的需求数量：可以看出产品团队里每个人提交了多少需求，如果再加上时间段的条件，就可以从一个侧面反映出某段时间每个人的工作情况，老板们一定喜欢看这样的内容。 统计“提交时间”、“发布时间”等信息：比如按月统计，可以从需求数量的侧面看出产品发展是在增速还是在减速。如果需求提交的数量明显减少，我们就需要考虑对策了。 统计每个“模块”的需求数量：因为需求都是直接或间接的从用户那里采集的，所以从各个模块的需求数量分布可以看出，用户对产品的哪些模块感兴趣，可以指导产品发展的方向。 统计每个“分类”的需求数量：从各种分类的变化，看出最近是在做新功能，还是更多地做老功能优化，从而了解产品是在成长期还是成熟期。 统计需求的“商业价值”、“性价比”变化：可以看出这个产品的发展空间还有多大，如果连续几个月，需求的“商业价值”、“性价比”都不高，就要考虑改变方向以求突破了。
和需求一起奋斗
一个需求的奋斗史
第3章 项目的坎坷一生
3.1 从产品到项目
做产品VS.做项目
产品经理VS.项目经理
为什么让产品经理管项目
3.2 一切从Kick Off开始
帅哥美女，我们需要你
别忘了最初的约定
沟通从头开始
不可或缺的誓师大会
任何时候都要心中有“树”
3.3 关键的青春期，又见需求
3.3.1 真的要写很多文档
产品需求文档，PRD
学一点UML：类图、用例图、状态图
用例文档，UC
再学一点UML：时序图、活动图及其他
Demo也要我们做吗
概要设计与详细设计
3.3.2 需求活在项目中
评审：一个头两个大
再看需求的生老病死
3.4 成长，一步一个脚印
开发阶段，旁观者说
测试阶段，大家一起上
Bug眼中的项目
那一夜，项目发布
以终为始，项目小结
怕什么来什么，只能拥抱变化
3.5 山寨级项目管理
3.5.1 文档只是手段
建立自己的文档规范
模板作用知多少
多人协作与版本管理
玩转Office足矣
3.5.2 流程也是手段
项目VS.流程
流程的本质目的
那么多评审，可以省吗
商业评审与技术评审
3.5.3 敏捷更是手段
从书本到实践
项目中的敏捷沟通
与外包团队的敏捷尝试
3.6 物竞天择适者生存
3.6.1 亲历过的特色项目
如何做好“老板项目”
秘密行动，封闭开发
开发外包，项目外包
3.6.2 一路坎坷，你我同行
几个项目的成败
一次只有七天的战斗
3.1 从产品到项目
1. 项目的定义【1】： 只会进行一次，包含多项互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。
2. 从这句话里看出，产品是一个解决问题的东西，而项目是一个过程
做产品VS.做项目
3. 第一，从生命周期的角度来看。 做产品的生命周期相对较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程。而项目有特定的目标，所以生命周期较短，通常在项目开始以前就有明确的起始和结束时间，通过验收则表示项目生命周期就算完成了。 我们要开始做一个产品的时候，没法明确这款产品何时“结束”，一般会随着时间的推移、市场的变化、公司战略调整等因素，渐渐走向“生命周期完结”。所以，会有一个已经“结项”的项目，但不可能有一个已经“完成”的产品（只有不断完善中的产品，除非它被新产品替代）。
4. 第二，从具体要做的事情来看。 做产品的过程，会有更多的探索，随着各种内外部信息的变化，产品负责人需要不断地修正自己的判断，给出适宜的创新；而项目在开始时就已经有明确的目标，更注重计划与控制，项目的过程很像是执行一个任务。当然，也有很多事情无论是做产品还是做项目都是必不可少的，比如与团队成员的协调沟通，对未来一段时间做出计划等
5. 第三，从产出物的角度来看。 产品是可以批量生产，或者提供给大量用户的，所以相对通用，通常考虑用有限的资源去满足更多的、能有更多回报的需求；而项目只进行一次，意味着每次都是定制的、个性化的，通常为了满足特定的需求，产出物也比较个性化。这就意味着，项目要满足那个特定的需求；当然我们会看到有的项目产出物经过改造，成为更通用的产品，或者有的产品也可经历“个性化定制”（即做项目）。
6. 一家小软件公司接到某酒店的订单，要在6个月内做出一套管理软件，典型的一个项目；而一家大一点的软件公司发现了这个市场，受此项目的启发做了一套通用的软件，可以卖给很多的酒店，就更像做一款产品
7. “做产品”和“做项目”也是分不开的，“做产品”的过程，正是通过做一个又一个项目实现的，但并不是项目的简单累加。在产品渐渐满足目标用户群体的通用需求后，继续做下去的话，会使产品成为项目的集合体，臃肿不堪，因此我们就需要细分市场，这时候产品可能升级为“产品线”，按不同的细分市场，推出不同的产品，表现形式上叫版本、模块、增值服务，什么都行，本质上是通过合理地安排项目来实现产品的规划。
产品经理VS.项目经理
1. 产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。 项目经理——靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。
2. 产品经理关注的是做正确的事，关注的是产品生命周期，关注的是产品能否赚钱，能否持续地赚钱。因此产品经理必须要能够规划整个产品的架构和发展路线，能够确定产品的定位和受众，能够预计产品真正的价值和效益。 项目经理是需要正确地做事情，即按照产品规划制定的项目目标正确地做事情。项目能够按照目标完成则项目就是成功的，即使项目的产品不能真正赢利，那往往也是产品规划出现了失误。 项目经理关注的是项目能否按照既定的目标顺利完成。产品究竟应该规划哪些功能点那是产品经理的事情，是项目范围的输入。
3. 用我自己的话总结，就是：一个内部驱动，一个外部驱动。 对产品经理来说，最重要的是判断力与创造力，产品经理决定做不做、做什么、做多少，保证方向正确。他是产生一个想法，“我要把它实现！” 对项目经理来说，最重要的是执行力与控制力，项目经理决定怎么做、谁来做、何时做，保证方法得当。他是接到一个任务，“我要把它完成！”
为什么让产品经理管项目
1. 后来公司发现这样的一些弊端： 对PD考核的是产品的商业价值，比如用户活跃度等，而这些指标和产品的用户体验关系极大，大家知道，想把产品的用户体验做到极致，让用户轻松，通常我们就要“受罪”，特别是开发的同学，要额外做很多在他们看来价值不大的细节工作。 比如一个最简单的登录页面，有两个输入框，一个填账号，一个填密码，想体验好一点，就要考虑如何限制输入内容长度，如何控制输入非法字符，如何给用户提示等很多问题。仅仅是“输入账号的字符长度控制问题”，就又要考虑是单击“登录”按钮提交数据时判断？是鼠标焦点移动到密码输入框时判断？还是输入账号时随时计算长度直接判断…… 矛盾产生了，开发工程师的考核一般是项目的完成情况、Bug数量等。很显然，如果他们做项目经理，就会倾向于简化项目，尽量少做、做自己熟悉的，使得项目顺利完成，并且Bug很少，但是做出来的东西也许会商业价值不足、用户体验不好。 由于上述原因，公司决定让PD兼任项目经理，希望能让对商业目标负责的人自己来掌控，在商业目标、项目资源、用户体验等各种限制条件下取得平衡，解决目标不一致的问题。
2. 当然，在项目中仍然保留了开发经理，毕竟在“哪位工程师更适合做哪个任务，需要多少时间”这类问题上，他们是专家。
3. 一个事物必然有它的两面，如果你只看到了一面，说明你只看到了系统的一部分，这时你一定要跳出去，寻找另一面，之后再努力寻找“对立”背后的“统一”，正如黑格尔所说的“正反合”【2】。 果然，2009年的时候，我了解到有的团队又调整为让开发经理担任项目经理了。主要是发现PD会不断地给项目增加新的需求，导致项目总是无法按期完成，继而大家怨声载道，影响了团队的士气。 其实公司也是一直试图通过职责的划分，寻找一个平衡点，但作为产品经理或项目经理来说，如果认识到问题的本质和公司的良苦用心，也就无须在意形式上是谁来做项目管理了，正如下面这段话所说： 一个产品经理可能想要增加非常多的功能和特征以满足获取到的用户需求，但是项目经理却想要尽可能小地控制工作范围，以保证项目在规定时间与预算内完成。好的产品经理和好的项目经理能在冲突中找到平衡。好的项目经理明白，一个项目真正的成功并不是看它是否在规定的时间和预算内完成，而是它是否达到了拟定的目标。好的产品经理则明白，如果项目被不断延期并且从未投入市场，又或者因为大大超过预算而被结束，那么所有的产品功能特征都会变得毫无意义。
3.2 一切从Kick Off开始
1. Kick Off是足球比赛开球的意思，现在被广泛用于开始做某事，在项目里指的是项目的启动大会，而启动大会及其准备工作（主要是团队组建和各种计划的确定），就是所谓立项阶段的工作内容，如图3-2所示。
立项阶段的工作内容
帅哥美女，我们需要你
2. 因为产品经理并没有行政上的管理权，也就意味着每次项目都需要去跟不同团队的主管、经理要人，所以其中的艰辛也只有经历过才能体会。
3. 我做过的一个项目，在需求阶段由于合作部门的PD太忙，所以屡次无法兑现承诺，被逼无奈，我只好给他的主管写了一份邮件，抄送给了一些相关人员，争取资源。下面就是当时的邮件与回复。 发送时间：2008年9月9日 11:53 主题：双龙会项目，PD的资源问题 重要性：高 Hi，××，不好意思，打不通你电话，这个事情比较急我还是发邮件说明一下。 双龙会【3】的项目时间很紧，现在我们碰到了一个问题，王××由于手头A产品的客户问题很多并且都很紧急，占用了不少时间，导致能够做本项目的时间不足，他自己也很辛苦。 现在已经产生了一个小问题：今天原本要做的UC评审，但是到现在还没法确定时间，希望我们能一起防止问题扩大！ 希望能提高本项目工作的优先级，不然需求的延期很可能导致整个项目的延期，希望××可以支持，帮着协调一下，非常感谢。 发送时间：2008年9月9日 13:22 主题：答复：双龙会项目，PD的资源问题 已经安排××接手处理有关A产品的客户问题。王××会集中精力参与双龙会项目。
4. 这样的方法快速有效，却似乎少了点人情味儿，个人不建议经常使用。好在有这么几点可以降低团队组建的难度，一是我们启动的项目都是经过产品会议，大老板们认可的，所以基本的资源有保证，但资源充足的情况就比较难得了；二是经常合作的都是相对固定的人，沟通也比较顺畅，所以说PD新人不太适合做项目经理，通常要和团队混到脸熟以后再说，这可不单是个人能力问题。
5. 在项目的组织结构中，项目经理并不是结构中的顶端，我会组织一个“项目督导委员会”，这很有必要，成员一般是项目成员的老板，甚至老板的老板，他们的任务也很简单——“背黑锅”和“买单”，因为权力越大，责任越大。当项目因为种种原因出现重大变更的时候，比如成本、时间、需求等，我会向他们提出申请，获得批准后才执行变更，这也是项目经理对自己和项目成员的保护。而在整个项目过程中，各种资源的提供也需要靠他们，除了人，还有很实在的项目经费，有可能的话都尽量多要一点，最好有富余，但也要尽量省着用。整个项目期间，各种信息会随时知会督导委员会成员，但大多数情况老板们无须有什么动作，所以他们也乐于参与。同时，对于项目成员来说，知道老板们随时在监督项目，并且看得到自己的努力，所以也会做得格外卖力。
典型的项目组织结构
6. PD，负责这个项目的需求，他们中的某一个可能兼任项目经理；开发经理及其团队，负责开发相关的任务，其中开发经理需要负责开发的时间计划与任务分配，并全程掌控设计、编码直至上线的过程；测试经理及其团队，负责测试相关的任务；UE（用户体验团队），对于互联网、软件类产品来说，负责产品给用户的展现，比如交互效果、视觉效果等；服务团队，负责产品帮助的编写，以及上线后的服务工作等；
7. 一般来说，最关键的几个人到位了，就可以继续做下面的事情。他们通常是项目经理，需要统筹管理整个项目；PD，开始写需求文档；开发经理，制定项目的开发计划。
别忘了最初的约定
8. 还记得BRD里给各项需求做的工作量初评吗？现在把这些信息再一次拿出来参考，因为从产品会议结束到制定项目计划的日子中，PD们同时也在做PRD【4】的细化，开发的同学看到PRD时，每个功能点的工作量评估得已经更准确一些了。更重要的区别在于，初评工作量的时候是开发经理之类的角色统一评估的，未考虑谁来做，而现在是开发经理根据团队里开发工程师的能力特点、擅长领域等因素，“因事择人”，把各项开发任务分配给最合适的人（当然，要把高手调入项目的关键路径【5】）。之后，每一位领到任务的开发工程师自己评估工作量，为各自的任务买单，承诺最可能时间。之前的初评只是一个参考，毕竟每个人对自己最熟悉。常用的方法是“三点估算法”，即评估出最乐观的工作量、最悲观的工作量、最可能的工作量，然后按下面的公式估算出工作量： “工作量＝（最乐观＋最悲观＋最可能）/3” 或“工作量＝（最乐观＋最悲观＋最可能×4）/6”
9. 之后，开发经理会把项目中各位工程师评估的工作量做汇总，推算出工期，需要注意的是，工作量只是说某人完成这件事需要多少时间，而工期是转化到日历上，说明这件事从何时开始到何时可以结束。这时候要考虑到各项任务的依赖关系，以及项目成员在这段时间内的其他工作，并适当留出机动时间。
沟通从头开始
10. 项目沟通方式各有不同： 周期：以“日”或“周”为单位，主要取决于项目时间的长短及变化的频率。 渠道：会议、邮件等，需要在成本和效率之间取得平衡。 发起者：一般由项目经理、开发经理、测试经理主导相应的沟通。 参与者：发起者确定参与者，不要遗漏项目边缘的同事。 不管选择何种沟通方式，目的都是相同的——为了项目成功。一般来说，常做的项目，通用的沟通方法有如下几种，供大家参考。
11. 项目晨会：自项目进入开发阶段至发布日止，开发经理每日召集相关人员，主要是PD、开发人员、测试人员参加。 项目日报：自Kick Off起至发布日止，项目经理每日发给项目的所有干系人，测试开始后以测试日报为主。 评审会：相应PD召集需求评审；相应开发人员召集设计评审；相应测试人员召集TC【6】评审；产品可用之后，项目经理尽快召集功能评审【7】，项目所有干系人参与评估。 项目变更申请：项目发生重大变更，项目经理与项目督导委员会沟通后确认变更。 发布预告及公告：项目经理在项目发布前两个工作日发预告给项目所有干系人，项目发布成功后发公告给所有干系人。
不可或缺的誓师大会
12. KO通常只需要15分钟左右的时间，在这15分钟内，需要传达的信息有如下几点。 项目背景 我们在哪里？说过去，做项目之前的“悲惨境地”，明确为什么要做这个项目，以让听众“痛下决心”为终极目标。 项目意义、目的与目标 我们去哪里？说将来，做项目之后的美好前景，解决什么问题就算成功了，以让听众“面带桃花”为终极目标。 需求、功能点概述 我们怎么去？说现在，具体用什么方法促使“过去”到“将来”的转变，以让听众“跃跃欲试”为终极目标。 上述这三部曲其实和BRD里的项目背景、商业价值、需求描述大同小异，可以借用，下面三点就是新鲜的了，也正是之前三节准备的内容。 项目组织架构 目的是让项目成员互相认识，明确有什么事应该找谁。
13. 项目计划 让所有人了解两个关键点： 第一，项目的时间点与里程碑； 第二，各个时段需要的资源，即每个人要在各个阶段做什么事情。
14. 沟通计划 和项目全体成员明确这点非常重要，因为太多事情的不顺利都是沟通的问题，大家都做不到一直主动、彻底地沟通，所以有个规矩来逼着做一些沟通的工作，并且在项目开始的时候就约定好，可以免去很多麻烦。 最后提一点，凡是会议，就总会有人缺席，所以别忘了把会议记录发给所有干系人。
任何时候都要心中有“树”
15. 项目就要正式开始了，在这里我简单分享一下对项目管理的理解。感兴趣的同学可以阅读项目管理的相关书籍，并根据项目的情况，灵活应用最合适的项目管理方法。 做项目的目标无非是多快好省：范围大、时间短、品质高、资源省。但又要马儿跑又想马儿不吃草的事情是没有的，有理智的老板们也都明白这一点，所以我们通常是在上述4个要求中做平衡。 上面所说的目标对比经典的项目TRQ：项目时间（Time）、项目资源（Resource）、项目质量（Quality），几乎一样。一点小区别就是Q（质量），我觉得把Q解释为“Quality+Quantity”（品质+数量）更准确，而我所经历的项目，Q更多的是表达Quantity（除非有特殊情况，“品质高”这点是不会舍弃的，所以可变的是项目范围）。 综合一下，我们做项目的本质就是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。
3.3 关键的青春期，又见需求
3.3.1 真的要写很多文档
16. 抽象到具体的过程主要产出的文档：BRD、MRD、PRD
17. 抽象到具体的过程主要产出的文档：BRD、MRD、PRD和FSD。 BRD：Business Requirements Document，商业需求文档。这是产品生命周期中最早的文档，其内容涉及市场分析、销售策略、赢利预测等，通常是给大老板们演示的PPT，比较短小精炼，没有产品细节，有点像创业者给投资人看的商业计划，主要为了获得认可，争取资源。 MRD：Market Requirements Document，市场需求文档。获得老板们的支持后，产品进入实施阶段，需要写出MRD，要有更细致的市场与竞争对手分析，包括可通过哪些功能来实现商业目的，功能、非功能需求分哪几块，功能的优先级等。实际工作中，PD在这个阶段常见的产出物有产品的Feature List、业务逻辑图等，这是从商业目标到技术实现的关键转化文档。 上述两份文档都是给老板看的，里面偏商业的内容，我会在第5章“别让灵魂跟不上脚步”里做更多描述，接着往下看。 PRD：Product Requirements Document，产品需求文档。PRD是对产品功能的进一步细化，是PD新人写得最多的文档，也就是我说的“需求开发”过程。文档主要包含整体说明、用例文档、产品Demo等，会对产品功能做具体描述，更多内容在下一节详细讲述。 FSD：Functional Specifications Document，功能详细说明。比较像我们常写的用例文档，经常包含在PRD中，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定，比如网页上的某个表格中的数字，应该左、中、右对齐？保留几位小数等，有点像“概要设计”。与此同时，硬件系统的设计、数据库设计、表结构设计等工作，也开始由架构师、系统分析师们编写了。
18. 需要说明的是，每个公司并不会严格地写这么多文档，比如我在阿里待过的团队主要写BRD和PRD，我们说的BRD实际上包含了上述BRD和MRD的核心内容，PRD实际上包含了上述PRD和FSD的核心内容；而百度有的团队主要写MRD，包含了上述前三种文档的主要内容。有时候叫法相同内容不同，有时候叫法不同内容相同，关键是我们要知道写这些文档的目的，说清楚哪些事就可以了。 上面说到的后两种文档主要是写给技术人员看的
产品需求文档，PRD
19. 这里我们说说PRD。通常一个项目会有一到多份PRD，每一个PRD会包含逻辑相关的若干功能点，这些相关的需求在“需求打包”的环节已经被识别出来，也就是产品需求列表里的若干行。
20. 开始是一些总体说明。 图3-7
一份实际的PRD模板目录与结构示意图
21. 一份实际的PRD模板目录与结构示意图 修订历史：写清楚每次修订的日期、版本号、说明和作者，便于以后追溯。 项目概述：简单描述项目的背景、意义、目的、目标等，描述业务领域知识，让文档读者明白这个项目是为什么而做，这部分内容可以参考Kick Off会议所用PPT里面的内容。如果此PRD没有包含项目的全部需求，也应做相应说明这部分需求是什么，其他需求在哪里等。 功能范围：给出本PRD的业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规则等。 用户范围：对本PRD涉及的角色、系统做出简单的说明。 词汇表：对本PRD涉及的专有词汇、术语、缩写等做出说明。 非功能需求：如性能需求、数据监控的需求等。我们公司曾要求过针对每个新功能设置监控点，并且在功能上线两周后，由PD给出数据分析报告，以验证是否达到预期的商业目标，从而不断改善前期判断的准确度。 其他说明：其他任何需要说明的内容都可以写在这里。
22. 总体说明之后是用例文档部分，首先需要对这个PRD中所有的用例进行说明，给出用例的可视化表示，说明各个用例之间的关系，一般有类图、用例图、状态图几种表示方法，其中用例图最为关键
23. 接下来是用例的正文，由一个个的用例组成，这部分也就是我们常说的——用例文档【9】。 最后一部分“对单个UC的说明”是一些注释，我常用的PRD模板里有如下内容： 注1：视觉层面的描述通常直接通过Demo表达（如页面大小、颜色、字体、字号等）； 注2：界面细节，引用界面规范文档（如表格中的文字对齐方式等）； 注3：交互细节，引用交互规范文档（如出错提示的方式等）； 注4：文案细节，引用文案规范文档（如各种提示文案等）。接下来，我们从用例文档部分慢慢说。
学一点UML：类图、用例图、状态图
类图
用例图
状态图
用例文档，UC
24. 首先是UC概述： 用例的唯一标识：我们拿PRD“小明下馆子”中的“点菜”为例，其中唯一标识记为“UC_ordermeal”，这项我们经常偷懒不写，关系并不大。 用例名称：就是“点菜”了，用一个短语讲清楚这个UC是做什么的。一个UC写一个任务，任务的粒度可以自行把握，比如同样是“增加、删除、修改订单”，在新人、新业务的情况下，就最好分为三个用例详细描述；如果是“老人”、老业务，也许用一个“管理订单”的用例描述就足够了。 业务描述：商业目标、用户目的等业务内容，说明为什么要做这个UC？例如，小明工作一周辛苦了，周末晚上会去吃一顿好的犒劳一下自己。 需求描述：产品需求，需要实现哪些功能点，这个UC要做什么？去餐厅，点几个菜，之后等烧好了吃掉。 行为者：该用例的Actor，小明。 前置条件：触发这个用例的前提是什么？周末，小明有空去餐厅等。 后置条件：用例完成，后续动作是什么？服务员接受订单，去厨房等。 其他说明：任何其他信息，针对这个UC的特殊说明，没有就空着。 然后是UC主体： 界面描述：通常互联网、软件产品中界面描述会占很大的篇幅，给出截图，界面上各种元素的说明，并且会和Demo关联起来，当然还有一种做法是单独写界面文档，然后与UC文档互相引用。不过小明的例子中并没有界面描述。 业务规则：整个用例的通用规则，比如限制条件小明不吃辣、小明预算只有100元等。而界面元素或流程中的私有规则不适合写在这里。 流程描述，分主干、分支和异常三种，描述在这个用例发生的过程中，由什么事件触发，系统与用户之间产生何种交互步骤，这里尽量用时序图和活动图来替代文字描述，具体的例子下一节给出。
现实中的UC模板
再学一点UML：时序图、活动图及其他
25. 刚才提到了UC里的流程描述，我们再学几种UML的图，它们描述的是用例的内部事务。当然，用例内部不一定是“单个用例”内部，也可能有用例之间的关系。这些图在描述业务规则和流程的时候非常有用。
时序图
活动图
Demo也要我们做吗
26. PRD写完了，工程师拿着它就可以开发了吗？不是。还缺了很重要的一块，产品Demo，也经常被说成是产品原型、演示版、Mockup。
纸面demo
线框图
27. 产品不同，用到的Demo工具会不同，或者各个阶段也会不同，还是那句话，心中有剑，手上拿根树枝都能杀人。我看过用Windows自带的画图板都能画出很清晰的Demo的强人，当然我不是要大家学他，只是又想说，最重要的不是工具。
概要设计与详细设计
28. 我在写UC的时候，经常写着写着就觉得是在越俎代庖地做概要设计，甚至是详细设计的事情了。
29. 每当此时我都很纠结，询问工程师后也常常会得到相反的答案：有人希望你写得越详细越好，而有人希望你交给他决定。后来我们渐渐总结出两种做法。
30. 每当此时我都很纠结，询问工程师后也常常会得到相反的答案：有人希望你写得越详细越好，而有人希望你交给他决定。后来我们渐渐总结出两种做法。
3.3.2 需求活在项目中
1. 我们辛辛苦苦地把各种需求文档都写完了，开发和测试的同学可不敢拿过去直接就用，为了保证产品的质量，需求还必须要在项目中通过各方的评审，方可进入开发阶段。
2. 项目中的需求阶段，通常会围绕着“写作→评审→修改→评审”循环展开
评审：一个头两个大
3. 往简单了说，评审就是项目中相关的几个小团队坐在一起，一方讲，另外几方听并确认，统一认识，消除误解，及时发现偏差，防止问题随时间放大。不做评审，当时看似省了时间，但往往隐藏了问题，待到其爆发的时候会耽误更多事，而且会在谁负责的问题上纠缠不清。与其亡羊补牢不如尽早在流程上预防，所谓“防病优于治病”。
4. 我做过的项目中，最重要的三种角色就是PD、开发人员、测试人员，所以派生出三次评审——需求评审、设计评审、测试评审
5. 需求评审，是PRD评审、UC评审、Demo评审的统称。于需求的相应部分完成以后进行，评审会上PD把PRD和UC说给开发、测试听，Demo评审则由UE的同学主讲。
6. PRD评审会重点关注偏商业的内容，强烈建议叫上老板、营销人员、服务人员，甚至用户一起来听。
7. PRD通过以后，PD们会和UE的同学一起细化UC和Demo，而开发的同学也会同步进行一些开发前的准备工作，比如细化和修正项目计划，部分系统的设计等。接下来的Demo评审，决定了产品的外观，项目干系人最好都来把一下关，而UC评审更偏重技术实现，商业团队的成员可以选择参加。
需求阶段的工作内容
8. 设计评审，是在概要设计与详细设计完成之后进行，由开发工程师把对需求的理解以设计文档的形式说给PD、测试听。
9. 测试评审，俗称TC评审，是在TC编写完成，测试开始执行之前进行，由测试工程师把对需求的理解以TC的形式说给PD、开发听。
10. 每一种评审都可能有多轮，会上没问题就快速地通过，有小问题当场确认，大问题带回去，原则是“改动较多的话必须再次评审，异议不大可以通过”。
再看需求的生老病死
11. 如图3-17所示是一个简化版的项目流程，也是一个需求从提出到发布的流水账，对于小型团队应该比较实用。
日常需求发布流程
12. 项目开始之前。在产品团队内部分析需求商业价值的需求讨论会、多个产品间的产品会议上，PD们带着自己的需求参与讨论，为那仅有的开发和测试资源PK。人性的本能让每个人都极力地维护自己提出的需求，并设法反驳别人，当然出发点都是为了用户，最终也会达成一致。“活下来的”需求会确定需求负责人，状态变为“需求中”。 项目中的需求阶段。项目启动之后，PD就得抓紧时间完成需求的开发，不时召集需求评审会，大家一起讨论这样做有哪些问题。PD收集到意见反复修改需求，直至最后一次评审通过，需求得以确认，状态变为“开发中”。当然，之后的需求微调总是无法避免，但“需求冻结”的里程碑要求我们在这之后就不要轻易改动了。 项目中的需求阶段之后。进入开发之后，PD需要不断地和开发、测试人员确认各种细节。我们一直想在早期环节中考虑到所有的细节，以期减少这种费时费力的确认，但事实证明细节总是多到无法预计，有的甚至要发布后才被发现。在开发提交测试之后，PD需要在测试环境【19】中代表产品的用户做功能验收，确认一下产品与自己的设计是否相符，顺便也可以发现一些可用性问题。当然如果能让真实用户来验收则更好，通常我们会组织一次功能评审会，让项目干系人来确认这些功能是不是大家想要的，如果有问题还可以补救。最后功能上线，别忘了把Feature List中的相应需求改为“已发布”。 很显然，需求发布之后仍然会有改动，可能是客户反馈了问题，或者自己想到了更好的解决方案。我们的做法是把它视为一个新的需求或当做一个Bug，重新进入流程。
3.4 成长，一步一个脚印
13. 我们会把“需求评审通过”视为项目中一个重要的里程碑，称做“需求确认”或“需求冻结”。之后进入开发阶段，如果还需要修改需求的话，不是不可以，而是要更加慎重，甚至是强制走一些需求变更的流程。这也是为了更好地控制项目风险，在信息充分的情况下，随着项目的进行，风险应该越来越小，否则项目必然有问题。
14. 需求阶段之后的常规项目过程就是开发、测试、发布，需要注意的是，这类项目都是围绕着产品研发工作的，所以没有包括上线后的销售、运营、服务等活动。之前我们谈过的立项与需求阶段，那是PD作为主要角色参与的环节，而本节重点讲述的内容之做事的主力则是工程师们，我们作为PD要随时配合他们确认需求，项目经理要做的就是“控制”。
开发阶段，旁观者说
开发阶段的工作内容
15. 比较强的开发工程师，可能叫开发经理、架构师、系统分析师等，会带着普通工程师一起做概要设计、详细设计，如果项目涉及数据库、硬件系统的改动，那就还会带上运维的人员。设计完成以后，会组织一次设计评审，PD和测试人员都会参与，审核一下工程师们对需求的理解是否正确。 评审通过以后，就进入编码阶段，编码完成以后，如果时间充裕可以做一些代码评审的工作，不过我们的项目一般都紧张，代码评审的工作通常只能在开发工程师提高自我修养的周例会上进行。
16. 之后工程师们需要对自己的代码做单元测试，自测环节做到位，可以减少后期测试同学很多的工作量，问题总是越早发现解决的成本越低。 当开发工程师认为自测已经完成，就可以把代码从开发环境上提交到测试环境了。按照开发计划，当项目的主体部分提交测试的时候，我们又走过了一个里程碑——开发完成。
测试阶段，大家一起上
17. 开发工程师在设计与编码的同时，测试工程师也没有闲着，他们会继续细化和调整测试计划，并完成TC编写的任务。在TC中，测试人员会进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。 测试阶段的主要任务如图3-19所示。
测试阶段的工作内容
18. TC编写完成后，测试经理会组织TC评审，时间一般在开发人员提交测试之前，PD和开发人员都要参与评审，再次确认大家对需求的理解是否一致。很多需求的细节无法在需求阶段考虑完全，我们会通过开发和测试阶段的反复沟通来不断细化。 TC评审通过，待开发提交测试以后，测试人员迅速完成一轮“冒烟测试”【20】，目的是确认软件基本功能正常，可以进行后续的正式测试工作。 在测试人员正式开始测试的同时，PD又要出场了，我们会组织一次产品的“功能评审”，或者叫“产品演示会”，利用测试环境，把可以使用的产品在第一时间展示给所有的项目干系人，更进一步确保做出来的东西就是大家想要的。功能评审通过之后，PD一般还会代表用户做更详细的UAT【21】，或者称为“验收测试”【22】。 接下来，测试的同学会做多轮测试，是一个“发现Bug，开发修正，测试验证，发现新Bug”的循环过程，从第二轮开始就可以叫做“回归测试”，在Bug都处理妥当之后，项目紧接着就进入了发布阶段。有的项目除了功能测试以外，还需要做性能测试，比如验证系统是否能承受1万用户同时访问的压力，公司也有特定的测试工程师做这方面的事情，他们一般是多个产品共用的资源。 在测试阶段【23】，商业方面的准备工作也早已动起来了。PD可能要准备面向用户的功能、卖点介绍的文档，产品更新的公告；培训服务人员和销售人员；运营人员可能已经在策划推广方案；销售人员可能在更新销售说辞；服务人员可能在依据测试环境里的产品制作帮助……多个部门协同，很有大家在一起战斗的感觉。
Bug眼中的项目
19. 一般来说对一个Bug的描述有以下几个关键点。 ► 缺陷级别（Severity）：即上图中的Ⅴ级别定义，一般大于等于III级的Bug被认为是严重的问题。 ► 所属产品、项目：有的人需要同时处理很多产品、项目，这个属性可以用来筛选。 ► Bug名称：一个短句，对此Bug的简单说明。 ► Bug描述：写成如下形式，“执行某操作，期望出现什么情况，实际出现什么情况”，还可以添加截图、文档等附件。
20. 在发现一个Bug以后，我们会提交给相应的开发工程师，如果认为是需求问题也可以提交给对应的PD，这时候Bug的状态为Open，之后的状态改变，
Bug状态流转图
21. 任何人收到Open的Bug，确认并修复，状态变为Fixed；否认，也许提出者理解错了，也许不打算修改，状态改为Rejected；认为不是自己的问题，或者PD对需求问题作出解释以后，把Bug转交（Assign to）给了合适的人。 测试人员验证状态为Fixed的Bug，没问题了就Closed，否则可以Reopened。看到Rejected的Bug，发现是自己理解错了，就可以Closed，仍然认为是Bug的可以Reopened。对于Deferred的Bug，意味着本项目中暂不修正，可能是因为技术做不到、时间不允许、性价比太低等，这个认定必须慎之又慎，通常由能负责的人，比如是测试经理、项目经理最终同意才Deferred。
那一夜，项目发布
22. 在整个过程中，Bug的每次状态改变都可以添加注释说明，我们更鼓励在有争议时叫上当事人面对面的交流，而不是在系统里不停地纠缠。 到了项目发布之时，我们要求所有Bug的状态必须是Closed或Deferred，当然对I、II级的Bug，有时候并没有这么严格。
23. 辛苦了那么久，项目终于进入发布阶段了，可黎明前总是最黑暗，我们要考虑很多问题
24. 我们会安排专门的代码版本管理员，通常用SVN【25】，所以又叫SVN管理员，负责项目每日的代码更新。修改的代码从“每位开发人员的开发环境→测试环境→预发布环境→生产环境”一步步更新，如果版本控制不好，就会发生“改掉的Bug又回来了”
25. 然后，“发布计划”的评审也很重要，需要运维人员的确认。特别是对于系统改动较大的项目，可能需要分模块分步骤发布。比如我经历过的一次发布，涉及几十台服务器，就需要先更新几台××服务器，再更新几台××服务器，名词太专业我都叫不上来。对于用户影响较大的升级，我们有时候采用“分流发布”，或者叫“灰度发布”，即让一部分用户先用，然后收集反馈再决定大面积发布的时机。
26. 正式的发布过程，是从更新“预发布环境”开始的，预发布环境会尽量模拟生产环境上的真实状态，比如数据库用的是同一个，测试人员会在预发布环境进行最后的回归测试，没问题的话，更新“生产环境”，测试人员再做一次最简单的回归测试，完成发布。当然，这么多次回归测试，其覆盖面不尽相同，越到后面的回归，测试的内容越少，直至只包含最重要TC的“最小集”，来简单判断系统是否能正常运行。
27. 对了，在正式发布之前，可能还有一些手续要办，比如填写“发布申请单”，写上项目的大致内容与影响，让所有关键人物签字，大家最后确认一次；有时候我们会用E-mail形式的申请。有一段时间，我们公司还有“立项申请表”、“预发布申请单”等，每张表格都需要N多人签字画押，手续的烦琐也许会耽误时间，但是是为了防止出错，而每个手续的背后通常都有一段“血泪史”，如果你发现公司最近突然又多了一个单子要填，不妨去打听一下前段时间是不是有什么项目出了乱子。
28. 发布成功！回家睡个好觉。 所有人终于舒了一口气，但是作为项目经理，事情还没完，第一件事就是赶紧发出一封E-mail——“项目发布公告”。小项目的公告会比较形式化，而意义重大的项目就会写得很煽情了，比如项目中的种种艰辛、对每一个参与者的感谢、发布之后的内心感言、产品对公司和用户的革命性意义、贴几张产品的最新图片等，有时候还会有人诗性大发，再让视觉设计师帮着设计一些海报，不但邮件里用，甚至在公司墙上也贴几张。这封邮件也是一次内部宣传的好机会，我们除了发送给项目的干系人，甚至会抄送给整个公司。作为项目经理，应该时刻做到为团队成员争取各种精神、物质的奖励，这种邮件、海报、大老板的回信……都是很好的鼓励，如果还有项目经费的话，再组织一次聚餐，大家以后还要继续合作，开开心心，皆大欢喜。
怕什么来什么，只能拥抱变化
29. 一步一个脚印地走下来，这个项目似乎也还顺利，可是现实情况往往要复杂很多，有各种各样的不确定因素，真的是怕什么来什么，所以我们只能拥抱变化，常见的有下面几种。
30. 变更主要关注的是“需求冻结”后较大的变化。我们会制订一些流程做控制，不是为了限制变更，而是为了让每次变更都经过深思熟虑，最怕发生的情况就是需求方举棋不定，来回反复。流程会要求提出变更的人先和相关方确认，获得一致认可后，再修改文档、邮件说明、即时通信群里吼一声……而过大的变化或过晚的变化，比如到了发布前一天还在修改业务逻辑，项目经理有权决定是拒绝，还是上报更大的老板定夺。
31. 搭车事件，是指项目范围的扩展，一般来说，5个开发工作日以下的零散小需求不参与产品会议讨论，所以搭车事件总是存在。但我们要尽量搭顺风车，找内容相关的项目；尽量早搭车，在“需求冻结”之后一般不要再提；
32. 紧急事件，这也总是难免，所以一般由较高层的老板确认后自上而下的推动，不受常规流程的限制，越是高层确认的紧急事件，越可以突破常规限制优先处理。
3.5 山寨级项目管理
33. 带过我的一位老板说：“计划与控制，就是项目管理”，话虽简单，但做好太难。第3.2节到3.4节，我们从Kick Off开始讲到项目小结，先说计划，再说控制，完整讲述了项目的坎坷一生。这节中，我们再从互联网和软件项目自身的特点出发，看看项目管理中的几个关键问题，它们是：文档管理、流程管理、敏捷方法。
3.5.1 文档只是手段
34. 模板、规范、操作步骤……这些文档的作用实在太大了，大到导致有些朋友会醉心于此，特别热衷于问别人要一些很个性化的PRD模板、项目流程等，本来文档只是更好做事的手段，却被有的人当成了目的。
建立自己的文档规范
35. 通过几年的总结，我觉得图3-22中的文档基本能覆盖PD日常的绝大多数工作，从BRD开始，按顺时针顺序介绍一下各个文档。
36. 商业需求文档：很重要的BRD，单独列出，第2章里已经讨论过。 产品需求文档：同样重要的PRD，前文已有详细阐述。
37. 需求规范类： ► PD做什么：这是对产品和团队的PD工作内容的一份总结，可以让新人快速了解自己的工作职责。 ► 用户体验规范：又细分为如下几个部分，这部分最好让负责用户体验的同事编写。 交互规范：页面上各种控件的规范，如列表的默认排序、列表翻页控件的样式等；各种判断规则的规范，包括字段的校验规范、出错信息反馈的规范等。 视觉规范：如页面大小、字体字号、颜色编码等。 文案规范：如语言风格、语法模板、常用操作的标准说法等，最常见的问题是，一个产品中同时出现“新增”、“新建”、“创建”多种同义词。 ► 通用原则：待补充，大家可以看到这份文档也是需要不断优化的。
38. 需求管理类： 这部分内容第2章中都有涉及。 ► 用户调研：这份模板说明了典型的用户调研前、中、后都要做什么，调查问卷、用户访谈提纲怎么设计，有哪几块内容。 ► 产品需求列表（含需求管理流程）：产品需求列表的模板，需求管理文档的模板，需求状态变化的流程图等。 ► 产品信息架构：待补充，用来描述产品的页面或功能之间的关系，比如网站地图、导航结构等，可以和负责用户体验的同学一起制作。
39. 流程管理类： 只列出了小团队常用的。 ► 日常发布流程：在第3.3.2节中的“再看需求的生老病死”中已经提到。 ► 变更事件流程：如紧急发布流程、需求变更流程、需求搭车流程等，本书不做详细讲述。 项目管理类： ► 项目管理制度：原则性的东西，比如产品会议制度，项目经理、开发经理、测试经理的权责利，这里沿用了公司统一的制度。 ► 项目任务书：网上有很多模板，小项目可以灵活变通，用BRD代替。 ► Kick Off的PPT：之前已经说过。 ► 项目组织结构：这个模板我每次填几个名字就可以了，没啥技术含量。 ► 项目WBS（可生成进度）：我用的是一个叫“WBS Chart Pro”的小软件画的WBS图，可以直接生成Project文件，就是说项目计划也有了。 ► 项目日报周报：主要有今日/本周要闻、明日/下周看点、当前问题、所需支持、项目进展等几项，在第3.4节的“以终为始，项目小结”中给大家分享的本书项目周报，用的就是这个模板。 ► 项目发布预告与公告：大量的重复内容模板化，为了省时间而已。
40. 日常工作类： ► 会议记录：大家都很痛恨没结果的会议，有了这份文档，多少能逼着每次会议都产出一些内容，比如会议决议、遗留问题与行动方案等。在第5.3.2节的“我们急需靠谱的会议”里我还会单独分享“会议”这个话题。 ► 个人日报周报：用于团队分享每个人的工作情况。
模板作用知多少
41. 上节提到了我的常用文档模板，其实模板的本质作用有三： 让经常看同类文档的人提高效率：当开发工程师看惯一种UC文档以后，如果突然换成一种哪怕更好的写法，他们也会很不适应。 让写文档的新人可以尽快上手：新人可以根据模板，快速写出和团队里“老人”差距不大的文档。 让写作者不会漏考虑某些内容：比如PRD文档的整体说明部分，有7项内容，如果每次都从零开始写，难免漏掉一两项。
多人协作与版本管理
42. 项目中我们会生成很多文档，一开始并不需要多人协作与版本管理，因为事情并没有那么多，只需要一个人来负责，自己在本地维护一份文档，及时主动地给团队成员更新，注意备份就好。但产品和团队在不断前进，渐渐地一个人实在是忙不过来了，于是我们遇到了新的问题：经常需要多人维护同一份文档，某人更新之后，其他维护者或阅读者手中还是老版本。 产生文档版本管理的本质需求是多人合作，协同办公。
43. 完全抛弃了Word、Excel等软件，直接把常见的PRD、产品需求列表等写在Wiki上，这样完美解决了多人合作的问题，可以告诉团队其他成员直接上Wiki阅读，随时看到的都是最新的版本。
玩转office足矣
44. 聊了这么多文档的事儿，在很多外人眼中，需求人员整天就是在写文档，那总得给平时一直在用的几款写文档的工具露脸的机会吧。其实我们能玩转微软的Office就足够了
3.5.2 流程也是手段
项目 VS. 流程
45. ► 概念：启动阶段，关注商业规划，DCP1【30】。 ► 方案：立项，项目执行层面的非关键成员加入，关注规格、计划，DCP2。 ► 开发：控制过程。 ► 验证：测试，DCP3。 ► 发布：项目团队解散，成立LMT【31】，老人带新人做生命周期管理。 ► 生命周期维护：DCP4。 前面两个阶段需要高手做，进入第三个阶段，高手应该去做新项目。这里有个通用的原则：新人做老产品，新人不挑活，老产品不容易出事；老人做新产品，老人需要变化才有激情。
流程的本质目的
46. 当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事的时候起码不会太无助。在这点上，规范、模板的作用也类似，这就是团队的核心竞争力【33】。
那么多评审，可以省吗
47. 3年过去了，我也斗胆冒充一下老鸟，分析一下日常的项目中，那么多评审会议，是否可以省。我把项目中一次又一次的会议，都看做是评审：从立项之前的产品会议，到Kick Off会议，需求评审（又可分为PRD评审、UC评审、Demo评审），设计评审，代码评审，TC评审，功能评审，以及发布评审。
48. 产品会议：必须有，决定“做不做、做多少”实在太重要了，方向错了很可怕，如果没有多个产品之间的资源争夺，同一个产品的不同需求也必须争夺，
49. Kick Off会议：最好开一下，鼓舞士气的，磨刀不误砍柴工，可以考虑与需求评审合并为一次会议
50. 需求评审：如果项目Kick Off之后只做一次评审的话，那就是需求评审。具体的PRD、UC、Demo评审，我们也很少分为三次，看项目情况，任意两个都有可能合并，甚至三个合并。
51. 设计评审：表面上看起来经常在时间紧的情况下省略，实际上是在开发人员实力很强的情况下省略（他们在需求评审时会问很多问题），而开发较弱、新人多、业务不熟的团队，则必须进行设计评审
52. TC评审：仅次于需求评审，这是在项目KO以后第二重要的评审，敏捷方法很看重测试，实在要省也可以，那么PD会更辛苦一些，需要做更细致的验收测试。
53. 功能评审：这其实也是必须的，而且需要项目干系人都参与，但我之所以没有把它列为和需求评审一样重要，是因为功能评审经常采取线下的方式进行，比如邮件里告诉大家产品的测试环境地址，然后大家自己去看。
54. 发布评审：可以让开发经理决定是否需要。
55. 重要的评审不能省，最好单独评审，参与者取决于评审内容偏商业还是偏技术，而这些判断，没有统一标准，我只能说是与产品、项目、团队的特点相关了。
商业评审与技术评审
56. 上一节把所有常见的评审放在一起又分析了一遍，不知道你有没有隐隐地觉得，它们分为两类，即“商业评审”与“技术评审”。简单地讲，商业评审决定“做不做”，是产品会议与功能评审；而技术评审决定“怎么做”，是需求、设计、TC、发布评审。
57. 商业评审的三个决定是：项目继续、重新定向、项目终止，很重要的目的就是砍项目。商业评审也是分阶段分发资源的时间点，会给通过评审的项目发放到下一个商业评审点之前的资源，而在两次评审之间可以“将在外君命有所不受”。 技术评审的三个决定是：项目继续、有风险的继续、必须解决某问题后再继续。需要避免的情况是技术评审三部曲：抓壮丁，随便找有空的人来参加；科普会，来的人根本不了解情况，说很多基本信息；批斗会，没完没了的争论。 商业评审与技术评审两者最好分开，或者说在任何评审会议上不要同时讨论商业与技术问题，否则会被技术人员带入细节讨论，或者商业人员打击技术人员，或者决策者思维被搅浑。当然，无论哪种评审，来参加评审的人都要承担相应的责任，反之，没关系的人都不要来参加，免得浪费时间。
3.5.3 敏捷更是手段
从书本到实践
58. 后来人们非常想定出一个统一的、简单的流程，以减少人为影响，所以软件工程里的瀑布模型【34】等出现了；再后来发现瀑布模型有其局限性，于是提出了敏捷方法【35】。
59. 经典的软件工程方法旨在定义一套完备的过程规范，使软件开发的运作就像是机器设备的运转，人在其中则是可更换的零件，不论是谁参与其中，机器都能运转良好。这意味着：开发进度的可预见性，流程方法的固化与可复用，人力成本的节省，人员的流动不会对软件开发构成影响等。这样的做法对于公司而言，是具有很大吸引力的。其背后所隐含的观点则是：软件从业者无须是具备非凡智力的高级人才，人是一种可以被任意替代的资源，并且软件的需求从项目开始的时候就是确定的，而且不会改变。这显然是不符合事实的。 所以在瞬息万变的互联网、软件行业，大家渐渐体会到敏捷的优势。我们参考了几种经典的敏捷模式，按照产品、团队的需要定制了属于自己的敏捷方法，特点如下：
60. 有计划，更要“拥抱变化”。 随着时间变化，必然有新的信息出现，特别是市场环境、用户情况等瞬息万变的互联网业界，所以死守着的项目计划不调整是没有逻辑的做法。
61. 迭代周期内尽量不加任务。 敏捷再灵活，也不能容忍毫无控制的变化，“迭代”权衡了变化的成本和不变的成本，这是一个将“大项目长期不变”细化为“当前迭代不变，下次迭代待定”的做法。
62. 集中工作，小步快跑。
63. 持续细化需求，强调测试。 需求唯一不变的特征就是“不断变化”，项目与产品都要小步快跑，用不着在需求阶段纠缠。有些需求在开始的时候是提不出来的，或者说没法细化的，所以试图一次性完成需求分析的工作会存在“过度需求”的问题，是浪费时间的行为，到后来多半还是要改。 我们在开发和测试过程中完善需求，而且特别看重测试驱动项目，更早的测试，重度的测试。这需要有很强很严谨的测试人员，TC编写、TC评审，甚至测试执行的过程可以用来补充和细化需求，比如业务逻辑里的一些限制条件、异常流程等，往往都是测试人员提出来的。
64. 不断发布，尽早交付。
65. 我们的“冒烟测试”、“每日构建”就符合“尽早交付”的概念，可以让需求方尽早看到最新的产品。不断地发布也是为了把大问题分而治之，先解决最核心的，风险最大的部分。我们会先完成最重要的功能，所以说敏捷的里程碑是功能驱动的。
项目中的敏捷沟通
66. 项目经理都会建立一个即时通信的IM群，我们用的是阿里旺旺；一个临时的邮件列表，把项目干系人全部加入。IM用于实时沟通，比如发了重要邮件要大家赶紧收、文档有重要更新、测试环境正在构建暂时没法访问等，都可以在群里吼。旺旺有群公告，我们会贴上项目各种文档、资料的Wiki地址，以及一些测试环境的地址等公共信息。项目相关的第一封邮件，会把大家的E-mail收集齐，在此邮件最后说明“本项目干系人以此封邮件为准，大家的项目邮件可以直接回复全部并修改邮件名称和正文”，我们可以通过此邮件建立项目的邮件列表。当然，之后有人员变化也可以随时增删。
67. 我们坚持着经典的每日站立晨会，对于典型周期为2～4周的项目，控制粒度到“天”很有必要，“项目看板”视情况而定，举例如下。 如图3-23所示，是用白板做的项目看板，这类项目典型长度是两个星期，看板可以和项目日报、晨会整合应用，板上横向为各个功能点的进度百分比，纵向为项目成员。每个项目成员负责的功能点，用一张张便笺表示，在项目开始的时候这些便笺都贴在0％的下方，随着项目的进行，它们就逐渐被拿到右边的方格里。
68. 这个看板的最大好处是随时可视，项目成员、老板路过都会看两眼，而每个人要自己贴条，也是一种督促和帮助，试想大家都按进度在走，你老是滞后，自己也有压力，另一方面，如果真遇到困难，大家也能及时发现并提供帮助，让每个项目成员都对项目进度负起责来。
69. 最后小结一下，从沟通扩大至整个敏捷方法，任何团队都在探索一个介于“无过程”和“过度过程”之间的折中方案，使之给团队带来最大的收益。
与外包团队的敏捷尝试
70. 首先，项目外包使得甲方不愿意砍需求。甲方认为，反正是乙方干活，合同都签了，那么显然是能多做一点就占一点便宜。比较而言，公司内部项目的需求在很大程度上是可以砍的，是“保质不保量”，这更符合敏捷的原则。但是项目外包，甲方在提需求的时候不愿把任何一个功能像平时那样推到下一期做，因为这个项目结束后，下一期在哪里都不知道，所以“保质保量”变成了“不保质保量”，希望一口吃个胖子。
71. 其次，甲方“验收测试”团队的工作方式与乙方配合困难。敏捷会导致提交测试的产品和最初的需求之间必然有很多变化，并且文档很难完全反映，而这种敏捷在公司内部之所以运行得很好，是因为PD、开发、测试人员在项目过程中可以充分交流，测试在TC评审的时候会叫上PD和开发，有些属于详细设计的细节是在评审的时候直接与开发人员确认的，在测试执行过程中也会协助确认需求细节并迭代测试。而这次项目外包的时候，甲方的测试团队没有和乙方一起办公，只是从一份颗粒度过粗的需求文档上派生出“验收测试”的TC，又因为验收有“考试”的性质，所以不允许乙方的开发人也参加甲方的TC评审，导致我只能和甲方代表确认细节，而我对如此细节又没有要求，无奈之下只能按照自己的想法描述，我经常发现甲方的测试人员考虑到了很多乙方开发人员根本没有考虑到的问题，再通过我来传递信息，必然导致双方对需求理解的鸿沟。虽然乙方也有自己的测试团队，但明显他们的测试强度比起甲方的验收测试差很多。
72. 最后，乙方缺乏“敏捷”的经验和意识。职业性质和国内的项目管理现状决定了外包团队里的工程师习惯于按照详细的设计文档做开发和测试，抗拒需求改变。所以强行“敏捷”会导致失控，因为没有一份完整的详细设计文档，开发人员会按照自己的想法编码，测试人员也照自己的想法测试，又没有和需求人员充分沟通的习惯，也没有一个迭代的过程，再为了工期的死命令削减测试
73. 但一次失败给人带来的收获往往大于一次成功，幸运的是我学到很多，不幸的是公司损失不少。最后送大家一句话：任何情况下，我们都要做好手头的事情，确保“就算这事儿对公司来说又黄了，我也要通过做事有所收获”。
3.6 物竞天择适者生存
74. 项目好比生小孩： 怀胎容易生下来难，生小孩容易养小孩难，不但培养成功很难，如果他身体不好看着也心疼……所以我们要少生优生。 如果不幸多生就要排定优先级，把资源投入到回报最大的小孩身上。 这就是“物竞天择适者生存
如何做好“老板项目”
75. 老板项目，就是指老板突然跟你说，我们要做个什么什么，然后你只有执行份儿的项目。什么，你们公司所有项目都是老板项目？很正常，那我们更应该聊聊这个话题了。 复习一下，我们做项目通常要在保证品质的前提下，在时间要求T、人财物花费R、项目范围Q三点上做平衡。
76. 传统项目管理中的那一套，先需求，知道要做多少事情以后，再协调资源，最后推算出时间计划，在这里跑不起来了。于是，阿Q的我们想到了一个理论支撑：Agile，敏捷！不是吗，更多的时候我们并不是很创新地提出敏捷，而是被迫敏捷，或是被老板逼的，或是被用户逼的，或是被对手逼的……人类的本性应该还是恐惧变化和不可知的吧，不知有多少人看到这里内心在呐喊——我爱瀑布模型！ 所以有公司在价值观里宣扬“拥抱变化”真是很积极的一种人生态度。那我们来拥抱敏捷吧，看看在TRQ三方面应该如何拥抱。
77. T是给死的。
78. Q是可变的。先说Q，一般越大的老板给出的指示越具战略性，越不具体，所以具化出来的Q就可大可小了，这是我们可以发挥的地方。开始的时候，尽量施展自己的聪明才智，天马行空的爽一把，把Q搞大，尽量搞大，并合理地算出一个巨大的R，然后，你就可以欣赏到老板因为无法付给你这么多R而自己砍Q的表演了……当然，我们应该尽职地帮老板排出各种功能的建议优先级和所耗的资源，好让老板知道刀该往哪里挥。
79. R是丰富的。老板项目么，第一优先级，R就是大大的有，其他项目统统让路，让多少路，这个问题应该抛回给老板决定，我们只提供专家意见，狮子大开口：让得越多越好！
80. 真的这么爽？ 当然不是，有时候你发现，老板比较猛，Q都帮你想好了，那只能说没劲，也别废话了，老老实实干活呗。更悲剧的是，R也是不足的，就那么几个人，又要在固定的T下做这么多Q，绝望？不至于，我们还有IT民工最后的必杀技——加班，天天加班，天天加班还不要加班费……我们期望的是老板看得到，公司有前途，明天会更好…… 如果这样还做不完，那只能说——老板丧失理智了！同学，撤吧……
81. 最后谈谈，老板项目到底好不好？从个人角度，如果是纯项目经理，这就是本职工作，无所谓好坏，而对于我们这些做产品的同学来说，老板项目没有成就感，有成就感的项目是自己去做市场分析、用户研究，然后发现问题，发起项目。另外一件麻烦事就是，有可能你不认同老板的项目目标，我碰到这种情况就用“有良知的职业杀手”的思路：只要不违背自己的价值观，就尽心尽力地完成任务，否则，据理力争，如果争论失败，要么调整自己的价值观，要么放弃这份工作。好处方面，从个人角度看，老板项目接近老板，无须多说。从老板和公司角度看，这样的项目效率高，但决策风险大，其实，这很像民主与专制的区别。
秘密行动，封闭开发
82. 封闭的好处比较明显，大家都挤在一间房里，甚至围着一张大会议桌办公，交流非常方便，有什么事情，吼一声就通知到所有人了；小空间可以更容易产生讨论，而且参与者会更加投入，不用担心激烈的争论会打搅到外人，因为屋里没有外人；而且封闭的时候经常会不自觉地加班，并且是高效的集体加班
开发外包，项目外包
83. 再和大家分享一个我参与过的项目，这是完全外包给乙方的项目，但是做着做着双方都理解成了开发外包，所以出现了很大的问题。
84. 而在项目的过程中，乙方渐渐地做成了开发外包，导致甲方投入的资源越来越多，最终产生矛盾。
85. 既然是项目外包，项目管理的方法应该由乙方定，由甲方来做项目管理风险是极大的，因为项目团队完全不熟悉甲方的那一套。比如我们事后才发现双方对“需求→设计→编码”环节的理解有差别，乙方对软件工程的理解是很教科书式的，而甲方的“需求”包含了很多“设计”的内容，“编码”也包含了部分“设计”，所以项目中看起来是“需求”完了直接进入“编码”。说法不同，实质一样，不过后来由于采用甲方的项目管理方法，导致乙方真的跳过了“设计”阶段，没有产出相应的文档，这是很低级的错误，但真的发生了。
86. 需求相关的工作当时也产生了职责不清的现象，我觉得项目外包的话，乙方应该主动向甲方收集需求，并维护PRD等文档，当然甲方要积极配合并即时告知最新变动并走乙方的流程进行评估，而开发外包就是甲方驱动更合适，走甲方的需求流程，不断给外包的工程师更新需求。
87. 同样的问题也发生在测试工作中，甲方肯定会有验收测试，但是乙方一定要在项目范围内安排比验收测试更详细的测试，千万不能把“找Bug”的测试寄托在甲方的验收测试上，而这次到项目提交的时候，项目组内部做过的测试还远不如验收测试详细，很显然，乙方还是把自己当作一个开发外包的团队了。
88. 这个项目的一些细节已经回忆不起来了，但它让我一直牢记的最大教训就是：在职场中，做任何事情，除前面已说的权责利的划分外，还要权责利对等，有权力的人、或者被授权的人，可以享受事成的好处，也要担负失败的损失，千万不能只是因为你有能力做某事就把任务接下来，这样对谁都不好。
3.6.2 一路坎坷，你我同行
89. “三边”指的是：边计划、边行动、边修改。 造成“三边行动”的根本原因是在目标未清、职责未明的情况下就仓促开始往下做细节，结果常会因为在一些小事上扯皮导致项目不断地延期，即使最后勉强完成了，也与最初的目标相去甚远。 “六拍”拍的是：脑门、肩膀、胸脯、桌子、屁股、大腿。 “拍脑门”决策：经常有某些领导有了做一个项目的想法后，不是组织相关人员严格论证是否可行并广泛征求社会意见，而是自己觉得可行就上马项目。拍脑门作决策的做法，从一开始就为项目实施带来了很高的风险和不确定性，可以说也为项目的失败埋下了伏笔。 “拍肩膀”信任：领导拍完脑袋后，为了鼓舞士气，调动项目组成员的积极性，大多会采取一些激励手段，例如——拍肩膀。但事实证明，错误的激励往往比没有激励带来的后果还要糟糕！ “拍胸脯”承诺：受到领导激励的项目组成员为了让领导放心，也会有所表示——拍胸脯，而且往往还会说出一句话：“老板，放心吧，包在我身上！”但盲目的乐观与热情只会让前进的方向与最初的目标越偏越远。 “拍桌子”骂娘：项目进行一段时间后，领导忽然发现项目进展情况与自己的预期相去甚远，于是大发雷霆，爆发了“四拍运动”——拍着桌子训斥项目组成员。 “拍屁股”走人：项目组成员受到老板的严厉批评后，不少人往往会“拍屁股”。表现有二：一种是“明拍”，不干了，直接走人；另一种是“暗拍”，再也没有热情，消极怠工，这种人留在项目组中对项目毫无益处，反而会打击努力工作者的积极性。 “拍大腿”后悔：五拍之后的项目结果必然令所有人大失所望。这个时候，从决策层到项目经理再到项目组成员，大家都痛心不已，却又无可奈何。
90. “三边”并不可怕，比如在敏捷开发的过程中，我们就是“边计划、边行动、边修改”的，重要的是，关键的方向、目标得一开始就清晰，一些原则、约定不能总是变。“六拍”也不可怕，最可怕的就是拍完了却不吸取教训，在随后的项目中依然延续“六拍”。 聪明人并不是不会被石头绊倒，而是不会被同一块石头绊倒两次。
几个项目的成败
一次只有七天的战斗
91. 项目的坎坷一生讲完了，我们看着如图3-25所示的详图再回顾一下本章的主要内容，几十个步骤，每一步都潜藏着危险。
“项目的坎坷一生”详图
