为什么现在的开发流程是产品对接开发，开发对接测试，而不是产品对接测试、测试对接开发？

[sunjourney]

现有的开发流程中，显著问题是：

1. 产品无法理解技术难点，对产品有第一份理解
2. 开发无法理解需求文档，对产品有第二份理解
3. 验收阶段，测试加入，产生第三份理解

开发人员对需求无法掌握的点：一些模糊的需求、没有考虑足够的情况、功能冲突。需求文档实质应该是一份伪代码，覆盖足够多的分支

测试人员一定程度又扮演了产品的角色，除了反馈报告，开发回头又要补丁式的修改，还会对项目提出功能上的修改要求，回归测试可能要发生多次。

既然这样，开发为什么不是 产品直接对接测试，由测试出 spec，交付开发人员，在这个模式中测试人员完全有能力把产品中模糊的需求点校正，没有涉及的点覆盖，并且一份明确的 spec 对开发来说，大大减轻开发负担。不能说对三份理解降低成了一份理解，但三份理解通过 spec 可以取得较为一致的统一。

开发总是吐槽需求文档的问题，那么由专业的测试人士把需求变为 spec，开发做 TDD，PRD -> SPEC -> 实现 是否一种更好的模式？

[FrankHB]

测试出 spec ……既当运动员又当裁判？

[lofbat]

在整个项目流程中，都应当是产品，开发，测试三者同时参与

[nolest]

产品无法理解技术难点
开发无法理解需求文档
这不都是产品的锅吗？为什么要一整个团队来分担？

[ww980624]

所以貌似一个正常、标准且合格的项目要有测试的介入吧应该？还有我接触了解到的测试除去代码外还需要对文档类的进行测试...只是个学生，不清楚真正的情况...

[sunjourney]

@nolest #3 这种锅可以理解为无解问题。如果有哪个公司可以做到产品与开发完全契合请告诉我去投简历

[luozic]

产品自己知识水平不行，那还有别的招，你以为中国的产品和美国产品一样个个 mba 技术通才

[sunjourney]

@lofbat #2 大部分情况是测试要对接多个团队和项目的需求，都是在验收阶段介入，他们无法跟上整个开发周期（因为可能时间较长，期间也没有具体可干的事情）。这个情况可以理解为现状，如果你的公司的模式更好，可以说说。

[sunjourney]

@luozic #6 哈哈，之前接触过谷歌 AMP 线上的产品，真是技术大牛

[woshiaha]

对测试要求有点高。。。而且按你这个流程为啥不产品测试开发三方一起在初期参与讨论呢

[jeffc]

产品出 PRD 后，交给测试去写测试用例，看有哪些路径遗漏的再补充完善，最后再给研发，比较靠谱。个人实际体验。

[liuhuansir]

@woshiaha 初期的讨论不可能涉及到所有细节，开发经常做到一半，发现需求有缺陷，甚至有矛盾的地方，这就是我这边的现状

[StephenHe]

开发怎么就没法理解需求文档了。。。

[RorschachZZZ]

所以现在对开发要求比较高，除了技术到位，沟通协调能力也要强

[sunjourney]

@liuhuansir #11 是的，立项、讨论的环节都是产品主导，也是早早酝酿的，开发是新接触项目，短期意识不到有什么问题，但开发一段时间后就经常发现细节与产品冲突，掌握和要关心细节会猛然多于产品，各种不合理的地方都突现了。测试这方面是长于开发的

[zdnyp]

不把运营当人（狗头

[janus77]

测试不需要理解需求本身的合理和设计点，只需要保证需求正常运行。

[sunjourney]

@StephenHe #12 你见过那种只列 happy path 的产品吗？开发最头痛的就是错误要如何处理。

[pimin]

一千个读者眼中就会有一千个哈姆雷特

最好让用户来当产品,让用户来开发,让用户来测试

[sdushn]

@sunjourney 请去谷歌微软英伟达试一下，多数产品经理都是有数年开发经验的，国内互联网企业普遍降低了产品经理的要求，地位及薪资，导致很多人都是技术不达标找不到开发类工作才去当产品，所以这个问题才无解的

[x7395759]

完全不需要除了程序员以外的其他人。