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

[请教] 关于程序员与产品经理的恩恩怨怨 进来聊聊

  •  1
     
  •   willzzz · 2023-10-10 09:25:13 +08:00 · 2317 次点击
    这是一个创建于 433 天前的主题,其中的信息可能已经有所发展或是发生改变。

    兄弟们大家好,先讲下背景:

    本人产品岗位(但为了更好的推动工作,自学了 PHP 、JAVA 等,按我们公司的程序员来说我这说明找个初级程序员工作应该没问题)

    目前本人负责公司的产品团队(大概 20 多人)

    近期研发团队提出了一些对产品的问题,产品经理的需求文档规范问题:

    这个问题老生常谈了,我们最初的时候是产品经理提供 PRD 的方式= 需求文档说明书:包含需求背景介绍、需求业务逻辑、需求流程图、前后台 UE 截图及文字说明 需求 UE:axure 版本的原型图,原型图内仅体现交互说明,没有需求说明。 现在问题:技术反馈 [产品经理的需求文档动辄上万字,与原型图对比看的太累了,希望可以把需求直接写到原型图上,方便开发人员查看]

    其实站在产品的角度按这种方式 UE+需求一起通过 Axure 输出是没问题的,但是这样对于后续需求发生修改、变动、以及与运营团队、外部客户交付的时候会不太方便(我们公司也行业输出,因此对外部会有交付),使用文档的方式直接本地文件即可,使用 axure 要生成 html 文件,对于普通运营来说有一定门槛。

    以上。想请教下程序员大佬们,你们在与产品经理协同的方式是怎样的?是文档+UE ,还是 UE 内直接体现需求说明的呀?

    其实在我看来,如果哪种方式都是一个形式,重点是产品与研发的协同效率得到提升即可,达成一致即可。

    27 条回复    2023-10-13 12:20:36 +08:00
    Amekumo
        1
    Amekumo  
       2023-10-10 09:31:11 +08:00 via Android
    产品路过,现在写需求基本只提供原型了,有什么说明页放在原型上了,后续更新只要复制粘贴一个新的页面写好版本号就好。Axure 可以发布到云端啊。
    willzzz
        2
    willzzz  
    OP
       2023-10-10 09:33:34 +08:00
    @Amekumo 都没有文档了么?你们公司都是这种方式嘛?前后端的所有需求都是在 axure 啦?
    haozxuan001
        3
    haozxuan001  
       2023-10-10 09:51:58 +08:00
    其实,你最终已经总结出来了, [不管哪种方式,达成一致是核心] ,但这个说起来简单,就像站在研发角度应该写单测一样的,但这个应该需要建立在一定的基础上,既然你负责产品团队 20 人,想必管理能力也是有一定自己的沉淀;从我个人角度(研发)看,研发强势的公司,那就按照研发的逻辑来,反之则是产品,毕竟哪有你也开心,我也开心的局面,都是在侵害对方利益的事情,没有 happy ending 的

    PS:最后肯定下,会画 PRD ,把需求写在里面的产品是真的受研发欢迎,毕竟单产品输出时没办法交付给老板项目的,最终是以研发的实现成果作为最终交付产物;
    iOCZ
        4
    iOCZ  
       2023-10-10 09:55:23 +08:00
    不可能单一输出,根据你面向的群体,输出对应的文档。难道你文档更新了,设计稿不更新,肯定要做版本管理。
    GoopleXD
        5
    GoopleXD  
       2023-10-10 09:55:50 +08:00
    我也是产品 , 多年跟开发合作下来发现 , 他们从来懒得看需求文档 , 文档写长篇大论也被吐槽 , 文档不写人家也吐槽
    现在想开了 , 我连原型都懒得画 , 直接在线 markdown 抽象描述业务问题和对业务思考的具体实现
    小团队相安无事
    8355
        6
    8355  
       2023-10-10 10:01:09 +08:00
    研发更关注的是你想实现什么功能,并不关注你的背景,背景本身也许很重要但是你只需要开会讲清楚即可,需求文档需要看很多次,大篇幅的文档再多次观看的时候很难找到重点,写在 axure 图上框框一拉标红即可。文字可以从你的文档中复制粘贴,并不耗费你很多时间。
    dz5362
        7
    dz5362  
       2023-10-10 10:14:05 +08:00
    原型上直接写需求,然后更新后标注一下,可以用版本号、新页面或者标红即可,我现在也是懒得写文档,觉得不直观
    tabris17
        8
    tabris17  
       2023-10-10 10:16:54 +08:00
    你把用户文档当产品文档给开发?开什么玩笑
    idolud
        9
    idolud  
       2023-10-10 10:30:19 +08:00
    对外部客户(非开发人员)提供文档+UE 等等,对开发人员直接 UE 内直接体现需求说明
    yagamil
        10
    yagamil  
       2023-10-10 10:48:40 +08:00
    适合的沟通频率. 例会.

    太频繁了, 开发会觉得你在催促.

    不沟通, 开发到后面偏离里轨道, 这个时候返工也是浪费了精力.

    越来越发现这工作不好当.
    willzzz
        11
    willzzz  
    OP
       2023-10-10 11:15:31 +08:00
    @tabris17 很怀疑你的阅读理解能力
    willzzz
        12
    willzzz  
    OP
       2023-10-10 11:15:46 +08:00
    @yagamil 哈哈哈啊哈哈
    zjuster
        13
    zjuster  
       2023-10-10 11:18:11 +08:00
    我的工作方式:
    1. Axure 上原型只做框架图,不做交互。 交互还需要程序员前后端 2 个人分别去尝试,特别容易漏需求。
    2. Axure 上原型全部用引导线说明这个按键的交互逻辑,核心的要点全部列原型图上,重点的需要全部标强调(红色、蓝色,最好有一套约定俗成的颜色语言)
    3. 如果是改版,小改动直接标记所有改动点,大改动直接重新另外画页面(因为前后端接口大概率要重写)
    4. 原型文档另外准备。这个文档是我在画图前就准备好的,是为了帮助自己管理产品思路和迭代,以及核心的功能路程图、业务流程图。 这个文档的主要用户是业务方,给业务方讲解,然后评审的时候,技术也要看这个文档的出技术需求书的。
    最后技术实现的过程是对着原型和原型说明一个一个做的,不会去反复查文档。
    我们的测试比较辛苦,文档和原型要一一对照的。

    如果开发过程需求不变更,我们只开三次会:
    1. 需求评审会,根据文档讲业务流程,根据原型讲改动点。
    2. 技术评审会,技术出技术方案,技术接口改。
    3. 测试用例评审,过图和文档。
    zjuster
        14
    zjuster  
       2023-10-10 11:21:24 +08:00
    合作多了哪个开发的性格如何也就比较清楚了。

    比较马虎的我会单独顶住他一个 list ,别漏了功能。
    比较仔细的我就直接问他什么时候上测试环境,让我验收。
    willzzz
        15
    willzzz  
    OP
       2023-10-10 11:25:35 +08:00
    @zjuster #13 我认为这是比较符合常规的产研协同的流程。我们现在也是类似的方式,但是程序员团队有些新招的 或者是外部来的 带来一些新想法 然后大家(研发团队)就觉得很好,就开始提各种各样的要求。
    Amekumo
        16
    Amekumo  
       2023-10-10 13:30:42 +08:00
    @willzzz 后端的我个人因为比较懒,直接写完了之后放到 Axure 去了
    yueye115
        17
    yueye115  
       2023-10-10 13:41:49 +08:00
    版本管理是必须的,每次改动标明改动了什么,没人想去做校对。做好版本管理,即便写在文档里也能接受的,当然画在图上更直观
    cnhongwei
        18
    cnhongwei  
       2023-10-10 13:43:52 +08:00
    和你的产品类型有关吧。比如滴滴类的,就一个打车按钮,后端要实现的东西就多了,在原型图上怎么说得清楚。如果大部分业务在原型图上能说清楚,我感觉直接在原型图上说明就行了。
    jones2000
        19
    jones2000  
       2023-10-10 16:23:09 +08:00
    @GoopleXD 需求文档都是开发组长看, 然后他在切分模块下派任务, 下派任务的会写更详细的说明和技术实现路径等等。产品的文档只能算是原始文档了, 下面的人一般不会看原始文档。。组长这层在了解需求和构架的时候会跟产品沟通,把大的问题了解清楚在开搞。
    GoopleXD
        20
    GoopleXD  
       2023-10-10 18:40:04 +08:00
    @jones2000 我感觉我兼了这个开发组长........
    horizon
        21
    horizon  
       2023-10-10 18:54:25 +08:00
    上万字?什么行业
    darkengine
        22
    darkengine  
       2023-10-10 22:05:57 +08:00
    我们出设计文档 + 需求给开发用.
    xingming123
        23
    xingming123  
       2023-10-10 23:45:21 +08:00
    都改成用在线协同的工具会好很多,我司用 figma+notion ,原型和文档也是分开的,但是因为是在线的,修改起来比较方便。
    另外,产品文档到了上万字,我猜是没做好版本管理,或者产品写的太啰嗦
    cssTheGreatest
        24
    cssTheGreatest  
       2023-10-11 13:21:51 +08:00
    我们的产品以前会给出一份几页的文档(面向开发供应商,也就是外包)
    后来我们来了之后加上和设计师的磨合,改成在 figma 设计稿上标注需求描述就搞定了。文档唯一、实时更新、协作性基本都能满足。
    willzzz
        25
    willzzz  
    OP
       2023-10-13 12:18:30 +08:00
    @horizon 零售数字化行业,涉及 tob erp scrm ,还有一堆 toc 的
    willzzz
        26
    willzzz  
    OP
       2023-10-13 12:20:06 +08:00
    @xingming123 也不是啰嗦 我们一般是前后端一起的,我们要求是 功能背景、价值、业务场景、解决什么问题 这些必须要有。然后就是需求的业务流程、功能涉及多系统流程图、前后端的字段说明 逻辑说明等等。甚至还有涉及 open API 的字段说明等等。随随便便上万字了。
    willzzz
        27
    willzzz  
    OP
       2023-10-13 12:20:36 +08:00
    @willzzz #26 当然可能技术不看,但是我们要求必须要有。同时技术团队要求做功能前必须要了解背景 价值 等等。
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2891 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 27ms · UTC 13:01 · PVG 21:01 · LAX 05:01 · JFK 08:01
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.