事前药

本文阅读时长约10-30分钟，建议先浏览下总纲，很多细节不一定是通用的，主要还是想引导大家为什么这么做，而不是套模板，灵活比什么都重要，这个是初衷；

内容是全体测试同学及老大共同参与整 理，并得到了公司各职能的认可，目前已经在对某些团队宣讲及试点，并会不停优化整个流程，期望能形成一个好的团队合作模式；

从内容而言，算是一个大而全的输出，建议不同同学灵活运用，根据不同团队制定合适的流程和规范；

前言

随着互联网的飞速发展，企业为了争夺市场而快速迭代，随之而来的，就是敏捷、免测、自动化等一系列规范化的诞生，为的就是确保项目在高速迭代时依然能保持好的质量及团队配合；

而测试是处于整个迭代的最下游，一旦上游出现delay，项目在不延期的情况下，就会压缩测试时间，从而产生上午写bug，下午发布的情况，而这情况越来越普遍；

在这种环境下，测试人员压力很大，甚至喘不过气，而且bug发布后，一旦有线上问题，就归根到测试没有发现问题等，导致人员心里越来越疲惫，说句话说，员工感觉不到幸福感；

而这种情况，往往在小公司里会更明显，因为流程不清晰，各种不规范，产品乱插需求等等，很不巧，jb也遇到，正如上面说的，乱排优先级、delay家常便饭，老板一看，什么，又要delay？怎么搞的啊！ 不用测试啦，快速迭代，然后出问题又怪到 测试这，怎么那么多问题等；

正如弹簧一般，被压久了，就失去弹力，习惯了是个很可怕词语，一旦习惯了，就麻木了，人就渐渐失去激情了；

为了改变这种现状，测试团队及老大（技术负责人）也想改变这种情况，因此就有了下文的内容，主要是制定一系列的项目流程规范，跟各职能达成共识，严格循序；

做什么？

既然老大都支持做这个事，那就思考下要做什么吧？

常见的项目流程应该是这样的：

• 需求文档；
• 评审；
• 工作量评估；
• 制定项目计划，立项；
• 开发；
• 提测；
• 测试；
• 延期&需求变更；
• 验收；
• 上线；
• 结项；
• 线上问题跟进；

好像，大概，流程就是这样啦，没啥毛病；

但是，够了吗？可是要站在项目的角度想这个事情呢；

经过一轮脑暴，发现是还有很多细节，如：

• 职责；
• 开会效率；
• 邮件；
• 请假；
• 团队意识；
• 办公室命名；

还有吗？肯定还有的，只是没想到而已，但毕竟不是专业的项目经理，那先把想到的搞定先吧；

按照上面说的，会分几块：

项目迭代流程、职责分工（针对项目跟产品）、团队意识、开会、邮件、请假、 通讯工具（如某钉、某信）；

总纲

项目迭代流程

1.产品经理建立confluence版本目录;
新项目就先建新空间;
所有文档按照文档组织规范来存放；
2.产品经理收集各方（运营、客服等）需求后撰写需求总表，包含需求概述（一到两句话）和优先级;
3.需求文档：按照需求总表的顺序出，每个需求的细致程度和优先级一致;
写需求期间设计师同步做设计初稿;
4.负责人评审：由研发、测试的主管评审可行性和资源可用性（人力、服务器等）;
简单的需求不一定需要开会;
5.设计师初稿：有客户端或前端参与的需求，初稿要在全体评审前要做出来。
期间设计师有机会先提出产品文档缺陷;
6.全体评审：所有实际参与项目的同学参加。尽可能提前发现缺陷;
7.工作量评估：各职能给出时间长度和依赖关系，汇总给项目经理排期;
8.排期，立项：项目经理发出邮件，包含所有的信息;
设计师标注切图;
9.开发设计评审（一般小于10个工作日的需求不需要，具体由研发主管判断）;
10.测试用例评审（一般小于10个工作日的需求不需要，具体由测试主管判断）;
11.开发，提测;
12.测试：先准备好冒烟测试案例给开发。每轮测试撰写测试报告;
所有人都可以去报bug;
13.延期和需求变更;
14.加班;
15.验收、上线：发布后运营和测试再做一轮冒烟测试或持续监控，达到放量的标准才叫完成上线;
16.结项：数据分析、复盘，项目经理汇总后发邮件;
17.线上故障;

专项版本流程

专项版本的特点是独立版本项目，不跟随版本迭代的需求； 在项目空间的根目录建一个文件夹存放项目相关的内容； 确定搭车哪个版本上线后，可以把所有文档转移到那个版本的目录下；

具体流程规范尽量和版本迭代流程保持一致。

职责分工

产品经理对结果负责，项目经理对信息传递负责，各职能主管对流程负责。

项目经理的核心作用是信息枢纽，主要职责：

• 制定和优化项目流程规范；
• 收集工作量评估，排期，确认里程碑时间，如有必要可召开立项会议，最终发出立项邮件；
• 结项会议主持；
• 解决团队资源冲突，确定项目的优先级，协调人力资源；
• 发现团队合作中可以提升工作效率的地方，并推动解决。例如建设产品的axure预览空间；
• 发周报邮件；
• 对团队的问题做监督、总结、给解决方案；

产品经理：

• 确保需求通过评审，得到各方确认，并宣布立项；
• 收集来自运营、商务、客服的需求，做成需求文档安排到版本迭代中；
• 接收客服的反馈，bug就转交给测试跟进，产品建议则统一回复，如果需要处理及插入到各版本迭代计划里；
• 版本发布的最终决定人，即时有问题，只有产品同意，都可以发布；

团队意识

1.目标导向，不是为了任务而做任务；
2.所有规则都不是死的，哪些要哪些不要，要具体地判断，按时高质量完成是最基本的目标；
3.所有事务都有优先级顺序，如果不清楚的话就询问上司，直至boss；
4.及时反馈，并通知到应该知悉的人；
5.团队互助：别人做得60分，如果你抱怨着等别人完善，你也是60分；
6.项目安排一旦定下来就是个承诺，能否兑现是职业素养的体现；

开会

1.主持人要做好时间控制，尽量一小时内讨论完；
2.开会要说明会议目标和议程；
3.按需写纪要：讨论内容与结论，需要跟进的问题和责任人；
4.按时参会，有事不能来或迟到应该告知主持人请假；
5.在提前2小时有通知并说明了迟到要发红包的前提下，会议主持人可以要求迟到未请假者发红包，总额按参会人人均X元；

邮件

1.什么时候要发：需要跟进和后续查阅的事项；
2.推荐使用foxmail为客户端，也可直接使用钉钉；
3.邮件标题，简明扼要，如果紧急，写上【紧急】、【项目周报】、【测试周报】，以此类推；
4.称呼：写清楚是对谁说的，对全体就是“Dear All”；
5.要有签名栏，至少有自己的名字；
6.抄送：自己的上司、涉及人员的上司（至部门一级）；

钉钉

1.每个项目组建一个群，拉上所有实际参与的人和各级主管；
2.项目事情不允许建立小群来讨论，只要是说正事就不要怕打扰人。
只有讨论非工作事宜的才能建，例如下午茶群。

请假

务必保证上司知悉。
如果自己身上有重要任务，必须让项目组也知悉。

晨会

在项目迭代较快的时候，都要求进行晨会，目的是快速同步信息，了解进度，如果有遇到问题，也及时提出，让对应负责人推动，避免一切延期的风险；

在晨会反馈时，需要技巧，不能这样：XX功能进度正常，按照原计划执行；

应该是需要反馈做了什么事情，这个事情的进度，大概什么时候完成，这个事情不是一个项目，而是拆分出最小的一个功能，比如：

昨天做升级功能，界面及接口联调已经完成，进度60%，今天会进行防劫持功能开发及自测,今天内开发完毕；

小结

看到这里，是不是觉得很繁琐？这种鸡毛蒜皮的事都要管？
没错，看上去越是鸡毛蒜皮的事，往往却是最重要的，互联网时代，什么都要高效、注重用户体验，这些事情都不例外；

那接下来，就针对项目迭代流程里的每个小点进行说明吧；

文档组织规范

总则

所有文档以Confluence（下文简称cf）为中心做管理，cf不方便存放的东西才放到svn。

项目组的钉钉公告栏只放置版本页的cf链接和当前版本的提测记录。

CF规范

每个项目由产品经理或项目经理建一个空间。

目录规范如下：

• 主页
• • 通用文档，包括第三方文档、全局术语表、全局信息（测试服务器地址、svn地址）等，跟具体版本无关联;
• • 专项文档，跨版本的需求统筹、跟版本无关联的运营活动需求;
• • x.x.x（版本号，按具体版本划分）
• • • 需求总表；
• • • 立项。可以不独立成文档，只存在于邮件或钉钉公告栏里即可，或在需求总表文档上回复；
• • • 各个需求文档，以需求名称命名文档名。如果用axure，在这里填写svn地址，还可以包括预览空间的url地址；
• • • 测试文档，以作用命名文档名，主要是用例，可放svn。测试报告只存在于邮件中，如果不嫌烦可以在需求总表的文档那里做回复；
• • • 结项。这个必须要，不能只在邮件里；
• • 垃圾桶（废弃的需求、不再使用的第三方文档等移动到这里）

SVN规范

目录规范如下：

• 根目录

• • 小程序(按产品形态或者具体业务来分，任君选择)
• • • A项目
• • • • 设计文档
• • • • 接口文档
• • • • 测试工具
• • • • x.x.x（版本号）
• • • • • 需求文档（axure源文件和导出的html文件夹、各个需求的word，以需求名字命名）；
• • • • • 设计文档
• • • • • • ps源文件，设计稿、标注、切图
• • • • • 测试文档
• • • • • • xmind、excel用例整理
• • • B项目 ...

需求总表

表格格式

需求名称	优先级	产品	UI	前端	后端	测试	运维
A需求	核心	JXX、BXX	JAX	BAX	JBAX	JXX	BXX
B需求	高	AXX、CXX	EAX	DAX	FAX	EXX	IXX
A需求	核心	JXX、BXX		BAX	JBAX	免测	BXX

列填写

• “需求名称”和“优先级”由产品填写。
• 需求名称：只能是1句话。 如果这都做不到，这个需求肯定不清晰;
• 以优先级排序。 优先级说明： 核心：必做，先做，不能砍，不做完就不发布新版本。可单独形成一轮提测。 高：必做。条件不允许的话可以降低为中优先级。可单独形成一轮提测。如果存在多个高优先级，则产品继续细分； 中：如果时间允许，会做； 低：可以不做； 优先级还可以用分数来表达，如核心100，高是99-90，从而充分体现各高优先级里更高优先级的需求；
• 各职能人员名单，由对应主管决定，谁填写都可以。 如果人不多，直接写在表格外更好；

执行说明

• 产品应该先写总表再写需求文档，需求文档的完善程度与总表的优先级是一致的，优先级低的需求还可以在核心需求开发过程中再完善;
• 怎样算是一个需求？（成为表格里的一行）
• • 跟其它需求无关联；
• • 可以和其它需求并行开发的，多人合作不会产生交叉；
• • 优先级相同且属同一个模块，允许合并；
• • 重要的bug可以作为需求列上来；
• • 运维的工作独立算成需求；
• 整个项目组都按优先级做。 核心和高优先级的可以做完一个提测一个；

需求文档

前置说明

文档的标题是1句话，跟需求总表里的一致。

• 需求描述的基本要求：条理清晰，逻辑严谨，用词专业，格式规范，易于阅读，重点词句标红；
• 全体评审时，需求文档上应该是设计稿，而不是原型图，避免实际开发/测试时大量出现设计稿跟原型图不相符的情况；
• 如果是基于旧需求的补充完善，把旧需求复制到新版本，加上修订记录并标记修改的部分。

写作思路和本模板的设计原理

请参考 www.woshipm.com/pmd/1579154…
本文是公司大佬在人人都是产品经理发表的文章，也得到的产品经理的认可；

实际的示例，可以参考 www.woshipm.com/evaluating/…
但请注意要灵活运用，本文是来自于人人都是产品经理的文章，算是比较全面的文章；

修订历史

版本	日期	修订人	修订内容
V1.0	18.9.27	jb	初版
V1.2	18.9.29	jb	需求评审，修改XX功能
V1.3	18.10.28	jb	需求变更，原因是原来功能无法实现
V1.4	18.11.01	jb	1.增加XX功能，2.修改XX文案

目标

包括但不限于以下内容：

• 解决什么问题、痛点；
• 此需求本身达到多少使用率、转化率；
• 此需求能提升多少PV、UV、交易额等。（需要脱敏写百分比，不需要就写绝对值）；

主要是防止无脑、拍脑袋需求，凡事要用数据推动，有理有据，让团队都知道做这个事的目的，同时也避免浪费资源却没有好的结果；

术语表

术语	说明
自动还款	...

哪些东西需要在术语表里列出？

• 没有标题的页面、区域，内部怎么统一叫法；
• 新功能的名称；
• 特殊的叫法、代号；
• 一些流程的简称；

之前在负责seo项目的时候就出现过，同一个功能，产品、前端、测试、UI各有各叫法，导致沟通造成成本；

参考资料

（这里放关联需求和第三方文档资料，没有就不需要这部分）

产品结构图

暂定新项目一定需要此章节，原因是梳理产品结构图需要时间，在产品迭代如此快速的情况下，功能可能每个版本都在变化，考虑到人力成本，让产品每个版本去维护也不可能，因为先要求新项目一定需要，迭代中的项目，酌情处理，能有是最好的；

原型和说明

• 如果用axure做，不要把axure的截图贴过来，这里直接放导出网页的svn路径，还可放上http空间的链接，方便大家在线阅读，免得到处找文档，其它工具画的图才截图;
• 如果整个需求能用简单图文说清楚的，就不要用Axure，直接用cf简短写;
• 不强制要画流程图、状态表，只要能表达清楚完整，什么形式都可以；
• 前端和客户端混合的需求，应标记一下是哪个端的实现；

非功能性需求

• 性能
• 统计
• 安全
• 兼容性：系统(iOS8，Android4.4)、分辨率&尺寸(4.7寸、长宽比>19：7的屏幕)、浏览器（Chrome、ie、火狐）

需求评审和工作量评估

两轮评审

流程：

• 预审：产品提前2小时发出通知和初稿（不需要完善细节，可以只是原型），召集主管或负责人预审; 未必需要开会，只要每个人能确认需求没大问题就好;
• 全体评审：产品提前1天发出通知和需求链接（设计师已出完初步设计图），全体人员参加； 应该在会前审完大部分问题，而不是会后；会上只是查漏补缺；
• 跟运营有关的需求，应该在全体评审前由运营先审核完毕；
• 产品经理根据问题修改完毕后，逐个找负责人确认。
• 都通过后，发出通知通知；
• 项目经理收集工作量评估进行排期，并在各方确认后发出立项邮件；

要求：

• 全体评审不能在上个版本未上线的时候进行，要给参会人足够的时间精力做好评审；
• 如果问题太多，应该再举行一次需求评审；

预审

核心作用就是向开发打招呼，知道要做什么，好安排人力资源。 所以产品文档不需要很完善，但一定要交代清楚目标和核心的功能点。

召集开发测试的主管或负责人简单过一遍即可，主要是评审可行性。

不需要预审（免测）的条件：

• 开发工作量小于5个工作日；
• 改UI为主，没有难度；

评审要评些什么？

所有人都要评的：

• 目标是否清晰；针对目标，需求的设计是否合理；
• 针对需求：不完善的地方、影响范围、用户体验； 尽量在写代码前发现需求问题；
• 具体工作量；
• 时间安排：限时上线的就砍需求，不限时就由大家来决定发布时间；
• 风险点：所有导致评估不准和项目延期的可能性；

特别注意地：

• 技术要评估可行性，影响开发时长的难点，是否需要预研；
• 测试要评估测试资源的充足性（例如测试设备）、自动化测试可行性；
• 运维要评估服务器资源的充足性；

工作量评估

按照每个需求来评，各个职能都评。

以0.5人天为最小单位。

一个关于战斗力的评估法：

列出参与这个项目的所有人员。为了便于描述，我们把其中能力最强或工作效率最高的人称为A。A一天（除去加班、
小憩时间）能完成的工作量定义为1人天，同时把A的战斗力定为1.0。这个需求按照A的标准要几天才能完成，
则它的工作量可量化为多少人天。

再对其他人员逐一跟A比较做评估，如果B一天能完成的工作量是A的70%，则把B的战斗力定为0.7。

假如还有C的战斗力0.5，则这个团队的总战斗力为1.0+0.7+0.5=2.2。如果某个需求的工作量是11人天，则最理
想的情况下，这个团队需要用11÷2.2=5天来完成。

团队的人越多，花在沟通上的时间也会增多。再加上可能有评估不准、部门会议、临时请假的情况，在估算整
体所需时间时，应乘以一个系数，例如1.2，来作为最终时间。即上例中，应为5×1.2=6天。类似地，如果要996，则可乘
以一个小于1的系数，可以是0.85。

在实际情况下，并非所有团队成员都全天参与此项目，同时参加多个项目的情况很常见。如果A对本项目只投入一半
的时间，则团队的总战斗力应算成1.0×0.5+0.7+0.5=1.7。

设计师流程规范

前置说明

• 这里只关注影响合作的规范，跟“好不好看”有关的标准是设计师内部的专业规范，这里不涉及。
• 程序员期望的设计师能力，可参考https://www.zcool.com.cn/article/ZODIyODM2.html

设计图规范

预审的目标是让负责人评估可行性，设计稿着重表达出样式的位置、形状和交互即可，是原型还是设计稿都没关系。

全体评审的目标是让开发准确评估工作量。对工作量影响极小的东西可以不是终稿，例如颜色值、字体大小、间距。

终稿可在各需求实际写代码前确定，允许在验收阶段再进行不需要测试回归的微调，当面调试的需要记得到同步回设计稿。

切图规范

• 设计师自身维护所有的图片，每次都是给开发所有的切图（包括新增和剔除废弃），且同一张图或有小改动但放在原位的图文件名不变，自身知道哪些图片在这个版本不需要了；
• 所有源件不是拆分版本上传svn，每个版本下都是保存当前用到的所有东西；
• 切图文件按规范命名，全小写英文，下划线连接；
• 宽高应是偶数；

对某些组件是否在切图中应用透明边距和对应做标注，应统一风格。

标注规范

• 最好能有全局规范；
• web项目字号不能低于12px，app项目不能低于10px；
• 所有大小均为偶数；
• 标注不好说明的，应使用文字说明；

命名规范

UI文件的命名规范，可参考下方：

排期和立项

术语解释

• 里程碑（时间）：重要的时间节点，例如提测、发布，来自英文milestone。 风险点：任何可能造成项目延期的事项 立项：经过核心和高优先级的全体需求评审后，由项目经理收集各职能的工作量、风险、所需资源评估，协商得出里程碑时间，发出邮件。
• 每轮提测叫t1、t2、t3，t = test；
• 每轮提测内提交的修改，叫patch；
• 合起来看：第2轮提测打的第3个tag，叫t2p3；
• 全功能提测：所有在本版本要上线的需求都做完了，也可以让UI提前验收；

关于提测，很多大型公司叫rc1，全称是Release Candidate的缩写，意思是发布倒计时，这个阶段大多数用于集成测试后的版本；

一般的不同流程的命名如下：

beta、rc、trial、release、patch、hotfix

项目排期

排期目标：

• 每个需求的职能依赖关系以及时间表，比如前端依赖ui和后端，被依赖者什么时候做完；
• 分几轮提测，每轮的时间点，提测内容，“核心”和“高”优先级的需求，都可形成一轮提测；
• 发布时间；
• 风险点；

里程碑时间安排示例：

• t1：11.2，需求A、B。UI在11.1前给出，后端接口在11.1前准备完毕；
• t2（全功能）：11.5；
• t3：11.7；
• 发布：11.8；

可能的风险点：

• 参与人员业务不熟；
• 长假的前后，工作效率低；
• 人员请假；
• 第三方服务或政策因素；

版本管理

版本号格式：x.x.x，说明：

• 有新需求，第2位+1，第3位置0
• 大改版，第1位+1，第2、第3位置0
• 小bug改动，第3位+1

立项邮件

收件人：项目组钉钉群

标题：【立项通知】xxx（项目）y.y.y（版本），例如 【立项通知】XXXX产品3.2.4

正文：

Dear All，

本期项目共有5个核心和高优先级需求，3个中低优先级需求。有12个人参与实际工作。具体请看需求总表【url】；

项目周期：10月4日-10月18日，共10个工作日

里程碑：

1. t1：10月12日（周三）。提测需求A、B。UI在10.10前给出，后端接口在10.11前准备完毕
2. t2：10月13日（周四）
3. t3（全功能）：10月18日（周二）
4. 发布：10月20日（周四）

风险点：
1.新同学加入实现需求A，业务不熟，可能会延长解bug时间
2.需求B需要技术预研，预留时间未必准确。请 @xxx 随时汇报进度
第三方合作商xxx在月中要进行数据迁移，影响我们对接

如何做版本规划

需求池，关联度梳理，拆解，优先级评估，迭代周期，专项；

版本规划的目的

在现代社会市场和需求变化快的情况下，产品经理制定迭代周期短的产品规划，可根据市场的反馈，及时调整产品下一个迭代的需求功能和产品形态以满足公司的战略和业务需求；

需求池

产品经理在做产品设计之前，都会创建一个需求池，用来收集各种需求，防止有遗漏的需求和方便对需求的梳理； 由产品经理管理维护，项目相关人员补充内容； 无论需求是否可行，项目相关人员都可以将需求填进需求池中，且无数量的限制； 需求梳理时，产品经理可从需求池中分析和筛选； 制作需求池的方式有两种：文档表格和OA系统。表格内可含以下内容：

• 需求名称（必选）：
• 需求描述（必选），详细描述需求功能，有以下分类：
• • 用户需求：用户想要的功能；
• • 业务需求：赚钱的功能；
• 需求类型（可选），包含以下分类：新增功能、功能优化、Bug修复、体验优化；
• 来源（可选），包含以下分类：战略规划、竞品分析、用户需求、运营市场反馈；

需求梳理

产品经理收集完成产品需求之后，对需求池中的需求进行分析，梳理出需求功能结构图，为产品迭代提供方向； 需求分析时，可执行以下操作：

• 需求合并：合并同类型需求。
• 需求删除：筛掉不合理、不符合产品定位的需求。
• 需求关联：梳理需求之间的依赖关系，
• 需求拆解：将需求拆解成一个个可实现的功能，形成需求功能结构图，可用脑图表示；

需求优先级评估

需求优先级的评估就是在有限的资源（时间、人力、硬件），产品经理安排优先做的需求功能，以达到产品的阶段性目标，符合公司的价值；

可按以下优先级排序：

• 公司战略： 公司战略指定的核心功能/业务需求，能为公司带来直接收益；
• 利于日活/拉新： 能够有效的提成用户活跃度和用户量；
• 功能优化、Bug修复、体验优化： 这类主要就是用户体验类，提升产品的使用满意度；
• 提升运营、运维效率：减少成本；

迭代周期规划

迭代周期就是要一个迭代从开始时间到结束时间的时间窗，完成设计、开发、测试、上线等活动；

固定的迭代周期就是固定的时间窗，有以下好处：

• 建立团队的节奏感：有预期的节奏，容易让团队形成习惯，团队生产效率更规律；
• 降低协同成本：能够并行的去安排多个迭代的规划，评审等活动。每个人都知道这些活动什么时候进行，减低沟通和协同成本；
• 简化规划活动：固定的迭代周期，固定的人力，固定的产出交付，有利于产品规划的合理性；

短周期：10个工作日（两周）以内的时间窗； 长周期：10-20个工作日（一个月）的时间窗；

根据需求优先级，团队的实际情况，选择合适迭代周期，一般需要考虑以下因素：

• 项目周期：短周期迭代，快速取得反馈意见并改进；
• 需求数量：需求越少，采用短周期；
• 不确定的因素：项目组的工作效率、技术门槛等； 不确定性越多，就应该采用短周期迭代；
• 需求优先级变化：频繁更改优先级，采用长周期迭代；
• 迭代系统开销：每次回归时间成本很高，采用长周期迭代；

专项

专项是在项目预审或需求评审时，涉及范围（多部门合作、代码重构、功能优化）大，时间窗超过长周期的，需要专门设立的项目；

专项是所有项目集中优先级最高，安排专人负责项目，集中当前的人力资源优先解决问题；

专项的特点：

• UI/UX 大幅度修改，耗时10工作日以上；
• 系统代码重构；
• 时间窗超过20个工作日；

如何做好专项：

• 适当调整其他项目的优先级，由组长介入分配参与此项目的人力；
• 专项组员当前只负责当前专项工作，确保项目不被其他项目干扰，按期完成；
• 项目负责人定期去推进；

产品和UI协同规范

产品经理在描述某个需求功能有多个异常状态时，在产品文档用不用颜色的文字或者表格来强调突出；

由UI同学在画高保真设计稿时，针对不同状态来进行设计；

有助于产品经理在验收UI设计稿的时候，针对功能点和多种异常状态的验收；

运营介入需求

运营提前提前确认产品需求功能和迭代，确保当前迭代是符合产品整体规划，有利于团队协同效率；

但过多的流程会导致运营做不好自身的工作，因此简化如下流程：

• 产品经理制定产品迭代规划，需告知运营，如运营有异议，可沟通及时调整；
• 产品经理在预审时，需告知此版本迭代需求，如运营有异议，可沟通及时调整；
• 产品经理在需求评审时，提前通知项目组员，包括运营人员，进行产品的文档修正，如产品文案等；

开发规范（待梳理）

待梳理的原因是，开发规范目前来说是最内部的，优先级应该是最低的，因此暂时不考虑，大致会涉及到这几个内容：

代码风格规范
api规范，数据结构、文档规范
git 分支和log规范
review制度
对外文档规范
设计文档：数据库结构、系统设计图

提测流程和免测标准

规则

• 右前端、客户端、后端参与的需求，由对应开发来提测；

流程

• 开发自测，确保主路径没问题，如果测试组有提供冒烟测试，必须冒烟都通过；
• 在钉钉公告栏写上本次提测的tag和测试重点，每个版本内累计更新，不要覆盖上次的内容
• 如果质量不过关，测试可以打回；

提测通知示例

（术语解释参考排期和立项）

前端t1 2.3.3/1803031104 已自测，自动XX、UI改版
前端t2 2.3.3/1803041203 未自测，XX
前端t2p1 2.3.3/1803051404 …… 解决一个崩溃，会影响所有需要登录的界面
iOS t3 2.3.3/1803061203 已自测，全功能提测
后端t1 1803061203 解决xxx问题

patch的提交频率以天为单位，不建议解决一个bug就提测一个patch； 如果实在需要，应该开发和测试同学单对单地验证完毕，然后发patch时再由测试回归多个问题；

前端、后端、小程序、H5这种没有tag概念的话，就用当前日期处理；

打回

标准：

• 测试环境没搭好（提供部署环境的代码时未提供部署文档）；
• 主路径跑不通；
• 开发未通过冒烟测试用例；
• 开发未写明测试重点、修改代码的影响范围；
• 开发未提供相关数据库设计文档、接口设计文档；

通知：

• 钉钉群里 @所有人 来通告，说明原因；

免测标准

免测的前提是确认测试已知悉，然后才是下面的条件：

• 只改UI布局或文案，没有改交互和业务；
• 只是改后台报表统计；

测试报告

撰写原则

• 最终目标不是故意找茬，而是让管理者知道哪个环节有问题，能及时做调整；
• 要能反映质量，不要写成在描述需求或业务；
• 质量问题要具体到职能或人；不能模棱两可，看不出谁要为问题负责；
• 记录测试手段，为线上故障的漏测找依据；

邮件模板

收件人：项目组的钉钉群 抄送：测试组的钉钉群 标题：【测试报告】xxx项目y.y.y（版本）[第z轮|release]，例如 【测试报告】jb项目1.2.1 t1

正文：

Dear All， 1.结果概况

结果：[通过|有条件通过|失败打回]； [有条件通过的原因]：产品同意部分bug不影响发布，并已知晓问题风险，同意下次解决；

（一两句话总结项目质量）例如：开发比上一版本的质量有明显提升，需求变更数也少了，给大家点个赞！

遗留问题数：x个。

（不多的话下面直接列出来，带有禅道url的超链接）

2.质量报告

质量指标：

• 需求变更数：10个，增加工作量：20人天；
• 测试案例一次通过率：76%；
• bug总数：108个；
• 性能指标：api接口平均响应时间：400ms；
• 兼容性：测试设备（列表见过程记录）中没有发现兼容性问题；
• 每轮提测的patch数；

bug分布： 一系列的饼图，数量和百分比。维度：责任人、报bug人、出错原因、严重程度、解决耗时、异常状态（打回和重新激活）；

本轮测试后，处于未关闭状态的bug，责任人分布：

3.过程记录

需求与测试人员参考立项文档：(url)

案例情况：

• 数量：76个；
• 类型覆盖：功能测试，接口测试，接口自动化，兼容性测试，性能测试；
• 自动化案例增加3个接口的监控；

测试环境：

手机型号：

系统类型与版本：

浏览器类型与版本：

• Windows Chrome Version 69.0.3497.100 (Official Build) (64-bit)
• Mac Safari Version 12.0 (13606.2.11)
• iPhone 7, iOS 11.3.2 Safari
• 小米6A， MIUI 10.2.2 系统浏览器，UC浏览器 V12.3.3.2342

bug系统使用规范

报告规范

指派：

• 直接指派给你知道的负责人，否则先给测试负责人；

模块：

• 尽量选对，不同模块通知到的负责人可能不同；
• 不知道的话选其它，由测试负责人再修改；

标题：

• 一句话总结出错的位置、现象；或者是建议做法；
• 思考一下要搜索出这个bug时会用什么关键字，这个关键字应该存在标题里；
• 标题可以用[]来存在重要内容，如【小说】小说模块出现无法加载问题；

重现步骤：

• 说明问题的现象是什么，为什么这算是一个bug；
• 可以补充说明要修复成什么样，如果是显而易见的就不用说了；
• UI展示问题或文字说不清的问题，截图说明，必要的话做成GIF或录屏；
• 特定情况才触发的问题，要包含测试数据，例如：
• • 账号密码；
• • app项目的操作路径，例如 首页->资讯广场->点击第一条->白屏；
• • web项目的URL；
• • 如果觉得可能是兼容性问题，写上重现条件，例如手机版本、系统版本；
• • 其他能帮助重现的信息；

严重程度划分标准：（目前禅道对应1、2、3、4）

• 严重：崩溃、白屏、404/500错误；业务错误，流程不通，主要功能缺失，数据计算错误，性能；
• 一般：次要功能错误、缺失；数据长度；界面样式影响使用
• 轻微：界面样式问题但不影响使用
• 优化建议：体验不好；速度太慢

优先级划分标准，产品经理对优先级有最高决定权：（目前禅道对应1、2、3、4）

• 立即解决：主路径问题，不解决无法继续做测试；
• 下次提测时解决：默认项；
• 发布前解决：相对独立，对其它功能没影响的问题；
• 下个版本解决：未严重影响用户，但解决起来有难度，可能造成项目延期；

这里需要注意，一般严重问题都是紧急的，但是要考虑到问题出现的概率及影响面，从而会有严重不紧急，紧急不严重的情况；

如启动页的logo错了，虽然不严重，但会影响到公司声誉，所以是紧急的；
某个功能出现闪退，但是只在极端的情况出现，考虑到修复成本及影响面，可能属于严重不紧急；

使用规范

• 转给他人时，可以考虑添加备注；
• 及时解决，产品的bug添加到需求池或其它地方有记录就算已解决；

注意事项

切勿将需求当Bug报，报Bug之前，需要了解Bug和需求之间的区别：

• 需求是描述一件事情，作为什么用户，希望如何，这样做的目的或价值何在；
• 需求需要构建用户角色，描述使用场景，定义用户问题；
• Bug是程序中隐藏或被发现的功能缺陷或漏洞。简单说就是使用软件时，出现的错误问题；
• Bug需要描述重现的步骤，环境及其他因素，以便定位问题；

但并不是说需求不能报禅道，只是希望能用更好的方式来区分出来，如标题写上[需求]、选择对应模块和优化建议，指派给产品经理；

延期和需求变更

延期

有延期风险时应及时通知项目经理，并由项目经理组织各负责人确认是否延期；

最终由项目经理发出邮件，列明延期原因、修改后的里程碑时间，同步更新cf文档；

邮件标题：【项目延期】xxx项目延期说明mmdd

Dear all，
    XXX项目 上线时间由11.13 延期到 11.14，延期一天
    延期原因如下：
    1、处理XX问题，超出计划时间。

需求变更

通知规则：

• 必须在需求文档的修订记录上有所体现；
• 在钉钉上@所有人 通知。如果增加的工作量超过1人天的，必须发邮件；
• 会导致项目延期的变更，必须产品主管确认；

通知内容：

• 以前是怎么，要改成什么样；
• 更新文档在哪；
• 影响的具体工作量；
• 影响后的项目计划安排；

操作流程

项目执行过程中，预计项目延期2天以内，与技术人员评估之后，发出延期通知； 超过2天或者延期2天，召开会议，讨论解决方案，发出延期会议邮件；

所有的延期说明，都需要给出具体可量化的原因；

集体加班制度

集体加班的标准

• 及时上线能带来可观收入；
• 外力因素（政府政策、第三方故障等）；
• 延期了太久，要把进度赶回来；

集体加班需要由产品和项目共同决定，并且有邮件通知；

不满足条件的，不得随意要求项目组加班，更不得由产品或项目私下要求加班；

别人过失导致的个人加班，应根据自己意愿决定是否加； 不加是合理的，项目延期是符合流程的； 如果选择加班，那是个人为项目顺利所做的努力，是高绩效的有力依据； 加班完了最好有意识地记录自己的贡献，在述职时列出这些积极表现；

通知

由项目经理发邮件通知，模板：

标题：【加班通知】xx项目mmdd

正文：
（加班的原因、人员名单、目标）

补贴

集体加班，可由产品或项目申请经费购买周六下午茶，人均x元左右； 如果领导同意，可协调成补休，不同团队视实际情况落地，下午茶补贴是一定要有；

验收、发布、上线

验收者

产品、UI、后台系统使用者（运营、客服、风控等）；

验收进入条件

测试流程结束的下一步是验收； 进入验收的最理想标准是所有bug都已关闭；

如果时间紧张，可以放宽到同时满足这两个条件：

• 优先级为“下次提测前解决”的bug都已关闭；
• 优先级为“发布前解决”的bug不超过人均2个；

测试环境验收

• 测试向验收者演示主流程，形式多样，主要是要沟通清楚；
• 验收者自己操作，或让测试演示更多流程；
• UI核对，主要是颜色值和像素级大小的比对你，肉眼能看出来的差异，应该在测试过程就发现；
• UX体验反馈；

发布与线上验收

• 产品经理宣布测试环境通过，让开发发布到生产环境，各职能核心人员待命应对故障；
• 发布后，测试和产品再过一遍主流程，后台系统使用者也应该做些操作来检验或持续一段时间观察相关数据是否异常；
• 线上验收标准由各验收者自己决定 尽量在周二或周四上午发布，以便出现问题时大家有时间精力立即修复；

上线

生产环境验收通过后，确认可以开始放量，这个结果视为“上线”；

由产品经理宣布，如果没什么问题，钉钉群里说完即可，如果有风险，应发邮件：

收件人：项目组
标题：【上线通知】xxx项目y.y.y
正文：
...
（风险预估）
（应急预案）

结项

结项会议

时间：上线三天后 主持人：项目经理或助理 参会人员：实际参于项目的所有人员，主管酌情参与 会前准备：把需要投影的东西给主持人，自己准备好发言提纲 会议流程分为两部分 第一部分，结果总结，按以下次序发言：

• 项目：简单回顾整体项目进度，消耗的人力时长，偏差多少与原因；
• 产品：线上版本相关数据（脱敏）。主要目的是让大家知道劳动成果的意义；
• 测试：简要说测试报告的重点，突出质量的部分；

第二部分，过程总结，这部分发言可进行讨论：

按以下次序发言：项目->运营->产品->UI->后端->前端->客户端->测试->运维；

发言内容指引：

• 对事不对人，主要目的是点赞和总结下次如何做得更好；
• 自己或合作方哪里有改进，上次的问题解决得如何；
• 自己或合作方哪里做的不好，有什么解决方案或建议；
• 提升工作效率的心得（沟通方式，工作方式、项目安排、工具使用等）；

结项邮件

发件人：项目经理或助理

收件人：项目组钉钉群**，可接着项目周报发**

标题：【结项报告】xxx（项目）y.y.y（版本），例如 【结项报告】XX3.2.4

正文：（下划线表示是示例，真实邮件不要有）
Dear All，
（暂无模板，几乎就是结项会议的会议纪要）

例子：

Dear all，
XX小程序VX.X 整体概况如下：
1.XX暴雷X.X的项目计划是X.X -   XX.XX，预计消耗X工作日。实际项目执行是从X.XX -  XX.XX，总共消耗 XX工作日，延期XX工作日。
2.小程序上线之后，使用分享解锁和动态分享功能的人数很多，后续产品会针对分享功能进一步优化及挖掘用户，详情数据请查看附件；
3.整个项目测试反馈的总bug反馈数XX个，有效问题XX个，X个不处理，X个延期处理，X个转为需求;

延期原因：
1.项目人数不足，前端同学在项目中期才开发;
2.需求评审过后，没有进行技术可行性分析，导致项目中后期才发现某些功能实现起来困难;
3.评审需求时，没有足够时间仔细阅读文档。需求里面隐藏着好多功能点，导致评审时间不准;
4.产品文档发生修改的时候，没有马上通知项目成员，增加沟通成本;
5.开发时发生UI及需求文档和后端接口字段串联不上，增加沟通成本和研发成本;
6.bug数量多，有效Bug 有93个，修复时间长;
7.消息中心功能在项目后期才调通，处理时间久;
8.测试跟前端双方在bugfix阶段的配合存在问题，需要优化;

解决方案：
1、XXX

表格说明

线上故障

##故障定义 发布生产环境并验收通过，确认放量后，还发现的bug都算线上故障；

报告标准

什么情况的线上故障需要报告？

• 对营业额有大影响，例如无法打开页面，无法买标；
• 对用户口碑有大影响，例如功能无法使用；

什么情况的不需要报告？

• 简单的用户体验或纯UI的问题

处理流程

• 无论谁发现的，首先应该反馈给测试同学；
• 测试确认重现步骤后，报bug给开发解决，并由产品经理决定是否紧急发布修复；
• 修复后，由测试负责人汇总各职能的报告并发出邮件；
• 产品报告对运营数据的影响；
• 开发报告出错的原因、（代码层面的）影响范围；
• 测试报告没测出来的原因；
• 由测试组织讨论如何防范这样的情况再出现；

报告邮件

原则：

要找出责任人（或指出是哪个职能即可）和出错类型（代码、需求、沟通之类的），并明确写到报告中；
对事不对人，注意措辞；
要有解决方案，且有明确的跟进人；

例子：

收件人：项目组钉钉群

抄送：测试组钉钉群

标题：【线上故障】xxx项目a月b日yyy问题

正文：（下划线表示是示例部分，真实邮件不要有）

Dear All,

本次故障的现象：散标详情页出现白屏，并一直弹框“数据异常”

持续时间：10月3日14:30上线就存在，在10月3日18:00由后端修复，故障持续3.5小时

发现时间：由客服在10月3日16:00收到用户反馈而发现
影响：用户无法查看和购买散标
原因：后端……
解决方案：解决代码错误即可

未能更早发现故障的原因：后端上线前改代码未通知测试

防范方案：需要开发自觉，开发主管要加强宣导。最佳解决方案是git提交都有监控，但目前可执行性太弱；

项目周报

原则

• 有事起奏无事退朝；
• 项目经理可在周一上午召开站会收集信息，各职能负责人需积极配合；
• 周一下午3点前发出邮件；

邮件模板

收件人：接着立项邮件全体回复，每周接着上一周发直到结项

标题：【项目周报】xxx（项目）mmdd（月日），例如 征信通1018

正文：

Dear All，

（1-3句话总结情况。）

（当前进度，是否存在风险。有就说明异常情况与原因，提醒注意，请求协助。）

本周项目进度正常，按计划进行中，无特别情况需要汇报。项目计划参考立项文档；


本周进度基本可控，可能的风险点：

周三xxx要请假，也许会造成延期
xxx需求还没出UI稿，设计师在忙别的项目，可能造成前端延期


10月4日周二上线了1.3.2版本，运营数据在持续观察中。1.3.3的需求正在评审中。

项目确定延期1天，改为10月28日发布，原因：

需求变更，xxx需求未考虑到yyy的情况，补上后产生新工作量，具体请参考 需求变更文档/邮件
xxx临时有事请假
阿里云服务器故障，情况未知，@xxx正在处理

10月5日发生了线上故障 xxx，具体请参考 测试 发的邮件，标题为：yyy

本周运营数据：（由产品经理进行脱敏处理，有图表更好）

PV变化在5%以内，在合理范围内
UV下降了20%，应该跟国庆假期有关
买标数据上涨30%，交易总额上涨50%，上线的新功能非常有用！
xxx的运营需求，转化率为7.8%，效果很差！

例子

例子1：

hi，all，上周XXX各项目进度如下：
XXXAPP：
VX.X.X版本：
研发侧：
1）bugfix中，目前还剩下X个bug，开发进度约XX%；
2）XX功能上周已开发完毕，计划周二周三跟客户端联调，周四提测；
3）对接XX工作，确定延期，需要等XX上线才可以对接，初定XX月上旬，产品已知晓；
4）考虑XX可能存在风险，决定把该功能延期到X.X.X版本上，避免因XX功能导致项目延期或承担风险；

测试侧：目前已提测t1、t2，均测试完毕，处于bugfix验收环节；

VX.X.X版本：
该版本为小版本，主要是体验优化（具体优化内容）；

1）产品侧：需求已与测试、后端、UI评审，前端因还在忙VX.X.X项目，暂时未参与；
2）研发侧：后端，除了版本兼容需要跟前端讨论可行性，其他功能能在本周内开发完成；
3）UI侧：已经提供了设计稿；

VX.X.X版本：
该版本为大版本，主要是新增XX功能；

1）产品侧：需求已与测试、后端、UI评审，前端因还在忙VX.X.X项目，暂时未参与；
2）研发侧：后端，除了版本兼容需要跟前端讨论可行性，其他功能能在本周内开发完成；


XXX：
1）研发侧：上周已提测XX功能，目前开发进度XX%，进度正常，预计下周五全部开发完毕；
2）测试：测试中，测试进度10%，在测试XX模块中，因页面内容跳转还未完全实现，因此后期存在返工量，后期可能会存在风险；


XXX项目VX.X：上周已上线；

例子2：

Dear All，
上周主要项目进度
 已发布 ：
 针对线上问题修改预付利息算法
 产品：XXX   开发：XX  测试：XX萱
 进行中 ：
1.轻松投部分退出     测试阶段
 产品：蔡菁菁   开发：黄振廷，吴冬冬（本周增加），蔡晓萍，林博淳   测试：周佩萱
风险：故障较多，主流程仍不通结算失败，并且问题反复出现。前期开发（业务）设计存在许多缺陷
    原计划本周上线
解决方案：协调产品及开发负责人讨论，决定增加一名开发。看故障解决情况明天早会再讨论进一步解决方案

2.App优化-XXX功能  测试阶段  进度正常
产品：XXX   开发：XXX   测试：XXX

3.XXXX  测试阶段  进度正常
产品：XXX  开发：XXX   测试：XXX

4.XXX  开发编码阶段
产品：XXX  开发：XXX   测试：XXX

5.XXX 开发设计阶段
产品：XXX 开发：XXX    测试：XXX

小结

上面的内容，是整个团队的努力，大家一起完成的，完成这么一件事不容易，虽然花费了很多时间，但真的很值得，因为之前只是在门外，而如今在门内，不亲力亲为，真的不知道需要了解这么多内容；

好了，就这样吧，如果有补充的，欢迎提出，谢谢大家；