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

我感觉我经常听不懂产品对“新需求”的描述……我一度怀疑到底是他们不会描述还是我的理解能力真的不足

就是有些 pm 就喜欢用自然语言描述一下复杂需求……画个流程图可能就好多了，而且在自然语言中，很难明确一些专业名词和业务实体，对于不熟悉的人是看都看不懂，尤其是在一段话里对某个实体使用多个别名，看得是真的头疼……

你是对接客户还 pm ，或者说你是 pm 还是纯技术
纯技术只需理解能力就够了，谈判只是为了个人利益，风险发现不干你的事，做到排除歧义就好了，需求文档一般没时间做

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

我觉得好的 pm 不是人人能当的，尤其技术转 pm 很难突破谈判这一关

@gitrebase 是的，但是一般产品都很少画流程图这种东西吧

@NoOneNoBody 对接 pm 的纯技术，很多东西不太好实现，或者说实现的成本很大，但是产品就会觉得老子偷懒，所以想谈判，用其他的路线去实现这个功能

@rouxi #4
是的，这就是我上面说的“个人利益”——“我可以完成这个需求，但不能背锅”
谈判要抓痛点，然后“双方”让步，才能谈得成，对经理来说，肯定是耗时、容易出 bug ，甚至引发服务器 down ，这样即使有人祭旗，他的锅也不小
至于谈判话术，我也不擅长

ps: 我上面说的 pm 指项目经理，离岗多年，不知道现在怎么称呼，不过在我心目中，产品经理算是“工业设计”岗位，要低于项目经理。项目经理的技术面也是强的，产品经理/工业设计偏业务，懂客户和用户，但技术实现这块不一定很强

@NoOneNoBody 确实是这样，感谢大佬的回复，受益匪浅

产品一定要懂点技术，基于当前技术栈做业务设计，如果产品一点不懂技术，需求设计就会很主观，这样就会导致业务后续不可控，风险也会提高。

需求肯定是要有使用场景的，如果你发现他们提出的使用需求站不住脚的话（尤其是当你将自己看作用户的情况下，你经过他们提出的需求，没办法理解这个需求合理性），那你是肯定要考虑让他们给出更详细的需求文档，来解释这个的合理性的。相当于丢包袱回去，而且声明并不是你不想开发，但是他并没有理清楚用户的需求

现在业务基本都抄来抄去的，自己用下对应你们业务的需求的竞品软件，大致都可以明白这些需求。至于实现其他家都实现了，照着抄不就行了。

多写代码，多参考别人的产品

先熟悉基本业务流程，借鉴“用户故事”的三要素来理解需求，知道它们是给谁用的用来干什么的怎么运作，对于复杂的需求要给出流程图。
需求风险发现能力靠业务和项目的熟悉程度即可，越熟悉对风险的感知和预判能力越强。
谈判能力要结合具体的业务和应用领域，关注竞品动态，还要学习商业谈判技巧，产品和管理知识，要让对方知道需求实现的成本、代价和潜在风险，意识到这不是最优解决方案从而改变原方案或推翻重新设计需求。
有一次系统频繁发版却无人使用但 PM 仍说是“业务方反馈的”必须开发，我问 PM 为什么这么多功能没人用？没人用哪来的用户反馈？发布后是否有给员工讲解？ PM 说发布后就不管了，于是我提出发布后必须讲解所更新/添加的功能用法并更新系统使用手册后就有人用，从此再也不敢随便提需求，这个涉及到管理上的工作流程优化。
不过谈判的风险较大，有时候我们觉得需求很奇怪不只是业务上的考量还有 KPI 作祟，故意设计复杂一点让更多人获得绩效，水可能很深处理不好容易给自己带来危险。
至于楼里提到的“产品经理懂技术更好”我不太认同。懂技术的产品经理如果不能跳出技术思维会给程序员带来许多麻烦，业务上的任何问题都想用技术解决，不懂得优化业务流程，挖掘真实需求。

尝试考一考系统架构师，这些都会解决的

@YassoWithSpeaker #12 可以的，我关注一下