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

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