标签：进度 宣讲 验证 处理 三方 也会 联系 敏捷开发 详细设计
老生常谈的一个话题：增速提效！
确实，现在面试的时候，偶尔会有人问起。及时平时，项目经理、产品经理、前后端研发，也会说上一嘴。不过自己也会经常琢磨，想着想着就笑了……
不管之前的瀑布流式开发，还是现在的敏捷开发，每个大小项目，要经过的环节就那么多。再想压缩，都有很多人踩坑，并且付出"血淋漓"教训的。
通常的项目流程是什么样？
产品收集需求 --> 需求宣讲 --> 概要/详细设计 --> 测试用例评审/开发 --> 测试/改bug --> 产品验收 --> 上线验证
一般什么时候开始有人关注项目的时间呢？需求宣讲完！甚至见过很多需求讲完，就问啥时候能上线，就要几号几号上线的也不少。
需求宣讲之后，到上线完成期间，与项目联系最紧密的跑不了三方：产品、研发、测试。
讲的直白一点：现在三方对项目的进度都有影响，那么是不是可以粗略（确实很粗）计算下，每一方占比1/3。
如果你想要一个项目提前3天上线，只是压缩其中一方的3天时间，结果就三种：①直接辞职走人；②一大堆线上问题，又缝缝补补一周；③线上一大堆问题，同时离职走人了。
每一方都适当的提升点效率，还是很有希望的，同时质量没准也好了呢。
作为测试的我，开始评估3天还是5天，肯定有我的原因，绝对不会故意拖沓。如果压半天，可以让产品跟着我们最后一轮测试，同步进行验收测试，但其间可能会有个别问题。
无缘无故压缩我的测试时间，第一我肯定不能接受，第二我会尽量保证质量，但时间短造成的风险，我肯定不会承担。
啥？24小时测试！要脸不？？？
我对提高效率和提高质量的想法有些类似，大家的关注点肯定不是一个小组、一个部门，而是这个项目什么时候能交付给需求方使用。
那何尝不是大家一起需要努力的呢？
产品经理需求出的仔细点，别老让我们测试追着屁股后面，细化一条条规则；
前后端研发需求理解的全貌点，我们测试用例评审时候认真听点，提测后质量肯定不会差；
测试前数据准备的充足点，测试依赖都提前处理，尽早抛出问题，尽早验证。
增速提效是好事，但有些人的关注点是不是该换换了？脑子可以好使，但要用对地方！
标签：进度 宣讲 验证 处理 三方 也会 联系 敏捷开发 详细设计
原文地址：https://www.cnblogs.com/yunren/p/14284580.html
