一、从产品到项目

项目的定义：只会进行一次，包含多项互相关联的任务，并且有绩效、时间、成本和范围限制的一项工作。

产品是解决某个问题的东西，项目是一个过程。

1、做产品VS做项目

①从生命周期角度区别

做产品的生命周期相对较长，关注的是整个产品从规划到制造，再到最终维护和消亡的整个过程；

项目有特定的目标，生命周期短，通常在项目开始以前就有明确的起止时间，通过验收则表示项目生命周期完成；

②从具体要做的事区别

做产品的过程会有很多探索的过程，随着各种内外信息的变化，需要不断修正进程，不断创新；

项目在开始就已经有明确的目标，更注重计划与控制，项目的过程很像执行一个任务；

共同点：协调沟通，对未来一段时间做出计划等因素；

③从产出物的角度区别

产品可以是批量生产或提供给大量用户使用的，相对通用，通常考虑用有限的资源去满足更多的、更大利益回报的需求；

项目只进行一次，意味着每次都是定制的、个性化的，通常为了满足特定需求，产出物也比较个性化；

④产品和项目的关联性

“做产品”的过程，正是通过做一个又一个项目实现的，但并不是简单的项目累加。在产品渐渐满足目标用户群体的通用需求后，继续做下去会使产品变为一个项目的集合体，臃肿不堪；

这时候需要细分市场，产品可以升级为“产品线”，按不同市场推出不同产品。表现形式可称为版本、模块、增值服务等，其本质是通过合理的安排项目来实现产品的规划。

2、产品经理VS项目经理

产品经理（product manager）和项目经理（project manager），工作都需要跨团队，工作范围也有重叠，都是简称PM，那么他们的区别又是什么？

产品经理：靠想。产品经理是做正确的事情，其所领导的产品是否符合市场的需求，是否能给公司带来利润。因此产品经理必须能规划整个产品的架构和发展路线，能确定产品的定位和受众，能预计产品真正的价值和效益。

项目经理：靠做。项目经理是把事情做正确，把事情做得完美，在时间、成本和资源约束的条件下完成目标。即使项目本身不能真正盈利，那往往是产品规划出现了失误。

用《人人都是产品经理》作者苏杰的话说，就是：一个内部驱动，一个外部驱动。

对产品经理来说，最重要的是执行力与创造力，产品经理决定做不做、做什么、做多少，保证方向正确。他的想法是“我要把它实现！”

对项目经理来说，最重要的是执行力与控制力，项目经理决定怎么做、谁来做、何时做，保证方法得当。他的想法是“我要把它完成！”

二、一切从项目启动开始

1、团队组建

项目启动后，第一件事就是“团队组建”。通常在项目中，会有如下几种角色：

PD：负责这个项目的需求，其中的某一个可能兼任项目经理；

开发leader及其团队：负责开发的时间计划与任务分配，并全程掌控设计、编码直至上线的过程；

测试leader及其团队：负责测试相关的任务，比如需求分析，测试计划、方案的设计，工作安排，质量模型等工作；

UE（用户体验团队）：对于互联网产品来说，负责产品给用户的展现，比如交互效果、视觉效果等；

其他角色：团队的人员角色会随着项目的进行不断微调，无须一开始就把人凑齐，只要关键几个人到位就可以继续做下面的事情。

2、项目计划

做项目计划，首先要做的第一件事，也是最重要的事情，就是再次评估工作量，并推算出“工期”。

最开始的需求阶段，已经做过一次工作量初评，但随着项目的展开，PRD相对来说也会进行细化，这时候开发和测试进行工作量评估，会更加准确；

还有一点，初评是leader等人进行评估的，未考虑谁来做什么。而项目正式开展后，需要根据每个工程师的特点。擅长技术领域等因素进行工作分配，把工作任务分配给最合适的人。

然后开发测试leader把各个工程师的工作量汇总，推算出工期；当然也要考虑到各个项目任务的依赖关系，留出一定的buffer。

PS：高手要调入项目的关键路径（影响项目完成时间的关键任务）。

3、沟通必不可少

在项目的整个生命周期中，无时不刻都需要沟通，由于沟通问题导致的项目问题，日常工作中已经出现很多例子了。比如：权利责任不明确，出工不出力，对需求理解的不一致，遗漏

了项目相关部门、责任方等很多情况，所以很有必要在一开始就约定好项目的沟通方式。

PS：沟通方式只是一种手段，而不是目的；不管选用何种沟通方式，结果都是为了项目成功。常见的沟通方式有如下几种，仅供参考：

项目晨会：一般不超过15分钟，参与人员主要有PD、开发、测试，简述昨天做了什么，遇到什么问题，哪里需要辅助解决，今天预计工作是什么等等内容；

项目日报：一般以测试介入后开始，主要内容为今日完成工作，未完成工作，遇到问题及如何解决等内容；

项目周报：同日报类型相似，只是内容上更全面，以及方便随时调整工期和计划；

评审会：需求评审、设计评审、用例评审以及系统测试完成后的功能评审等；

项目变更通知：项目发生变更或需求变更等较大的变更，需要及时通知项目所有干系人；

发布上线通知：项目发布前以及发布成功后需要给全体干系人发布公告通知；

4、随时做到心中有数

其实就是项目管理，做项目的目标无非就是多快好省：范围大、时间段、品质高、资源省。但要完全做到这几点，难度是地狱级别的，因为实际的制约因素太多。

综合而言，在尽量保证品质的前提下，在时间、人力物力、项目范围三点上做平衡和取舍。

在了解项目背景、目的、目标等前提下，明确任务后，首先分解任务，即著名的WBS（Work Breakdowm Structure：工作分解结构）。

其实每个项目，都没有固定的流程，但每个项目的流程管理，都有一定的共通性，多实践，然后总结经验，渐渐就有了自己的一套行之有效的流程，不过还是要灵活运用。

三、需求？哦不，文档！

项目开始后，不仅开发要做代码开发，PD也需要开发，这个阶段，PD的内容是“需求开发”，即大家俗称的“写文档”。

1、PD最常写的几类文档

BRD：Business Requirements Document：商业需求文档。这是产品生命周期最早的文档，内容涉及市场分析、销售策略、盈利预测等，通常给BOSS看的，短小精炼，没太多细节；

MRD：Market Requirements Document：市场需求文档。内容包括可行性分析、商业目的、功能/非功能需求分块、优先级等；其产出物一般有Feature List、业务逻辑图等；这是从商业目标到技术实现的关键转化文档。

PRD：Product Requirements Document：产品需求文档。它是对产品功能的进一步细化，是PD写的最多的文档，也就是上面所说的“需求开发”的过程；其主要包含整天说明、用例文档、产品Demo等，会对产品功能做具体描述。

FSD：功能详细说明。比较像常说的用例文档，主要包含产品界面、业务逻辑的细节等内容；与此同时，硬件设计、数据库设计、表结构设计等工作，也要由技术人员开始编写了。

PS：以上几种文档其实都有重合点，大多公司没有这么严格的文档要求，灵活运用即可。记住：写文档也是手段，而不是目的，最终结果，还是——-要把项目做成功！

△关于PRD：
通常来说，一个项目会有一到多份PRD，每个PRD会包含逻辑相关的若干功能点，主要的构成元素如下：

修订历史：包含每次修订的日期、版本号、说明和作者，以便于日后追溯；

项目概述：包含项目的背景、意义、目的等，描述业务领域知识，以便于读者可以明白这个项目的一些关键点，形成项目思维框架；

功能范围：对本PRD涉及的角色、系统做出简单说明；

词汇表：对本PRD涉及的专有词汇、术语等做出说明；

非功能需求：如性能、数据监控等需求；

其他：其他任何需要说明的内容都可以写在里面；

上面的部分是总体说明，之后是用例文档部分，其中包含对PRD中所有用例的说明，各种类图、状态图、流程图，以及每个需求点的详细说明等。

2、UML、Demo和概要详细设计

了解产品的童鞋应该都知道，做产品需要产出很多的文档，其中包括各种用例，说明文档，图表等，而UML大多是用来将需求转化为图的一种工具。

UML：Unified Modeling Language，统一建模语言，它试图将软件工程过程规范化；利用UML，可以产出很多图，比如类图、用例图、状态图（系统里的实体转换）、时序图、活动图（比较接近我们所谓的“流程图”）等很多图形说明文档；

Demo：即所谓的产品原型图、演示版的东西；

几种常用的图形绘制工具：Visio、PPT、Axure、Dreamwever、Xmind等工具；

概要设计和详细设计：举个例子，比如一个登陆输入框，长度限制在多少个字符，允许最多输入几个汉字、敏感字、非法字符、是否必填、对齐等，就是比较详细的设计；当然，一般的设计都是产品从业务角度描述，而工程师负责技术上的实现和描述等；

3、需求评审

当产品的产出物————需求文档给到后，工程师一般并不直接拿来用，为了保证产品质量，还需要做这件事：需求评审！！！

所谓需求评审，一般都是项目中关键的小团队坐在一起，一方讲，另外几方听，统一认识、消除误解，及时发现偏差以及随时改正的过程；

在互联网行业，一般参与需求评审的主要是PD、开发以及测试人员，所以有了需求评审、设计评审、测试评审，按照项目阶段，大概顺序为下：

需求评审：即PRD评审、UC评审、Demo评审的总称。一般在需求相应部分完成后进行，PD将PRD说给开发、测试听；

设计评审：在概要设计和详细设计完成后进行，由开发工程师把对需求的理解以设计文档的形式说给PD、测试听；

测试评审：也是俗称的用例评审，是在测试用例编写完成，测试开始执行之前，由测试工程师把对需求的理解说给PD、开发听；

每种评审一般都会进行多轮，没问题的快速通过，小问题当场确认，大问题带回去重新思考解决，循环往复。。。

四、开发、测试、发布。。。

需求阶段之后的项目过程就是开发、测试、发布，这个阶段的主力是工程师，作为PD，要随时配合工程师确认需求，项目经理，要做好“控制”。

1、开发阶段，各显神通

开发阶段，大概是设计、设计评审、编码、单元测试这几点，大概过程如下：

设计：就是俗称的开发设计，包括系统采用何种框架、服务，数据库设计表字段等等，以及定义开发接口、参数字段等相关的一些东西，一般都会有相关设计文档；

设计评审：一般完成开发设计后，会组织PD和测试人员一起参与评审，审核工程师们对需求的理解是否一致正确，以及方便测试童鞋展开下一步的工作；

编码：这个阶段就是针对需求的具体实现阶段了，开发同学埋头码代码，测试童鞋埋头写用例，讨论需求，功能点，巴拉巴拉，一派和谐；

单元测试：就是开发在自己本地开发环境自测，保证代码功能的实现，自测环节做到位，可以减少很多后期测试童鞋的工作量，问题总是越早发现解决成本越低；

开发完成单元测试后，就会将代码从生产环境提交到测试环境，然后就会进入下一个阶段，测试。

PS：有些公司是单元测试交给专职的人员来做；有些公司开发完成后发提测邮件，由测试拉取分支代码到测试环境，进行测试，具体以公司流程为主！

2、测试阶段，人人有责

之前的读书笔记中有提到过，产品质量是所有人的事，不只是测试的事；缺陷一般都是内建的，而不是外力造成的，所以，测试，人人有责。。。

开发在编码时候，测试一般都是进行需求分析，功能点划分，设计测试计划、测试方案、测试用例（包含测试数据、测试脚本等），并形成文档；大概过程如下：

用例编写：经过需求分析，功能点筛选划分等工作之后，测试工程师根据项目具体情况，利用设计用例的各种方法来设计、编写测试用例；

用例评审：用例编写完成后，会组织PD和开发童鞋进行评审，时间一般在开发提测之前，大家再次确认对需求的理解一致性，很多细节性的东西无法在需求阶段考虑完全，要通过开发和测试阶段的反复沟通来不断细化；

冒烟测试：即简单快速的对主流程功能进行测试，确认软件基本功能是否正常；

测试阶段：完成冒烟测试后，接下来就是接口测试、系统测试，不断回归验证BUG，UAT测试、上线验收测试等等；

3、发布上线，提心吊胆

完成开发、测试之后，接下来就是该发布到生产环境供用户使用了，几个重点如下：

①代码管理

常用的代码管理工具有SVN、Git等，修改的代码从“开发环境-测试环境-预生产环境-生产”等一步步更新，如果代码版本控制不好，很容易发生BUG频发的情况，工程师想必是深有体会。。。

如果涉及到多个项目并行，就会牵涉到多分支开发，以及代码迁出、合并等问题。

②发布评审

即决定发布的产品，要满足什么要求，是否符合既定的发布上线规定等，比如牵涉到改动较大的项目，甚至可能分模块分步骤发布，比如先发布到哪几台服务器，让一部分用户先用，然后根据情况

发布剩余的服务器等等，对于用户影响较大的版本升级，可以采用“灰度发布”这种方式。

③生产验证

在发布到生产环境之后，测试人员也要进一步在生产环境进行一轮测试回归，确认无问题后，一般需要发邮件或其他形式告诉相关成员：“生产环境验证完成，发布成功”。

④发布时间

一般来说，能安排白天发布固然好，但很多时候为了避开用户使用高峰，只能安排的晚上进行；还有就是尽量不要在周五发布，因为如果出现故障，双休日人员反映等比较困难。

4、关于需求变更

在项目周期内，最怕的是什么？相信有过经历的工程师，都会提起一个词：需求变更。下面是几种常见的情况（需求变更和新增需求这里都归结为变更）：

①需求变更

需求变更是指项目范围内的需求变化，需求细节的确认、微调总是不断存在，对于这点，需要定制一些流程做控制，不是为了限制变更，而是为了让每次变更都经过深思熟虑，对变更的范围大小以及时间上的影响进行分级和确定，灵活调整整个项目的“工期”；

②新增需求

所谓的新增需求，是指项目范围外的扩展，这种“半路搭车”事件总是存在，对于这种情况，需要今早在需求评审通过之前就确定，作为项目经理等管理者，也要做好控制，不能因为随意让别人搭车而导致团队长期、高负荷加班，这样得不偿失；

③紧急事件

这种事情偶尔也难以避免，不受常规流程控制，一般是由较高层的leader确认后自上而下的推动，级别越高越需要优先处理（其中种种，有过经历的工程师相信都明白。。。）。

五、项目管理

“计划于控制，就项目管理”。从互联网角度出发，项目管理中的几个关键问题，就是：文档管理、流程管理、敏捷方法。

1、文档管理

模板、规范、操作步骤……等等一系列的文档，导致有些人甚至醉心于此，特别热衷于向别人要一些文档模板、项目管理流程之类的东西，本来只是一种手段，却演变成了一种目的。

文档的存在只是为了方便项目流程管理、新人快速上手、遇到问题快速回溯等，实际上，“文档只是手段”。

至于具体的文档模板，每个公司的文化，团队氛围造就了不同的文档适用性，需要整个项目团队协作和管理，才能有效的进行项目管理。

2、流程管理

长视者把目的当手段，短视者把手段当目的。比如教育里的高考，公司里的KPI等，研究手段，不能忘记目的，“流程也是手段”。

①关于项目VS流程

有个需要注意的原则是：新人做老产品，不挑活儿，老产品稳定不容易出事；老人做新产品，需要变化才有激情。

②流程的本质目的

当团队较小的时候，需要“个人”把自己的经验技术转变为显性的知识表达出来，当团队变大，对于经常做的事就需要流程这种形式固化、传承，最起码后来者做事不会太无助。

关于这点，规范、模板作用也类似，这就是团队的核心竞争力。

核心竞争力：个人的核心竞争力是把显性知识转化为隐性知识的能力，团队的核心竞争力是把隐性知识转化为显性知识的能力。

③评审可以省略吗

之前列举了很多的评审，大概如下面几项：

产品会议：必须有，决定“做不做，做多少”，方向错了很可怕；

项目启动会议：最好开一下，鼓舞士气，磨刀不误砍柴工；

需求评审：最好有，以确认统一对需求的理解，问题越早发现越好；

以上三项可以算作商业评审，其决定“做不做”，是产品会议与功能评审。

设计评审：如果时间紧张或开发人员能力较强，可以省略，但如果开发较弱，新人多，业务不熟悉的团队，就很有必要，否则就是给自己找麻烦；

TC评审：仅次于需求评审，这是纯技术的评审，如果不做，那么PD的工作量就更多，后期的验收测试，也需要更细致；

功能评审：可以理解为UAT，是上线发布前的最后一个测试环节，相对来说比较重要，如果注重敏捷方法，也需要通知到相关的人员，让大家去看看；

发布评审：重要程度相对较低，由项目管理者决定是否需要；

以上四项可以说是技术评审，其决定“怎么做”，完全是工程师们的工作职责。

3、敏捷方法

敏捷方法，是互联网发展至今，越来越被提倡的一种软件工程模型，不过需要明白一点：“敏捷更是手段”！

敏捷方法的特点，下面列举一些：

①有计划，更要拥抱变化

互联网行业，一切的信息环境瞬息万变，死守着项目计划不调整最后只有死路一条，而且不确定性会累积越来越大，直至造成不可挽回的结果，类似“雪崩效应”。

所以，强行遵守计划是没意义的，应不断修正不断调整，当然，项目计划开始留出一定的弹性空间很有必要。

②迭代周期内尽量不加任务

敏捷再灵活，也怕毫无控制的变化，所以，确定迭代的权限、范围、内容，就显得很有必要。

③集中工作，小步快跑

小步快跑的精髓，“沟通是核心”。有效快速的沟通，永远是效率提升的不二法门。

④持续细化需求，强调测试

“唯一不变的就是改变”。项目产品都要小步快跑，不用在需求过多花费精力。对于这种敏捷方法下的项目，TDD是一种很好的策略。

⑤不断发布，今早交付

让需求方甚至用户不断、尽快的看到结果，并给予反馈，因为，真正的“用户”，更知道自己要什么。

六、项目的坎坷一生思维导图

---

资源分享

下方这份完整的软件测试视频学习教程已经上传CSDN官方认证的二维码，朋友们如果需要可以自行免费领取 【保证100%免费】