产品和测试都属于研发技术部门

产研应该是一体的

@belin520
@Jooooooooo
一体的话，就出现了上面说的问题。

那就说明你总结的内容的团队没有做好团队管理，不过就没有完美的团队，一旦大了，但是产研测应该是一体的

我们是放在业务部门的 因为我们是业务导向的
pm 负责整理内部需求和研发对接

产品不成熟归开发部，产品成熟归业务部

我觉得应该分情况吧，业务的产品应该靠近业务，数据的产品应该靠近研发

分阶段的，如果说一个企业在某个阶段的信息化落后很多，业务甚至从上层分解到了要信息化的指标，这种归业务一起会更有战斗力。这阶段完了之后进入价值提升期，就需要重新审视一下业务是不是在瞎 jb 提需求，缺乏系统性思维，缺乏价值思维，那可能做一定区分比较好。 而且项目都归拢在产研会有利于产研资源的共享

为啥不是单独一个部门

产品是业务部门和工程团队对接的 API ，产品不是开发的包工头

告诉你一个秘密：产品经理的主要职责之一，就是将业务需求转变为产品需求

这楼歪得呀都没法看了，都在扯产研一体，帖主说的是业务部门啊，跟产品部门有啥关系？产品和研发都是业务部的支撑部门

产品经理不就是用来干这个的么（梳理业务需求，转化为有可行性的开发需求）？否则你想让产品经理天天做什么？凭空想需求来难为开发？

@Vegetable
@kop1989

产品确实就是做这个的。但产品归属开发部门，也确实存在我说的问题。

如果说做一个场景的 app ，没问题。
有些业务复杂，非专业的人根本不知道是什么流程的玩意，这种产品归属开发部，就出现了业务部门不配合的问题。


甚至不需要不配合，就是不积极配合，这玩意就要垮，最后设计的肯定有问题。

如果说做一个场景的 app ，没问题
=
如果说做一个常见的 项目 ，没问题

这得看是业务部强势，还是技术部强势。 谁强势归谁。

@lagoon #15 这就是展现产品功力和价值的时候。
一个优秀的产品，其实他 /她就是要八面玲珑。
1 、要懂业务口到底要什么。（业务口的表达未见得是其真正想要的，也即便是，也未见得是其问题核心）
2 、要合理预计实现这个业务的成本到底是多少。（反例：本来业务口解决这个事儿需要一个人力，结果算上开发成本变成俩人力了）
3 、要合理预测开发难度和工期。（反例：人家业务口双十一要做活动，结果第二年春节上线了）
4 、要合理设计功能逻辑。（反例：需求、实现、deadline 什么都对，就是太难用，业务口用不起来）

5 、还要有一定的业务理解，能够反客为主。靠产品推进业务。（业务口需求没下来的时候，你不能让开发天天嗑瓜子）

”产品“属于”产品部“

敏捷不是要产品和研发坐在一起么

一般情况下产品与研发 都应该归入业务线，为业务服务的，否则一定会出现两者负责指标不同，产生矛盾与内耗，不利于实际业务迭代。

产研结合，与业务独立划分这种情况，多是中台或者后端部门，本身离业务线较远，变动频次低，对业务影响相对较小。即使这种形态，中间也会有相应的业务产品进行协调对接，以满足实际需求。

@zhaodong 根本原因在于，要保证产品能理解业务，深入业务，才能做好需求，形成三个群体的合力。

这个问题很经典。但是这个问法不太对。。。
一两句话讲不清楚，具体看 Marty cagan 的 empowered 会有所了解