产品经理可能经常会犯的错误有哪些。我想了想，整理了很多可能会犯的错误，但发现大多数问题是表象的。唯有一条是很多人常犯的而且发生时很多人甚至意识不到自己在犯错的问题——那就是很多产品经理在做“称不上有错的但未必是正确的事情”。
实现一个目的有很多方法，但往往会选择最容易想到的而不是最好的方法。这样就导致花了大量精力在没必要的事情上，其一，你做的事情其实应该是别人做的；其二，你做的事情应该有避免重复劳动的更高效的方法。
一、协作管理
协作的核心在于，如何在同一个目标即“实现好的产品”下共同合作，实现共赢。在《高效能人士的七个习惯》一书中提到了“双赢思维”，描述了我们在人际交往中最重要的指导思想。作为产品经理，跟其他部门的协作在很多情况下并不存在标准的答案，问题常常出在沟通不力、交流不通畅等原因上。所以在协作上要保证的是，每次遇到问题要让大家在情理都可以接受的范围内解决掉，而不是从逻辑上证明到底谁对谁错。这里提供一些管理协作的方法作为参考。
1、与技术人员的常规协作
在第8章里，已从需求管理的角度描了跟技术人员间需要协作的事项。其中可行性评审，以及后续的很多评审都是协作中的关键。评审最重要的目的就是正式场合下的沟通，意义在于：
第一，确保产品经理对产品的要求传递给了技术人员；
第二，确保技术部门的意见得到了表达；
第三，双方对共同认可的内容予以确认。
缺了第一项，技术人员可能做错功能；缺了第二项，技术人员可能中途才发现问题，不得已返工；缺了第三项，最后出了事大家扯皮的时候可能发现不了问题，找不到源头。
2、与技术人员协作的临时状况
常规协作不能覆盖所有情况，临时状况也会层出不穷。最常见的是紧急新增或者修改需求，以及要求提前上线。遇到临时状况，势必引起技术部门的不满，因为绝大多数情况下会影响他们正常工作，导致加班，最轻的情况也可能让他们之前的很多工作白费。所以这时候产品经理首先要安抚，不要拿“这不是我决定的啊”“你要有大局观”这样的话反驳同事，而是表示理解他们的情绪，帮他们想办法，如果加班，尽量也来陪同他们加班（这不是必须的，但是很有效的）。
其次，再去解释原委，而不要一句话“就是这么要求的”来应付，要主动解释背景，最好是详细的并且有理有据的解释。技术部门的同事并不是不在意业务的，他们也会理解业务的困难，以他们的逻辑思考能力，当然也能知道业务上遇到的变数是怎样带来当下无奈的后果的。
如果有异议，那么就在节点尽快解决，拟定解决方案。如果原本拟定的规划和推进的情况都没有问题，但需求方临时变卦或者有其他要求，那么就可以驳回。
如果是客观原因导致的完成情况有问题、有延期，也要跟需求方的同事有理有据地解释清楚，同样是动之以情、晓之以理。
实际上，侯世达定律提到了，“做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律”。掌握如何在延期的时候安抚需求方，是每个产品经理必备能力。
4、双赢心态
在跟同事的协作当中“双赢”是很重要的思想。在很多语境里，产品经理和程序员都是对抗的关系，这让很多产品经理误把程序员当成“要处理的问题”。跟程序员有良好的协作确实是要认真对待、当成一项任务完成的，但把程序员本人当成问题，却容易把他们变成对抗的、有矛盾的一方。
在遇到问题时，有的产品经理首先想的是说服程序员，想要“赢”。有时很多问题是需要妥协的，在一些并没有太大影响的细节上跟程序员争执，看起来结果是取胜，但事情却往更糟的方向发展了。程序员会变得不信任你、不喜欢你，在未来的工作中，也视你为威胁。你会发现有的团队任何冲突都需要第三方调解，那就是协作上有严重的问题了，而且不会是需求功能方面的问题，而是由不信任造成的问题。所以在判断事情如何解决最有利时，要确保是“对大家有利”以及“对产品有利”，而不是“对我有利”。这样的心态才能确保协作的价值最大化。
除了上述流程层面的协作之外，在具体的协作形式上开会和记录都是必备的工作环节。以下是一些建议。
1、开会
开会时最重要的是讲规则。规则有很多种，越多人参加的议题，越复杂的会议越需要规则。最基本的规则有：
? 针对拟定的主题讨论，其他无关议题禁止讨论或者加会再讨论。
? 讲求发言顺序，不能争抢和吵闹，最好有主持人。
? 禁止人身攻击，避免太过情绪化的讨论。
? 会议要对原定的主题输出结论，如果没有结论，要制定解决方案（比如由于信息不全面无法决定，要设立日期再议）。
这些基本规则可以保证会议顺利进行，也可以视情况加入更多机制，尤其是极为正式和重大的事项讨论。可以参考《罗伯特议事规则》一书中提到的很多基本的辩论规则和表决规则，多年来一直是美国国会和法庭上大家遵循的指导思想。
2、记录
产品经理接触的很多工作都需要知道思考的过程和结果，这些内容如果不记录下来，那么经过一段时间几乎不可能都回忆起来。记录的意义在于，任何时候在工作流程中的许多思考、分析和讨论的内容都可以沉淀下来。
作为产品经理，至少要对以下内容记录有所关注。
1．文档文档（需求描述）
再小的需求描述也要有一定的记录，至少要在邮件当中有所体现。最好要求统一撰写完整的需求文档。
大部分团队很少有把文档的整理和维护做得很好的，文档都是跟随迭代走，每迭代一份文档只关心当前修改的内容，没有针对产品完整的需求文档。这样对新来的产品经理、技术开发及各个部门的同事都是不够友好的，没有办法了解现在产品的全貌。对要查阅当前产品情况的老同事也同样是困难的。所以建议在有余力的情况下，还是要把完整的产品功能描述文档整理好，产品有迭代时在上面做记录。
2．会议记录
任何会议都要有记录。如果是小团队作战，在时间精力有限的情况下，可以简化格式但不能丢弃记录的环节。大致来说，记下主要的讨论节点和最终认同的结论就可以了。会议记录可以找专人来记，也可以大家轮流记。会议结束后，实时发出，大家就可以依照这次记录的内容来执行已经认可的方案了。
二、流程管理
在软件开发中，有句广为流传的话：不要重复造轮子。意思是如果存在一些别人做过的框架和脚本，那就不要花费时间自己再去写，不用再重复别人的工作了。
对产品经理来说，为达到不重复造轮子的目的，有几种方法可以参考。
第一，协作标准化和流程化。不管是产品内部协作还是部门间协作，很多工作是可以标准化形成流程的。大家恪守同样的规范协作，效率必然是最高的。
第二，减少手工劳动。如果你发现大量的时间花在毫无价值的手工劳动上，那就要反思是不是要想办法解决这个问题了。
第三，让一些工作可复用。复用也是软件开发中经常用到的词，指的是可以重复利用在别的地方。产品经理的很多工作其实也是可以复用的。
第四，避免重复犯错。遇到问题时解决问题自然很重要，但避免下次再犯更加重要。
三、个人管理
1、任务管理
经常会掉进一些陷阱：
1）把表现出来的焦急当成任务的紧急程度。我们接到的任务或者自己给自己定的任务，经常会受到情绪上的影响。A每天催我们两三次，B一周才催我们一次，就习惯性地以为A更着急，把他给的任务当成更重要的。或者我们对任务甲的兴趣更大，潜意识里就给它比任务乙更重要找了很多借口。
2）把充实感当成完成任务。在工作到身心疲惫时，总会产生充实感，觉做了很多事情。可是任务的完成并不以充实感为准，而是以真正产生的作用为准。
3）眼光不够长远，只做半衰期短的事情。用半衰期长短和收益大小一起来衡量事情的价值，是采铜在《精进》里提到的。半衰期长是指带来的收益可以持久地对我们产生影响，而半衰期短则是短暂、甚至一次性地对我们产生影响。因此在衡量事务之间的重要程度时，不要只看它们带来收益的多寡，更要看这个收益的持续时间。
4）不设截止日期。无论多么不紧急的事情，一定要设定截止日期。不然任何紧急的任务都可以插到前面，所有不紧急的任务都无限期地延后了。对一个不紧急的任务设定了截止日期后，肯定不是马上开始动手做的。但快到它的截止日期时，这个任务就变成了紧急的、必须要完成的任务。
5）不检视效果。除了把充实感当成任务完成的标志之外，还要不断反思、复盘每件任务完成的效果是不是达到了目的，或者以怎样的程度完成了设想。跟前文提到的工作流程中的复盘一样，对自己处理事务的方式、方法也要有把控，把任务拆解开来找出做得不够好的地方，然后判断如何做得更好。
2、知识管理
知识管理指的是要把很多知识、信息记录在案，方便以后查阅。这是基于一个假设：我们不能记住全部所学、所见的知识。
3、团队管理
? 专业技能服众
? 管理技能
领导技能是指一些要修习的专业技能，包括制定团队规划、对团队成员的工作进行评估、营造好的工作氛围、为团队获取必要的资源，等等。
时间管理在上一节就提到了，对领导来说在关注个人事务的同时，还要关心整个团队的任务，懂得怎样评判任务的优先级和时间规划，并且恰当地安排给合适的人。
工作理念则是最重要的。作为领导要转换思路，把团队的得失当成自己工作的得失，借由他人成功而不是自己成功。很典型的例子是当下属遇到问题时，不要自己冲上去说“还是我来吧”，而是要指导下属注意哪些事项，指导其把问题解决掉。作为领导，带出一个优秀的下属，比让自己优秀重要。
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！