产品经理在向开发同事提需求时,如何完善需求,让需求细节全面并且清晰?

开发人员最讨厌产品经理的哪些做法? - 沟通这个问题中提到开发人员最讨厌产品经理的第一条就是需求不清晰。 作为一个互联网菜鸟,提问者自己在工作提需求时也往往思考不周,一拍大腿就提过去了,没有想到的一些需求细节由开发同事指出来时就措手不及,这时候才一拍脑袋,当时怎么没有想到。 在提需求的时候没有考虑清楚,对后面开发及测试的影响都比较大,求教如何全面的考虑需求,从什么方面着手能让需求全面而且细节清晰。 相…
关注者
679
被浏览
53,039

26 个回答

和你的直觉相反。我们开发真正希望的是产品经理在交代需求时,不要求全面细致,但要重点突出。

其实工程师不仅仅要了解产品的方案的核心设计思路,还要知道工程上取舍的条件。这样我们可以集中精力解决对公司对整个产品有巨大回报的问题,同时在那些次要的功能点上做变通。

而面对那些重点不突出的需求,越是交代得细致,我们越是反感。因为不知道你真正想解决的问题是什么,我们就不知道一处设定是你重点关注的还是随便拍脑袋的,那我们肯定要到处挑刺啦。

此外,如果一个名产品经理知道自己方案的核心要点,也是不会为一些次要的细节被挑刺而乱了阵脚的。只要底线没被触及,完全可以让开发有些发挥的余地,降低下整体的成本呀。相反,越是不知道底线在哪的 PM,面对开发的反馈越敏感,越怕自己的方案有一点的变化。

所谓一流产品讲故事,二流产品列单子,三流产品哭鼻子,就是这个道理。
求教如何全面的考虑需求,从什么方面着手能让需求全面而且细节清晰。

既然你希望需求既要全面又要细节清晰,广度与深度兼顾,那么必然要学习掌握被软件工程界所广泛采用的科学、系统的需求分析方法论。没有科学的方法论,其他都是扯谈。

作为一个互联网菜鸟,提问者自己在工作提需求时也往往思考不周,一拍大腿就提过去了,没有想到的一些需求细节由开发同事指出来时就措手不及,这时候才一拍脑袋,当时怎么没有想到。

菜鸟出这种状况是正常的,因为菜鸟最缺乏经验,很多地方想不到。需求分析涉及到许多细节,通过学习掌握了科学、系统的方法论,熟悉了各种需求分析的框架(frameworks)、模版(templates)、步骤指南(guides)、质量检查点(checkpoints)等等工具,就可以最大程度的避免“当时怎么没有想到”情况的发生。


任何需求一般可分为功能需求(FR)、非功能需求(NFR)两种。

非功能需求

NFR 分析比较流行的框架一直是 FURPS+(源自 HP)。

Wikipedia:FURPS

根据成熟的分析框架和模版来梳理非功能需求,出现遗漏的可能性就会大为降低。

功能需求

FR 分析目前最好的技术是源自爱立信的 Ivar Jacobson 发明的用例分析(UCA,Use Case Analysis)技术,远强于特性(Feature)与 XP 的用户故事(User Story)。

Wikipedia:Use case

我是从 1998 年开始研究和推广用例技术的,一个最大的体会是:

用例分析(加上图形建模技术如 UML)可以把复杂的产品、系统或软件需求梳理得非常清楚。

。。。