当时的我还没有意识到一个问题：思维导图并不适合说明需求，而更适合整理需求点——而整理需求点，是产品经理自己的作业，拿出来给工程师和设计师看，谁都会很困惑吧。于是，费尽了功夫的我获得了两个教训：

选择工具很重要。
罗列功能并不是需求文档。

经历了现实的打击之后，我重新调整了需求文档，将改用Word 模版的需求文档交付给对应的设计师。

第一次做功能：开发阶段

没过多久，交互设计师就输出了基本的交互稿，和我的想法是基本一致的，于是我开心地找工程师评审需求了。然后又遇到了第二个问题：那些轻描淡写的“自动刷新逻辑”、“页面排版逻辑”究竟是什么玩意？

工程师对此表示很遗憾，他们找遍了需求文档也不知道要怎么做，于是我给他们又进行了一次方案宣讲，并把对应的内容都写入了需求文档中。对于工程师来说，他们的目标就是准确地实现需求文档的要求。因此越清晰的要求，对于他们来说越省力。所以入门的产品经理需要关注这个案例：尽量用详尽的文字去描述每一个细节。

自动刷新逻辑

触发条件：当用户进入该页面，触发自动拉取最新数据的操作。

刷新展示：如果刷新成功，则页面展示最新内容（渐显效果）；如果刷新失败，则弹出“刷新失败，请稍后再试”的提示。

图片展示：未拉到图片时，需要展示一个占位图，在一分钟内进行多次图片拉取；如果图片拉取失败，则出现一个裂图；超过一分钟，允许用户手动点击占位图进行拉取图片的操作响应。

每篇文章的摘要显示及排版：××××××××

如果由于网络原因数据拉取失败，需要提示网络错误。

如果由于网络比较慢，则在一分钟内多次尝试拉数据；超过一分钟则等待用

户手动触发刷新操作。
……

以上只是展示了正常的逻辑，还有许多异常情况没有考虑，因此产品经理在描述需求时，切记把每一个细节都考虑到，尤其是异常情况。对于工程师来说，没有歧义且包含多种场景的需求描述，才是好的需求文档。“自动刷新”虽然是简简单单的四个字，却包含了有可能四百字都描述不完的细节。

第一次做功能：产品体验及改bug 阶段

只有真正参与过项目，产品经理才会了解人与人之间的沟通是多么重要。如果仅仅依靠需求文档，产品经理可能会发现开发工程师实现的功能和当初构想的功能会有许多差异。先不要担心，这些差异的存在是必然的，毕竟开发工程师不会读心术，而文字描述本身就容易出现歧义，这些差异都可以在体验阶段修改。
但这个事情从侧面反映了一个问题：需求文档还是不够细致。

灾难到这里就结束了吗？产品经理体验了产品之后交给测试工程师测试，这才是产品经理发现自己无知的时候呢！测试工程师会根据测试用例提出许多异常情况，而产品经理会发现，怎么这些场景我都没有考虑到！怎么会有如此多的bug！

先别着急，这些问题几乎在以后的产品开发过程中都会遇到。但这些“突如其来”的灾难的确容易让刚入门的产品经理手忙脚乱。有条理地去解决这些问题吧！产品经理之路还远着呢！

虽然第一次做产品需求就像个灾难，但后来回首这样的经历，可以发现一个有趣的事实：尽早失败，尽快改正，是产品经理成长的必经之路。而在我往后的产品经历中，往往都会想起这样一句话：把功能想透彻。对于产品经理来说，需要想清楚以下几个问题。

●Who：用户是谁，他们有哪些特征？

●What：这个功能具体是怎么样的，确认需要做哪几个功能？

●When：什么时候会使用？

●Where：使用场景是什么，功能页面之间是什么样的关系？

●How：用户如何正常使用对应的功能？

什么叫作“想透彻”？不如请各位产品经理先想一想如何用一句话准确地表达手头的需求，如果不需思考就能脱口而出，那说明你已经在思考，反之则需要扪心自问，自己是否已经了解该需求。如果想要检测自己是否想透彻了，还可以通过以下的几个问题进行自测：

●用户的需求是什么？

●这个需求可以分解成多少个小点？

●这些小点有哪些可以满足，哪些不需要满足？

●每个需求点可以通过什么样的功能去满足？

●这几个功能之间的关系是什么？

●整个方案有几个页面，和整个产品的关系是什么？

●功能的入口放在哪儿？

●用户发现了这个功能之后，他们会怎样使用？

●如果用户中断了操作，会出现什么提示？

●是否针对功能操作设置了保护机制？

这些只是最简单的一些问题，接下来我会结合自己做产品的经验及一些朋友的经历举出一些常见的问题，希望可以给刚入门的产品经理提供更多启示。

常见的问题案例

问题一：没有分解需求。

每个人对于需求的理解都有所不同。产品经理在描述需求的时候，需要尽可能详细和无歧义。例如：

●我想在坐电梯的时候可以获得资讯。

●我想在坐电梯的时候可以获得关于股票的消息。

●我想在坐电梯的时候可以了解到公司股票的实时走势图和实时价格。

各位觉得哪个描述更容易被理解，而且没有太多含糊的信息呢？不仅仅是描述容易出现问题，大部分时候需求描述有问题就是因为需求没有得到有效地分解。产品经理还需要注意对需求进行分解，像严谨的解构主义者，不放过任何一个概念。越是分解细致，越容易降低含糊信息出现的几率。

问题二：缺乏对用户的了解。

虽然在前面一直提到以用户为中心的产品理念，但因为某些原因，大部分时候产品经理不得不尽快明确需求，而等不及对用户进行了解。这种闭门造车的需求很容易产生一个可怕的后果：用户不买账。历经千辛万苦做完一个功能，产品经理没有功劳也有苦劳，但用户不买账。这就是缺乏对用户了解的后果，即使产品经理耗费大量资源和时间，但是做出了用户不喜欢的产品，那么一切都是在做无用功——即使产品经理自己觉得在做创新，用户不买账是因为他们视野不够，但不被用户接受就失去了产品的使用价值，不符合市场的供求机制。

问题三：急于推动方案，而非获得支持。

因为刚入门的产品经理往往缺乏自信和魄力，所以很难得到工程师和设计师的信任。但由于产品经理希望尽快推动功能进行开发，所以会不断地催促设计师和工程师动手做需求。

做需求本身是一个合作的过程，如果忽略沟通，不管需求的背景和目标，而仅仅是传达任务，那么对于设计师和工程师来说，这是一种缺乏合作精神的行为。虽然产品经理是无授权的领导，但在日常需求合作的过程中，产品经理更重要的角色是“润滑剂”，即沟通各方人员，确认他们都了解需求的背景和目标，保持信息一致。

得道者多助，失道者寡助。获得了设计师和工程师们的支持，对于产品经理来说是好事，因为这意味着你们在同一条船上，可以一起朝目标前进。而失去支持的产品经理，时常会遭遇到不合作，或者不认真的合作，这种情况下,需求在实现过程中常常会出现恶性循环，导致需求总是返工，每个人都不好受。

问题四：容易被忽悠。

不懂技术的产品经理时常会被忽悠。这种情况并非开发工程师不合作，而是他们在暗示对产品经理缺乏信任。

●你自己根本不清楚需求要怎么做。

●你根本不了解我的工作很多，总是打扰我。

●和你沟通很费力，忽悠你赶快走！

刚入门的产品经理缺乏经验，总是容易被各种术语忽悠——想要改变这种情况，那就要让工程师们信任你。我常用的方法可以分享给各位试一试。

●复杂的功能如果已经在其他应用上实现了，工程师们二话不说，拼了自尊也会去实现的。

●如果他们冒出大量术语，你可以试一试请教他们这些“牛逼哄哄”的术语都是什么意思，他们愿意介绍这些“牛逼哄哄”的术语。

●不管如何，确认他们对需求理解到位，必要的时候可以让他们重复表述一遍。

其实以上几个问题都非常容易出现，但大部分时候都可以归结为一个概念：含混性。什么是含混性？产品经理对用户的需求理解出现偏差，工程师对产品需求理解出现偏差，设计师对产品需求理解出现偏差，这些都是含混性的表现。

文章来源：腾讯大讲堂