1. 评审
哼哧哼哧写完需求文档，为了保证产品的质量，需求方案还必须要通过各方的评审，方可进入开发阶段。产品需求是产品每个干系人的事情，项目中的需求阶段通常会围绕着写作、评审、修改、评审的循环展开。评审就是项目中相关的几个小团队坐在一起，一方讲另外一方听，并确认统一认识，消除误解，及时发现偏差，防止问题随时间放大。不做评审看似省了时间，但往往隐藏了问题，待到其爆发的时候会耽误更多的事，而且会在谁负责的问题上纠缠不清，与其亡羊补牢，不如尽早在流程上预防，所谓防病优于治病。
项目中最重要的三种角色，就是PD（Product Designer/Product Director）、开发人员、测试人员，由此派生出三次评审：需求评审、设计评审、测试评审。
1.1 需求评审
需求评审是PRD评审、UC评审、DEMO评审的统称，评审会上PD把PRD和UC说给开发测试听，DEMO评审则由UE的同学主讲。在做出比较大的PRD之后马上安排一次评审，当然也会有UC和DEMO的半成品，以期尽早发现问题，比如业务规划的不合理、产品界面太丑陋、某功能技术上无法实现等。
PRD的评审，会重点关注偏商业的内容，强烈建议叫上老板、营销人员、服务人员甚至用户一起来听。PRD通过以后，PD们会和UE的同学一起细化UC和DEMO，而开发的同学也会同步进行一些开发前的准备工作，比如细化和修正项目计划、部分统计的设计。
接下来的DEMO评审决定了产品的外观项目，干系人最好都来把下关。而UC评审更偏重技术实现，商业团队的成员可以选择参加。
1.2 设计评审
设计评审是在概要设计与详细设计完成之后进行，由开发工程师把对需求的理解，以设计文档的形式说给PD、测试听。
1.3 测试评审
测试评审俗称TC评审，是在TC编写完成，测试开始执行之前进行，由测试工程师把对需求的理解，以TC的形式说给PD开发厅。
每一种评审都可能有多轮，会上没问题就快速的通过，有小问题当场确认，大问题带回去。原则是改动较多的话，必须再次评审，审议不大可以通过。评审会议的组织者可以考虑都由QA担任，作为项目过程管理的一部分，也可以考虑由每次评审的主讲人发起。
需求评审会的组织过程中，特别要注意两种容易漏掉的参与者，大家可以扩展应用到各种评审会上。一是能做决定的人，因为评审的时候，各方不可避免的会对需求有不同理解，从而出现争论，而很多问题都是公说公有理，婆说婆有理，谁也说服不了谁。这个时候啊，就需要有人能拍板，有人能负责。二是与此项目有关的产品接口人，他的参与可避免太晚发现与其他系统有冲突，修改起来措手不及，作为PD肯定是希望只要有点儿关系的人都来参加会议，但现实中呢是不可能的，所以必须识别出对当前项目来说谁更重要。
再看需求的生老病死，之前是从某个需求本身的状态变化来看，现在我们把它融入项目再审视一番。除纯技术项目外，PD是产品不断改进的原动力，所以项目前期PD主导的环节比较多，而一个需求就在这些环节中生老病死了。我觉得可以用几个会议来概括，项目大小有不同，所以这里的会议不需要严格理解成会议室里一群人正襟危坐，有可能是两三个人围在电脑前的几分钟交流。
2. 项目中的各个阶段
项目开始之前，在产品团队内部，分析需求商业价值的需求讨论会、多个产品间的产品会议上，PD们带着自己的需求参与讨论，为那仅有的开发和测试资源PK，人性的本能让每个人都极力维护自己提出的需求，并设法反驳别人，当然了出发点都是为了用户，最终也会达成一致，活下来的需求会确定需求负责人，状态变为需求中。
2.1 需求阶段：
项目中的需求阶段：项目启动之后PD就得抓紧时间完成需求的开发，不时召集需求评审会，大家一起讨论这样做有哪些问题，PD收集到意见反复修改需求直至最后一次评审通过，需求得以确认，状态变为开发中。当然，之后的需求微调总是无法避免，但需求冻结的里程碑要求在这之后就不要轻易改动了。
2.2 开发阶段
项目中的需求阶段之后，进入开发，PD需要不断地和开发测试人员确认各种细节。我们一直在想早期环节中考虑的所有细节，以期减少这种费时费力的确认，但事实证明细节总是多到无法预计，有的甚至要发布后才能被发现。
在开发提交测试之后，PD需要在测试环境中代表产品的用户做功能验收，确认一下产品和自己设计的是否相符，顺便也可以发现一些可用性问题，当然如果能让真实用户来验收则更好了，通常我们会组织一次需求评审会，让项目干系人来确认这些功能是不是大家想要的，如果有问题还可以补救，
最后功能上线。别忘了把FeatureList中相应的需求改为已发布，很显然需求发布之后仍然会有改动，可能是客户反馈了问题，或者自己想到了更好的解决方案。将它视作一个新的需求，或当作一个BUG，重新计入流程。
我们会把需求评审通过，视为项目中一个重要的里程碑，称作需求确认或需求冻结，之后进入开发阶段。如果还需要修改需求的话不是不可以，而是要更加慎重，甚至是强制走一些需求变更的流程。这也是为了更好的控制项目风险。在信息充分的情况下，随着项目的进行风险应该越来越小，否则项目必然有问题。
需求阶段之后的常规项目过程就是开发、测试、发布。需要注意的是，这类项目都是围绕着产品研发工作的，所以没有包括上线后的销售，运营，服务等活动。
立项和需求阶段是PD作为主要角色参与的环节，PD要随时配合开发测试确认需求。项目经理要做的就是控制，对于每个特定的项目应该在开始之前，就约定好各种管理方法，比如文档怎么管理，测试过程怎么管理，使用哪些技术工具等。
开发阶段开发经理的存在会帮PD省不少心。设计到设计评审，再到编码，再到单元测试，比较强的开发工程师可能叫开发经理、架构师、系统分析师，会带着普通工程师一起做概要设计、详细设计，如果项目涉及数据库、硬件系统的改动，那就还会带上运维的人员。设计完成以后会组织一次设计评审，PD和测试人员都会参与，审核一下工程师们对需求的理解是否正确，评审通过以后，就进入编码阶段。编码完成以后如果时间充裕可以做一些代码评审的工作，不过我们的项目一般都很紧张，代码评审的工作，通常只能在开发工程师提高自我修养的周例会上进行，之后工程师们需要对自己的代码做单元测试，自测环节做到位，可以减少后期测试同学很多的工作量，问题总是越早发现解决的成本越低，当开发工程师认为自测已经完成，那就可以把代码从开发环境上提交到测试环境了，按照开发计划当项目的主体部分提交测试的时候，我们又走过了一个里程碑开发完成。
2.3 测试阶段
开发工程师在设计与编码的同时，测试工程师也没有闲着，他们会继续细化和调整测试计划，并完成TC编写的任务。在TC中，测试人员会进行测试任务的描述，体现测试方法、方案、技术和策略，内容包括测试目标，测试环境、输入数据、测试步骤、预期结果、测试脚本等并形成文档。
测试阶段的主要任务：TC编写、TC评审、冒烟测试、功能评审、最后测试。
TC编写完成之后，测试经理会组织TC评审，时间一般在开发同学提交测试之前，PD和开发人员都要参与评审，再次确认大家对需求的理解是否一致，很多需求的细节无法在需求阶段考虑完全，我们会通过开发和测试阶段的反复沟通来不断的细化，TC评审通过了，待开发提交测试以后，测试的同学会迅速完成一轮冒烟测试，目的是确认软件基本功能正常，可以进行后续的正式测试工作。在测试人员正式开始测试的同时，PD又要登场了，我们会组织一次产品的功能评审，或者叫产品演示会，利用测试环境就可以把使用的产品在第一时间展示给所有的项目干系人，更进一步确保做出来的东西就是大家想要的，功能评审通过之后PD一般还会代表用户做更详细的UVT（或者称为验收测试），接下来测试的同学会做很多轮的测试，是一个发现BUG、开发修正、测试验证、发现新BUG的循环过程。从第二轮开始就可以叫做回归测试，在BUG都处理妥当之后，项目紧接着就进入了发布阶段。有的项目除了功能测试以外，还需要做性能测试，比如验证这个系统是否能承受1万用户同时访问的压力，公司也有特定的工程师来做这方面的事情，他们一般是多个产品共用的资源。在测试阶段，商业方面的准备工作也早已动起来了，PD可能要准备面向用户的功能卖点，介绍的文档、产品更新的公告、培训服务人员和销售人员。运营的同学可能已经在策划推广方案，销售的同学可能在更新销售说辞。
2.4 发布阶段
对用户影响较大的升级，可采用“分流发布”，或者叫“灰度发布”，即让一部分用户先用，然后收集反馈再决定大面积发布的时机。Gmail就经常采用这种方式，把一些还在实验室状态的功能先开放给小部分的用户试用。把握不大的项目，发布计划中还要加上“回滚方案”，一旦发布不成功，就赶紧把产品退回原来的状态。
正式的发布过程，是从更新“预发布环境”开始的，预发布环境会尽量模拟生产环境上的真实状态，比如数据库用的是同一个，测试人员会在预发布环境进行最后的回归测试，没问题的话，更新“生产环境”，测试人员再做一次最简单的回归测试，完成发布。当然，这么多次回归测试，其覆盖面不尽相同，越到后面的回归，测试的内容越少，直至只包含最重要TC的“最小集”，来简单判断系统是否能正常运行。
测试人员在确认完“发布标准”中的各项之后，会发出邮件通知同意发布，发布人员在没有收到通知前，不能自行发布。
测试人员在发布后，将做一轮生产环境的回归测试，测试完成后发出一封邮件通知“生产环境已验证完成，发布成功”。只有收到该邮件后，发布相关成员才能撤离现场。还有一点想说，发布的时间选择，能安排在白天的工作时间固然好，但很多互联网产品为了避开用户使用高峰，必须安排在晚上进行，难免弄到深更半夜。
2.5 项目小结阶段
项目经理撰写“项目发布公告”。小结一下做这个项目的心得体会，比如碰到了哪些问题，原因是什么，怎么解决的，如何避免再犯；项目的资源评估是否合理，收获了哪些经验，如何提高准确度；根据数据监控的反馈，分析出了什么结果，项目的商业目标是否达到等等。