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

[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]

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

[chipmuck]

对于开发来说，现在接触到的产品在需求阶段最显著的问题是，边际条件的处理（处理错误、空值、初始化状态等）。通常产品只会在 PRD 中详尽描述完美场景，而极大忽略了以上的内容，导致开发产出的结果可能偏离了产品的预期（开发如果不询问产品，就只能按照一般用户使用竞品的角度来开发了），极大地降低了效率。

我感觉这是经常会遇到，而且比较严重的问题了。

[exploreXin]

没有垃圾岗位，只有垃圾员工，产品不懂技术，只能说明国内产业还不规范，Google 招聘招聘经理有一条硬性规定就是必须懂技术。技术人员不懂需求也只能说自己没有注重培养产品思维。现在大公司都在招聘全栈工程师，我和许多大小公司的负责人聊过，其中有一个某大厂出来在创业公司当技术负责人的传说有 30 年 Java 编程经验的工程师，对方说全栈就是前端后端数据库运维一锅端。听完我很诧异，连大厂的人都鲜有明白全栈的本质，也不奇怪小公司天天跟风喊着招全栈了。

全栈不是一个岗位，全栈是一种思维，一种站在全局看问题的思维。与全栈相对的是另一种我们常见的思维，就是我不管你需求是什么，你原型图就是这么弄得，我已经做完了，这锅我不背！这就是非全栈思维。这样的情况再加上国内产业不规范，人员技能不过硬，干产品的许多是干不了技术才干的产品，产品工资多高啊，干什么技术。干技术的就只会技术，不想拓展其他技能。这样断层的两种思维，交流过程中会产生剧烈的碰撞与摩擦，产品与技术的撕逼行为，也就难以避免了。

大厂招聘全栈的目的是消除沟通断层，也就是我规划产品，我会知道怎么避免技术实现的时候会出现很困难的情况，产品会稍微变通一下，实现相同的功能，但是技术实现会容易许多，这样也就不会出现产品想实现根据用户心情改变手机壳颜色的需求了。同样的，技术也会在不影响产品大方向的情况下，反馈技术难点，贡献自己的产品意见。要知道，一个团队凑在一起，最终目的是要做出符合市场的产品，而不是互相扯皮推脱。产品的命令是天条吗？产品说的就不能改吗？技术就那么难实现吗？学点新技术看看能不能实现不行吗？如果大家一开始就是剑拔弩张的状态，局面就不可收拾了。

有问题一起商量解决才是最好的方式。但真实生活中是产品被领导狠命的催进度，为了保住自己的工作，不得不牺牲沟通时间，去催自己的下游岗位，这时候技术也同样为了保住工作，会死命的与产品撕逼，从而拼命试图砍掉需求。所以这样的团队一开始就失败了，团队里没有谁会胜利，只会互相敌对，一起坠入深渊。

所以如果大家都能站在全局看问题，产品经理明白需求改了不会影响自己提出的功能，技术也明白怎么反馈产品经理意见能够减少自己的工作又不影响自己，那么大家的日子就都好过了。

所以全栈是一种思维，不是一个岗位，那种小公司想要招会前端后端，数据库，服务器，运维测试，最好还能客串一下售后技术支持的老板，根本不是想招全栈，他想招的是“全干工程师”，用一个岗位的钱招做几个岗位工作的员工，这样的风气在国内创业公司屡见不鲜，这种公司里面，员工没有办法术业专攻不说，长期高强度的工作还会损害自身健康，公司也不会有什么大的进展。老板的无知与自己为是，最终只能害人害己。

对于这种情况，除了全栈，还需要行业的规范。要明白，不是你只能干产品，而应该是你喜欢干产品，所以才选择了产品，相同的，技术岗位也是一样，要明白你可以干除了技术以外的工作，只是因为分工不同，所以你才干了技术。行业规范例如，产品岗位的人员都要有相关系统化规范化的培训，技术人员也要有相关的培养机制。这是一个周期相当长的过程，国家也在努力逐步规范行业，相信今后总会有一天，我们会把大多数精力用在工作上，而不是与同事互相撕逼，在痛苦与挣扎中度过。

[xuanbg]

我司没有什么对接不对接的，产品、开发、测试都在一起搅基。大家在一起非常融洽地吵架，开发过程很是和谐高效呢。

[chaixiaomu]

之前看 [二爷鉴书] 说到产品经理的职责是「让正确的事相继发生」。

工程师不理解需求，我们不论是画图、写文档、做原型还是直接表演给他们看，一定要弄到他们理解需求为止;合作伙伴不配合，我们不论是威逼还是利诱，拍桌子红脸还是跪在地下磕响头，一定要弄到他们配合为止;老板不支持，那我们就用最小的代价和完整的逻辑证明你的观点，说服他，没日没夜地说服他，厕所里堵住他说服他，电梯里拖住他说服他，满地打滚，以头抢地，把刀架在自己脖子上说服他
......

「让正确的事情相继发生」，就是产品经理的全部工作，如果在这个过程中需要懂技术，就去学技术，需要懂交互，就去学交互，需要懂画图，就去学画图，需要懂公开演讲，就去学公开演讲，需要懂 XX，就去学 XX。团队中，谁都可以说这不是我的职责范围，只有产品经理不行。

[jiang1597841]

产品连需求背景 业务场景都不能完全了解，写出的文档可想而知

[codingKingKong]

@chipmuck #21 赞同, 有的时候产品还会说出类似: 用户怎么会那么干呢... 以及这怎么可能会发生呢...

[yoke123]

现阶段无解 只能慢慢熬 熬到大家整体水平都提上来为止

[lfmy]

现在的开发既做产品，也做测试。。。。不知道是不是只是国内这样。。

[6260628]

人人平等，别把自己太当回事，开发、产品、测试一样重要，你的意思是你比测试金贵？你是高级工程师必须对接高级产品经理吗

[wanacry]

所以 ddd 就是用来解决这个矛盾的

[qooweds]

"大部分情况是测试要对接多个团队和项目的需求，都是在验收阶段介入"
这是啥年代的测试了?
稍稍复杂一点的产品,测试如果不在需求阶段介入,根本没法保证产品的质量
如果是简单的产品,还要测试干嘛?单元测试跑完,产品验收一下不就完了?

[janxin]

看起来就是每个环节的人都没做好

[index90]

产品经理出故事->故事会->技术评审->测试用例评审->开发一个故事测试一个故事->回顾会

敏捷开发了解一下

[jingyulong]

软件工程中已经有规范的流程了，哪个阶段需要哪些人参与，都讲的很明白。

但是实际开发流程中，大部分人水平不够，乱指挥。

有时候需求不明确，每个开发都不知道要做什么的情况下，还喊着敏捷开发，这明显还需要再深造下。

[guyeu]

国内技术型测试还是少。我觉得楼主这个想法有搞头，希望有公司能实践一下。

[mars0prince]

你们测试人员不参加评审吧？需求评审多叫人，测试、开发、产品、设计，各种人都叫到，所有需求必须落实文档，达不到一致理解不开工，就没啥问题了

[mars0prince]

我们需求评审一次，技术评审一次，基本不存在上述问题，上面的问题主要是评审开的过于草率，产品开发两个人小屋一对就完了

[supuwoerc]

测试 -> 开发
运维 -> 开发
产品 -> 开发
开发激情一喷三 :)

[supuwoerc]

@pimin 妙！实在是妙！

[Chenamy2017]

对测试要求太高，而且测试出的 spec 到开发手里也可能会出现折扣。

[seansong]

从来没觉得存在你说的相互不理解，产品确实可能存在对技术不了解，开发也确实可能会有时候不能马上领会产品的意图，但是可以沟通啊，所有的疑问和不了解，不都是可以在沟通中变得了解么，干了这么多年产品经理，可能是我沟通能力太好吧，你说的问题从来都没出现过

就算是产品不了解技术提出了什么不合理的需求，或者是技术一时间无法领会产品的设计意图，难道就不能相互理解一下么，没有谁是全才，理解是王道

在我的工作历程中，产品经理一直都是需要直接直面设计、开发和测试的，帮助设计师做出漂亮好用的图，向开发传达需求本身以及需求的前世今生，与测试一起分解需求书写测试用例，是我干得太多吗？其实不是，这就是产品经理的基本工作而已。

看了楼主的描述，你说的那些需求描述不清楚、考虑不够周全、容易引起歧义，这些都是产品经理的基本功，所有的产品经理终其一生不就是在不断改进这些点么？换位思考一下，你的代码就考虑多么周全么？你需要别人连代码框架都先给你，也难怪你会这么多抱怨了

[tony9413]

这个是产品质量的要求，三方相互制约。
有时候开发也要多考虑需求是怎么来的，不要一味的敲代码，产品的需求也是从市场来的，这中间也会存在一定的误解，最好的消除办法就是一个人坚固市场，产品，开发，测试的工作，但至今应该还没有这个物种出现。

[testsec]

中国人人都是产品经理

[yufeng0681]

产品无法理解技术难点，那说明开发团队无能，难点都讲不清楚自己为何做不出来，别人是怎么做出来的（产品肯定是看到竞品可以，才有底气说能做出来的）；
开发对含糊需求文档，按照自行理解做，理论上无责，但最好是和产品讨论，并细化；帮助产品把文档写到位，保证一致性；如果一个功能还是多个终端开发，到时候终端一致性就不一样了
测试对需求也产生一种理解，也是因为产品写得不清楚；测试也需要和产品讨论，并喜欢；帮助产品把文档写到位； 写测试用例期间就能发现问题，而不要等着开发结束再说，这样会照成需求变更，返工成本高；
产品不给力，那就前期多评审，多沟通，把这个环节的工作做到位，再进入开发阶段。 不然就会出现返工工作，带来更大的成本损耗；

你的解决方案：由专业的测试人士把需求变为 spec，开发做 TDD，PRD -> SPEC -> 实现
这个角色不是测试，是 SE，开发团队当软件复杂度高的时候，需要抽出 SE 的角色来分析需求，制定实现方案，必须要考虑性能需求，可靠性需求，不在前期设计时就考虑到位，到了开发阶段，大家各做各的，基本上就是裸奔前行，未来用户量上来，出事概率百分百，天天救火，最后痛定思痛，可能就要重构版本了。

[nolest]

换一个真正的产品经理就能解决，不是那种“人人”的产品经理

[liuhuansir]

@yufeng0681 你这个偏向性太明显了吧，产品无法理解技术难点，就一定是开发团队无能？有些产品提出的需求天马行空，但更多的需求不是无法实现，而是改动太大，有点得不偿失，或者说工期不够。你怎么不说产品自己也应该去了解一下技术呢，了解之后就可以避免提出一些脑残的需求，导致浪费大家时间

[sunjourney]

@yufeng0681 #44 数据格式是非常钳制功能的，有的格式定了，有的需求就难点更改，有的需求第一版适合 noSQL，结果第二版又更适合关系型，还有缓存设计的变更，为了特殊功能需要对框架的定制，看似简单的变化对架构设计的影响都非常大，要一一和产品讲吗？对于没有相关技术背景的产品，这个沟通成本非常大，只能回一句做不了。可以简单地断言是开发团队无能吗？认为显示一个 count 有什么难的产品大有人在

[jabin88]

为什么不是开发对产品，产品对测试

[onmyoji]

测试在需求阶段就应该介入了吧

[kpppp]

其实还有一点我觉得作为产品要清楚.一个产品说:为什么支付宝能做成这个样子,而我们不能.为啥 window 系统有这个功能,我们确做不到.你看 iOS 的动画多么丝滑流畅,我们为什么做不到. 对于开发的工程而言,他心里面清楚,你要的所有功能我都给你做了,那我还留在这个小公司里面干嘛?不去 Google 上班,听你一天瞎 BB.

[leisut]

产品是面向程序员编程，开发是需求文档测试 XD

[spritewdx]

@kpppp 这句笑死我了

[Azmaveth]

没有垃圾岗位，只有垃圾员工

我见过研发干不了自己上阵的产品
见过测试没排期自己做测试的产品
见过因为一个研发拖进度一个产品死掉的
见过测试敷衍了事上线出事故的

为什么要有三个岗位？因为这是保证你不出错


末了说一句，现在研发要我布服务器，老板让我导数据，宣讲要我做原型~~~~~~~~~~
而我现在只是个运营~~~~~~~~

[hyy1995]

@kpppp 小公司的通病就是这样。。。

[passerbytiny]

@sdushn #19 其他得都没问题，“多数产品经理都是有数年开发经验的”这一句是信口开河。http://www.chinapm.com.cn/?p=1523

@sunjourney 如果照你说的那么干，看看下面的对话。
产品经理（产品总监）：
小王呀，听说你对我（大张）提的需求有看法，而且还想改一下，你明天去找一下人事吧。

开发：
测试，听说你要写测试代码，太好了我们终于解放了；不过你注意别只做黑盒测试，而且既然是你写测试代码，接口你也自己写吧；哎呀接口你都写好了，我只写实现由啥意思，我准备辞职了。
测试：
不，我们只提前写测试规格，单元测试或测试代码是你们开发干的事。
开发：滚粗，那根之前的测试用例有啥区别，我们并行干就行了，为什么要先等你写完用例我们才能编码。

看出来真正的问题了吗？那就是产品是“领导”。

[sunjourney]

@passerbytiny #55 测试只用写外部接口嘛，内部还得开发上

[AllenW]

因为产品忙着写需求 手动狗头

[xmsz]

... 所以开发者是直接凭空写功能？？？？？

意义上，产品是直接对接所有人，开发及需求方，没有中间者，因为产品就是中间者
流程上，产品先过开发，再配合测试过一次，有问题？

如果开发可以读懂需求，那要产品做什么？
如果，产品无法表述清楚，那很正常。但如果表述错或天方夜谭的需求那就是不专业。

[CoCoMcRee]

我这里的测试， 都分不清 前端页面没数据 是接口问题还是页面问题。。。

[WytheHuang]

就怕测试啥都不懂, 连 SQL 语句和数组都分不清, 开始乱提 Bug. 还有弱智产品经理, 老在测试阶段改需求, 原型和需求完全不一样, 要什么没什么, 写跟狗屎那样. 项目延期还说开发问题, 去怼自己上级领导.

[beingWH]

并行工程 了解一下

[Andyliu123]

@yufeng0681 什么都替产品经理做了，那还要产品经理干什么