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

[sunjourney]

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

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

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

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

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

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

[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 到开发手里也可能会出现折扣。