产品经理经常会遇到两个问题：其一是来自业务部门的需求困扰，其二是来自技术部门的实施阻挠。下面，我们将针对这两个问题进行简单的分析，并提出解决的办法。

常遇问题一：来自业务部门的需求困扰

这绝非个案，而是许多产品经理遇到的共同问题。大部分来自业务部门的需求通常总是非常多的，而很多产品经理则总是在把这些串连成线以及规划成面的过程中痛苦不堪，甚至于还没意识到便已经落入业务部门随意布置的“陷阱”中。如果您有如下症状，那么我们可以断言，您已经身在其中了。

症状一：沟通困难。

任何沟通的问题大部分是三个原因导致的，第一是立场不一致，第二是理解不一致，第三是无意达成共识。如果抛开第三点不谈，我们会发现第一点和第二点通常是由对业务理解的角度不一致或者对同一对象的理解产生分歧造成的。我们认为造成这些的原因的核心都在于不够专业，比如很多产品经理在获得最初需求时便急于深入展开从而导致走向歧路，很多业务人员在描述业务时为了表现自己对技术的了解而重在描述功能而非业务造成产品经理错误理解，很多业务人员对业务不够熟悉而造成业务矛盾，很多产品经理习惯性的把产品设计得过于烦琐而缺乏严密等。这些问题经常会导致了沟通时不能倾听或者不能理解对方的意见而固执己见，最终形成了沟通困难的局面。

症状二：概念设计多次返工。

返工永远是效率的杀手，而且这是最常出现的问题之一。大部分出现这个问题的产品是设计或者技术出身本身出了问题，原因在于产品经理习惯于立刻动手，还没有能够充分理解业务就立刻开始考虑技术实施，这往往造成了项目的风险。如果业务部门没有及时叫停，那么这个实施将会是彻头彻尾的浪费。当然这里不是说非技术出身的产品经理不会犯这样的错误，之所有这样说是希望我们能够重视思考而不是立刻着手实现。概念设计之前应该有足够充分的准备，比如足够的用户分析，足够的流程图，足够的产品规划方案，足够的业务理解，足够的市场认知，以及其他足够多的各种各样的准备，在这些准备足够充分之后，产品设计的基石才足够稳。

症状三：疲于奔命。

疲于奔命的产品经理是非常不幸的，他们虽然可能足够努力，但是常年看不到绩效的增长，却天天受到实施部门的抱怨声。在很多企业，今天业务部门要开放一个需求，明天要把这个需求关闭掉，今天要改动一下这里，明天要改动一下那里，产品和技术天天跟着业务部门后面，似乎业务部门更像“产品经理”。出现这样的问题，企业通常是两个原因导致的：第一个原因是业务部门缺乏长期规划而只有短期“小动作”，第二个原因是产品经理对业务部门的长期规划不理解而诱使业务部门任意妄为。产品经理必须清楚地知道，其不只接收业务而已，还要对产品负责。产品的长期、中期和短期规划必须匹配以业务的长期、中期和短期规划，即使业务部门不够专业，产品经理也必须有对应的措施，比如适当的引导、提议、要求、拒绝、反对等。

除了以上三大典型症状以外，还有非常多的各种类型的困扰，这些困扰大部分造成了产品需求效率低下，产品实施困难，需求变更过多过快等相关问题。虽然很多问题的原因来自业务部门，但是我们也必须加以重视，因为身为产品经理这必将成为你的负担。那么如何能够彻底解决呢？以下几个小诀窍也许可以帮助您。

诀窍一：分角色讲故事，完整描述需求。

让业务人员讲故事也许是最棒的方法了。分角色讲故事不仅仅可以充分再现情景，而且可以在情景模拟中发现错误的业务逻辑以及业务不能连接的地方，甚至很多不好的用户体验要点也能够立刻体现出来，所以我们建议产品经理应该要求业务部门以分角色举事例的方式来完整描述需求，必要时甚至可以要求业务人员“演出来”。产品经理的概念设计应该建立在充分的理解情景的基础上，业务人员“扮演”的情景通常是真实情景的样板。

诀窍二：充分了解整个业务逻辑。

产品经理必须了解业务，甚至于比大部分业务人员更“懂”业务。“懂”业务包括对业务大局的把握，对业务的客户体验要点的了如指掌，对用户的充分了解，对业务逻辑的透彻认识。其好处在于对产品的大方向能够很好的把握，而对细节则能够细致入微，这将大大提高产品经理的工作效率和成果率，同时更好的支持业务部门并对其决策和行事风格产生重要影响。

诀窍三：通过时间管理形成工作流。

简单来说，工作流性质的产品管理类似于流水线操作，虽然每个产品经过流水线的每个步骤都将更完善，但是流水线从来不会因为某个产品的缘故而停滞。我们可以把产品开发的过程当作为生产过程，在这个生产过程中每个迭代都能够增加新东西，但是都通过时间计划管理和版本管理变得有章可循。在工作流中，业务部门也不能影响整个生产，而我们需要做的是确切地知道业务部门需要的是什么，然后把业务部门的最终愿望结合到产品终极规划中，从而形成产品工作计划逐步实施。我们也经常遇到这样的情况，在开发一半的时候业务部门提出变更需求，此时我建议如果业务需求不是非常致命的，那么必须在开发前封闭需求，所有的计划提前通知业务部门。如果业务部门也认可了，那么任何的改进需求通常不本次开发中实现。建议在下一次时展开具体开发需求时展开。

常遇问题二：来自技术部门的实施阻挠

我相信遇到这个问题的产品经理绝不在少数，即使技术出身的产品经理也未必能够应付自如。在大部分情形中这个问题之所以出现并非由于技术部门提出的诸如难以实现等问题，而是技术部门作为制造部门必须为了保证完工以及工程质量向需求方施压以争取时间和减少开发的压力。有经验的产品经理通常能够非常清楚地了解什么确实难以实现，什么是技术部门向产品施压，而且他们能够针对性的进行处理。您正在收到这个问题困扰吗？看看您是否遇到以下症状吧！

症状一：技术部门总是反馈难以实现。

技术部门反馈难以实现已经成为产品开发的家常便饭了，如果进一步追问通常会出现诸如需求混乱、时间不足、人手不足、架构不能支持等理由。如果产品经理抓住这些问题不放，那么整个事情就会变得一团糟。有经验的产品经理通常首先把所有问题都当作是工作量的问题。“好吧！如果一周内不能完成，那么要增加多少时间可以做到呢？”在这个问题如果能够得到完整的解答，那么诸如需求混乱等事实上都是借口而已，通常大多数情况都是如此。但是如果确实是需求的问题，那么产品经理则应该立刻找到问题的症结并立刻解决之。

症状二：技术部门修改需求，实施效果大打折扣。

技术部门修改需求也是常常发生的。很多产品经理都会在这个问题上进行妥协，多次之后终于助长了技术部门的坏习惯。如果需求是正确的，产品经理必须坚持需求的原样，不容许任何折扣，这是产品是否能够精益求精的根本。我们必须记住，每一处设计必有初衷，每一点折扣必伤用户体验。

症状三：技术部门不能按期交付。

技术部门不能按期交付通常是最头痛的，这虽然是技术部门的责任，但是产品经理也必受牵连。在大部分企业中，交叉部门的事务总是很头痛的问题，但产品经理的职责包括于此。产品经理必须实施走动式管理，与开发自己产品的技术人员经常沟通，慢慢培养出默契，这是密切配合的前提。有经验的产品经理总是能够在不动声色中实施走动式管理，在随意的沟通中能够适当施压，随时掌握开发情况，并能准确预估项目时间，提前完成各种调整和准备工作等。

事实上，大部分产品经理都会遇到以上三种症状，且超过半数沉浸其中。产品经理和技术部门的沟通不仅仅依靠专业程度，更依靠人际处理能力以及沟通策略等。以下诀窍为很多优秀产品经理在工作中共同总结的经验，也许对您有所帮助。

诀窍一：接收需求时，确保项目经理在场。

确保项目经理在场不仅能够及时发现来自业务部门的原始需求，而且能够使项目经理更加直接的感受到来自业务部门的压力，这不论是对未来的开发工作还是对需求分析工作都非常有益。另外很多难以解释的业务通过业务部门的直接阐述也使得项目经理的印象更为深刻，这将会避免之后出现歧路。

诀窍二：产品需求说明的重点部分要求技术部门确认。

确认是非常重要的工作，经过确认的需求我们认为在本轮迭代中除非是因为重要事务被叫停否则是不可改变的，这是对开发的完整交付非常重要。产品经理必须管理好每一次交付的内容，所有的需求都能够“开关”，所有已经确认的需求必须能够按时看到结果。这里我们再次强调，任何工作必须充分确认，而确认之后则必不可改。

诀窍三：实施走动式管理，及时了解情况。

走动式管理我们认为是一种艺术，是最佳的即时发现问题的手段，大部分优秀的管理者都实施走动式管理。产品经理必须非常清楚，团队中大部分人员都不会主动汇报项目的问题，至少不会在适当的时间主动汇报问题，这会使得问题越藏越深、越拖越大，所以通过走动式管理及时发现问题不失为管理的好方法。