3.4节标题“成长，一步一个脚印”，主要讲的是“需求评审通过”之后的项目历程，主要是开发阶段、测试阶段、和项目发布阶段，主力主要是工程师们。

---

需求确认或冻结之后就进入开发阶段，如果需求还要修改的话必须要更加慎重，甚至强制走一些需求变更的流程，主要是为了更好地控制项目风险。开发、测试、发布阶段主要围绕产品研发工作，不包括上线后的销售、运营、服务等活动。之前谈到的项目立项与需求阶段主要角色是PD，而本节的三个阶段主角则是工程师们，PD的任务是随时配合他们确认需求，项目经理的任务是“控制”。

开发阶段

比较强的开发工程师，可能叫开发经理、架构师、系统分析师等，会带着普通工程师一起做概要设计、详细设计，如果项目涉及数据库、硬件系统的改动，那就还会带上运维的人员。设计完成以后，会组织一次设计评审，PD和测试人员都会参与，审核一下工程师们对需求的理解是否正确。

评审通过以后，就进入编码阶段，编码完成以后，如果时间充裕可以做一些代码评审的工作，不过我们的项目一般都紧张，代码评审的工作通常只能在开发工程师提高自我修养的周例会上进行。

之后工程师们需要对自己的代码做单元测试，自测环节做到位，可以减少后期测试同学很多的工作量，问题总是越早发现解决的成本越低。

当开发工程师认为自测已经完成，就可以把代码从开发环境上提交到测试环境了。按照开发计划，当项目的主体部分提交测试的时候，我们又走过了一个里程碑——开发完成。

开发阶段的工作内容

测试阶段

开发工程师在设计与编码的同时，测试工程师也没有闲着，他们会继续细化和调整测试计划，并完成TC编写的任务。在TC中，测试人员会进行测试任务的描述，体现测试方案、方法、技术和策略。内容包括测试目标、测试环境、输入数据、测试步骤、预期结果、测试脚本等，并形成文档。

测试阶段的工作内容

TC编写完成后，测试经理会组织TC评审，时间一般在开发同学提交测试之前，PD和开发人员都要参与评审，再次确认大家对需求的理解是否一致。很多需求的细节无法在需求阶段考虑完全，我们会通过开发和测试阶段的反复沟通来不断细化。

TC评审通过，待开发提交测试以后，测试的同学会迅速完成一轮“冒烟测试”，目的是确认软件基本功能正常，可以进行后续的正式测试工作。

在测试人员正式开始测试的同时，PD又要出场了，我们会组织一次产品的“功能评审”，或者叫“产品演示会”，利用测试环境，把可以使用的产品在第一时间展示给所有的项目干系人，更进一步确保做出来的东西就是大家想要的。功能评审通过之后，PD一般还会代表用户做更详细的UAT，或者称为“验收测试”。

接下来，测试的同学会做多轮测试，是一个“发现Bug，开发修正，测试验证，发现新Bug”的循环过程，从第二轮开始就可以叫做“回归测试”，在Bug都处理妥当之后，项目紧接着就进入了发布阶段。有的项目除了功能测试以外，还需要做性能测试，比如验证系统是否能承受1 万用户同时访问的压力，公司也有特定的测试工程师做这方面事情，他们一般是多个产品共用的资源。

在测试阶段，商业方面的准备工作也早已动起来了。PD可能要准备面向用户的功能、卖点介绍的文档，产品更新的公告；培训服务人员和销售人员；运营的同学可能已经在策划推广方案；销售的同学可能在更新销售说辞；服务的同学可能在依据测试环境里的产品制作帮助……多个部门协同，很有大家在一起战斗的感觉。

从Bug的角度看项目

刚开始的一段时间，Bug总是不断地蹦出来。下面从Bug的角度来说说项目，下图是作者使用过的一份Bug级别定义，从中可以看出，III、IV、V级Bug是产品是否“能用”的范畴；II级是“好用”的范畴；而I级是“有用”的范畴，应该由PD在前期搞定，但在测试过程中，任何人也都可以提出质疑。

Bug级别定义标准

一般来说对一个Bug的描述有以下几个关键点。

缺陷级别（Severity）：即上图中的5级别定义，一般大于等于III级的Bug被认为是严重的问题。

所属产品、项目：有的人需要同时处理很多产品、项目，这个属性可以用来筛选。

Bug名称：一个短句，对此Bug的简单说明。

Bug描述：写成如下形式，“执行某操作，期望出现什么情况，实际出现什么情况”，还可以添加截图、文档等附件。

作为PD，也是会经常提Bug的，与测试人员相比，PD做测试的时候主要是模拟用户的身份正常使用产品，而测试人员会更多地按照TC执行，尝试极端的使用情景下产品有没有漏洞。在发现一个Bug以后，我们会提交给相应的开发工程师，如果认为是需求问题也可以提交给对应的PD，这时候Bug的状态为Open，之后的状态改变，可以用下图简单描述。

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，有时候并没有这么严格。

【工具】作者的测试过程使用了Mercury Interactive公司的Quality Center来管理，它是一个基于Web且支持测试管理的所有必要方面的应用程序。更小的团队，用Excel来管理Bug也未尝不可。使用Quality Center相比Excel的好处在于，每个Bug重要的状态转换点，系统都会有邮件通知到相关人员，防止遗漏；项目中每个人在系统里的角色不同，权限不同，此软件可防止误操作，甚至是一些恶意行为，比如开发人员就不能把Bug状态改为Closed；所有操作都有记录，谁在何时做了什么，便于追溯。这些都有效地防止了人为因素导致的问题。

项目发布

辛苦了那么久，项目终于进入发布阶段了，可黎明前总是最黑暗，我们要考虑很多问题。

发布阶段的工作内容

首先聊聊代码更新的事情。我们会安排专门的代码版本管理员，通常用SVN，所以又叫SVN管理员，负责项目每日的代码更新。修改的代码从“每位开发人员的开发环境→测试环境→预发布环境→生产环境”一步步更新，如果版本控制不好，就会发生“改掉的Bug又回来了”这种情况。有时候同一个产品多个项目并行，就会牵涉到多分支开发，更有代码迁出、合并的时机问题。

然后，“发布计划”的评审也很重要，需要运维人员的确认。特别是对于系统改动较大的项目，可能需要分模块分步骤发布。对于用户影响较大的升级，有时候采用“分流发布”，或者叫“灰度发布”，即让一部分用户先用，然后收集反馈再决定大面积发布的时机。把握不大的项目，发布计划中还要加上“回滚方案”，一旦发布不成功，就赶紧把产品退回原来的状态。

正式的发布过程，是从更新“预发布环境”开始的，预发布环境会尽量模拟生产环境上的真实状态，测试人员会在预发布环境进行最后的回归测试，没问题的话，更新“生产环境”，测试人员再做一次最简单的回归测试，完成发布。当然，这么多次回归测试，其覆盖面不尽相同，越到后面的回归，测试的内容越少，直至只包含最重要TC的“最小集”，来简单判断系统是否能正常运行。

注意，在正式发布之前，可能还有一些手续要办，比如填写“发布申请单”，写上项目的大致内容与影响，让所有关键人物签字，大家最后确认一次；有时候也用E-mail形式的申请。有时还有“立项申请表”、“预发布申请单”等，每张表格都需要N多人签字画押，手续的繁琐也许会耽误时间，但是是为了防止出错，。

作者分享了一个他们产品的发布注意事项作为【案例】：

发布标准

    SQL已经经过DBA确认无问题，DBA确认后，邮件通知到测试人员，抄送给某经理。

    搜索引擎通过相关人员确认无问题。

    QC中的Bug全部Closed或Deferred。

    因技术或时间原因造成无法修改的Bug，由测试、需求、开发三方一起研究是否能接受，如果有争议，上报上级主管。

    测试过程中，如果因为技术无法实现造成的需求改动，PD需要第一时间发送邮件到全组，让所有人都知道，同时修改相应的UC。

发布过程

    测试人员在确认完“发布标准”中的各项之后，会发出邮件通知同意发布，发布人员在这之前不能自行发布。

    测试人员在发布后，将做一轮生产环境的回归测试，测试完成后发出一封邮件通知“生产环境已验证完成，发布成功”。只有收到该邮件后，发布相关成员才能撤离现场。

项目小结

发布成功！所有人终于舒了一口气，但是作为项目经理，事情还没完，第一件事就是赶紧发出一封E-mail——“项目发布公告”。小项目的公告会比较形式化，而意义重大的项目就会写很煽情了，比如项目中的种种艰辛、对每一个参与者的感谢、发布之后的内心感言、产品对公司和用户的革命性意义、贴几张产品的最新图片等，有时候还会有人诗性大发，再让视觉设计师帮着设计一些海报，不但邮件里用，甚至在公司墙上也贴几张。这封邮件也是一次内部宣传的好机会，我们除了发送给项目的干系人，甚至会抄送给整个公司。作为项目经理，应该时刻做到为团队成员争取各种精神、物质的奖励，这种邮件、海报、大老板的回信……都是很好的鼓励，如果还有项目经费的话，再组织一次聚餐，大家以后还要继续合作，开开心心，皆大欢喜。

之后，写一份项目小结，对于一个几周到两三个月的项目来说，比较合适在发布后半个月内完成。小结一下做这个项目的心得体会，比如碰到了哪些问题，原因是什么，怎么解决的，如何避免再犯；项目的资源评估是否合理，收获了哪些经验，如何提高准确度；根据数据监控的反馈，分析出了什么结果，项目的商业目标是否达到，等等。

很多项目经理一到写小结的时候就难产，似乎项目中的种种困难到了这时都烟消云散，然后下次项目再为类似的问题抓耳挠腮。这点和我们日常工作生活也很像，做的时候抓耳挠腮，结束了让总结却觉得没什么可写的。对此，作者的经验是通过项目的日报或周报随时记录每天的情况，到总结的时候就水到渠成了。大家千万不要把这种事情当作额外的任务，而是要想清楚它的价值，很直接的一点就是可以作为对项目成员的保护，有绕不过的坎及时让老板们看到，如果不帮我们解决，那老板需要承担后果。下图是作者在这本书写作过程中某一周的周报（那会儿正在写第2章的初稿），为了控制进度、不断改进，加上希望把这本书的写作过程完全公开，所以从一开始作者就用Google的SpeadSheet随时展示最新进展。

本书的一篇写作周报

拥抱变化

现实情况往往比书中所讲的要复杂很多，有各种各样的不确定因素，经常是怕什么来什么，所以我们只能拥抱变化，常见的有下面几种。

变更事件，是指项目范围内需求的变化，需求细节的确认、微调总是不断存在，变更主要关注的是“需求冻结”后较大的变化。团队会制订一些流程做控制，不是为了限制变更，而是为了让每次变更都经过深思熟虑，最怕发生的情况就是需求方举棋不定，来回反复。流程会要求提出变更的人先和相关方确认，获得一致认可后，再修改文档、邮件说明、即时通信群里吼一声……而过大的变化或过晚的变化，项目经理有权决定是拒绝，还是上报更大的老板定夺。

搭车事件，是指项目范围的扩展，一般来说，5个开发工作日以下的零散小需求不参与产品会议讨论，所以搭车事件总是存在。但我们要尽量搭顺风车，找内容相关的项目；尽量早搭车，在“需求冻结”之后一般不要再提；作为项目经理，也要把好关，不能因为随意让别人搭车导致团队长期、高负荷加班，这是得不偿失的。

紧急事件，一般由较高层的老板确认后自上而下的推动，不受常规流程的限制，越是高层确认的紧急事件，越可以突破常规限制优先处理。此外，时不时的还会在发布之后出现生产环境的故障，拥有产品经理和项目经理双重身份的我们也是义不容辞，需要站出来紧急应付，相当于临时发起一个小项目，每次也都是惊心动魄。

最后，就算没有碰到刚刚说的那些变化，项目中还会碰到资源不足的问题。多个项目并行是正常现象，一般在产品会议上已经确认优先级，所以资源冲突时遵循“慢车让快车”的原则。