实战：产品经理常见问题解决方案

实战：产品经理常见问题解决方案

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