项目管理：这个bug是你的问题！这个不是bug是需求变更！
背景是我新入职的一家单位，项目经理说从今天开始针对项目bug数进行考核，大致就是你的bug多就给你扣分，影响你的绩效等。
我们的研发经理（总管我们怎个前后端研发团队），他认为这个模式不合理，因为我们之前就一直在赶进度，没去控制质量。而且我们还有好多模块是找第三方公司 去做然后交接到我们手上的，就是有好多历史问题 。
还有好多是因为测试同学 ，测试不够充分，在上线后因为没人使用，导致后面过了有5-6个月才反馈出来的问题。
我们的研发经理认为所有的问题都让我们背锅，那不是谁接的模块多，那么谁就遭殃 吗？然后跟项目经理 大吵一架！
其实针对bug考核每个单位都会有，但是因为他们有完整严格的项目管理流程，然后bug统计出来大家也都是服从的
我们在上家其实也有研发同学 跟测试同学 以及产品经理 争吵过，比如这个问题是需求变更 ，并非bug,但是测试同学认为它就是一个bug。
那么一起来看看我们上家单位中是怎么做一个完整且严格的项目管理吧！
需求评审 -> 研发设计评审 -> UI评审 -> 测试用例评审 -> 研发评估工时 -> 测试评估工时 -> 项目经理确定时间线 -> 开发完成提测 -> 测试完成（UI走查 + BUGFIX） -> 上线交付
需求评审
第一点： 需求评审 前至少2天，产品经理要把需求发出来给研发测试同学查阅，有问题请留言等产品经理答复，或者等需求评审时答复。有需求优化 请留言，由产品经理决策是否采纳。
第二点： 需求宣讲 时一定保证必要参会人员都在测试同学、后端研发、前端研发，以及主审人 （主审人可能是研发经理、部门经理、模块负责人）。如果人员不齐就再约下次会议。
第三点：需求宣讲后 会有参会人对产品经理进行打分。满分10分，平均分低于6分时是要面临打回去 重新评审的！主审人 有一票否决权（主审人低于6分直接打回重新评审），如果是需求宣讲 中的一些小问题，做会议纪要发群里，等会后让产品经理补充至需求文档后告知大家。
第四点：需求文档 一定要细化要做的每一项内容，不能存在一句话的需求。比如那个字段非空等校验，提示语句等等都要有。测试同学在测试阶段会把需求文档 中不存在 项一律归为需求优化 。（这么样就不会有问题是bug还是需求的争议了）
设计评审
这块主要是针对前后端研发的设计评审，如果是简单的小模块功能逻辑可以跳过这个阶段，但是对于新 的模块，需要有设计评审 。
前后端同学在完成需求评审后，需要评估工时 发到研发群里面，以及需要对本次需求进行一个设计文档的编写。
针对后端一定要做好每一个逻辑的处理，精确到每个字段的类型，枚举的值、以及逻辑判断，流程的运转。
前端研发 做的设计评审不是很多，一般针对特殊的功能逻辑才需求，比如图谱的技术选型等等
第一点：保证模块研发人都在（前后端 + 测试 + 主审人）
第二点：提前2天发出 设计文档，各个角色查阅，有问题提前留言
第三点：设计评审完成打分机制（如需求评审样）
UI 评审
UI评审一般是产品经理拉着前端开发 过一下设计稿，看下设计稿是否对开发上有什么问题，以及提供的图标资源等确认。又或者有些好的展现形式的沟通优化。 过完后需要发到研发群里，再给领导查阅一遍，确认是否还要整改。
测试评审
在完成需求评审 后，测试同学要评估工时 提测周期，也就是测试同学要在研发开发阶段 完成测试用例 编写以及测试评审 。如果有着急的项目可以跳过测试评审，但是测试工时是要有的。
第一点：保证模块研发人都在（前后端 + 测试 + 主审人）
第二点：提前2天发出 测试用例，各个角色查阅，有问题提前留言
第三点：测试评审完成打分机制（如需求评审样）
不同点就是测试需要定义好冒烟测试 内容，如果在提测后不满足冒烟测试的用例 ，会被打回去重新提测的。
工时评估，定义研发周期时间
针对研发同学的任务评估不能单个任务大于2天 ，复杂的任务模块请做好任务拆分。前端、后端、测试同学评估后工时后同步到研发群 里，由项目经理做为信息汇总定义研发时间线，约定好提测时间 ，约定好上线时间 。
如果有问题正常顺延，比如研发同学没有经过充分的测试就提测了，被测试同学打回了。这其中的延期时间会重新定制在顺延 的。
因为开发质量被测试打回 很严重 ，每次复盘会都会说这个问题的，我们平均1 - 2 个月会复盘一次。
这里再着重说下，好多同学会说，因为我们在测试中才发现逻辑流程问题，经过跟产品经理协商要怎么怎么样整改，导致本次迭代不能按期交付。
如果说我们需求评审、设计评审、测试用例评审，都没发现这个逻辑漏洞的话，我觉得他可能问题不算很大，如果是小改动可以测试阶段给改了，如果成本很大，可以先放下一期的需求池中。
还有人会说了如果我们经过了需求评审、设计评审、测试用例评审都没发现这个逻辑漏洞，要想本次的功能上线，需要很大的成本去弥补，要延期。那你们应该看下是那个环节出了问题，是不是研发同学不够专业引起的。
测试阶段
研发开发完成后，按期发提测邮件（抄送给部门经理、直属领导、项目经理等参与研发的同学），邮件里面需要有测试范围，以及环境，账号准备等等内容
冒烟测试 通过，由测试同学发回复邮件，继续测试。
一轮测试完成 后，由测试同学发邮件，内容大致就是提了多少问题，以及下轮研发需要提测 的时间，以及是不是按期完成测试，有风险提前暴漏。
-
P1 级别一般都是阻塞测试的bug，需要必须立刻修复发版（比如界面级别的异常，再者后端服务问题，没办法继续测试，）。P1级别的bug我们会在复盘会议上分析，看到底是哪里的问题
-
p2 级别的bug, 第一轮测试可以晚一天修复，第二轮提测后，必须当天修复。
-
P3 级别的bug，一般都是样式，或者字段映射错误等情况，可以延迟修复。
-
p4 级别的bug, 一般是提示语句或者文字错误，可以延迟修复。
-
需求优化 在测试过程中发现需求文档中没有，需要优化的地方，由产品经理 决策是否放在本期更改。如果改动成本过大 ，也是由产品经理决策是否跟项目经理沟通顺延。
修复bug阶段，需要各位研发同学修改完后进行充分自测，避免重新打开，如果重新打开的次数过高，也会在月度复盘会议上总结。
历史bug 问题，我们因为用的是jira管理的项目，所以之前的单子都是有追踪的，可以看到当时情况下为什么没修复，又或者能看到责任人是谁。可以向他们了解下背景。
遗留bug 这里着重说下因为着急发版本，有些P3 + p4级别的延后修改，一定要放在下个版本中修改，不能作为遗留就不管了。
UI走查
UI走查 是设计同学 对开发还原度的考察，会在提测 2轮 ，或者要上线前2天进行。然后交由前端同学重新整改完成后发版本。
总结
我觉得如果严格执行以上的项目管理机制，应该可以避免很多问题。
应该有好多公司都是领导给时间线，然后倒排时间的，其实这种我们很多时候也是这个样子的。我们会这样做：
这种可以节省掉测试用例评审、设计评审，甚至UI设计，编写需求文档。领导的意思项目要保证发版的时机，抢先发版可以站住市场。
或者是一些需要紧急演示 的需求，这种我们会让产品经理出原型，然后由产品经理已原型对我们（前后端+测试同学）需求分析，最后决策出技术方案，最后在压缩研发时间以及测试时间保证发版。
但是我们这种也不是说不要质量了，可能会存在一些P3、P4 不做修复，进行上线，就是我们问题肯定是都给暴漏了，由产品经理决策为了保证时间线发版本，延期修复（留作下个版本在改）
为了保障交付时间，咱们应该有个好的完整的项目管理方案。以上是我上家单位的经验，大家可以参考。