V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
lagoon
V2EX  ›  职场话题

产品究竟该归属开发部,还是业务部

  •  
  •   lagoon · 2021-11-22 16:53:38 +08:00 · 2584 次点击
    这是一个创建于 1096 天前的主题,其中的信息可能已经有所发展或是发生改变。

    做傻瓜需求,无所谓归属哪里。

    产品归属技术部

    业务部肯定不配合需求调研,做好了,业绩是开发部的,但耗时是自己的。
    这点在复杂的业务时特别明显。
    以至于产品没办法整理好需求,需求设计的很有问题。
    对业务部门来说,反正出了问题是技术部没设计好没做好。

    产品归属业务部

    业务部门自行提出需求,交给开发部开发。
    坏处似乎是,比较费产品?万一需求零散?
    如果有 n 个业务部,大家都有自己的小需求,怎么办。

    好奇大家的公司是怎么样的。

    24 条回复    2021-11-24 12:51:05 +08:00
    belin520
        1
    belin520  
       2021-11-22 17:00:20 +08:00
    产品和测试都属于研发技术部门
    Jooooooooo
        2
    Jooooooooo  
       2021-11-22 17:10:20 +08:00
    产研应该是一体的
    lagoon
        3
    lagoon  
    OP
       2021-11-22 17:16:29 +08:00
    @belin520
    @Jooooooooo
    一体的话,就出现了上面说的问题。
    belin520
        4
    belin520  
       2021-11-22 17:23:49 +08:00
    那就说明你总结的内容的团队没有做好团队管理,不过就没有完美的团队,一旦大了,但是产研测应该是一体的
    dunn
        5
    dunn  
       2021-11-22 17:25:53 +08:00 via iPhone
    我们是放在业务部门的 因为我们是业务导向的
    pm 负责整理内部需求和研发对接
    hjw45611
        6
    hjw45611  
       2021-11-22 17:26:01 +08:00   ❤️ 2
    产品不成熟归开发部,产品成熟归业务部
    wellsc
        7
    wellsc  
       2021-11-22 17:28:39 +08:00
    产研一体
    ysp123
        8
    ysp123  
       2021-11-22 17:33:39 +08:00
    我觉得应该分情况吧,业务的产品应该靠近业务,数据的产品应该靠近研发
    defage
        9
    defage  
       2021-11-22 17:42:00 +08:00
    分阶段的,如果说一个企业在某个阶段的信息化落后很多,业务甚至从上层分解到了要信息化的指标,这种归业务一起会更有战斗力。这阶段完了之后进入价值提升期,就需要重新审视一下业务是不是在瞎 jb 提需求,缺乏系统性思维,缺乏价值思维,那可能做一定区分比较好。 而且项目都归拢在产研会有利于产研资源的共享
    xiaowei7777
        10
    xiaowei7777  
       2021-11-22 17:46:29 +08:00
    为啥不是单独一个部门
    neutrinos
        11
    neutrinos  
       2021-11-22 17:58:24 +08:00 via iPhone
    产品是业务部门和工程团队对接的 API ,产品不是开发的包工头
    Vegetable
        12
    Vegetable  
       2021-11-22 18:14:24 +08:00
    告诉你一个秘密:产品经理的主要职责之一,就是将业务需求转变为产品需求
    wudaye
        13
    wudaye  
       2021-11-22 18:16:27 +08:00
    这楼歪得呀都没法看了,都在扯产研一体,帖主说的是业务部门啊,跟产品部门有啥关系?产品和研发都是业务部的支撑部门
    kop1989
        14
    kop1989  
       2021-11-22 18:17:53 +08:00
    产品经理不就是用来干这个的么(梳理业务需求,转化为有可行性的开发需求)?否则你想让产品经理天天做什么?凭空想需求来难为开发?
    lagoon
        15
    lagoon  
    OP
       2021-11-22 18:29:06 +08:00
    @Vegetable
    @kop1989

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

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


    甚至不需要不配合,就是不积极配合,这玩意就要垮,最后设计的肯定有问题。
    lagoon
        16
    lagoon  
    OP
       2021-11-22 18:29:41 +08:00
    如果说做一个场景的 app ,没问题
    =
    如果说做一个常见的 项目 ,没问题
    hefish
        17
    hefish  
       2021-11-22 18:35:25 +08:00
    这得看是业务部强势,还是技术部强势。 谁强势归谁。
    kop1989
        18
    kop1989  
       2021-11-22 18:35:52 +08:00
    @lagoon #15 这就是展现产品功力和价值的时候。
    一个优秀的产品,其实他 /她就是要八面玲珑。
    1 、要懂业务口到底要什么。(业务口的表达未见得是其真正想要的,也即便是,也未见得是其问题核心)
    2 、要合理预计实现这个业务的成本到底是多少。(反例:本来业务口解决这个事儿需要一个人力,结果算上开发成本变成俩人力了)
    3 、要合理预测开发难度和工期。(反例:人家业务口双十一要做活动,结果第二年春节上线了)
    4 、要合理设计功能逻辑。(反例:需求、实现、deadline 什么都对,就是太难用,业务口用不起来)
    kop1989
        19
    kop1989  
       2021-11-22 18:37:48 +08:00
    5 、还要有一定的业务理解,能够反客为主。靠产品推进业务。(业务口需求没下来的时候,你不能让开发天天嗑瓜子)
    kiotech
        20
    kiotech  
       2021-11-22 18:40:00 +08:00
    ”产品“属于”产品部“
    raaaaaar
        21
    raaaaaar  
       2021-11-22 18:40:01 +08:00 via Android
    敏捷不是要产品和研发坐在一起么
    zhaodong
        22
    zhaodong  
       2021-11-22 18:58:07 +08:00
    一般情况下产品与研发 都应该归入业务线,为业务服务的,否则一定会出现两者负责指标不同,产生矛盾与内耗,不利于实际业务迭代。

    产研结合,与业务独立划分这种情况,多是中台或者后端部门,本身离业务线较远,变动频次低,对业务影响相对较小。即使这种形态,中间也会有相应的业务产品进行协调对接,以满足实际需求。
    zhaodong
        23
    zhaodong  
       2021-11-22 19:00:59 +08:00
    @zhaodong 根本原因在于,要保证产品能理解业务,深入业务,才能做好需求,形成三个群体的合力。
    cqcn1991
        24
    cqcn1991  
       2021-11-24 12:51:05 +08:00 via Android
    这个问题很经典。但是这个问法不太对。。。
    一两句话讲不清楚,具体看 Marty cagan 的 empowered 会有所了解
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2825 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 07:13 · PVG 15:13 · LAX 23:13 · JFK 02:13
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.