2007年下半年，我在逐渐掌握了用户与需求相关工作之后，又渐渐担负起了项目管理的职责。个人的最大感触是自己从一个会议的参与者变成了组织者，原来只需要接受各种会议邀请，现在则需要与老板、同事们约时间，发出会议邀请了。我意识到迎来了角色转变的挑战。
从一个在项目组中负责产品需求的人转变为项目经理让我认识到“从产品到项目”，对个人的要求有哪些变化。本章一开始辨析了“做产品VS.做项目”的异同，“产品经理VS.项目经理”的异同，进而分析了在有些团队中，“为什么让产品经理管项目”。
接下来，项目启动总是“一切从Kick Off开始”，我们确定了团队成员、时间计划、沟通方法等，就可以做到“任何时候都心中有‘树’”。
然后，项目进入了“关键的青春期，又见需求”。这时候我们会发现作为互联网、软件行业的产品经理，“真的要写很多文档”，从产品需求文档、用例文档到Demo，甚至是设计文档。作为与第2章的呼应，我们会在项目的需求阶段里“再看需求的生老病死”。
确定需求之后，项目会进入开发、测试、发布等几个主要阶段。“成长，一步一个脚印”，在每一次的成长经历中，我们要“以终为始”，别忘了小结，还要“拥抱变化”。
接着，我要和大家分享我们的“山寨级项目管理”，也许对于互联网、软件行业，这些方法有一定的通用性。主要谈三个话题，分别是文档、流程、敏捷，但“文档只是手段”，“流程也是手段”，“敏捷更是手段”，他们都是为项目、产品、团队服务的。项目坎坷一生的缩略图如图3-1所示。
图3-1 “项目的坎坷一生”缩略图
本章的最后，举了一些例子，都是我“亲历过的特色项目”，比如“老板项目”、“封闭开发”等。从“几个项目的成败”中，我体会到“物竞天择适者生存”，项目总是“一路坎坷，你我同行”才能有并肩“战斗”的感觉。
3.1 从产品到项目
产品的定义在第1.2节中的“产品到底是什么”里和大家分享过，所以这里特别针对互联网、软件产品领域，给出项目的定义【1】：
只会进行一次，包含多项互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。
从这句话里看出，产品是一个解决问题的东西，而项目是一个过程，根本是两个不同层面上的概念，可人们经常说“做产品”、“做项目”，其所做的事情确实有几分相似，所以我们有必要把它们放在一起比较一番。
做产品VS.做项目
我们从三个方面来比较“做产品”和“做项目”。
第一，从生命周期的角度来看。
做产品的生命周期相对较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程。而项目有特定的目标，所以生命周期较短，通常在项目开始以前就有明确的起始和结束时间，通过验收则表示项目生命周期就算完成了。
我们要开始做一个产品的时候，没法明确这款产品何时“结束”，一般会随着时间的推移、市场的变化、公司战略调整等因素，渐渐走向“生命周期完结”。所以，会有一个已经“结项”的项目，但不可能有一个已经“完成”的产品（只有不断完善中的产品，除非它被新产品替代）。
第二，从具体要做的事情来看。
做产品的过程，会有更多的探索，随着各种内外部信息的变化，产品负责人需要不断地修正自己的判断，给出适宜的创新；而项目在开始时就已经有明确的目标，更注重计划与控制，项目的过程很像是执行一个任务。当然，也有很多事情无论是做产品还是做项目都是必不可少的，比如与团队成员的协调沟通，对未来一段时间做出计划等。
第三，从产出物的角度来看。
产品是可以批量生产，或者提供给大量用户的，所以相对通用，通常考虑用有限的资源去满足更多的、能有更多回报的需求；而项目只进行一次，意味着每次都是定制的、个性化的，通常为了满足特定的需求，产出物也比较个性化。这就意味着，项目要满足那个特定的需求；当然我们会看到有的项目产出物经过改造，成为更通用的产品，或者有的产品也可经历“个性化定制”（即做项目）。
下面举几个例子帮助理解。
你找裁缝做一件衣服，会当面沟通清楚需求。对于裁缝来说是接了一个项目，做完了与你一手交钱一手交货，项目结项；而如果这个裁缝是一位设计师，他做的衣服被某服装厂看中，最终做成流向市场的上万件成衣，这就是做产品了，上市之后，还会根据市场反馈不断修改，直至不再流行，这就需要进行产品的生命周期管理。
门户网站为国庆60周年做了一个新闻专题，一定要在10月1日之前上线，可以看成这是在做一个项目，任务明确；而整个新闻频道持续更新一个又一个新闻专题，则需要随时关注各种时事风云，持续创新，这就是在做产品。
一家小软件公司接到某酒店的订单，要在6个月内做出一套管理软件，典型的一个项目；而一家大一点的软件公司发现了这个市场，受此项目的启发做了一套通用的软件，可以卖给很多的酒店，就更像做一款产品……由此有很多软件作坊也发出“做项目太累，什么时候才能做产品”的感叹。
“做产品”和“做项目”也是分不开的，“做产品”的过程，正是通过做一个又一个项目实现的，但并不是项目的简单累加。在产品渐渐满足目标用户群体的通用需求后，继续做下去的话，会使产品成为项目的集合体，臃肿不堪，因此我们就需要细分市场，这时候产品可能升级为“产品线”，按不同的细分市场，推出不同的产品，表现形式上叫版本、模块、增值服务，什么都行，本质上是通过合理地安排项目来实现产品的规划。
产品经理VS.项目经理
我们接下来很自然就会想到产品经理和项目经理，他们有何异同？一个是Product Manager，一个是Project Manager，工作都需要跨团队，工作范围也有重叠，简称还都是PM，工作中我们自己都经常搞不清在说哪一个。
这两年我在网上好几次看到下面这段描述，其将两个PM的区别说得比较到位，消除了我不少疑惑。
产品经理——靠想。产品经理是做正确的事，其所领导的产品是否符合市场的需求，是否能给公司带来利润。
项目经理——靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。
产品经理关注的是做正确的事，关注的是产品生命周期，关注的是产品能否赚钱，能否持续地赚钱。因此产品经理必须要能够规划整个产品的架构和发展路线，能够确定产品的定位和受众，能够预计产品真正的价值和效益。
项目经理是需要正确地做事情，即按照产品规划制定的项目目标正确地做事情。项目能够按照目标完成则项目就是成功的，即使项目的产品不能真正赢利，那往往也是产品规划出现了失误。
项目经理关注的是项目能否按照既定的目标顺利完成。产品究竟应该规划哪些功能点那是产品经理的事情，是项目范围的输入。
用我自己的话总结，就是：一个内部驱动，一个外部驱动。
对产品经理来说，最重要的是判断力与创造力，产品经理决定做不做、做什么、做多少，保证方向正确。他是产生一个想法，“我要把它实现！”
对项目经理来说，最重要的是执行力与控制力，项目经理决定怎么做、谁来做、何时做，保证方法得当。他是接到一个任务，“我要把它完成！”
为什么让产品经理管项目
现在大家发现，两个PM的职责确实有所不同，连最重要的能力要求都有很大区别，所以一个人很难能同时做好这两项工作，那么为什么在很多团队里，都让产品经理来做项目管理呢？
这是我亲身经历的故事。
2007年年底之前的约1年时间里，我一直只是很单纯地在做产品的功能设计，在为产品所发起的一个个项目中，扮演一个PD的角色，主要负责“做多少、怎么做”的问题，那时项目经理是开发经理兼任，他负责“何时做、谁来做”的问题。
后来公司发现这样的一些弊端：
对PD考核的是产品的商业价值，比如用户活跃度等，而这些指标和产品的用户体验关系极大，大家知道，想把产品的用户体验做到极致，让用户轻松，通常我们就要“受罪”，特别是开发的同学，要额外做很多在他们看来价值不大的细节工作。
比如一个最简单的登录页面，有两个输入框，一个填账号，一个填密码，想体验好一点，就要考虑如何限制输入内容长度，如何控制输入非法字符，如何给用户提示等很多问题。仅仅是“输入账号的字符长度控制问题”，就又要考虑是单击“登录”按钮提交数据时判断？是鼠标焦点移动到密码输入框时判断？还是输入账号时随时计算长度直接判断……
矛盾产生了，开发工程师的考核一般是项目的完成情况、Bug数量等。很显然，如果他们做项目经理，就会倾向于简化项目，尽量少做、做自己熟悉的，使得项目顺利完成，并且Bug很少，但是做出来的东西也许会商业价值不足、用户体验不好。
由于上述原因，公司决定让PD兼任项目经理，希望能让对商业目标负责的人自己来掌控，在商业目标、项目资源、用户体验等各种限制条件下取得平衡，解决目标不一致的问题。
于是我也渐渐有机会接触了项目管理方面的事情，这段经历让我又成长了很多，全新思维方式的挑战对一个人的成长很重要。当然，在项目中仍然保留了开发经理，毕竟在“哪位工程师更适合做哪个任务，需要多少时间”这类问题上，他们是专家。
一个事物必然有它的两面，如果你只看到了一面，说明你只看到了系统的一部分，这时你一定要跳出去，寻找另一面，之后再努力寻找“对立”背后的“统一”，正如黑格尔所说的“正反合”【2】。
果然，2009年的时候，我了解到有的团队又调整为让开发经理担任项目经理了。主要是发现PD会不断地给项目增加新的需求，导致项目总是无法按期完成，继而大家怨声载道，影响了团队的士气。
其实公司也是一直试图通过职责的划分，寻找一个平衡点，但作为产品经理或项目经理来说，如果认识到问题的本质和公司的良苦用心，也就无须在意形式上是谁来做项目管理了，正如下面这段话所说：
一个产品经理可能想要增加非常多的功能和特征以满足获取到的用户需求，但是项目经理却想要尽可能小地控制工作范围，以保证项目在规定时间与预算内完成。好的产品经理和好的项目经理能在冲突中找到平衡。好的项目经理明白，一个项目真正的成功并不是看它是否在规定的时间和预算内完成，而是它是否达到了拟定的目标。好的产品经理则明白，如果项目被不断延期并且从未投入市场，又或者因为大大超过预算而被结束，那么所有的产品功能特征都会变得毫无意义。
3.2 一切从Kick Off开始
想清楚了为什么要我们做项目经理以后，项目也终于要启动了。还记得那些突破重重阻碍的需求吗？现在这些PK胜利的需求已在眼前，要决定“谁来做”、“何时做”了。
于是，我们也踏上了新的征程，这一切都从项目的Kick Off开始。Kick Off是足球比赛开球的意思，现在被广泛用于开始做某事，在项目里指的是项目的启动大会，而启动大会及其准备工作（主要是团队组建和各种计划的确定），就是所谓立项阶段的工作内容，如图3-2所示。
图3-2 立项阶段的工作内容
帅哥美女，我们需要你
这么煽情的标题是告诉大家，这节要聊的是“团队组建”的话题。因为产品经理并没有行政上的管理权，也就意味着每次项目都需要去跟不同团队的主管、经理要人，所以其中的艰辛也只有经历过才能体会。
我做过的一个项目，在需求阶段由于合作部门的PD太忙，所以屡次无法兑现承诺，被逼无奈，我只好给他的主管写了一份邮件，抄送给了一些相关人员，争取资源。下面就是当时的邮件与回复。
发送时间：2008年9月9日 11:53
主题：双龙会项目，PD的资源问题
重要性：高
Hi，××，不好意思，打不通你电话，这个事情比较急我还是发邮件说明一下。
双龙会【3】的项目时间很紧，现在我们碰到了一个问题，王××由于手头A产品的客户问题很多并且都很紧急，占用了不少时间，导致能够做本项目的时间不足，他自己也很辛苦。
现在已经产生了一个小问题：今天原本要做的UC评审，但是到现在还没法确定时间，希望我们能一起防止问题扩大！
希望能提高本项目工作的优先级，不然需求的延期很可能导致整个项目的延期，希望××可以支持，帮着协调一下，非常感谢。
发送时间：2008年9月9日 13:22
主题：答复：双龙会项目，PD的资源问题
已经安排××接手处理有关A产品的客户问题。王××会集中精力参与双龙会项目。
这样的方法快速有效，却似乎少了点人情味儿，个人不建议经常使用。好在有这么几点可以降低团队组建的难度，一是我们启动的项目都是经过产品会议，大老板们认可的，所以基本的资源有保证，但资源充足的情况就比较难得了；二是经常合作的都是相对固定的人，沟通也比较顺畅，所以说PD新人不太适合做项目经理，通常要和团队混到脸熟以后再说，这可不单是个人能力问题。
在项目的组织结构中，项目经理并不是结构中的顶端，我会组织一个“项目督导委员会”，这很有必要，成员一般是项目成员的老板，甚至老板的老板，他们的任务也很简单——“背黑锅”和“买单”，因为权力越大，责任越大。当项目因为种种原因出现重大变更的时候，比如成本、时间、需求等，我会向他们提出申请，获得批准后才执行变更，这也是项目经理对自己和项目成员的保护。而在整个项目过程中，各种资源的提供也需要靠他们，除了人，还有很实在的项目经费，有可能的话都尽量多要一点，最好有富余，但也要尽量省着用。整个项目期间，各种信息会随时知会督导委员会成员，但大多数情况老板们无须有什么动作，所以他们也乐于参与。同时，对于项目成员来说，知道老板们随时在监督项目，并且看得到自己的努力，所以也会做得格外卖力。
通常在项目中，项目经理下面会有这样几种角色，如图3-3所示。
图3-3 典型的项目组织结构
PD，负责这个项目的需求，他们中的某一个可能兼任项目经理；开发经理及其团队，负责开发相关的任务，其中开发经理需要负责开发的时间计划与任务分配，并全程掌控设计、编码直至上线的过程；测试经理及其团队，负责测试相关的任务；UE（用户体验团队），对于互联网、软件类产品来说，负责产品给用户的展现，比如交互效果、视觉效果等；服务团队，负责产品帮助的编写，以及上线后的服务工作等；如果项目牵涉了其他产品，我们还会设置各种职能的接口人以协同工作；更加复杂的情况，还会有其他角色出现，详细的介绍会在第4章“我的产品，我的团队”里与大家详细讨论，这里我们聚焦在如何做项目的话题上。
大家想想也可以理解，这个组织结构肯定会随着项目的进行不断微调，我们也无须在项目一开始的时候就把人凑齐，一般来说，最关键的几个人到位了，就可以继续做下面的事情。他们通常是项目经理，需要统筹管理整个项目；PD，开始写需求文档；开发经理，制定项目的开发计划。
别忘了最初的约定
约定，就是说好的，谁在什么时间要做什么事情，在项目中，就是项目计划。
我们日常的项目，如果是基于网页的软件，典型的项目周期在两周到一个月；大一点项目，最多不超过三四个月。项目的几个重要环节大家都已经很熟悉，所以这里最重要的一件事情就是：再次评估“工作量”并推算出“工期”。
还记得BRD里给各项需求做的工作量初评吗？现在把这些信息再一次拿出来参考，因为从产品会议结束到制定项目计划的日子中，PD们同时也在做PRD【4】的细化，开发的同学看到PRD时，每个功能点的工作量评估得已经更准确一些了。更重要的区别在于，初评工作量的时候是开发经理之类的角色统一评估的，未考虑谁来做，而现在是开发经理根据团队里开发工程师的能力特点、擅长领域等因素，“因事择人”，把各项开发任务分配给最合适的人（当然，要把高手调入项目的关键路径【5】）。之后，每一位领到任务的开发工程师自己评估工作量，为各自的任务买单，承诺最可能时间。之前的初评只是一个参考，毕竟每个人对自己最熟悉。常用的方法是“三点估算法”，即评估出最乐观的工作量、最悲观的工作量、最可能的工作量，然后按下面的公式估算出工作量：
“工作量＝（最乐观＋最悲观＋最可能）/3”
或“工作量＝（最乐观＋最悲观＋最可能×4）/6”
这里的工作量粒度也会比初评的时候细，至少精确到“1人天”，短期项目甚至是“1人小时”，按照经验，我们的“1人天”通常等价于5～6“人小时”，而并不是按照一天工作8小时计算，因为每个人都很难保证持续高效，并且不被其他事情打断。一个没人打搅的日子，能有5个小时高效的工作，就已经很不错了。
之后，开发经理会把项目中各位工程师评估的工作量做汇总，推算出工期，需要注意的是，工作量只是说某人完成这件事需要多少时间，而工期是转化到日历上，说明这件事从何时开始到何时可以结束。这时候要考虑到各项任务的依赖关系，以及项目成员在这段时间内的其他工作，并适当留出机动时间。
比如某个开发任务只需要工程师甲做“2人天”，但它需要等工程师乙“5人天”的任务完成后才能开始，那么这两个任务就没法并行，工期也就是“7工作日”而不是“5工作日”；又如开发团队每周五下午有周例会，项目中的成员必须要参加各种评审会议，还需要响应随时可能发生的线上故障，排工期的时候都需要考虑到这些。
加班是业内普遍存在的现象，我觉得长期加班对团队士气打击很大，所以一直让开发经理、测试经理评估资源的时候留一点余量，甚至我在汇总项目计划的时候会再留一点，但每次仍然还是有人加班。也许是习惯问题，大家不喜欢一下班就走，反而愿意上班时不时看看新闻，晚上时不时做点工作的方式吧。反正不管给大家多少时间，任务总是在最后一刻完成。
项目管理的新手总是认为可以通过加大资源投入来缩短项目时间，一般来说，如果各个任务相对独立，则可以更多地并行，通过投入资源来缩短时间，比如给一大片果园摘苹果就可以采用此方式；但如果任务互相依赖严重，就只能更多地串行，这时候加人也往往无能为力，就像我之前提过的那个“十月怀胎”的例子，更坏的情况，是在软件项目中，经常因为“延期、加人、老人带新人耽误时间、更加延期”，而进入恶性循环。
同样的，因为日常项目的资源瓶颈一般在开发阶段，所以其他计划会在开发计划初步确定之后再与之配合生成，而对于项目经理来说，需要在更大的粒度上把开发计划、测试计划、发布计划等合并成为项目计划，并确定项目的几个里程碑，也是监控点，通常是需求完成、编码完成、发布上线，在项目进行中，一定不要忘了这最初的约定！如图3-4所示是一个魔方计划的粗略时间安排。
图3-4 魔方计划的粗略时间安排
沟通从头开始
从项目开始直到结束，我们无时无刻不需要沟通，由沟通问题导致的项目不顺利也占了极大比例，常见的情况有“干系人权责利不明确，出工不出力，心不在焉”；“对需求的理解不一致总是到最后一刻才发现，不能防患于未然”，“遗漏了利益相关方，导致项目考虑不周，不能发布”等，所以有必要一开始就约定好项目的沟通方式。
项目沟通方式各有不同：
周期：以“日”或“周”为单位，主要取决于项目时间的长短及变化的频率。
渠道：会议、邮件等，需要在成本和效率之间取得平衡。
发起者：一般由项目经理、开发经理、测试经理主导相应的沟通。
参与者：发起者确定参与者，不要遗漏项目边缘的同事。
不管选择何种沟通方式，目的都是相同的——为了项目成功。一般来说，常做的项目，通用的沟通方法有如下几种，供大家参考。
项目晨会：自项目进入开发阶段至发布日止，开发经理每日召集相关人员，主要是PD、开发人员、测试人员参加。
项目日报：自Kick Off起至发布日止，项目经理每日发给项目的所有干系人，测试开始后以测试日报为主。
评审会：相应PD召集需求评审；相应开发人员召集设计评审；相应测试人员召集TC【6】评审；产品可用之后，项目经理尽快召集功能评审【7】，项目所有干系人参与评估。
项目变更申请：项目发生重大变更，项目经理与项目督导委员会沟通后确认变更。
发布预告及公告：项目经理在项目发布前两个工作日发预告给项目所有干系人，项目发布成功后发公告给所有干系人。
不可或缺的誓师大会
上面说的团队组建、时间计划、沟通方法准备好以后，我们就可以举行誓师大会了，也就是项目Kick Off会议。项目Kick Off会议，我们简称KO，也许有的人会觉得很形式化，但我认为很重要。我们自己全程参与项目，所以对各种信息都已经了解，但是还有很多项目成员在KO之前很可能完全不知道这个项目是要做什么，而且KO的很大作用是在心理上的，就好比如图3-5所示，周瑜在战前发表“演讲”、敬天地鬼神，鼓舞士气。自古以来，就有这样的KO。
图3-5 电影《赤壁》里的KO
KO通常只需要15分钟左右的时间，在这15分钟内，需要传达的信息有如下几点。
项目背景
我们在哪里？说过去，做项目之前的“悲惨境地”，明确为什么要做这个项目，以让听众“痛下决心”为终极目标。
项目意义、目的与目标
我们去哪里？说将来，做项目之后的美好前景，解决什么问题就算成功了，以让听众“面带桃花”为终极目标。
需求、功能点概述
我们怎么去？说现在，具体用什么方法促使“过去”到“将来”的转变，以让听众“跃跃欲试”为终极目标。
上述这三部曲其实和BRD里的项目背景、商业价值、需求描述大同小异，可以借用，下面三点就是新鲜的了，也正是之前三节准备的内容。
项目组织架构
目的是让项目成员互相认识，明确有什么事应该找谁。
关键人物都要到场，比如很重要的督导委员会成员，他们可以高屋建瓴地给项目成员描绘项目的重要性和伟大前景，说不定还会一时兴起追加一点团队建设费啥的，非常鼓舞士气。项目的早期，务必要让老板们多多参与，反复确认正确的方向，这时候做各种调整的成本都比较低。
注意也不要遗漏工作不多的项目成员，比如小型项目的大多数活动是开发及其相关过程，所以经常会忘记服务部门、配合部门的接口人。如果他们不知道相关信息的话，那么即使项目本身顺利发布，之后也会带来很多配合上的问题，比如培训没有到位，客服对新功能不熟悉等，从而导致客户投诉。
介绍成员的时候，气氛好的话可以让报到名字的人跟大家示意，我参与的项目中一般成员互相都已经熟识，而这批人又特别爱演，所以经常会变成很欢快的一段个人秀。
项目计划
让所有人了解两个关键点：
第一，项目的时间点与里程碑；
第二，各个时段需要的资源，即每个人要在各个阶段做什么事情。
这点就不多说了，项目管理其实很深奥，我也只是个初学者，但我们也可以最简单地把它理解成“计划与控制”，各种手段都是为这两点服务的。
沟通计划
和项目全体成员明确这点非常重要，因为太多事情的不顺利都是沟通的问题，大家都做不到一直主动、彻底地沟通，所以有个规矩来逼着做一些沟通的工作，并且在项目开始的时候就约定好，可以免去很多麻烦。
最后提一点，凡是会议，就总会有人缺席，所以别忘了把会议记录发给所有干系人。
任何时候都要心中有“树”
项目就要正式开始了，在这里我简单分享一下对项目管理的理解。感兴趣的同学可以阅读项目管理的相关书籍，并根据项目的情况，灵活应用最合适的项目管理方法。
做项目的目标无非是多快好省：范围大、时间短、品质高、资源省。但又要马儿跑又想马儿不吃草的事情是没有的，有理智的老板们也都明白这一点，所以我们通常是在上述4个要求中做平衡。
上面所说的目标对比经典的项目TRQ：项目时间（Time）、项目资源（Resource）、项目质量（Quality），几乎一样。一点小区别就是Q（质量），我觉得把Q解释为“Quality+Quantity”（品质+数量）更准确，而我所经历的项目，Q更多的是表达Quantity（除非有特殊情况，“品质高”这点是不会舍弃的，所以可变的是项目范围）。
综合一下，我们做项目的本质就是在保证品质的前提下，在时间要求、人财物花费、项目范围三点上做平衡。
工作中能碰到的几乎都是常规的项目，公司或团队已经做过无数遍了，所以该有哪些人、按照何种顺序做什么事情也相对清晰，之前说的团队组建、时间计划、沟通方法等，都已经默认了这个前提。但偶尔碰到一些全新的项目，我们该如何入手呢？这里简单介绍一下如何走最初的几步。
在了解背景、目的、目标等的前提下，明确任务之后，首先分解任务，即著名的WBS【8】，要重视完整性，保证“滴水不漏”，比如工作环境准备，有时候需要单独的会议室、额外的机器，各种福利的申请……一开始不考虑流程及资源限制，也不用把任务排序。有经验的项目可以利用原来用过的WBS模板，自顶而下地优化并套用，无经验的项目可以自下而上，列出一个个最小的任务点，再组装起来。WBS做完，看上去就是倒过来生长的树，在之后项目进行的过程中，任何时候都要心中有这棵“树”！
如图3-6所示就是我自己通过多次的项目，总结出的“产品模块级项目的WBS模板”，图中只展开了一小部分，如果全部展开的话，有上百个大大小小的任务点。
图3-6 产品模块级项目的WBS模板
我会把这些任务排序，几次实践之后就会发现绝大多数任务是有相对固定的执行顺序的，渐渐地这也就成为经验了。接下来，应对每个具体的项目，评估出每项任务的工作量，安排人力资源去完成任务，把工作量转化为工期，也就得到了项目的时间计划。
随着做的项目越来越多，你应该一边做项目，一边形成自己的WBS模板，以后再遇到类似项目的时候，不管规模大小，这些事情总是大同小异的，你就心中有“树”了。
我们都知道，实际工作中，其实任何项目都没有这么清晰的步骤，做完这个再做那个，通常我们都是“边计划、边行动、边修改”，这是现实，是无奈，但不论怎样，我们终于要甩开膀子干活了。下一节，也许你会感觉很亲切，因为这就是我们刚入行的最初几个月整天会做的事情——写文档。
3.3 关键的青春期，又见需求
同学们，我们又开始说需求了，我把这里的内容叫做“需求开发”，也就是大家俗称的“写文档”。确实有很多产品经理，包括我，一开始做产品就是在写需求文档，而且写得“痛不欲生”。
为什么做产品通常从写文档开始呢？我想作为一名缺乏经验和实战能力的新人，或者刚到一个全新的团队，只能先做一些执行层面的任务来熟悉产品、团队，以及团队做事的方法、常用的工具等。经过采集、分析、筛选需求，决定要做项目，通过团队组建、计划制订、Kick Off会议等步骤后，正式开始实施的第一步就是“写文档”，再明确不过了，拿来练手正合适。
3.3.1 真的要写很多文档
先从整体上看一下PD们都要写哪些文档吧。几年前看一个叫“Michael on Product Management & Marketing”的博客，它讲述了产品设计中的几种核心文档，我结合实际工作整理之后，形成了我心目中产品从抽象到具体的过程主要产出的文档：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中，从这步开始会出现很多技术的内容，产品界面、业务逻辑的细节都要确定，比如网页上的某个表格中的数字，应该左、中、右对齐？保留几位小数等，有点像“概要设计”。与此同时，硬件系统的设计、数据库设计、表结构设计等工作，也开始由架构师、系统分析师们编写了。
需要说明的是，每个公司并不会严格地写这么多文档，比如我在阿里待过的团队主要写BRD和PRD，我们说的BRD实际上包含了上述BRD和MRD的核心内容，PRD实际上包含了上述PRD和FSD的核心内容；而百度有的团队主要写MRD，包含了上述前三种文档的主要内容。有时候叫法相同内容不同，有时候叫法不同内容相同，关键是我们要知道写这些文档的目的，说清楚哪些事就可以了。
上面说到的后两种文档主要是写给技术人员看的，再往后，就到“详细设计”和编码了，其主要作者不是PD，就此打住，回来细说关键的。
产品需求文档，PRD
BRD在第2.4.1节的“武器：商业需求文档”里已经说过，这里我们说说PRD。通常一个项目会有一到多份PRD，每一个PRD会包含逻辑相关的若干功能点，这些相关的需求在“需求打包”的环节已经被识别出来，也就是产品需求列表里的若干行。
文档的结构如图3-7所示，开始是一些总体说明。
图3-7 一份实际的PRD模板目录与结构示意图
修订历史：写清楚每次修订的日期、版本号、说明和作者，便于以后追溯。
项目概述：简单描述项目的背景、意义、目的、目标等，描述业务领域知识，让文档读者明白这个项目是为什么而做，这部分内容可以参考Kick Off会议所用PPT里面的内容。如果此PRD没有包含项目的全部需求，也应做相应说明这部分需求是什么，其他需求在哪里等。
功能范围：给出本PRD的业务逻辑图，重点描述系统中角色的职责、与周边系统的关系、全局的商业规则等。
用户范围：对本PRD涉及的角色、系统做出简单的说明。
词汇表：对本PRD涉及的专有词汇、术语、缩写等做出说明。
非功能需求：如性能需求、数据监控的需求等。我们公司曾要求过针对每个新功能设置监控点，并且在功能上线两周后，由PD给出数据分析报告，以验证是否达到预期的商业目标，从而不断改善前期判断的准确度。
其他说明：其他任何需要说明的内容都可以写在这里。
总体说明之后是用例文档部分，首先需要对这个PRD中所有的用例进行说明，给出用例的可视化表示，说明各个用例之间的关系，一般有类图、用例图、状态图几种表示方法，其中用例图最为关键，下一节里即将给出几个例子说明。
接下来是用例的正文，由一个个的用例组成，这部分也就是我们常说的——用例文档【9】。
最后一部分“对单个UC的说明”是一些注释，我常用的PRD模板里有如下内容：
注1：视觉层面的描述通常直接通过Demo表达（如页面大小、颜色、字体、字号等）；
注2：界面细节，引用界面规范文档（如表格中的文字对齐方式等）；
注3：交互细节，引用交互规范文档（如出错提示的方式等）；
注4：文案细节，引用文案规范文档（如各种提示文案等）。
接下来，我们从用例文档部分慢慢说。
学一点UML：类图、用例图、状态图
公司一般会经历“人治→法治→德治”的三个阶段：人治是“由外而内”的被治，靠的是领袖魅力，更适合小公司；法治靠的是“硬法律+软伦理+执行者的以身作则”；而德治是“由内而外”的自治，靠的是企业文化，更适合大公司。很多小公司停留在第一阶段，很多大公司停留在第二阶段，只有少数公司才可能进入第三阶段。第三阶段和第一阶段表面上很像，但区别在于第一阶段根本无法，而第三阶段的法在每个人的心中而非纸上。
这也是产品和团队发展的必经阶段。一开始我们非常推崇个人英雄主义，或者在老板的带领下，或者自己带领几个菜鸟，没有章法地怎么快怎么做。慢慢地，产品越来越复杂，团队的新人也越来越多，于是我们开始在文档上做起了规范化的事情，从第一阶段走向第二阶段。在这个过程中，大家开始学起了UML【10】，从产品设计的角度，我把它对PD的价值简单理解成，提供了一系列的标准图形化的表达方式，把需求开发的过程串起来，充分体现了“字不如表，表不如图”的原则。
我们的小明，憋了很久没出现，这次他作为PRD的主角，终于又闪亮登场了，而这个PRD的名称就是“小明下馆子”。先说说PRD的“用例整体说明”中出现的几幅图，这些图中表达的都是用例之间的关系，不涉及某个用例的内部细节。
► 类图【11】：Class Diagram，描述系统中出现的各个对象之间的关系，以及和外部系统的关系，这是对业务领域的描述，一个外行看了以后就应该了解此系统是做哪方面事情的。如图3-8所示表示了小明与其所点菜式，是通过点菜单关联起来的。
图3-8 类图举例
► 用例图：Use Case Diagram，描述各个用例之间的关系，比如“include”或“extend【12】”，用例包【13】、用例和行为者（Actor）之间的关系，如图3-9所示里我们可以看出小明下馆子之后，具体可以做哪些事情。
图3-9 用例图举例
► 状态图：State Diagram，表达系统里实体的状态转换，同样也是贯穿多个用例的。如图3-10所示描述的就是小明的状态转换。
图3-10 状态图举例
上述几种图也可以看做是由整个产品最顶级的业务逻辑图细化而来，而对于商业演示场景所用的业务逻辑图的画法，团队内没有统一的意见，但一定要简洁清楚，因为受众都是大老板，他们可没那么多时间看细节，所以这也意味着业务逻辑图最难画。
用例文档，UC
用例整体说明部分结束，就要进入单个UC的写作了。UC是需求人员写给开发人员看的一种最基本的文档，查了一下资料，早期的需求人员是通过对应用场景（Scenario）的分析来细化需求的，20世纪初，一些牛人们才将这种方法正式归纳为用例法。之后在互联网和软件行业，又继续发展，逐步形成了今天的用例文档，或者说“任务分解”等描述需求的方法。理想状态下，一个UC代表了产品需求列表里的一行，但实际上并不绝对，也可能多个UC满足一个产品需求，或者一个UC涉及多个产品需求。
简单举一个用例的例子，来描述UC里要写哪些内容。
首先是UC概述：
用例的唯一标识：我们拿PRD“小明下馆子”中的“点菜”为例，其中唯一标识记为“UC_ordermeal”，这项我们经常偷懒不写，关系并不大。
用例名称：就是“点菜”了，用一个短语讲清楚这个UC是做什么的。一个UC写一个任务，任务的粒度可以自行把握，比如同样是“增加、删除、修改订单”，在新人、新业务的情况下，就最好分为三个用例详细描述；如果是“老人”、老业务，也许用一个“管理订单”的用例描述就足够了。
业务描述：商业目标、用户目的等业务内容，说明为什么要做这个UC？例如，小明工作一周辛苦了，周末晚上会去吃一顿好的犒劳一下自己。
需求描述：产品需求，需要实现哪些功能点，这个UC要做什么？去餐厅，点几个菜，之后等烧好了吃掉。
行为者：该用例的Actor，小明。
前置条件：触发这个用例的前提是什么？周末，小明有空去餐厅等。
后置条件：用例完成，后续动作是什么？服务员接受订单，去厨房等。
其他说明：任何其他信息，针对这个UC的特殊说明，没有就空着。
然后是UC主体：
界面描述：通常互联网、软件产品中界面描述会占很大的篇幅，给出截图，界面上各种元素的说明，并且会和Demo关联起来，当然还有一种做法是单独写界面文档，然后与UC文档互相引用。不过小明的例子中并没有界面描述。
业务规则：整个用例的通用规则，比如限制条件小明不吃辣、小明预算只有100元等。而界面元素或流程中的私有规则不适合写在这里。
流程描述，分主干、分支和异常三种，描述在这个用例发生的过程中，由什么事件触发，系统与用户之间产生何种交互步骤，这里尽量用时序图和活动图来替代文字描述，具体的例子下一节给出。
现实中的UC会做得比较美观，这也是为了防止大家看久了白底黑字太无聊。如表3-1所示可以看到对于界面描述、业务规则、流程描述的写作，我们都有一些模板式的总结，这些都是特定的产品、特定的团队通过不断优化得到的结果，并且会继续优化下去。经常有网友向我要文档模板，但我的非常个性化，拿过去直接用会有很多的地方不适合，甚至产生副作用，所以我建议你按照本节讲述的内容做一个最简单的模板，把现在你觉得没用的内容都删掉。然后在实践中慢慢优化，切身体会到缺什么了时再添加内容。
表3-1 现实中的UC模板
UC一般只用来描述功能需求，它不便于描述诸如产品扩展性、系统容量、人员培训等非功能需求，所以我们把非功能需求部分写在PRD的总体说明里。
UC里对语言的要求比较高，需要做到：无歧义、完整、一致、可测试等，相信为此吃过苦头的同学都有体会，举几个简单的例子。
无歧义：比如“小明和两个部门的同事一起去餐馆”，就不知道“两个”是形容“部门”还是“同事”。
完整：比如“小明预算不超过100元”，其实是不完整的，应该是“小明的人均预算不超过100元”，如果他和大毛一起来，则预算是200元。
一致：比如“小明非工作日去餐馆吃饭”与“小明周末去餐馆吃饭”就不一致，国庆节、春节怎么算？
可测试：比如“点菜时要考虑到金额限制”，就没有办法验证，应该说“如果金额大于100元，则需要修改点菜单”。
再学一点UML：时序图、活动图及其他
刚才提到了UC里的流程描述，我们再学几种UML的图，它们描述的是用例的内部事务。当然，用例内部不一定是“单个用例”内部，也可能有用例之间的关系。这些图在描述业务规则和流程的时候非常有用。
► 时序图：Sequence Diagram，也叫顺序图，描述事物变化在时间维度上的先后顺序，善于表达对象的交互，比如多个页面之间、多个角色之间。如图3-11所示就是小明点菜过程中，点菜者、服务员、厨师三个角色之间的交互。
图3-11 时序图举例
► 活动图：Activity Diagram，比较接近我们常说的流程图，描述各种动作如何引起系统变化，善于表达泳道【14】较多、分支较多的情况。如图3-12所示，描述了点菜过程中，点菜者与服务员两个泳道各自的动作引起的系统变化。
图3-12 活动图举例
► 协作图：Collaboration Diagram，表达不同对象之间是如何互相影响的。这幅图在日常的项目中用得不多，就不画了。理论上它和时序图是可以等价转换的，只不过时序图关注交互在时间上的步骤，而协作图关注交互过程中各个对象间的关系。
很多时候多种图都可以描述同一件事情，只是视角不同而已，选用哪个关键是看针对特定的系统，从哪个角度来描述更容易让受众理解。另外还有表述软件实施的构件图、描述硬件结构的部署图，这些图更偏向技术一些，对PD的用处不大，遵循性价比的原则，我们暂时跳过这部分的学习。
上述这些UML图都是用Visio画的。再次强调，工具是为人服务的，如果团队里其他成员都看不懂UML图，且学习成本太高，那一定不要强推UML，寻找合适自己的工具吧。描述需求的原则很简单：把要做的事情跟受众说清楚！
Demo也要我们做吗
PRD写完了，工程师拿着它就可以开发了吗？不是。还缺了很重要的一块，产品Demo，也经常被说成是产品原型、演示版、Mockup。
先看一下Demo与用例文档的关系。对于某个产品功能的用例是否包含界面的描述，每个团队有自己的做法，好坏难以评估，这取决于产品的特点、团队的习惯等，我的建议是不妨再次应用做产品的思路，去问问这些文档的用户，即团队里的开发工程师、测试工程师，按照他们喜欢的方式写就好了。但用例里最多只能放Demo的截图，所以如果要表现更多交互和视觉的细节，Demo是必须独立存在的。现在应该有一些可以嵌入富媒体内容的文档方式，可以直接把Demo嵌入用例，不过我们没有尝试过，周围也尚未看到有人用。
我认为Demo最好是由用户体验部门的同学主导，当然你在的团队可能并没有这样一个叫User Experience，简称UE的部门，那么做这个事情的人也许叫用户体验师、交互设计师、视觉设计师，甚至是比较过时的称呼——美工。但产品经理也必须参与Demo制作的过程，Demo的制作在产品会议之前就可以开始了，有可能的话在BRD中展示出来，很可能成为争取资源的加分因素。最关键是要保证Demo的设计师们充分理解商业目的和用户目标等，让大家在方向正确的前提下再自由发挥。
Demo也会经历从低保真到高保真【15】，从抽象到具体，从全局到细节的渐变过程，下面几幅图展示了“e网打进”新首页的Demo在几个关键步骤上的样子。一般来说，最开始会有一个纸面Demo，铅笔加A4纸的组合，或者是马克笔加白板再用手机拍个照，如图3-13所示，有了这样的东西，大家就可以开始沟通了。其实这些线下的工具，纸、笔、白板，加上口头交流，可以帮助我们进入很高效的工作状态。
图3-13 纸面Demo
接下来会有一个线框图，如图3-14所示，只关注界面框架而不考虑细节，使用的工具可以是Visio、PPT、Word，甚至Windows操作系统自带的画图板。
图3-14 线框图
进一步，我们要关注视觉效果，如图3-15所示，也许会用Photoshop做几张典型页面的效果图。然后，表达交互细节，使用Axure【16】、Dreamweaver【17】制作页面，这页面很可能就是将来产品里真实可用的网页了。
图3-15 视觉效果图
产品不同，用到的Demo工具会不同，或者各个阶段也会不同，还是那句话，心中有剑，手上拿根树枝都能杀人。我看过用Windows自带的画图板都能画出很清晰的Demo的强人，当然我不是要大家学他，只是又想说，最重要的不是工具。
实际工作中，PD肯定会对Demo给出一些自己的想法，甚至经常自己做，越是低保真的Demo我们做得越多。早年我是用Dreamweaver自己写页面的，很多时候没有去做高保真Demo也是因为没能力、不会做才交给UE同学的。
团队分工的形成总有各种各样的原因，凡事向好的方向看吧，如果要我们做Demo，那么就更加全面地锻炼了能力，如果有UE的同事，我倾向于信任专业人员，只提建议而不做决定，让专业的人做专业的事，这样产品才更完善。而关于Demo、界面等工作，我还是把它们归入用户体验团队的职责，到第4.2.2节“激情四射的设计师”里再和大家细聊。
概要设计与详细设计
我在写UC的时候，经常写着写着就觉得是在越俎代庖地做概要设计，甚至是详细设计的事情了。比如，对于网页上简单的一个“公司名称”字段，就有很多细节的设计。
长度应该限制在多少个字符，是64、128，还是100？
界面上应该允许输入多少个汉字？
不允许输入哪些非法字符？
有没有敏感词需要屏蔽？
输多了何时检测？何时提示用户？
是否必填？
是否有默认值？
在页面上的对齐方式？
……
每当此时我都很纠结，询问工程师后也常常会得到相反的答案：有人希望你写得越详细越好，而有人希望你交给他决定。后来我们渐渐总结出两种做法。
第一，不以写的东西是需求还是设计区分职责，而以“业务”或“技术”区分。比如上例，在业务上需要对“公司名称”的长度做何限制由PD确定，而“公司名称”的数据在数据库里如何存储，由工程师决定。
第二，细枝末节的设计经常重复，PD应该和开发工程师一起协商，渐渐沉淀出产品规范。比如上例，通过几次协商，我们确定了以后产品中出现的各种字段的各种限制规范，下次再写UC的时候，只要引用规范即可，省去了很多重复劳动。
3.3.2 需求活在项目中
我们辛辛苦苦地把各种需求文档都写完了，开发和测试的同学可不敢拿过去直接就用，为了保证产品的质量，需求还必须要在项目中通过各方的评审，方可进入开发阶段。早在第2章，我们就明白了产品需求是产品每个干系人的事情。
项目中的需求阶段，通常会围绕着“写作→评审→修改→评审”循环展开，下面来仔细聊聊需求评审的话题。
评审：一个头两个大
往简单了说，评审就是项目中相关的几个小团队坐在一起，一方讲，另外几方听并确认，统一认识，消除误解，及时发现偏差，防止问题随时间放大。不做评审，当时看似省了时间，但往往隐藏了问题，待到其爆发的时候会耽误更多事，而且会在谁负责的问题上纠缠不清。与其亡羊补牢不如尽早在流程上预防，所谓“防病优于治病”。
我做过的项目中，最重要的三种角色就是PD、开发人员、测试人员，所以派生出三次评审——需求评审、设计评审、测试评审，它们按照项目阶段依次为：
需求评审，是PRD评审、UC评审、Demo评审的统称。于需求的相应部分完成以后进行，评审会上PD把PRD和UC说给开发、测试听，Demo评审则由UE的同学主讲。
一般我们会在做出比较大粒度的PRD之后马上安排一次评审，当然也会有UC和Demo的半成品，以期尽早发现问题，比如业务规则的不合理，产品界面太丑陋，某功能技术上无法实现等。PRD评审会重点关注偏商业的内容，强烈建议叫上老板、营销人员、服务人员，甚至用户一起来听。
PRD通过以后，PD们会和UE的同学一起细化UC和Demo，而开发的同学也会同步进行一些开发前的准备工作，比如细化和修正项目计划，部分系统的设计等。接下来的Demo评审，决定了产品的外观，项目干系人最好都来把一下关，而UC评审更偏重技术实现，商业团队的成员可以选择参加。
需求评审的过程如图3-16所示，当然，实际操作中没这么复杂，简化的方法可以看第3.5.2节中的“那么多评审，可以省吗”里的描述。
图3-16 需求阶段的工作内容
设计评审，是在概要设计与详细设计完成之后进行，由开发工程师把对需求的理解以设计文档的形式说给PD、测试听。
测试评审，俗称TC评审，是在TC编写完成，测试开始执行之前进行，由测试工程师把对需求的理解以TC的形式说给PD、开发听。
每一种评审都可能有多轮，会上没问题就快速地通过，有小问题当场确认，大问题带回去，原则是“改动较多的话必须再次评审，异议不大可以通过”。评审会议的组织者，可以考虑都由QA【18】担任，作为项目过程管理的一部分。也可以考虑由每次评审的主讲人发起，我们就是这样做的。
需求评审会的组织过程中，特别要注意两种容易漏掉的参与者，大家可以扩展应用到各种评审会上：一是能做决定的人，因为评审的时候各方不可避免地会对需求有不同理解，从而出现争论，而很多问题都是“公说公有理，婆说婆有理”，谁也说服不了谁，这时候就需要有人能拍板，有人能负责；二是与此项目有关的产品接口人，他的参与可避免太晚发现与其他系统有冲突，修改起来措手不及。作为PD肯定是希望只要有点关系的人都来参加会议，但现实中是不可能的，所以必须识别出对当前项目来说谁更重要。
再看需求的生老病死
还记得第2.5节里聊过的“一个需求的生老病死”吗，当时是从某个需求本身的状态变化来看的，现在我们把它融入项目，再次审视一番。如图3-17所示是一个简化版的项目流程，也是一个需求从提出到发布的流水账，对于小型团队应该比较实用。
图3-17 日常需求发布流程
除纯技术项目外，PD是产品不断改进的源动力，所以项目前期PD主导的环节比较多，而一个需求就在这些环节中生老病死了。我觉得可以用几个会议来概括，项目大小有不同，所以这里的会议不要理解成严格的会议室里一群人正襟危坐，有可能是两三个人围在电脑前的几分钟交流。
项目开始之前。在产品团队内部分析需求商业价值的需求讨论会、多个产品间的产品会议上，PD们带着自己的需求参与讨论，为那仅有的开发和测试资源PK。人性的本能让每个人都极力地维护自己提出的需求，并设法反驳别人，当然出发点都是为了用户，最终也会达成一致。“活下来的”需求会确定需求负责人，状态变为“需求中”。
项目中的需求阶段。项目启动之后，PD就得抓紧时间完成需求的开发，不时召集需求评审会，大家一起讨论这样做有哪些问题。PD收集到意见反复修改需求，直至最后一次评审通过，需求得以确认，状态变为“开发中”。当然，之后的需求微调总是无法避免，但“需求冻结”的里程碑要求我们在这之后就不要轻易改动了。
项目中的需求阶段之后。进入开发之后，PD需要不断地和开发、测试人员确认各种细节。我们一直想在早期环节中考虑到所有的细节，以期减少这种费时费力的确认，但事实证明细节总是多到无法预计，有的甚至要发布后才被发现。在开发提交测试之后，PD需要在测试环境【19】中代表产品的用户做功能验收，确认一下产品与自己的设计是否相符，顺便也可以发现一些可用性问题。当然如果能让真实用户来验收则更好，通常我们会组织一次功能评审会，让项目干系人来确认这些功能是不是大家想要的，如果有问题还可以补救。最后功能上线，别忘了把Feature List中的相应需求改为“已发布”。
很显然，需求发布之后仍然会有改动，可能是客户反馈了问题，或者自己想到了更好的解决方案。我们的做法是把它视为一个新的需求或当做一个Bug，重新进入流程。
3.4 成长，一步一个脚印
我们会把“需求评审通过”视为项目中一个重要的里程碑，称做“需求确认”或“需求冻结”。之后进入开发阶段，如果还需要修改需求的话，不是不可以，而是要更加慎重，甚至是强制走一些需求变更的流程。这也是为了更好地控制项目风险，在信息充分的情况下，随着项目的进行，风险应该越来越小，否则项目必然有问题。
需求阶段之后的常规项目过程就是开发、测试、发布，需要注意的是，这类项目都是围绕着产品研发工作的，所以没有包括上线后的销售、运营、服务等活动。之前我们谈过的立项与需求阶段，那是PD作为主要角色参与的环节，而本节重点讲述的内容之做事的主力则是工程师们，我们作为PD要随时配合他们确认需求，项目经理要做的就是“控制”。
对于每个特定的项目，应该在开始之前就约定好各种管理方法，比如文档怎么管理、测试过程怎么管理、使用哪些技术工具等，这部分话题在任何一本讲述软件工程的书里都有，所以这里就不再理论，只说说我们是怎么做的。
开发阶段，旁观者说
开发阶段，开发经理的存在会帮我们省不少心，作为旁观者，看到开发团队做了如图3-18中的几件事情。
图3-18 开发阶段的工作内容
比较强的开发工程师，可能叫开发经理、架构师、系统分析师等，会带着普通工程师一起做概要设计、详细设计，如果项目涉及数据库、硬件系统的改动，那就还会带上运维的人员。设计完成以后，会组织一次设计评审，PD和测试人员都会参与，审核一下工程师们对需求的理解是否正确。
评审通过以后，就进入编码阶段，编码完成以后，如果时间充裕可以做一些代码评审的工作，不过我们的项目一般都紧张，代码评审的工作通常只能在开发工程师提高自我修养的周例会上进行。
之后工程师们需要对自己的代码做单元测试，自测环节做到位，可以减少后期测试同学很多的工作量，问题总是越早发现解决的成本越低。
当开发工程师认为自测已经完成，就可以把代码从开发环境上提交到测试环境了。按照开发计划，当项目的主体部分提交测试的时候，我们又走过了一个里程碑——开发完成。
测试阶段，大家一起上
开发工程师在设计与编码的同时，测试工程师也没有闲着，他们会继续细化和调整测试计划，并完成TC编写的任务。在TC中，测试人员会进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。
测试阶段的主要任务如图3-19所示。
图3-19 测试阶段的工作内容
TC编写完成后，测试经理会组织TC评审，时间一般在开发人员提交测试之前，PD和开发人员都要参与评审，再次确认大家对需求的理解是否一致。很多需求的细节无法在需求阶段考虑完全，我们会通过开发和测试阶段的反复沟通来不断细化。
TC评审通过，待开发提交测试以后，测试人员迅速完成一轮“冒烟测试”【20】，目的是确认软件基本功能正常，可以进行后续的正式测试工作。
在测试人员正式开始测试的同时，PD又要出场了，我们会组织一次产品的“功能评审”，或者叫“产品演示会”，利用测试环境，把可以使用的产品在第一时间展示给所有的项目干系人，更进一步确保做出来的东西就是大家想要的。功能评审通过之后，PD一般还会代表用户做更详细的UAT【21】，或者称为“验收测试”【22】。
接下来，测试的同学会做多轮测试，是一个“发现Bug，开发修正，测试验证，发现新Bug”的循环过程，从第二轮开始就可以叫做“回归测试”，在Bug都处理妥当之后，项目紧接着就进入了发布阶段。有的项目除了功能测试以外，还需要做性能测试，比如验证系统是否能承受1万用户同时访问的压力，公司也有特定的测试工程师做这方面的事情，他们一般是多个产品共用的资源。
在测试阶段【23】，商业方面的准备工作也早已动起来了。PD可能要准备面向用户的功能、卖点介绍的文档，产品更新的公告；培训服务人员和销售人员；运营人员可能已经在策划推广方案；销售人员可能在更新销售说辞；服务人员可能在依据测试环境里的产品制作帮助……多个部门协同，很有大家在一起战斗的感觉。
Bug眼中的项目
再说点测试的话题吧，刚开始的一段时间，Bug【24】总是不断地蹦出来。本节不妨从Bug的角度来说说项目，如表3-2所示是我们使用过的一份Bug级别定义，从中可以看出，III、IV、V级Bug是产品是否“能用”的范畴；II级是“好用”的范畴；而I级是“有用”的范畴，应该由PD在前期搞定，但在测试过程中，任何人也都可以提出质疑。
表3-2 Bug级别定义标准
一般来说对一个Bug的描述有以下几个关键点。
► 缺陷级别（Severity）：即上图中的Ⅴ级别定义，一般大于等于III级的Bug被认为是严重的问题。
► 所属产品、项目：有的人需要同时处理很多产品、项目，这个属性可以用来筛选。
► Bug名称：一个短句，对此Bug的简单说明。
► Bug描述：写成如下形式，“执行某操作，期望出现什么情况，实际出现什么情况”，还可以添加截图、文档等附件。
还有一些非必填的其他属性，此处先略去不说。
我们的测试过程使用了Mercury Interactive公司的Quality Center来管理，它是一个基于Web且支持测试管理的所有必要方面的应用程序。更小的团队，用Excel来管理Bug也未尝不可。作为PD，也是会经常提Bug的，与测试人员相比，PD做测试的时候主要是模拟用户的身份正常使用产品，而测试人员会更多地按照TC执行，尝试极端的使用情景下产品有没有漏洞。在发现一个Bug以后，我们会提交给相应的开发工程师，如果认为是需求问题也可以提交给对应的PD，这时候Bug的状态为Open，之后的状态改变，可以用如图3-20所示简单描述。
图3-20 Bug状态流转图
任何人收到Open的Bug，确认并修复，状态变为Fixed；否认，也许提出者理解错了，也许不打算修改，状态改为Rejected；认为不是自己的问题，或者PD对需求问题作出解释以后，把Bug转交（Assign to）给了合适的人。
测试人员验证状态为Fixed的Bug，没问题了就Closed，否则可以Reopened。看到Rejected的Bug，发现是自己理解错了，就可以Closed，仍然认为是Bug的可以Reopened。对于Deferred的Bug，意味着本项目中暂不修正，可能是因为技术做不到、时间不允许、性价比太低等，这个认定必须慎之又慎，通常由能负责的人，比如是测试经理、项目经理最终同意才Deferred。
在整个过程中，Bug的每次状态改变都可以添加注释说明，我们更鼓励在有争议时叫上当事人面对面的交流，而不是在系统里不停地纠缠。
到了项目发布之时，我们要求所有Bug的状态必须是Closed或Deferred，当然对I、II级的Bug，有时候并没有这么严格。
使用Quality Center相比Excel的好处在于，每个Bug重要的状态转换点，系统都会有邮件通知到相关人员，防止遗漏；项目中每个人在系统里的角色不同，权限不同，此软件可防止误操作，甚至是一些恶意行为，比如开发人员就不能把Bug状态改为Closed；所有操作都有记录，谁在何时做了什么，便于追溯。这些都有效地防止了人为因素导致的问题。
那一夜，项目发布
辛苦了那么久，项目终于进入发布阶段了，可黎明前总是最黑暗，我们要考虑很多问题，如图3-21所示。
图3-21 发布阶段的工作内容
首先聊聊代码更新的事情。我们会安排专门的代码版本管理员，通常用SVN【25】，所以又叫SVN管理员，负责项目每日的代码更新。修改的代码从“每位开发人员的开发环境→测试环境→预发布环境→生产环境”一步步更新，如果版本控制不好，就会发生“改掉的Bug又回来了”这种情况，想必大家都有切身体会。有时候同一个产品多个项目并行，就会牵涉到多分支开发，更有代码迁出、合并的时机问题。
然后，“发布计划”的评审也很重要，需要运维人员的确认。特别是对于系统改动较大的项目，可能需要分模块分步骤发布。比如我经历过的一次发布，涉及几十台服务器，就需要先更新几台××服务器，再更新几台××服务器，名词太专业我都叫不上来。对于用户影响较大的升级，我们有时候采用“分流发布”，或者叫“灰度发布”，即让一部分用户先用，然后收集反馈再决定大面积发布的时机。Gmail就经常采用这种方式，把一些还在实验室状态的功能先开放给小部分的用户试用。把握不大的项目，发布计划中还要加上“回滚方案”，一旦发布不成功，就赶紧把产品退回原来的状态。
正式的发布过程，是从更新“预发布环境”开始的，预发布环境会尽量模拟生产环境上的真实状态，比如数据库用的是同一个，测试人员会在预发布环境进行最后的回归测试，没问题的话，更新“生产环境”，测试人员再做一次最简单的回归测试，完成发布。当然，这么多次回归测试，其覆盖面不尽相同，越到后面的回归，测试的内容越少，直至只包含最重要TC的“最小集”，来简单判断系统是否能正常运行。
对了，在正式发布之前，可能还有一些手续要办，比如填写“发布申请单”，写上项目的大致内容与影响，让所有关键人物签字，大家最后确认一次；有时候我们会用E-mail形式的申请。有一段时间，我们公司还有“立项申请表”、“预发布申请单”等，每张表格都需要N多人签字画押，手续的烦琐也许会耽误时间，但是是为了防止出错，而每个手续的背后通常都有一段“血泪史”，如果你发现公司最近突然又多了一个单子要填，不妨去打听一下前段时间是不是有什么项目出了乱子。
下面是某段时间我们产品的发布注意事项，作为例子与大家分享。
► 发布标准
· SQL【26】已经经过DBA确认无问题，DBA确认后，邮件通知到测试人员，抄送给某经理。
· 搜索引擎通过相关人员确认无问题。
· QC中的Bug全部Closed或Deferred。
· 因技术或时间原因造成无法修改的Bug，由测试、需求、开发三方一起研究是否能接受，如果有争议，上报上级主管。
· 测试过程中，如果因为技术无法实现造成的需求改动，PD需要第一时间发送邮件到全组，让所有人都知道，同时修改相应的UC。
► 发布过程
· 测试人员在确认完“发布标准”中的各项之后，会发出邮件通知同意发布，发布人员在没有收到通知前，不能自行发布。
· 测试人员在发布后，将做一轮生产环境的回归测试，测试完成后发出一封邮件通知“生产环境已验证完成，发布成功”。只有收到该邮件后，发布相关成员才能撤离现场。
还有一点想说，发布的时间选择，能安排在白天的工作时间固然好，但很多互联网产品为了避开用户使用高峰，必须安排在晚上进行，难免弄到深更半夜。我们很多同事工作完时都已经见到第二天早上的太阳了，这时候作为产品经理兼项目经理，还有一件重要的事情——别忘了给大家买夜宵！
以终为始，项目小结
发布成功！回家睡个好觉。
所有人终于舒了一口气，但是作为项目经理，事情还没完，第一件事就是赶紧发出一封E-mail——“项目发布公告”。小项目的公告会比较形式化，而意义重大的项目就会写得很煽情了，比如项目中的种种艰辛、对每一个参与者的感谢、发布之后的内心感言、产品对公司和用户的革命性意义、贴几张产品的最新图片等，有时候还会有人诗性大发，再让视觉设计师帮着设计一些海报，不但邮件里用，甚至在公司墙上也贴几张。这封邮件也是一次内部宣传的好机会，我们除了发送给项目的干系人，甚至会抄送给整个公司。作为项目经理，应该时刻做到为团队成员争取各种精神、物质的奖励，这种邮件、海报、大老板的回信……都是很好的鼓励，如果还有项目经费的话，再组织一次聚餐，大家以后还要继续合作，开开心心，皆大欢喜。
之后，写一份项目小结，对于一个几周到两三个月的项目来说，比较合适在发布后半个月内完成。小结一下做这个项目的心得体会，比如碰到了哪些问题，原因是什么，怎么解决的，如何避免再犯；项目的资源评估是否合理，收获了哪些经验，如何提高准确度；根据数据监控的反馈，分析出了什么结果，项目的商业目标是否达到等。下面是某个项目小结的实例，内容不全，但很真实，有些敏感的字句我隐去了。
1．张××对系统不够熟悉的问题。
问题：项目交流中发现外包公司的张××对AA接口、B产品相关模块等不熟悉，导致无法独立胜任现在的“双龙会”项目，增加了团队的工作量。
解决方案：继续催促C公司完成交接工作（负责人：××）。
2．测试、预发布环境与生产环境差异过大的问题。
解决方案：下次升级项目前搞定（负责人：××）。
3．流程问题，生产环境直接改代码？
解决方案：控制生产环境访问权限（负责人：××），张××工作中积极了解我们公司现有的流程（负责人：××）。
4．系统复杂，升级发布方案不能单方面确认。
解决方案：确保C公司的叶某参与方案评估（负责人：××）。
5．修改生产环境数据库的流程问题。
问题：有一位用户要改某信息，只能直接修改生产环境的数据库。
解决方案：找周××咨询如何实施（负责人：××）。
后来类似的小结我们又优化了很多，比如用表格代替条目式的文字，每项解决方案要填写完成期限等。
很多项目经理一到写小结的时候就难产，似乎项目中的种种困难到了这时都烟消云散，然后下次项目再为类似的问题抓耳挠腮。对此，我的经验是通过项目的日报或周报随时记录每天的情况，到总结的时候就水到渠成了。我们千万不要把这种事情当做额外的任务，而是要想清楚它的价值，很直接的一点就是可以作为对项目成员的保护，有绕不过的坎及时让老板们看到，如果不帮我们解决，那老板需要承担后果。下面是这本书写作过程中某一周的周报，没有人要求我写，我自己写出来，为了控制进度、不断改进，正好我也希望把这本书的写作过程完全公开，所以从一开始就用Google的SpreadSheet随时展示最新进展，如表3-3所示就是本书第一份正式的周报，2009年8月24日～30日，那会儿我正在写第2章的初稿。
表3-3 本书的写作周报
怕什么来什么，只能拥抱变化
一步一个脚印地走下来，这个项目似乎也还顺利，可是现实情况往往要复杂很多，有各种各样的不确定因素，真的是怕什么来什么，所以我们只能拥抱变化，常见的有下面几种。
变更事件，是指项目范围内需求的变化，需求细节的确认、微调总是不断存在，变更主要关注的是“需求冻结”后较大的变化。我们会制订一些流程做控制，不是为了限制变更，而是为了让每次变更都经过深思熟虑，最怕发生的情况就是需求方举棋不定，来回反复。流程会要求提出变更的人先和相关方确认，获得一致认可后，再修改文档、邮件说明、即时通信群里吼一声……而过大的变化或过晚的变化，比如到了发布前一天还在修改业务逻辑，项目经理有权决定是拒绝，还是上报更大的老板定夺。
搭车事件，是指项目范围的扩展，一般来说，5个开发工作日以下的零散小需求不参与产品会议讨论，所以搭车事件总是存在。但我们要尽量搭顺风车，找内容相关的项目；尽量早搭车，在“需求冻结”之后一般不要再提；作为项目经理，也要把好关，不能因为随意让别人搭车导致团队长期、高负荷加班，这是得不偿失的。
紧急事件，这也总是难免，所以一般由较高层的老板确认后自上而下的推动，不受常规流程的限制，越是高层确认的紧急事件，越可以突破常规限制优先处理。回忆了一下，我们甚至发生过产品在发布前两天才发现“付费流程”跑不通的情况，付费过程中需要用户确认的时候，我们用了一个网页浏览器的弹出窗口，而这个窗口很可能被用户的浏览器阻止，于是一阵手忙脚乱。此外，时不时还会在发布之后出现生产环境的故障，拥有产品经理和项目经理双重身份的我们也是义不容辞，需要站出来紧急应付，相当于临时发起一个小项目，每次也都是惊心动魄。
我比较关注的还是需求方面的变化，所以上述几种情况发生以后，多多少少还是按照第3.3.2节里的图3-17“日常需求发布流程”来处理，只不过更灵活而已。从这几点上也可以看到让产品经理做项目经理的好处，因为了解业务，所以在面对各种情况时，可以有比较全面准确的判断。
最后，就算没有碰到刚刚说的那些变化，项目中还会碰到资源不足的问题，比如因为早期评估的不准确而吃紧。多个项目并行是正常现象，它们之间肯定有优先级高低之分，一般在产品会议上已经确认，资源冲突时遵循“慢车让快车”的原则，当自己在“开快车”时，“人挡杀人，佛挡杀佛”，不过也不要做得太过分了，谁没有“开慢车”憋屈的时候呢。
关于人力资源，半途加入项目的、其他部门配合的人员，很容易消极怠工，这时候就需要项目经理拿出沟通的本事了。再给他讲一遍Kick Off的PPT？把他从帮忙的心态转变成为自己做事的心态？请他喝一罐可乐聊聊人生、谈谈理想？大家各显神通吧。态度问题没办法，那是因为公司招了个烂人，或者办公室政治一类的烂事，如果对方确实是没时间，那好办，我的经验是统一战线，向他的老板表明问题，帮助他减轻压力，千万不能有“你不帮我做事，我向你老板告状”的情况发生，这实在太低级了。
3.5 山寨级项目管理
带过我的一位老板说：“计划与控制，就是项目管理”，话虽简单，但做好太难。第3.2节到3.4节，我们从Kick Off开始讲到项目小结，先说计划，再说控制，完整讲述了项目的坎坷一生。这节中，我们再从互联网和软件项目自身的特点出发，看看项目管理中的几个关键问题，它们是：文档管理、流程管理、敏捷方法。
题目叫“山寨级项目管理”，就像山寨精神一样，这并不是一个贬义词。我们的项目，没有系统的管理理论，没有成熟的文档与流程体系，甚至本身就不是一个完整的项目，一般没有采购、成本预算的事情。但我们牢记目标是为了把产品做好，作为产品经理来管项目，山寨没关系，工具不重要，“文档只是手段”，“流程也是手段”，“敏捷更是手段”。
3.5.1 文档只是手段
模板、规范、操作步骤……这些文档的作用实在太大了，大到导致有些朋友会醉心于此，特别热衷于问别人要一些很个性化的PRD模板、项目流程等，本来文档只是更好做事的手段，却被有的人当成了目的。
在这里，我先分享一下自己几年来建立的PD常用的文档规范，然后聊聊各种文档模板的本质作用，接下来谈文档的多人协作与版本管理，最后就文档写作常用的工具——Office软件说说自己的体会，希望同学们能更好地利用文档为产品创造价值。
建立自己的文档规范
从2007年下半年开始，我主动担负起了制定团队文档规范的责任，基本每隔几个月就会整理优化一次，然后像发布产品一样在产品团队内部发布一个文档包，并且起个很酷的名字：PD_std_template_tool_kit，如图3-22所示就是2009年的某个版本。
图3-22 PD常用的文档模板
通过几年的总结，我觉得图3-22中的文档基本能覆盖PD日常的绝大多数工作，从BRD开始，按顺时针顺序介绍一下各个文档。
商业需求文档：很重要的BRD，单独列出，第2章里已经讨论过。
产品需求文档：同样重要的PRD，前文已有详细阐述。
需求规范类：
► PD做什么：这是对产品和团队的PD工作内容的一份总结，可以让新人快速了解自己的工作职责。
► 用户体验规范：又细分为如下几个部分，这部分最好让负责用户体验的同事编写。
交互规范：页面上各种控件的规范，如列表的默认排序、列表翻页控件的样式等；各种判断规则的规范，包括字段的校验规范、出错信息反馈的规范等。
视觉规范：如页面大小、字体字号、颜色编码等。
文案规范：如语言风格、语法模板、常用操作的标准说法等，最常见的问题是，一个产品中同时出现“新增”、“新建”、“创建”多种同义词。
► 通用原则：待补充，大家可以看到这份文档也是需要不断优化的。
需求管理类：
这部分内容第2章中都有涉及。
► 用户调研：这份模板说明了典型的用户调研前、中、后都要做什么，调查问卷、用户访谈提纲怎么设计，有哪几块内容。
► 产品需求列表（含需求管理流程）：产品需求列表的模板，需求管理文档的模板，需求状态变化的流程图等。
► 产品信息架构：待补充，用来描述产品的页面或功能之间的关系，比如网站地图、导航结构等，可以和负责用户体验的同学一起制作。
流程管理类：
只列出了小团队常用的。
► 日常发布流程：在第3.3.2节中的“再看需求的生老病死”中已经提到。
► 变更事件流程：如紧急发布流程、需求变更流程、需求搭车流程等，本书不做详细讲述。
项目管理类：
► 项目管理制度：原则性的东西，比如产品会议制度，项目经理、开发经理、测试经理的权责利，这里沿用了公司统一的制度。
► 项目任务书：网上有很多模板，小项目可以灵活变通，用BRD代替。
► Kick Off的PPT：之前已经说过。
► 项目组织结构：这个模板我每次填几个名字就可以了，没啥技术含量。
► 项目WBS（可生成进度）：我用的是一个叫“WBS Chart Pro”的小软件画的WBS图，可以直接生成Project文件，就是说项目计划也有了。
► 项目日报周报：主要有今日/本周要闻、明日/下周看点、当前问题、所需支持、项目进展等几项，在第3.4节的“以终为始，项目小结”中给大家分享的本书项目周报，用的就是这个模板。
► 项目发布预告与公告：大量的重复内容模板化，为了省时间而已。
日常工作类：
► 会议记录：大家都很痛恨没结果的会议，有了这份文档，多少能逼着每次会议都产出一些内容，比如会议决议、遗留问题与行动方案等。在第5.3.2节的“我们急需靠谱的会议”里我还会单独分享“会议”这个话题。
► 个人日报周报：用于团队分享每个人的工作情况。
另外还有很多文档，比如编码规范，包含一些编写代码的规矩、函数命名规则等，对开发工作非常重要，但PD使用不多，也就不含在内。
我渐渐意识到，这文档规范是在为公司、为团队、为产品做，更是在为自己做。试想一下，把这份文档去除公司的烙印，融入自己的理解，随身带着走，今后不管在哪里工作，只要做的还是产品相关的事情，这份文档规范都是一笔独特的财富，也是自己的核心竞争力之一。如果你想要这份模板，可以到我的博客上下载【27】。
模板作用知多少
上节提到了我的常用文档模板，其实模板的本质作用有三：
让经常看同类文档的人提高效率：当开发工程师看惯一种UC文档以后，如果突然换成一种哪怕更好的写法，他们也会很不适应。
让写文档的新人可以尽快上手：新人可以根据模板，快速写出和团队里“老人”差距不大的文档。
让写作者不会漏考虑某些内容：比如PRD文档的整体说明部分，有7项内容，如果每次都从零开始写，难免漏掉一两项。
各种结构化的方法论，比如规范、流程的作用也大致如是。
相对成熟的团队与产品，在某个项目开始之前，我们必须约定好各种模板、规范与流程。某次，我和其他公司合作做项目，在此过程中，我深深体会到方法论差异导致的灾难，合作双方的各种文档差异很大，但是都在按照自己习惯的方式做，直接造成沟通成本的迅速提高，最终这个项目也不太顺利。所以在一个长期合作的团队中，方法的统一真的非常必要，注意，我强调的是“统一”，并没有强调一定要用“某种格式”。
我们知道各种模板、规范并不是与生俱来的，在团队刚成立、产品刚成型的时候强推，或者在团队、产品都已经很成熟的时候弥补，都是不合适的。和一些同行交流过，大家都比较认可模板与规范应该在需要的时候自然生成，逐步从简单到全面，不断迭代优化，无须也做不到一蹴而就。而最适合开始做这件事的时机，就是产品1.0版本发布，进入1.1、1.2版的升级阶段，但尚未开始研发2.0的时间当口；或者说创业团队开始膨胀，不断加入新人的阶段。这是因为1.0发布之前常常是急行军，顾不上文档之类的事情；刚发布后的一段日子团队会有一个休整期，PD收集反馈以确定下一步方向；开发和测试的同学也要为扑面而来的线上故障忙一阵子；团队人员也会做相应的调整。所以这时候，我们应该总结第一代产品、第一代团队的得失，取精华去糟粕；并把优良传统传递给新人，以期提高今后的效率，而模板和规范是很实用的形式。
当然，经常做的事情才有必要形成模板或规范，但总有一些偶尔为之的事情，它们就需要具体情况具体对待，生成一些独特的文件了。比如想对某网站的导航结构做调整，就可以单独写一个Excel文件描述。这时候千万别自作多情地又增加一个模板，因为这不符合“奥卡姆剃刀原理【28】”。用一次就束之高阁的模板，就像只制订却不执行的规定，只会反过来降低已有规定的权威性。
多人协作与版本管理
项目中我们会生成很多文档，一开始并不需要多人协作与版本管理，因为事情并没有那么多，只需要一个人来负责，自己在本地维护一份文档，及时主动地给团队成员更新，注意备份就好。但产品和团队在不断前进，渐渐地一个人实在是忙不过来了，于是我们遇到了新的问题：经常需要多人维护同一份文档，某人更新之后，其他维护者或阅读者手中还是老版本。
产生文档版本管理的本质需求是多人合作，协同办公。
比如产品需求列表的维护，团队每个人都有编辑的需求，于是我们在没有任何指导的情况下，想到了用Windows系统的共享文件夹，可是发现有人打开文档的时候，其他人就无法编辑了；又想到了Google Docs，可惜用惯了微软的Office，Google的总觉得不顺手；还想到了微软的Office live，可怜网络速度慢得让人难以忍受。
后来，我们借鉴了工程师们对程序代码的管理方法，尝试过几种版本管理工具：SVN，对权限的控制比较精细，有几次保密项目用得挺顺；VSS，只在和微软合作的项目中用过，感觉更复杂一点。
我们觉得版本管理软件总还是过于麻烦，再往后大家又尝试着用Wiki。主要有两种方式，一种是把任务做比较精细的切割，每个PD各自维护自己负责的文档并保持最新，上传到Wiki汇总整理，如有多人共同编辑的文档，养成随时去Wiki下载、及时上传最新版的习惯；另一种就更先进了，完全抛弃了Word、Excel等软件，直接把常见的PRD、产品需求列表等写在Wiki上，这样完美解决了多人合作的问题，可以告诉团队其他成员直接上Wiki阅读，随时看到的都是最新的版本。
这些版本管理方法，本质都是把“版本更新通知”的任务从文档维护者手中分散到每个人的手中，并通过相应的工具来降低这个过程的成本，不过工具总是不能完全解决问题，所以团队成员的积极主动也是此机制顺利运行的重要因素。为了保证每个人随时了解更新，我们还逐步养成了重大更新邮件通知在即时通信软件的群里“吼一声”，甚至在座位上站起来对着周围一片大喝一声“又有更新了！”的习惯。
继续谈谈在Wiki上直接写PRD的优缺点。我们团队之所以没用Wiki是觉得它的表现形式没有Word丰富，另外就是阅读者的习惯问题。但和使用Wiki写PRD的团队交流以后，他们告诉我用Wiki有一个重大好处就是可以有一份“随时更新的整个产品的PRD”。
在旧的模式中，整个产品的PRD只在产品1.0版本时出现一次，之后通常每个项目都只是升级产品的部分模块，对升级内容我们会写一份PRD，久而久之就形成了以项目为中心的很多份PRD，随着时间的推移，对产品最新需求的描述散落在各份文档里，谁也没法整理出完整的产品PRD了。这样造成的局面就是产品团队每个人都只清楚自己做过的项目需求，如果有团队新人想全面了解产品或产品要大面积的改造就很麻烦。和基于项目的PRD不同，基于产品的PRD会把文档像代码一样管理起来，Wiki可以直接在网页上编写，而且可以采用类似SVN使用的版本管理模式，项目启动后先把要更新的需求描述从产品PRD里分离出来，项目完成后再将最新需求并入整个产品的PRD中。
此外，Wiki里做超链接也非常方便，可以在各个功能的说明之间来回跳转。也许，我们团队也真的应该试试直接用Wiki写需求。
这节的最后，建议大家都养成用版本号管理文档的好习惯，这是为了自己，更是为了受众，与我长期合作的同学都知道，我的文档版本号中有很多含义。分享一下我的命名规则，非常简单：第一次给别人看是0.5，以后每次自己的修改，改小数点后第二位，比如到0.51、0.52，有过集体讨论后的较大修改，会改小数点后第一位，比如变成0.6，直到第一次正式对外发布，改为1.0。
玩转Office足矣
聊了这么多文档的事儿，在很多外人眼中，需求人员整天就是在写文档，那总得给平时一直在用的几款写文档的工具露脸的机会吧。其实我们能玩转微软的Office就足够了，应届生的简历往往会写精通Office，但工作几年的人，很少再敢这么写了……所以我也只说几点自己平时的心得点滴。
Word：做结构稍微复杂点的文档时才用，简单的几段话一般用记事本搞定，打开Word绝对不是一开始就码字，而是要先设置一堆东西，比如页面、格式、样式、标题级别等，充分利用Word的自动功能，我写这本书时就是这样的，这和编程有点像。
Excel：在写结构化文档的时候很好用，当你用Word写作时发现老是写1、2、3……条的时候，就要考虑是不是应该转用Excel了。它的几个基本功能：条件格式、筛选、单元格有效性、单元格锁定、隐藏，可以让你的表格看起来更专业。一些基本函数的应用，可以让我们处理表格、简单统计、数据计算与可视化的过程更加流畅，如果你会VBA【29】当然更好。
PowerPoint：阿里巴巴的CEO卫哲说PPT的简称就是“骗骗他”，而用PPT演示就会既没有“Power”也没有“Point”，开个玩笑。不过PPT只能是演示者的辅助工具，更重要的是思路。PPT中应该尽量减少文字，最好只有图片和超大的数字，但我们经常又要满足“受众拿到PPT就可以了解内容”的需求，非常幸运的是PPT里有一个叫做“单击此处添加备注”的地方，可以把所有想说的东西都附加在这里，在演示的时候用双屏，自己的电脑上显示“演示者模式”，这样一来防止自己忘词，二来不干扰听众，三来可以让有事来不了的人通过看PPT了解全部内容，一举三得。另外自己很注意的一点，也是从软件可用性概念获得的启发：让每张PPT上想说的观点一条一条地出现，并且突出当前在讲的这一条，这样做是为了让受众的注意力聚焦，从而更好地理解我们想传达的观点。
以上是我的Office三部曲，又是一次“字→表→图”的进化，越往后越高级，平时我们做文档的时候也多想想，尽量用高级的工具，让读者看着更轻松。顺便提一下另一种平时经常写的文档——Mindmap，思维导图，它用来整理思路特别合适，经常在某项任务的早期产生，常见的生成软件有MindManager、FreeMind、XMind等。
下面三款软件就稍稍专业一点。
Visio：这个真的很强大，绝大多数我能想到的图，Visio都能画。刚提到的思维导图；业务逻辑图；产品Demo（当然专业点比较流行用Axure）；简单的UML图，如用例图、活动图、时序图；团队组织结构；项目管理的甘特图；甚至家里装修布置都可以用。
Outlook：当邮件多到必须选择看一部分，无视另一部分的时候，Outlook才能发挥真正的作用。对于能够每封邮件必看的人，其实E-mail并没有达到需要管理的程度，换句话说，这时候我们还只是一个初级用户。不过，创建自己的收件夹结构、邮件规则、邮件标记、会议邀请几点真的有必要好好研究一下，其对提高工作效率很有用。
Project：开发经理和测试经理在安排详细的开发计划和测试计划时用得更多一些，对于PD，一个同事说他用得最深入的一次是自己的婚礼筹备。Project对于复杂项目的安排，特别是牵扯到超多任务、多种资源，互相之间又有复杂的依赖关系时，还是非常实用的。
Office的其他产品，如有不少人用OneNote作自己的时间管理工具；Access可以当做简单的数据库管理工具（在数据量大到Excel打不开的时候很管用）；另外还有Publisher、Infopath等，适合一些比较专业的应用。
3.5.2 流程也是手段
长视者把目的当手段，短视者把手段当目的。比如教育里的高考、科研里的论文、公司里的KPI……我们研究手段，一定不能忘了目的。
文档只是手段，流程也是手段，这些手段都是为了把项目做好，把产品做好；把项目和产品做好也是手段，是为了达到公司的商业目标；达到公司的商业目标也是手段，是为了完成公司的使命、实现公司的愿景；你要是愿意，还可以往下想。
回到本节，我们来聊聊流程。
项目VS.流程
“项目流程”只是一种特殊的流程，我们先辨析一下“项目”与“流程”这两个词的关系，小明和大毛又跳出来进行了如下一番对话。
大毛：项目只做一次，所以追求可行解即可；流程要反复做，所以要追求最优解。相似的做多了，就不会满足于可行解而想追求最优解……
小明抢话：这时会出现流程，比如结婚对于每一对新人来说都是一个很特别的项目，而对于婚庆公司来说就有整套的流程。装修也一样，如果自己做新家装修，那一定会起个项目来处理这件事，而如果是外包给装修公司，他们就可以走流程了。
大毛：嗯，例子不错，生活中的做事原则也是一样。项目是跳跃式发展，有始有终，比如历朝历代的开国皇帝，虽然打江山易，但它在价值链上更重要；流程是常规活动，周而复始反复应用，都说守江山难，是有点吃力不讨好啊，江湖地位总是差一些。但是项目管理是独特工作，风险大，效率低；流程管理则是例行工作，风险小，效率高。
小明：啊，我发现了，其实中国人不擅长做项目是有传统的，因为我们是农耕文明，生产制造大国，所以擅长做流程管理；而西方的狩猎、游牧文明，就有明显的项目管理的影子。
大毛：好吧，你真能扯……
有一次我去参加流程管理的培训，发现现场有很多传统行业的朋友，而且年纪也明显比我们大不少，正如传统行业比互联网、软件行业的年纪大很多一样。课程中我发现，经过几十年上百年的积累，传统行业的流程明显细化了很多，比如奇瑞汽车的项目过程中有两三百个评审点，这还是精简过的，加上采购、物流等实体工业特有的元素也让他们的产品开发过程复杂了不少。不过，毕竟都是产品研发的流程，总还是有相似之处，比如：制造业的样品，类似我们的Demo；小批量试产，类似部分用户的内测等。对于通用的做产品的流程，我也记录了下来与大家分享：
► 概念：启动阶段，关注商业规划，DCP1【30】。
► 方案：立项，项目执行层面的非关键成员加入，关注规格、计划，DCP2。
► 开发：控制过程。
► 验证：测试，DCP3。
► 发布：项目团队解散，成立LMT【31】，老人带新人做生命周期管理。
► 生命周期维护：DCP4。
前面两个阶段需要高手做，进入第三个阶段，高手应该去做新项目。这里有个通用的原则：新人做老产品，新人不挑活，老产品不容易出事；老人做新产品，老人需要变化才有激情。
流程的本质目的
我从做网店版开始，直到大半年后才有了日常需求发布流程，对于创业团队来说，流程也不是一开始就有，而是需求驱动的，再回顾一下那段经历。
2006年年底项目最初阶段，团队主要成员都是新人，当时连要做什么都不知道，所以靠的是几位老大和我们“随机应变”式的个人控制来把握项目进程。那时每个人对产品的一切都非常了解，对需求的响应速度也超快，经常是晚上要发布，下午PD还会直接跟开发的同学提新需求，而开发听了几句口头描述后马上就开始编码，然后测试的同学凭感觉点两下没问题也就发布了。这种猛打猛冲团队的感觉很畅快，其核心优势就如《功夫》里的火云邪神所说——天下武功，无坚不破，唯快不破。
到了后来，加入的人越来越多，产品也越来越庞大，大家越来越感觉已经不能掌握产品的全部，经常需要询问别人，有的时候甚至找不到一个知道的人。于是大家渐渐地不敢那么快了，不然出了问题都搞不清原因。插一句，当你对一个产品不太熟悉的时候才更容易体会到产品是否易用，这是对产品了如指掌的时候是体会不到的。
于是，产品、团队、项目进化了以后，再依靠个人英雄主义是不行的，那样英雄会累死，项目也会失败。这时候出现的流程和规范都是一种管理的方法，产品在“快”和“稳”的平衡上，也要稍微向“稳”偏移。
在淘宝UED团队的博客【32】上看到过一句话很认同：设计流程的目标，在于保证“无论谁来做这个产品的设计，都能达到80分”。没错，80分已经很难了，当产品越大的时候，诞生天才产品的概率也就越小，“又快又稳又有才”的100分产品是可遇不可求的。华为的同学也跟我说过他对流程的体会：流程的好处是人走了，事还能做，减少特定的人的影响。还一位前辈告诉我：路况（即软硬件环境）与开车水平（即个人能力）的要求成反比，流程的目的就是改善路况。
其实上面这些话说的都是一个意思，自己小结一下：
当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事的时候起码不会太无助。在这点上，规范、模板的作用也类似，这就是团队的核心竞争力【33】。
一件事情总是有它的两面，流程帮助了产品，但对于后来者的个人成长也许不利，比如只能接触到产品工作的某一个层面，缺乏对大局的了解和把握，从而成为一颗“螺丝钉”。这就需要后来者自己寻求突破了。结尾讲一个故事：
说古代有个著名餐馆有幸花重金请到了御膳房的一名厨子，老板毕恭毕敬地请他做一道拿手菜。
厨子：我不会做菜。
老板：啊？
厨子：我只是御膳房“调料部”的。
老板非常失望，转而又想调料也不错啊，很重要，至少能尝尝地道的宫廷味道，于是又毕恭毕敬地说：那烦请大师做一份宫廷特制的调料吧。
厨子：这个我也不会。
老板：啊？
厨子：我是调料部“青葱组”的。
老板：……转而一想，实在不行就尝个宫廷的葱味吧！
厨子：我也不会做葱的全部……
……
厨子：我是负责切葱的……
那么多评审，可以省吗
看到这里，你可能会想，小团队哪有这么复杂，没有定好的一步一步，从来都是具体情况具体分析，能省则省。没错，其实我们也是这么过来的，幸运的是当时团队里有头脑清醒、经验丰富的前辈，他很清楚哪些流程可以省、哪些不能省，以及背后的理由，这让我们少走了不少弯路。
3年过去了，我也斗胆冒充一下老鸟，分析一下日常的项目中，那么多评审会议，是否可以省。我把项目中一次又一次的会议，都看做是评审：从立项之前的产品会议，到Kick Off会议，需求评审（又可分为PRD评审、UC评审、Demo评审），设计评审，代码评审，TC评审，功能评审，以及发布评审。
产品会议：必须有，决定“做不做、做多少”实在太重要了，方向错了很可怕，如果没有多个产品之间的资源争夺，同一个产品的不同需求也必须争夺，可以把确定需求商业价值的需求讨论会、初评工作量等工作都放在一起作为产品会议。参与者最少得是产品团队、开发、测试、销售、服务等各个部门的头，或者有话语权的接口人。
Kick Off会议：最好开一下，鼓舞士气的，磨刀不误砍柴工，可以考虑与需求评审合并为一次会议，安排在最开始的15分钟，因为它们参加的人员差不多。这个会议，项目干系人都应该到场，有的人可以在Kick Off结束后离开，不参加需求评审。
需求评审：如果项目Kick Off之后只做一次评审的话，那就是需求评审。具体的PRD、UC、Demo评审，我们也很少分为三次，看项目情况，任意两个都有可能合并，甚至三个合并。举些例子，如果某个项目没产生几个新页面的话，Demo评审就可以并入UC评审；如果是一个简单的功能改进项目，不涉及重大业务调整的话，很可能三个评审合并；如果是一个产品页面改版项目的话，也许把PRD与UC评审合并，单独做Demo评审更好。
设计评审：表面上看起来经常在时间紧的情况下省略，实际上是在开发人员实力很强的情况下省略（他们在需求评审时会问很多问题），而开发较弱、新人多、业务不熟的团队，则必须进行设计评审，否则是给自己找不自在，后面出问题很麻烦。实战中还有一些技巧，比如一般是在设计简单的时候，合并UC评审与设计评审。又如有的团队在需求评审的时候，让开发人员而不是PD来讲述他要开发的那部分需求，PD则来提问。对比更常见的PD讲述，开发提问的方式，这样做有两个好处：一是逼着开发认真看需求；二是可以省去设计评审，更准确地说是降低不做设计评审的风险。
TC评审：仅次于需求评审，这是在项目KO以后第二重要的评审，敏捷方法很看重测试，实在要省也可以，那么PD会更辛苦一些，需要做更细致的验收测试。与设计评审类似，TC评审也属于纯技术的评审，商业团队一般就不参加了。
功能评审：这其实也是必须的，而且需要项目干系人都参与，但我之所以没有把它列为和需求评审一样重要，是因为功能评审经常采取线下的方式进行，比如邮件里告诉大家产品的测试环境地址，然后大家自己去看。当然，对于重要的项目，我还是建议开一个产品演示会。
发布评审：可以让开发经理决定是否需要。
评审会议本身并不产生价值，应该尽量简化，不要反受其害。而基本原则就是一句大白话：重要的评审不能省，最好单独评审，参与者取决于评审内容偏商业还是偏技术，而这些判断，没有统一标准，我只能说是与产品、项目、团队的特点相关了。
商业评审与技术评审
上一节把所有常见的评审放在一起又分析了一遍，不知道你有没有隐隐地觉得，它们分为两类，即“商业评审”与“技术评审”。简单地讲，商业评审决定“做不做”，是产品会议与功能评审；而技术评审决定“怎么做”，是需求、设计、TC、发布评审。我做过一些比较理论的摘录，分享如下。
商业评审的三个决定是：项目继续、重新定向、项目终止，很重要的目的就是砍项目。商业评审也是分阶段分发资源的时间点，会给通过评审的项目发放到下一个商业评审点之前的资源，而在两次评审之间可以“将在外君命有所不受”。
技术评审的三个决定是：项目继续、有风险的继续、必须解决某问题后再继续。需要避免的情况是技术评审三部曲：抓壮丁，随便找有空的人来参加；科普会，来的人根本不了解情况，说很多基本信息；批斗会，没完没了的争论。
商业评审与技术评审两者最好分开，或者说在任何评审会议上不要同时讨论商业与技术问题，否则会被技术人员带入细节讨论，或者商业人员打击技术人员，或者决策者思维被搅浑。当然，无论哪种评审，来参加评审的人都要承担相应的责任，反之，没关系的人都不要来参加，免得浪费时间。
评审是流程中的关键节点，节点设置的顺序正确、数量合适，才能保证流程的通畅。最后改编一个小段子，我们发现，连游戏都需要合理的流程与评审。
你进到赌场，环顾各种游戏，最终决定玩21点，这叫项目通过产品会议；你坐下来，示意庄家开始发牌，这叫Kick Off；庄家每次只给你一张牌，等你回应，这叫设立评审点；你每次都看一眼，决定放弃还是继续，这叫评审；你觉得手上的牌已经足够大了，最后亮牌，这叫发布；如果不幸点数爆了，这叫项目失败。
3.5.3 敏捷更是手段
2007年夏天，网店版在很长一段时间内保持一周发布两次的快节奏，最近两年，很多产品也都保持着平均一两周发布一次的频率。这么快的速度，是为了迅速响应市场与用户，这个特点和互联网、软件项目的其他特性杂糅在一起，必然要有相应的方法论支撑，所以，从2008年起，作为项目经理的我开始学习体会“敏捷方法”。
从书本到实践
在互联网和软件领域中，项目管理理论的发展，和任何知识一样，开始很混乱，每个项目自有一套，每个项目经理自有一套。后来人们非常想定出一个统一的、简单的流程，以减少人为影响，所以软件工程里的瀑布模型【34】等出现了；再后来发现瀑布模型有其局限性，于是提出了敏捷方法【35】。
经典的软件工程方法旨在定义一套完备的过程规范，使软件开发的运作就像是机器设备的运转，人在其中则是可更换的零件，不论是谁参与其中，机器都能运转良好。这意味着：开发进度的可预见性，流程方法的固化与可复用，人力成本的节省，人员的流动不会对软件开发构成影响等。这样的做法对于公司而言，是具有很大吸引力的。其背后所隐含的观点则是：软件从业者无须是具备非凡智力的高级人才，人是一种可以被任意替代的资源，并且软件的需求从项目开始的时候就是确定的，而且不会改变。这显然是不符合事实的。
所以在瞬息万变的互联网、软件行业，大家渐渐体会到敏捷的优势。我们参考了几种经典的敏捷模式，按照产品、团队的需要定制了属于自己的敏捷方法，特点如下：
有计划，更要“拥抱变化”。
随着时间变化，必然有新的信息出现，特别是市场环境、用户情况等瞬息万变的互联网业界，所以死守着的项目计划不调整是没有逻辑的做法。并且，项目估计的不确定性是会累积的，80％×80％×……以后，能确定的就更少了，所以开始订的项目计划，在一个月后很可能已经面目全非，强行遵守是没有意义的，而应该不断地修正，当然，在一开始的计划中间就应该留有一些弹性。
迭代周期内尽量不加任务。
敏捷再灵活，也不能容忍毫无控制的变化，“迭代”权衡了变化的成本和不变的成本，这是一个将“大项目长期不变”细化为“当前迭代不变，下次迭代待定”的做法。此外，如果某次迭代内的任务无法完成，可以为了时间点的要求，移出一部分任务到下一个迭代。我们可以把每个迭代看做一个小的瀑布模型，其实Royce前辈早在1970年提出瀑布模型时也谈到过迭代的思想，不过经常被后人忽略。所以说敏捷其实并没有排斥经典的项目管理方法，只是各种方法都应该用在最适合的场景，瀑布模型对于需求固定的项目还是不错的，比如它在管理一个工厂时就非常有效。
集中工作，小步快跑。
项目干系人都在一个区域办公，或者在一间会议室里办公，这样可充分利用白板和墙壁。相应地就要求团队较小，一般小于十几人，太多了可分割为多个团队。同时，项目有较短的迭代周期，通常是2～4周，我们推崇每日“站立晨会”，会长小于20分钟，每个人只能说3个问题：昨天做了什么？今天要做什么？碰到什么问题，打算如何解决，需要什么帮助？集中工作也是为了倡导较少的文档，更多的口头沟通，其实这点对团队成员要求很高，特别是对国内的技术人员。
集中办公、团队较小、文档较少等特点让很多创业团队看似敏捷，但其实他们徒有其表，并没有领会精髓，存在很多隐患，往往项目前期很快，发现问题的时候已经晚了……
持续细化需求，强调测试。
需求唯一不变的特征就是“不断变化”，项目与产品都要小步快跑，用不着在需求阶段纠缠。有些需求在开始的时候是提不出来的，或者说没法细化的，所以试图一次性完成需求分析的工作会存在“过度需求”的问题，是浪费时间的行为，到后来多半还是要改。
我们在开发和测试过程中完善需求，而且特别看重测试驱动项目，更早的测试，重度的测试。这需要有很强很严谨的测试人员，TC编写、TC评审，甚至测试执行的过程可以用来补充和细化需求，比如业务逻辑里的一些限制条件、异常流程等，往往都是测试人员提出来的。
不断发布，尽早交付。
让需求方不断地、尽早地看到结果，并给予反馈，当然需求方代表要有话语权，不然半途杀出个老板说三道四是令人极其郁闷的。这点也要求需求方充分投入，包括集中办公、参与验收测试等。我们的“冒烟测试”、“每日构建”就符合“尽早交付”的概念，可以让需求方尽早看到最新的产品。不断地发布也是为了把大问题分而治之，先解决最核心的，风险最大的部分。我们会先完成最重要的功能，所以说敏捷的里程碑是功能驱动的。
说到这里，我提一下，我们公司的项目发布时间通常是周二和周四晚上。这是因为周一大家刚回来工作，状态不佳；周五又归心似箭，并且发布后有问题的话第二天没人上班，不适合；安排在周三的话就会有连续两天发布，时间周转不过来，而且可能在精力体力上吃不消。所以公司渐渐形成了每周二、周四为发布日的惯例，如果需要额外的发布，则要特别提出申请，毕竟很多部门要相互配合。当然如果每周只有一次发布的话，周三也是个合适的选择。
以上各点之间也存在着千丝万缕的联系，比如说固定的迭代周期可以保证不断地发布，较轻量级的文档降低了持续细化需求的成本等。
项目中的敏捷沟通
“无论最终发现什么，我们必须理解并完全相信：每个人在其当时所处情况下，在其能力范围中，做了最大的努力。”
这是敏捷里让人很温暖的一句话，让我们互相理解，又能激发团队力量。在此基础上，更顺畅的沟通成为可能。接下来说说我亲历的团队在真实的项目中是如何沟通的，不妨起个名字叫做“敏捷沟通”。
我们的每个项目，项目经理都会建立一个即时通信的IM群，我们用的是阿里旺旺；一个临时的邮件列表，把项目干系人全部加入。IM用于实时沟通，比如发了重要邮件要大家赶紧收、文档有重要更新、测试环境正在构建暂时没法访问等，都可以在群里吼。旺旺有群公告，我们会贴上项目各种文档、资料的Wiki地址，以及一些测试环境的地址等公共信息。项目相关的第一封邮件，会把大家的E-mail收集齐，在此邮件最后说明“本项目干系人以此封邮件为准，大家的项目邮件可以直接回复全部并修改邮件名称和正文”，我们可以通过此邮件建立项目的邮件列表。当然，之后有人员变化也可以随时增删。
我们坚持着经典的每日站立晨会，对于典型周期为2～4周的项目，控制粒度到“天”很有必要，“项目看板”视情况而定，举例如下。
如图3-23所示，是用白板做的项目看板，这类项目典型长度是两个星期，看板可以和项目日报、晨会整合应用，板上横向为各个功能点的进度百分比，纵向为项目成员。每个项目成员负责的功能点，用一张张便笺表示，在项目开始的时候这些便笺都贴在0％的下方，随着项目的进行，它们就逐渐被拿到右边的方格里。每天晨会的时候，大家都围在白板前，集中调整便笺的位置。红黄绿不同颜色的便笺可以用来代表不同类型的任务，白板最右边留出一块写其他必要的信息，非常随意。用了这种看板，对于周期如此短的项目，邮件日报有时就可以省略了。这个看板的最大好处是随时可视，项目成员、老板路过都会看两眼，而每个人要自己贴条，也是一种督促和帮助，试想大家都按进度在走，你老是滞后，自己也有压力，另一方面，如果真遇到困难，大家也能及时发现并提供帮助，让每个项目成员都对项目进度负起责来。
图3-23 白板做的项目看板
如图3-24所示，是“魔方计划”的项目墙，和白板比起来，这个项目相对长期，两个月左右，毕竟这样一个KT板也要200多块钱，上面主要有整个项目的时间轴、各个团队的重要里程碑、产品设计过程的一些可视化文档等。究其目的，也是让所有项目干系人随时可以了解到项目的各方面信息，在每个项目里，类似的看板应该包含哪些内容，大家可以边实践边改进。最终能做到根据项目特点的不同，在启动的时候自然使出最合适的项目管理方法，从而画出最适合的看板，就是最高境界了。
图3-24 “魔方计划”的项目墙
我们还有一种特别的沟通手段——吼，就是一大早在办公区里吼一声，“魔方”的同学开晨会了，还是很提神的。顺便再说一些用过的项目代号，比如“还魂丹”，是激活沉默用户的项目；“画皮”，是产品的界面风格改版；“画心”，是产品的交互风格改版，这个项目Kick Off的时候，项目经理循环播放张靓颖的《画心》做背景音乐，感觉真的很不错；时间长了，会发现这些名字会有明显的风格特色，像我们团队就很古典民俗风，而有的团队就特别喜欢高科技元素。
最后小结一下，从沟通扩大至整个敏捷方法，任何团队都在探索一个介于“无过程”和“过度过程”之间的折中方案，使之给团队带来最大的收益。
与外包团队的敏捷尝试
2008年春，我在做一个相对比较大型的项目，二三十人，三五个月。亲身经历了一个项目是怎样不顺利地一步步走下来的。
先说一下背景，这是一个外包项目，我们公司是甲方，我是甲方的代表，也算是项目经理，负责项目实施的乙方是一家很大的外企。项目工期是由商业谈判决定的，时间非常紧，在没有充分评估工作量的情况下，乙方项目经理按照比较传统的“需求、设计、开发、测试、发布”的模式，把三个月的时间按照比例划分给各个阶段。于是，项目做着做着就出现了延期现象，大家先试图简单地用加班的方法赶上进度，不成功，后来我带头强行注入了一些笨拙的“敏捷”方法，结果比较失败，这个项目也引发了我对敏捷的兴趣。
事后分析，我觉得那次“项目外包”的模式本身就与敏捷格格不入，主要是在甲乙双方的意识上，存在着太多与敏捷理念冲突的问题，双方都有问题，也都付出了不小的代价。
首先，项目外包使得甲方不愿意砍需求。甲方认为，反正是乙方干活，合同都签了，那么显然是能多做一点就占一点便宜。比较而言，公司内部项目的需求在很大程度上是可以砍的，是“保质不保量”，这更符合敏捷的原则。但是项目外包，甲方在提需求的时候不愿把任何一个功能像平时那样推到下一期做，因为这个项目结束后，下一期在哪里都不知道，所以“保质保量”变成了“不保质保量”，希望一口吃个胖子。
其次，甲方“验收测试”团队的工作方式与乙方配合困难。敏捷会导致提交测试的产品和最初的需求之间必然有很多变化，并且文档很难完全反映，而这种敏捷在公司内部之所以运行得很好，是因为PD、开发、测试人员在项目过程中可以充分交流，测试在TC评审的时候会叫上PD和开发，有些属于详细设计的细节是在评审的时候直接与开发人员确认的，在测试执行过程中也会协助确认需求细节并迭代测试。而这次项目外包的时候，甲方的测试团队没有和乙方一起办公，只是从一份颗粒度过粗的需求文档上派生出“验收测试”的TC，又因为验收有“考试”的性质，所以不允许乙方的开发人也参加甲方的TC评审，导致我只能和甲方代表确认细节，而我对如此细节又没有要求，无奈之下只能按照自己的想法描述，我经常发现甲方的测试人员考虑到了很多乙方开发人员根本没有考虑到的问题，再通过我来传递信息，必然导致双方对需求理解的鸿沟。虽然乙方也有自己的测试团队，但明显他们的测试强度比起甲方的验收测试差很多。
最后，乙方缺乏“敏捷”的经验和意识。职业性质和国内的项目管理现状决定了外包团队里的工程师习惯于按照详细的设计文档做开发和测试，抗拒需求改变。所以强行“敏捷”会导致失控，因为没有一份完整的详细设计文档，开发人员会按照自己的想法编码，测试人员也照自己的想法测试，又没有和需求人员充分沟通的习惯，也没有一个迭代的过程，再为了工期的死命令削减测试强度，结果就是发现做的东西与需求不符的时候已经晚了。
这个项目的验收测试做了好几次，最后一次虽然通过了，但由于项目时间从三个月延长到七八个月，早已失去了当初的价值。很多原因共同造成了不好的结果，还有一些我到现在可能都没有发现的原因，但一次失败给人带来的收获往往大于一次成功，幸运的是我学到很多，不幸的是公司损失不少。最后送大家一句话：任何情况下，我们都要做好手头的事情，确保“就算这事儿对公司来说又黄了，我也要通过做事有所收获”。
3.6 物竞天择适者生存
三年多下来，大大小小的项目也做了几十个，总体感觉就是一路坎坷。听到过一段很辛辣的比喻，分享一下。
项目好比生小孩：
怀胎容易生下来难，生小孩容易养小孩难，不但培养成功很难，如果他身体不好看着也心疼……所以我们要少生优生。
如果不幸多生就要排定优先级，把资源投入到回报最大的小孩身上。
这就是“物竞天择适者生存”，不但是项目，你我在职场中也一样，借用《魔兽世界-巫妖王之怒》里的“安东尼达斯的银币”上面写的一句话：
请赐予我力量，去接受我所不能改变的；请赐予我勇气，去改变我所能改变的；并赐予我智慧去分辨两者的不同。
3.6.1 亲历过的特色项目
项目的特点决定了它们每一次都不一样，我也做过不少特别的项目，除了之前讲的那么多类似的事情之外，每个项目中，总会有第一次碰到的独特情况，所以随机应变也很重要，这一节就说几个让我印象深刻的项目。
如何做好“老板项目”
老板项目，就是指老板突然跟你说，我们要做个什么什么，然后你只有执行份儿的项目。什么，你们公司所有项目都是老板项目？很正常，那我们更应该聊聊这个话题了。
复习一下，我们做项目通常要在保证品质的前提下，在时间要求T、人财物花费R、项目范围Q三点上做平衡。
先来一个真实场景回放：
大毛突然被老板叫到办公室，他和蔼可亲，又情绪激动地对你说：“大毛啊，组织上有个重要项目要交给你，BlaBlaBla……（省去半小时）”，这都不关键，最后一句：“某月某日之前一定要发布！”
似曾相识？嗯。
首先恭喜你，通常这样的“老板项目”都是重要的项目，说明老板信得过你。然后你要反驳了，恭喜什么啊，我连做什么都不知道，居然TRQ的T已经定了？！
是的，当时就是这样。
传统项目管理中的那一套，先需求，知道要做多少事情以后，再协调资源，最后推算出时间计划，在这里跑不起来了。于是，阿Q的我们想到了一个理论支撑：Agile，敏捷！不是吗，更多的时候我们并不是很创新地提出敏捷，而是被迫敏捷，或是被老板逼的，或是被用户逼的，或是被对手逼的……人类的本性应该还是恐惧变化和不可知的吧，不知有多少人看到这里内心在呐喊——我爱瀑布模型！
所以有公司在价值观里宣扬“拥抱变化”真是很积极的一种人生态度。那我们来拥抱敏捷吧，看看在TRQ三方面应该如何拥抱。
T是给死的。可以试着商量一下，我们常犯的错误就是把老板的偏好当成规则，老板只是一时说最好怎样，结果我们理解成了必须怎样，那就亏大了。但也确实有很多时候很难改变，如果是老板的老板给老板定的，那就更甭想改了。通常，每一级任务的下放，老板都会给自己留一小段时间做缓冲，但是我们可千万不要在定项目计划的时候算上老板留给自己的这段时间，反过来，我们订计划的时候应该再给自己留一段，这些都是最后救命用的。
Q是可变的。先说Q，一般越大的老板给出的指示越具战略性，越不具体，所以具化出来的Q就可大可小了，这是我们可以发挥的地方。开始的时候，尽量施展自己的聪明才智，天马行空的爽一把，把Q搞大，尽量搞大，并合理地算出一个巨大的R，然后，你就可以欣赏到老板因为无法付给你这么多R而自己砍Q的表演了……当然，我们应该尽职地帮老板排出各种功能的建议优先级和所耗的资源，好让老板知道刀该往哪里挥。
R是丰富的。老板项目么，第一优先级，R就是大大的有，其他项目统统让路，让多少路，这个问题应该抛回给老板决定，我们只提供专家意见，狮子大开口：让得越多越好！记住，千万不用在这个时候就帮老板着想，应该怎么节省R，那样反而不讨好，老板会觉得你思路不开阔，没劲，我有过一次做了个项目方案，十几个人就可以搞定，沾沾自喜，结果老板说：你先给我照着100个人做这么久来规划……记得还有一次我在要项目经费的时候支支吾吾不敢开口，结果大老板以商量的口气问我：“一万？”我反而给吓到了。
真的这么爽？
当然不是，有时候你发现，老板比较猛，Q都帮你想好了，那只能说没劲，也别废话了，老老实实干活呗。更悲剧的是，R也是不足的，就那么几个人，又要在固定的T下做这么多Q，绝望？不至于，我们还有IT民工最后的必杀技——加班，天天加班，天天加班还不要加班费……我们期望的是老板看得到，公司有前途，明天会更好……
如果这样还做不完，那只能说——老板丧失理智了！同学，撤吧……
最后谈谈，老板项目到底好不好？从个人角度，如果是纯项目经理，这就是本职工作，无所谓好坏，而对于我们这些做产品的同学来说，老板项目没有成就感，有成就感的项目是自己去做市场分析、用户研究，然后发现问题，发起项目。另外一件麻烦事就是，有可能你不认同老板的项目目标，我碰到这种情况就用“有良知的职业杀手”的思路：只要不违背自己的价值观，就尽心尽力地完成任务，否则，据理力争，如果争论失败，要么调整自己的价值观，要么放弃这份工作。好处方面，从个人角度看，老板项目接近老板，无须多说。从老板和公司角度看，这样的项目效率高，但决策风险大，其实，这很像民主与专制的区别。
申明，这一节，我可不是教你如何跟老板玩花招，大家都是为了公司好。
秘密行动，封闭开发
2006年我刚进公司的时候，就直接进了会议室办公。
2007年底，我又和外包的项目团队一起进了会议室。
2009年春节后，我又带着一群人进了会议室。
我们把一些特别的项目，临时的团队集中在一个会议室办公，称之为封闭开发，这也是敏捷方法里面常用的一招。算起来，我在公司有一半左右的时间处于项目封闭状态，可以算幸运吧，因为封闭的项目通常是比较重要和神秘的。我悄悄地告诉你，在现实中，也可能是因为办公区域没有足够的座位了。《人件》【36】里很强调办公环境对人的影响，这可能是对于成熟的大公司而言的，那里也能保证有足够的封闭开发的环境，但说实话我们的封闭环境并不太好，从这点上看，公司里还是很有创业气氛的。
封闭的好处比较明显，大家都挤在一间房里，甚至围着一张大会议桌办公，交流非常方便，有什么事情，吼一声就通知到所有人了；小空间可以更容易产生讨论，而且参与者会更加投入，不用担心激烈的争论会打搅到外人，因为屋里没有外人；而且封闭的时候经常会不自觉地加班，并且是高效的集体加班，虽然这点不符合敏捷的思想，但这是事实，可能这就是种创业的精神力量吧。
另一面，封闭的缺点也是显而易见的，环境较差，比较挤，当大家对项目有激情，或者经常有团队激励的时候，比如出去聚餐、又跨过了一个里程碑等，可以保持高昂的战斗气氛，但长时间难免会让人心理疲惫、压抑，个人感觉上限是两三个月。
开发外包，项目外包
再和大家分享一个我参与过的项目，这是完全外包给乙方的项目，但是做着做着双方都理解成了开发外包，所以出现了很大的问题。
这个项目给我最大的体会就是：任何一个项目开始的时候，合作的多方必须要明确合作模式、划分权责利。其实很多内部项目，只要牵涉到跨部门的合作，都是如此。我们把这个项目外包给乙方，乙方又把开发外包，谁对谁负责，什么事情谁做一直没有明确界定。而在项目的过程中，乙方渐渐地做成了开发外包，导致甲方投入的资源越来越多，最终产生矛盾。
既然是项目外包，项目管理的方法应该由乙方定，由甲方来做项目管理风险是极大的，因为项目团队完全不熟悉甲方的那一套。比如我们事后才发现双方对“需求→设计→编码”环节的理解有差别，乙方对软件工程的理解是很教科书式的，而甲方的“需求”包含了很多“设计”的内容，“编码”也包含了部分“设计”，所以项目中看起来是“需求”完了直接进入“编码”。说法不同，实质一样，不过后来由于采用甲方的项目管理方法，导致乙方真的跳过了“设计”阶段，没有产出相应的文档，这是很低级的错误，但真的发生了。
需求相关的工作当时也产生了职责不清的现象，我觉得项目外包的话，乙方应该主动向甲方收集需求，并维护PRD等文档，当然甲方要积极配合并即时告知最新变动并走乙方的流程进行评估，而开发外包就是甲方驱动更合适，走甲方的需求流程，不断给外包的工程师更新需求。
同样的问题也发生在测试工作中，甲方肯定会有验收测试，但是乙方一定要在项目范围内安排比验收测试更详细的测试，千万不能把“找Bug”的测试寄托在甲方的验收测试上，而这次到项目提交的时候，项目组内部做过的测试还远不如验收测试详细，很显然，乙方还是把自己当作一个开发外包的团队了。
这个项目的一些细节已经回忆不起来了，但它让我一直牢记的最大教训就是：在职场中，做任何事情，除前面已说的权责利的划分外，还要权责利对等，有权力的人、或者被授权的人，可以享受事成的好处，也要担负失败的损失，千万不能只是因为你有能力做某事就把任务接下来，这样对谁都不好。
3.6.2 一路坎坷，你我同行
从一个经典的小故事开始，它讲述了我们身边最典型的“三边六拍”项目。
“三边”指的是：边计划、边行动、边修改。
造成“三边行动”的根本原因是在目标未清、职责未明的情况下就仓促开始往下做细节，结果常会因为在一些小事上扯皮导致项目不断地延期，即使最后勉强完成了，也与最初的目标相去甚远。
“六拍”拍的是：脑门、肩膀、胸脯、桌子、屁股、大腿。
“拍脑门”决策：经常有某些领导有了做一个项目的想法后，不是组织相关人员严格论证是否可行并广泛征求社会意见，而是自己觉得可行就上马项目。拍脑门作决策的做法，从一开始就为项目实施带来了很高的风险和不确定性，可以说也为项目的失败埋下了伏笔。
“拍肩膀”信任：领导拍完脑袋后，为了鼓舞士气，调动项目组成员的积极性，大多会采取一些激励手段，例如——拍肩膀。但事实证明，错误的激励往往比没有激励带来的后果还要糟糕！
“拍胸脯”承诺：受到领导激励的项目组成员为了让领导放心，也会有所表示——拍胸脯，而且往往还会说出一句话：“老板，放心吧，包在我身上！”但盲目的乐观与热情只会让前进的方向与最初的目标越偏越远。
“拍桌子”骂娘：项目进行一段时间后，领导忽然发现项目进展情况与自己的预期相去甚远，于是大发雷霆，爆发了“四拍运动”——拍着桌子训斥项目组成员。
“拍屁股”走人：项目组成员受到老板的严厉批评后，不少人往往会“拍屁股”。表现有二：一种是“明拍”，不干了，直接走人；另一种是“暗拍”，再也没有热情，消极怠工，这种人留在项目组中对项目毫无益处，反而会打击努力工作者的积极性。
“拍大腿”后悔：五拍之后的项目结果必然令所有人大失所望。这个时候，从决策层到项目经理再到项目组成员，大家都痛心不已，却又无可奈何。
“三边”并不可怕，比如在敏捷开发的过程中，我们就是“边计划、边行动、边修改”的，重要的是，关键的方向、目标得一开始就清晰，一些原则、约定不能总是变。“六拍”也不可怕，最可怕的就是拍完了却不吸取教训，在随后的项目中依然延续“六拍”。
聪明人并不是不会被石头绊倒，而是不会被同一块石头绊倒两次。
几个项目的成败
早在2007年，一年里我就经历了5个比较大的项目，它们成功或失败，让我切身体会到教科书里说的：大多数的软件项目都是失败的，实际上，约80％以上的项目都是不成功的，或者是因为超过预算或延期未完或缺失功能，或者几种因素都有，其中，30％的软件项目执行得十分糟糕以至于在完成之前就被取消了。并且，问题出现得越早，越早调整各方面的规划，损失越小，就像前文举的那个例子一样：小孩越小的时候越容易教、容易影响。
第一个项目是在测试阶段怎么也过不了“压力测试”，没有发布。我不是技术出身，所以具体原因不太清楚，感觉问题应该是出在系统的技术架构上，功能测试的时候都很顺利，但模拟数千人同时使用的时候始终很慢，改了几个礼拜仍然没法解决，最后由于人力资源的问题，渐渐地把团队成员调去做其他项目，权衡了这个项目的重要程度，最终砍掉。
第二个项目是在需求阶段叫停了，因为公司的政策因素，那个项目转移给别的团队做了，可以说完全是不可控的，作为基层员工的我，加深了对“项目发起应该是‘自上而下’”的认识，就算是“自下而上”发起，也要在充分获得高层的支持以后才靠谱，无论哪个项目，没有高层强有力的支持完全就是白搭，而且自己的努力突然全白费，会觉得很失落。
第三个项目是在（也可以看做一个新产品）早期的市场调研阶段结束，因为收集到的信息让我们觉得不值得继续做下去，于是做成了PPT向上汇报，高层接受了我们的建议，暂停了项目。一句老话：早一步是先驱，再早一步是先烈。
第四个算是成功了，顺利发布，之后不断升级、运营维护，一整套全部走完。这个项目我从2006年底开始一直做到2007年秋，然后逐渐移交给同事。它让我学到的最多，特别是到了项目上线以后，还有很多事情需要做，比如和客服的同学、技术支持、财务及其他业务部门的协调等。
第五个是和其他公司合作的项目，开始规划得很宏伟，但因为一些我无法控制的原因，不顺利地一步步走下来，最终延期了将近半年发布，而且也无法满足最早的商业目标，算是失败了吧，我在其间学到了很多项目管理方面的知识，仅此而已。
之后，我渐渐体会到，有些项目虽然按时、保质保量的发布，在项目的意义上是成功了，但是在产品的意义上也可能是失败的，比如在2009年我就经历过一个项目，项目执行的时候投入了很多资源，发布也很顺利，但在发布后三个月，因为战略调整，当初的项目目标已经不存在了，所以项目的工作完全白费，甚至还对新目标造成了一些反作用，很打击士气。
一次只有七天的战斗
项目的坎坷一生讲完了，我们看着如图3-25所示的详图再回顾一下本章的主要内容，几十个步骤，每一步都潜藏着危险。
图3-25 “项目的坎坷一生”详图
为了写这章，我翻看了几年以来的邮件，找到了一个只有七天的项目，光从项目日报里，就让我觉得那几天恍如昨日，回顾一下来结束本章。
2009年3月23日星期一，我接到一个任务，说为了配合3月31日下周二的新闻发布会，要做一个项目。我接过不少这种救火式的任务，每次开始的时候老板总能让我的嘴张成一个O型——这怎么可能呢，但结束的时候我们也屡次让老板的嘴张成O型——居然真做到了！
一大早接到任务，迅速地四处找人组建临时团队、制定时间计划、讨论项目方案……我一直是反对加班的，但在这种情况下，晚上晚点走也是不可避免的了，不过，我的计划中仍然留了余地：争取周五完成上线的准备，周末尽量不加班，下周一机动。我们直接看邮件来感受一下当时的情况吧。
主题：第1/7天，魔方计划2.0，项目进展汇报。
发送时间：2009年3月23日 21:16
Hi all，项目一共只有7个工作日，一切从简，尝试自由体日报。
今天主要进展如下。
1．Kick Off完成
2．项目范围与方案确定
a） 数据提取与分析，确认项目方案（详见附件）；
b） 某功能决定免费，账号数上限取消；
c） 魔方计划1.0遗留问题加入项目：更新帮助、修改“新手上路”、替换首页广告及链接；
d） TK（业务有关，不便透露，用字母替代，后面还有一些类似的。）相关问题另起项目，3月31日之前只对用户做告知。
3．需求写作
a） 附上PRD，明早评审。
4．团队组建
a） 开发同学（×××、××）搬到8楼，大家集中办公；
b） 测试资源在明天需求评审完成后确认。
5．知会周边干系人
a） ××搜索引擎：×××；
b） ××产品：××、×××。
明天重点预告：
1．需求评审；
2．进入设计与开发。
主题：第2/7天，魔方计划2.0，项目进展汇报。
发送时间：2009年3月24日 22:44
Hi all，今天是项目的第2/7天，晚上大家辛苦，感谢肯德基全家桶的支持，进展如下。
1．上午需求评审&确认完成
a） 下班时需求冻结，终稿见附件。
2．下午进入开发阶段
a） 只有16工作小时，周四中午提交测试；
b） 明天下午TC评审。
3．测试人员确定
a） ××＋半个×××，可能需要周末加班，先说一句辛苦了；
b） 存在人员不足的风险，随时监控，周五晚、周日晚为两个监控点。
4．相关事宜的跟进
a） 财务同学跟进修改用户协议；
b） 服务同学修改帮助；
c） ××方案制订；
d） 培训事宜跟进；
e） 配合运营整理MF与TK的材料。
主题：第3/7天，魔方计划2.0，项目进展汇报。
发送时间：2009年3月25日 20:19
Hi all，今天是项目的第3/7天，进展如下。
1．开发
a） 晚上部分功能提前半天提交测试，感谢同学们的努力。
2．TC评审
a） 来了6位测试的同学把关，感谢大家的支持。
3．相关事宜的跟进
a） 财务同学修改用户协议，周五下班前提交；
b） 服务同学修改帮助；
c） ××方案制订，原则确认；
d） 配合运营整理MF与TK的材料，××某负责制作页面；
e） 培训事宜跟进。
主题：第4/7天，魔方计划2.0，项目进展汇报。
发送时间：2009年3月26日 19:52
Hi all，今天是项目的第4/7天，进展如下。
1．开发
a） 全面提交测试，据测试同学说质量不错，感谢大家。
2．测试
a） 截至下班时，比计划稍有领先约1/3工作日。
目前一切顺利，但项目时间已经过半，更加容不得任何闪失，+U+U～～～
主题：第5/7天，魔方计划2.0，项目进展汇报。
发送时间：2009年3月27日 18:04
Hi all，今天是项目的第5天，进展如下。
1．第一轮测试完成，Bug全部修改完毕，等待下周二，配合新闻发布会上线。
2．周末测试的同学会加班再测一轮，其他人员待命。
3．下周一团队临时解散一天，下周二集合发布，谢谢大家。
很幸运，之后的周末没有碰到大问题，第6天空出来了，第7天的发布也很顺利。这是我喜欢的风格，每次项目顺利发布，我都在心中默念“一起战斗的感觉很好”。
注释
【1】本书说的项目是指为了实现产品而发起的一个又一个工作，比较简单。最通用的项目定义是指一系列独特的、复杂的并相互关联的活动，这些活动有着一个明确的目标，必须在特定的时间、预算、资源限定内，依据规范完成。比如三峡工程，其复杂性与我们日常所做的项目是不可同日而语的。
【2】正反合：一、发展的起点，原始的同一，即“正题”；二、对立面的显现或分化，即“反题”；三、“正反”二者的统一，即“合题”。正题为反题所否定，反题又为合题所否定。但合题不是简单的否定，而是否定之扬弃。合题把正反两个阶段的某些特点或积极因素在新的或更高的基础上统一起来。
【3】当时这个项目的代号，因为项目是把已有的两个产品做整合，所以我把它起名叫“双龙会”。
【4】PRD：Product Requirement Document，产品需求文档。
【5】关键路径：项目管理中，关键路径是指影响项目完成时间的关键任务。
【6】TC：Test Case，测试用例。
【7】各种评审在本章后续章节中有详细解释，这里先略过。
【8】WBS：Work Breakdown Structure，工作分解结构。
【9】用例即Use Case，简称UC。
【10】UML就是Unified Modeling Language，统一建模语言，它试图将软件工程的过程规范化，我的入门教材是《UML基础、案例与应用》，此类书应该都差不多，大家可以自己找一本学习。
【11】类图有点像软件工程里经常提到的实体关系图（ERD），只是ERD更接近现实世界的对象，类图更接近技术实现的对象。
【12】“include”与“extend”是UML里描述用例关系的专有词汇，详细解释可以参阅相关资料。
【13】用例包是指将一组相关用例打包而成的一个模块。
【14】在活动图中，每条泳道代表整个系统的工作流程中，某个部分的活动。
【15】低保真与高保真，在这里用来描述Demo与将来真实产品的相似程度。
【16】Axure：一款原型设计软件，能帮助网站设计者快捷而简便地创建带注释及交互效果的网页，并可自动生成网页文件，以用于演示与开发。
【17】Dreamweaver：美国Macromedia公司开发的集网页制作和管理网站于一身的所见即所得网页编辑器，它是第一套针对专业网页设计师特别发展的视觉化网页开发工具，利用它可以轻而易举地制作出跨越平台限制和跨越浏览器限制的充满动感的网页。
【18】Quality Assurance，指质量保证人员，负责产品品质保证的相关工作，比如流程控制，不同于测试人员。
【19】测试环境，Testing environment，这里指产品进行测试的环境，包括测试平台、测试基础设施、测试实验室和其他设施。与开发人员所用机器的本地“开发环境”、发布前最后验证的“预发布环境”、用户真实可见的“生产环境”相对应。
【20】冒烟测试，Smoke Test，名称可以理解为该测试耗时短，仅用一袋烟工夫足够了。也有人认为是形象地类比新电路板基本功能检查。任何新电路板焊好后，先通电检查，如果存在设计缺陷，电路板可能会短路，板子冒烟。
【21】UAT：User Acceptance Test，用户接受度测试。
【22】验收测试，顺带提一句，对于外包项目，需要由PD与测试人员共同完成，除了把系统所有的功能、性能概要测试一遍之外，还需要检查项目交付物，比如项目阶段文档、用户手册等是否齐全、是否符合规范。
【23】这里没有提到的“可用性测试”，它是在产品的各个阶段都可以做的一种用户研究方法，并不一定是在项目的测试阶段进行。
【24】Bug指缺陷或故障，区别在于项目发布之前发现的叫缺陷，项目发布之后发现的叫故障，通常故障会对用户造成伤害。团队里也针对故障责任人制订了相应的惩罚制度。
【25】SVN（subversion）是近年来崛起的版本管理工具，是CVS的接班人。目前，绝大多数开源软件都使用SVN作为代码版本管理软件。
【26】SQL（Structured Query Language）：结构化查询语言，是一种数据库查询和程序设计语言，用于存取数据以及查询、更新和管理关系数据库系统。
【27】下载地址：http://iamsujie.com/9000/9078/。
【28】奥卡姆剃刀原理即“如无必要，勿增实体”，Entities should not be multiplied unnecessarily。
【29】VBA（Visual Basic for Application）是一种自动化语言，它可以使常用的程序自动化，可以创建自定义的解决方案，可以称作Excel的“遥控器”。
【30】DCP：Decision Check Point，商业评审点。
【31】LMT：Life-Circle Management Team，生命周期管理团队。
【32】博客地址：ued.taobao.com，是国内顶尖的UED团体博客。
【33】关于核心竞争力，分享一句话：个人的核心竞争力是把显性知识转化为隐性知识的能力，而团队的核心竞争力是把隐性知识转化为显性知识的能力。
【34】瀑布模型于1970年由温斯顿·罗伊斯（Winston Royce）提出，直到20世纪80年代早期，它一直是唯一被广泛采用的软件开发模型。
【35】我是阅读《敏捷迭代开发——管理者指南》和《敏捷估计与规划》入门的，附录里有简单介绍。
【36】《人件》是软件工程领域的经典作品，关注的是软件开发中的“人”。
