如何更好的与产品，需求方沟通

如何更好的与产品，需求方沟通

来自业务部门的需求，大致可以划分为两类：
第一类是明确的提出一些新功能需求，需求的背后通常都是同事自己在工作中遇到了困难，希望通过开发产品来节省自己的时间和力气、提高工作效率，例如说想在管理后台增加定时上线功能；在向产品人员提需求的过程中，运营方会说明自己在工作中遇到的问题，但是具体的解决方案就要靠产品经理自己了。我曾经做过一个EDM系统，其中有一个细节给我的印象很深，运营人员把他们的一个需求描述的很复杂，还跟我描述了他们做邮件营销的整个工作流程，拿他们的工作文档给我看，其实终归他们只是需要看一下自己的营销邮件发送时间与别的产品是否有撞期的情况。想要的东西其实很简单，但却费了很多唾沫。
因公司内部需求而做的产品，很大程度上也是供公司内部人员使用的。在产品设计中，我们有一条原则是先有后优，本身也是后台，更注重实用性，所以本着优先上线、缩短开发成本的原则，对于产品的交互和美观性方面的要求相对也都会低一些。
第二类是反馈用户的需求，毕竟运营人员是直接跟用户打交道的，他们会把一些用户的反馈转述给产品经理。如果是转述用户的需求，就需要寻找满足需求的方法，这也分两种情况，如果是用户提出的新功能就要衡量是否有必要开发新产品满足，如果是对现有产品的改善建议，那就要寻找现有产品的缺陷，继而优化改善。至于怎么优化，要综合三个方面进行考量，一个是同一个问题用户反馈的数据量，二是针对用户的反馈做一些相关的数据分析，看问题的用户覆盖范围，三是考虑与产品未来的发展方向是否一致，有时候如果用户反馈的意见与产品未来的发展不一致，即便是呼声很高，产品经理也要继续坚持。
我个人在产品经理与需求方沟通过程中总结了一个原则，就是：听他的，但不跟他走。听他的——要听运营方的需求，毕竟产品的最终目的是要满足他们的需求。不跟他走——虽是满足运营方的需求，但是产品经理不应被牵着鼻子走，不能他说什么就是什么。而且产品经理与需求人员在合作的过程中各司其职，需求人员负责的是功能和内容能否满足，而产品经理则需要决定界面的排版和详细的功能。实际情况中，如果产品经理一味听从需求方而没有自己判断的话，会发生一种情况就是把需求的满足方式设计的特别复杂，结果给开发人员带来了很大工作量。但是当产品经理的设计与需求方的设想有出入的时候，多半还是要产品方作出让步。
有两点需要产品经理注意：
一是由于需求方因为不懂技术，所以提需求的时候不会去考虑能否实现，但很少会碰到无法实现的情况，如果有这种情况，需要产品经理的脑子灵活一点，找一种折中的方式解决。也有需求方由于担心技术实现难度，所以在提需求的时候会提的比较简单，有些工作宁可自己做。这时候就需要产品经理发挥自己的能力，给需求方提供一些更好用的工具。
二是在沟通的过程中很多事情需求方也未必能想得到，如果产品经理帮他们想到了或是根据他们的需求给出了更好的方案，这样肯定会达到更好的效果，也会提高需求方对于自己的信任度。我曾经做过一个奖品管理系统，需求方提出了他们想看到的数据，我当时规划的后台已经能够满足他们，后来我给他们添加了一个统计功能，便于他们查看某个活动奖品的发放情况以及花费的费用等，因为当时觉得这些会是他们非常关注的信息，他们看到后就感觉很欣喜，觉得很有用。
跟需求方打交道，有时候也看产品经理的运气，合作的愉快程度跟需求方的职能和工作经验有关。如果需求方的工作经验很丰富的话，他们会帮产品经理想到很多点。如果是做产品运营的，因为他们的互联网思维意识比较强，所以无论对于概念的理解还是功能的使用上都会更熟悉，在需求的沟通过程中也会更顺畅一些。相对而言，跟市场、客服部门的同事沟通起来就会差一些，因为这些部门的人有很多都属于小白用户。
如果需求方的经验不多或是小白用户，在沟通的过程中，产品经理会非常被动。特别是当由产品部去发起做一个供公司内部人员使用的产品时，就需要不断的去了解产品使用者的工作流程，去问他们在这中间遇到的问题，这不仅需要产品经理积极的推动能力，还需要有很大的耐心，如果对方属于比较强势的那一种的话，恐怕还需要产品经理受一些委屈。
理想的情况，如果业务部门跟产品经理合作的过程中，双方都能够积极的配合，会使得产品上线的过程更加顺利。反之，则需要产品人员的主动意识和责任心更强一些。