产品经理常见问题解决方案是什么

在众多学习中，文章也许不起眼，但是重要的下面我们就来讲解一下！！今天的产品运营的知识数不胜数，大家感兴趣的话，可以过来看看，具体内容如下：产品包装

 作者：Lisa，某外汇外企公司产品经理。3年测试经验，2年产品管理经验。产品经理职责
来源：http://blog.sina.com.cn/s/articlelist_2477511650_0_1.html
公司按产品划分团队初期，大家还是没有意识产品经理到底需要做什么。只是在职责上赋予全权负责产品项目的权力，能不能胜任还是个迷？跟个人的工作经验有很大的关系，虽然之前我司是QA把控进度，保证质量，驱动开发，属于在一定程度上有些许的管理项目的经验，但是遇到问题都是测试总监和开发总监出面解决，自己在之前的项目中并没有全权把控的能力与机会。导致初任职时，各种问题层出不穷。
问：需求文档都是以邮件模式出现，无归档备份，后期追溯难，怎么办？
答：拿到项目后，就算没时间整理详细需求，一定要整理需求的框架或者大纲，如下图。不管是用Word还是工具（禅道、confluence），然后不分样式，全部贴到对应的目录下，以备后期追溯。

标绘图流程使用的符号与流程图很类似，指出整个过程中某一特定环节的运作情况。标绘图流程的符号包括：
只有通过运营或决策才实现价值提升。要确定过程中有多少步骤没有增加价值，可将它们一一列出，并为每一行为符号插入一列。对每个步骤标明其涉及的行为类型（如运营、移动、延迟等）。对各列的标记进行合计，由运营列和决策列相加得到能增加价值的步骤总数，随后将其余列相加得出不增加价值的步骤总数。
您可以由此开始流程的改善工作。
模型化和模拟“假设”情况网络运营
您所创建的流程图和标绘图流程也可以作为模型参考。尽管这些模型能很好的解释“结果”，但是它们无法回答更细的问题，诸如“如何做”、“何时”以及“何地”。某典型业务所用流程若具有一定复杂度，则单纯依靠流程图很难判断变革所产生的效果。而这时模拟模型就有了用武之地。模拟方式允许您对模型加以更改，有助于更清楚地了解流程变化带来的影响。通过对流程的模拟，您可以优化流程，进而节省财力。
通过模拟您还可以做一些“假设”情况的试验。您可以判断：
员工缺勤可能对流程的影响
取消初步看上去无设置必要的岗位后可能导致的额外开支
通过对工作区域的简单调整，使存放部件和原料占用更少的仓储空间而可能节省的时间和资金。
由技术人员自己撰写报告，不经行政人员而可能节省的财力。
这种模拟需要一些创造性的思维和相关人员的投入。不要忽视实际执行人员对流程优化的意见。他们或许是对所从事的任务了解最为全面的人，很可能对改善系统有相当多的想法。
 问：不能直接接触客户，需求反复，无法把控怎么办？
答：在互联网项目中，这已经是普遍存在的现象，很多公司已经有了预先与用户商量好管理方案，但是老板项目怎么办？老板的突发灵感，往往是不容置疑的，而且是优先级极高的。为此只能在有限的资源里，延缓之前的进度安排。但是这样的结果会导致，项目开发时间极长。为此跟很多大牛聊过以后，发现，项目的版本控制尤为重要，采用迭代式的方式管理，方可避免该类问题发生。一个版本限定最高优先级，高优先级，中等优先级，低优先级，并评定时间。如果突然有最高优先级的任务，可以把低优先级的放到下一个迭代版本。以此类推。

问：不懂技术，被开发牵着鼻子走，怎么办？
答：开发经常会说这个任务可能需求多点时间，不一定按时完成，你说的那种方式做不到，由于我们是QA转产品经理也是项目经理的，经常会被开发的阔论虎的一愣一愣的。无奈下只能妥协，因为争论，只会让开发觉得我们不信任他的技术，反而会产生逆反情绪。这在项目中是不可取的。遇到这样的问题，就要应用职权，组织会议了。邀请开发总监或者技术大牛参加，一轮探讨下来，往往会有意想不到的效果。开发不但更有斗志反而更完美的把你想要的东西呈现出来。
其实根本不用担心，整个产品流程，从前期的市场调研，竞品分析，需求评审，项目提案，到中间的产品实体化，设计，交互体验考量，公司内资源协调，公司外资源需求整合，项目考量，落实规划到后期的运营规划，市场推广，程序开发，用户反馈，产品迭代，需求评审等等一系列的工作内容中。你们觉得涉及到真正需要能跟你勾通这里代码如何处理？这个存储流程如何涉及，这个算法如何调整的环节有多少？占他们多少的时间和工作强度？
没错，产品经理需要通才，懂得越多越好，但绝对不是需要他们在技术方面懂的越多越好，而是知识扩展，行业深度的方面通才。程序员能够和产品经理在工作中接触的无非是产品落实开发的那一小部分，就因为他们不能够理解一个看起来简单的需求为何需要较大的工时，于是就质疑这个行业的普遍胜任力，这有点夸张了吧？
问：开发、测试的时间没有评审，到交付时间，发现一直无法交付，怎么办？
答：项目执行前，一定要有时间的评审会议，并在这个结果下预留多点时间，保证自己许诺的时间下，可以有满意的交付。
需求不清晰，当开发人员问PM需求的时候，发现PM也弄不清楚，这样的问题是一定要杜绝也完全可以杜绝的，如果PM自己都不清楚需求，的考虑这样的工作是否适合自己了。
干预纯技术问题，例如：这个code应该这么写。避免之道:对于纯技术的问题不要干预，如果他的技术实现真的有问题，自有相关的人去负责，产品只需关注他最终是否实现了预期的功能。
交付的方案不确定，开发人员讨厌“其实这样也可以”，“要不就这样吧”的言论，他们需要的是一个明确的方案。在多种方案犹豫不决需要思考的时候，PM最好只是将这样的犹豫不决体现在自己的思考中。除非工程师无力实现你的第一种方案时，再将备选方说出来。
没有必要的预留时间,”这个我们修改一下，明天提交新的版本，一看，列了一大堆增加的功能，并不是仅仅是修改。coder真的不是神，增加的功能是需要测试的。pm给自己留时间同时，可怜可怜攻城湿，留点时间思考吧。”这是一位工程师的原话。Pm要对进度负责，压力很大，但是预留时间是一定要的。
不能完全避免但短期内可以改善的：
需求变更，这是回答中出现平率最高的一个词汇。但是，要让开发人员失望的是，因为种种原因，这个问题并不能完全避免，PM能做的就是尽量在交付开发之前将尽可能多的问题都考虑到，使可能发生改变的需求讲到最少;另外一个就是要杜绝需求的往复性变更，不要让从方案A改为方案B之后觉得不行，又改回方案A。
**次数太多：要避免口头交代，显然不现实，再完美的文档也无法代替口头上的直接交流。但频繁的口(头)交(流)可能会打断工程师的思路，延缓进度。PM可以做一是尽量完善你的文档，第二个就是尽量在一次口头交流中集中讲完尽可能能多的事情，从而减少次数。
问：调研不彻底，开发测试后，才发现问题，费时费力
答：做一些大家都无经验的项目时，在需求调研阶段不能想的全面，导致开发做无用功。我记得很清楚的是，我们有个使用Docusign来跟客户签约的功能。需求阶段，我们只考虑技术实现，没有考虑成本问题。开发做完测试后才发现，这个功能是要按签名的合约进行收费的，告诉boss后，直接被砍掉了。当时我们花了2个周期的工作成果，就这样无端浪费了，想想都觉得心里不舒服。之后，我们在做需求的时候，就考虑全面了，成本、风险，资源一定是必填项。
大家学到了多少？如果意犹未尽，可前往课课家官网直接查看，希望大家获益匪浅哦！！！