V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
rouxi
V2EX  ›  程序员

作为开发怎么提高需求理解能力,需求风险发现能力,需求谈判,以及技术需求文档能力

  •  2
     
  •   rouxi · 352 天前 · 1543 次点击
    这是一个创建于 352 天前的主题,其中的信息可能已经有所发展或是发生改变。
    13 条回复    2023-12-22 10:11:32 +08:00
    gitrebase
        1
    gitrebase  
       352 天前   ❤️ 1
    我感觉我经常听不懂产品对“新需求”的描述……我一度怀疑到底是他们不会描述还是我的理解能力真的不足

    就是有些 pm 就喜欢用自然语言描述一下复杂需求……画个流程图可能就好多了,而且在自然语言中,很难明确一些专业名词和业务实体,对于不熟悉的人是看都看不懂,尤其是在一段话里对某个实体使用多个别名,看得是真的头疼……
    NoOneNoBody
        2
    NoOneNoBody  
       352 天前   ❤️ 1
    你是对接客户还 pm ,或者说你是 pm 还是纯技术
    纯技术只需理解能力就够了,谈判只是为了个人利益,风险发现不干你的事,做到排除歧义就好了,需求文档一般没时间做

    pm 的话,需要很多知识,对接客户首先谈判能力要强,适当拒绝,多以成本为论据,但对方立场肯定是要便宜,别家能低价做,你家觉得成本大就不给你做了,所以谈判这点是比较难的,因为包含阅人能力
    风险发现当然就是“无法完成”或者“成本巨大”的部分,前者需要评估自身技术力量,不自量力自然就烂尾还损失信誉,后者需要计算工时,客户立场只会考虑“时”,而不是“工时”
    理解能力一般不是问题,除非自身有问题,更多是花费时间,理解业务模型,自己能模拟出来,不要匆匆听几句就哦哦哦全部承诺下来
    文档就是把描述性的需求,转化为技术性需求,不要像#1 所说的那些 pm 只懂转述,因为下一步对接的是技术人员,需要多看和多参考前人的经验,历史文档等等

    我觉得好的 pm 不是人人能当的,尤其技术转 pm 很难突破谈判这一关
    rouxi
        3
    rouxi  
    OP
       352 天前
    @gitrebase 是的,但是一般产品都很少画流程图这种东西吧
    rouxi
        4
    rouxi  
    OP
       352 天前
    @NoOneNoBody 对接 pm 的纯技术,很多东西不太好实现,或者说实现的成本很大,但是产品就会觉得老子偷懒,所以想谈判,用其他的路线去实现这个功能
    NoOneNoBody
        5
    NoOneNoBody  
       352 天前
    @rouxi #4
    是的,这就是我上面说的“个人利益”——“我可以完成这个需求,但不能背锅”
    谈判要抓痛点,然后“双方”让步,才能谈得成,对经理来说,肯定是耗时、容易出 bug ,甚至引发服务器 down ,这样即使有人祭旗,他的锅也不小
    至于谈判话术,我也不擅长

    ps: 我上面说的 pm 指项目经理,离岗多年,不知道现在怎么称呼,不过在我心目中,产品经理算是“工业设计”岗位,要低于项目经理。项目经理的技术面也是强的,产品经理/工业设计偏业务,懂客户和用户,但技术实现这块不一定很强
    rouxi
        6
    rouxi  
    OP
       352 天前
    @NoOneNoBody 确实是这样,感谢大佬的回复,受益匪浅
    coderzhangsan
        7
    coderzhangsan  
       352 天前   ❤️ 1
    产品一定要懂点技术,基于当前技术栈做业务设计,如果产品一点不懂技术,需求设计就会很主观,这样就会导致业务后续不可控,风险也会提高。
    vsitebon
        8
    vsitebon  
       352 天前   ❤️ 1
    需求肯定是要有使用场景的,如果你发现他们提出的使用需求站不住脚的话(尤其是当你将自己看作用户的情况下,你经过他们提出的需求,没办法理解这个需求合理性),那你是肯定要考虑让他们给出更详细的需求文档,来解释这个的合理性的。相当于丢包袱回去,而且声明并不是你不想开发,但是他并没有理清楚用户的需求
    jones2000
        9
    jones2000  
       352 天前   ❤️ 1
    现在业务基本都抄来抄去的,自己用下对应你们业务的需求的竞品软件,大致都可以明白这些需求。至于实现其他家都实现了,照着抄不就行了。
    janus77
        10
    janus77  
       352 天前   ❤️ 1
    多写代码,多参考别人的产品
    zhanshen1614
        11
    zhanshen1614  
       352 天前   ❤️ 2
    先熟悉基本业务流程,借鉴“用户故事”的三要素来理解需求,知道它们是给谁用的用来干什么的怎么运作,对于复杂的需求要给出流程图。
    需求风险发现能力靠业务和项目的熟悉程度即可,越熟悉对风险的感知和预判能力越强。
    谈判能力要结合具体的业务和应用领域,关注竞品动态,还要学习商业谈判技巧,产品和管理知识,要让对方知道需求实现的成本、代价和潜在风险,意识到这不是最优解决方案从而改变原方案或推翻重新设计需求。
    有一次系统频繁发版却无人使用但 PM 仍说是“业务方反馈的”必须开发,我问 PM 为什么这么多功能没人用?没人用哪来的用户反馈?发布后是否有给员工讲解? PM 说发布后就不管了,于是我提出发布后必须讲解所更新/添加的功能用法并更新系统使用手册后就有人用,从此再也不敢随便提需求,这个涉及到管理上的工作流程优化。
    不过谈判的风险较大,有时候我们觉得需求很奇怪不只是业务上的考量还有 KPI 作祟,故意设计复杂一点让更多人获得绩效,水可能很深处理不好容易给自己带来危险。
    至于楼里提到的“产品经理懂技术更好”我不太认同。懂技术的产品经理如果不能跳出技术思维会给程序员带来许多麻烦,业务上的任何问题都想用技术解决,不懂得优化业务流程,挖掘真实需求。
    YassoWithSpeaker
        12
    YassoWithSpeaker  
       346 天前   ❤️ 1
    尝试考一考系统架构师,这些都会解决的
    rouxi
        13
    rouxi  
    OP
       337 天前
    @YassoWithSpeaker #12 可以的,我关注一下
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   1991 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 23ms · UTC 00:23 · PVG 08:23 · LAX 16:23 · JFK 19:23
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.