产品经理必修课（9）：工作流中的管理

一、协作管理

在产品经理的职位要求里，无一例外都会提到“沟通能力”。协作、项目管理、产品跟进、迭代安排等，很多产品经理的分内之事。不过，单纯的沟通是解决不了问题的。

协作的核心在于，如何在同一个目标即“实现好的产品”下共同合作，实现共赢。在《高效能人士的七个习惯》一书中提到了“双赢思维”，描述了我们在人际交往中最重要的指导思想。

作为产品经理，跟其他部门的协作在很多情况下并不存在标准的答案，问题常常出在沟通不力、交流不通畅等原因上。所以在协作上要保证的是，每次遇到问题要让大家在情理都可以接受的范围内解决掉，而不是从逻辑上证明到底谁对谁错。

这里提供一些管理协作的方法作为参考。

与技术人员的常规协作

在前文中，我们已经从需求管理的角度描述了跟技术人员之间需要协作的事项。其中可行性评审，以及后续的很多评审都是协作中的关键。

评审最重要的目的就是正式场合下的沟通，其意义在于：第一，确保产品经理对产品的要求传递给了技术人员；第二，确保技术部门的意见得到了表达；第三，双方对共同认可的内容予以确认。

缺了第一项，技术人员可能做错功能；缺了第二项，技术人员可能中途才发现问题，不得已返工；缺了第三项，最后出了事大家扯皮的时候可能发现不了问题，找不到源头。反思一下之前跟技术部门协作中出现的状况，是不是大多是这三种里面的一种呢？

对于较大的需求也就是较复杂的功能，建议多进行几次评审，拉长进入开发前的准备时间是有帮助的。

与技术人员协作的临时状况

常规协作显然不能覆盖所有情况，临时状况也会层出不穷。最常见的无非是紧急新增或者修改需求，以及要求提前上线。遇到这样的临时状况，势必引起技术部门的不满，因为绝大多数情况下会影响他们正常工作，导致加班，最轻的情况也可能让他们之前的很多工作白费。

所以这时候产品经理首先要安抚，不要拿“这不是我决定的啊”“你要有大局观”这样的话反驳同事，而是表示理解他们的情绪，帮他们想办法，如果加班，尽量也来陪同他们加班（这不是必须的，但是很有效的）。其次，再去解释原委，而不要一句话“就是这么要求的”来应付，要主动解释背景，最好是详细的并且有理有据的解释。技术部门的同事并不是不在意业务的，他们也会理解业务的困难，以他们的逻辑思考能力，当然也能知道业务上遇到的变数是怎样带来当下无奈的后果的。

总之，先动之以情，再晓之以理，事情就好解决。

与需求来源方的协作

需求来源方根据项目不同差别很大。作为产品导向的项目，可能几乎不会有外来需求。但目前可见的大部分项目还是会有营销、运营、业务等部门会提出各种各样的需求，这时的产品部门，更像是一个支撑部门。

跟他们协作，主要关心的重点是需求完成的准确程度和及时程度，所以也是类似跟技术部门的协作，要在需求管理的重要节点，跟需求来源方同步信息，确保他们认可你的方案及认可目前的进展。如果有异议，那么就在节点尽快解决，拟定解决方案。如果原本拟定的规划和推进的情况都没有问题，但需求方临时变卦或者有其他要求，那么就可以驳回。

如果是客观原因导致的完成情况有问题、有延期，也要跟需求方的同事有理有据地解释清楚，同样是动之以情、晓之以理。实际上，侯世达定律提到了，“做事所花费的时间总是比你预期的要长，即使你的预期中考虑了侯世达定律”。所以掌握如何在延期的时候安抚需求方，估计是每个产品经理必备的能力了。

双赢心态

前面提到了，在跟同事的协作当中“双赢”是很重要的思想。别小看这个耳熟能详的词，我们在处理很多事情时其实并不会意识得到“双赢”的重要性。

在很多语境里，产品经理和程序员都是对抗的关系，这让很多产品经理误把程序员当成“要处理的问题”。严格来说倒也没错，跟程序员有良好的协作确实是要认真对待、当成一项任务完成的，但把程序员本人当成问题，却容易把他们变成对抗的、有矛盾的一方。

在遇到问题时，有的产品经理首先想的是说服程序员，想要“赢过”程序员。有时很多问题是需要妥协的，在一些并没有太大影响的细节上跟程序员争执，看起来结果是你能取胜他们落败，但事情却往更糟的方向发展了。程序员会变得不信任你、不喜欢你，在未来的工作中，也视你为威胁。你会发现有的团队任何冲突都需要第三方调解，那就是协作上有严重的问题了，而且不会是需求功能方面的问题，而是由不信任造成的问题。

所以在判断事情如何解决最有利时，要确保是“对大家有利”以及“对产品有利”，而不是“对我有利”。这样的心态才能确保协作的价值最大化。

除了上述流程层面的协作之外，在具体的协作形式上开会和记录都是必备的工作环节。以下是一些建议。

开会

说到开会，我过去也认为没什么可多说的，就是讨论问题而已嘛。但随着会开得越来越多，我也慢慢体会到高效会议的重要性。如果一个会议没有有效地组织和进行，那么一大群人挤在一起浪费几个小时也是有可能的。不要小看几个小时，对很多互联网公司来说，支付这几个小时参会者的时薪也会是一笔不小的费用。

对于开会，有很多可以慢慢学习掌握的技巧。很多人并不注意会前的准备。其实如果在会前能够跟与会者预先通知大致的背景信息，甚至达成比较宽泛的共识，会议会进行得特别顺利。

会议通知邮件不要写成“各位，下午2点在会议室2开会，请大家按时出席”，这样是极糟糕的写法，完全可以做得更好，说清楚会议的主题和内容，以及大家需要提前准备的阅读材料。比如“各位，下午2点在会议室2召开‘校园群体用户需求讨论会’，希望大家提前做好准备，调研相关的信息。附件中有部分背景材料，推荐阅读。”

除了通知的内容翔实之外，还可以尽可能地与重要的参与者事先做一下沟通。尤其是比较重要的讨论会，预计会有很多矛盾和冲突要解决，如果提前能私底下达成基本共识，会上就能少费很多力气，因为毕竟在非正式的环境下氛围会轻松很多。

开会时最重要的是讲规则。规则有很多种，越多人参加的议题，越复杂的会议越需要规则。

最基本的规则有：

• 针对拟定的主题讨论，其他无关议题禁止讨论或者加会再讨论。

• 讲求发言顺序，不能争抢和吵闹，最好有主持人。

• 禁止人身攻击，避免太情绪化的讨论。

• 会议要对原定的主题输出结论，如果没有结论，要制定解决方案（比如由于信息不全面无法决定，要设立日期再议）。

这些基本规则可以保证会议顺利进行，也可以视情况加入更多机制，尤其是极为正式和重大的事项讨论。可以参考《罗伯特议事规则》一书中提到的很多基本的辩论规则和表决规则，多年来一直是美国国会和法庭上大家遵循的指导思想。

记录

对很多疲于跟同事扯皮的产品经理来说，记录可能尤为重要。大部分事后发现之前的环节出了问题时的扯皮，都可以用历史记录来回溯问题的源头。如果没有办法找到，也就死无对证了只好就这么过去。

产品经理接触的很多工作都需要知道思考的过程和结果，这些内容如果不记录下来，那么经过一段时间几乎不可能都回忆起来。记录的意义在于，任何时候在工作流程中的许多思考、分析和讨论的内容都可以沉淀下来。

作为产品经理，至少要对以下内容记录有所关注。

1.文档

文档（需求描述）一般都会写，但很多产品经理对零碎的需求并没有记录，都是直接跟工程师们打声招呼，口头说一下或者在微信上提一句。这样做是很危险的。

再小的需求描述也要有一定的记录，至少要在邮件当中有所体现。最好要求统一撰写完整的需求文档。

说到需求文档，大部分团队很少有把文档的整理和维护做得很好的，文档都是跟随迭代走，每迭代一份文档只关心当前修改的内容，没有针对产品完整的需求文档。这样对新来的产品经理、技术开发及各个部门的同事都是不够友好的，他们没有办法了解现在产品的全貌。对要查阅当前产品情况的老同事也同样是困难的。

所以建议在有余力的情况下，还是要把完整的产品功能描述文档整理好，产品有迭代时在上面做记录。

2.会议记录

任何会议都要有记录。如果是小团队作战，在时间精力有限的情况下，可以简化格式但不能丢弃记录的环节。大致来说，记下主要的讨论节点和最终认同的结论就可以了。

会议记录可以找专人来记，也可以大家轮流记。会议结束后，实时发出，大家就可以依照这次记录的内容来执行已经认可的方案了。既然是大家认同的结果，那么邮件的内容就是执行的标准了，谁都不能赖账。

3.想法和思路

有些稍纵即逝的想法和思路要及时记一下，以防忘记。可以用常见的在线笔记应用，也可以用纸笔记录。

4.其他事项

产品经理在工作中也经常会遇到上述情况之外需要记录的场景，比如在写文档时有同事说了一个简单的需求，你可以先记录下来。比如跟技术部门的同事讨论出了方案，也可以做简单记录。总之，你觉得以后可能会忘、可能有回溯需求的，都应该事无巨细地做一下记录。

二、流程管理

有很多对产品经理工作流程的管理和改进，其价值可能远超我们的想象。

其实我们面对的互联网产品，从根本上讲就是用很多全新的组织方式在运作的，我们正享受着它们带来的高效福利。甚至从工业时代开始，我们就在享受标准化、流程化以及高效工作带来的好处。用几个字来描述它的价值，那就是——不用再重复造轮子了。

在软件开发中，有句广为流传的话：不要重复造轮子。意思是如果存在一些别人做过的框架和脚本，那就不要花费时间自己再去写，不用再重复别人的工作了。

对产品经理来说，为达到不重复造轮子的目的，有几种方法可以参考。

第一，让协作标准化和流程化。不管是产品内部协作还是部门间协作，很多工作是可以标准化形成流程的。大家恪守同样的规范协作，效率必然是最高的。

第二，减少手工劳动。如果你发现大量的时间花在毫无价值的手工劳动上，那就要反思是不是要想办法解决这个问题了。

第三，让一些工作可复用。复用也是软件开发中经常用到的词，指的是可以重复利用在别的地方。产品经理的很多工作其实也是可以复用的。

第四，避免重复犯错。遇到问题时解决问题自然很重要，但避免下次再犯更加重要。

让协作标准化和流程化

协作里面大家最讨厌的就是扯皮，无休止的争论和辩解特别低效，问题最后能解决但过程都很痛苦。让一些事情变成标准，大家对某些原则达成共识，遵守同样的规范就会有显著改善。

把一些东西做成流程，要在合适的时机，用合适的方法。有的产品经理太过于追求刻板固定的方法，四处找人问：“什么样的方法最好呀？”“该用什么协作工具啊？”“文档该怎么写开发最满意啊？”然后把别人的经验直接拿来复制，结果可想而知。这也是为什么很多中小规模的团队，一直反对使用大公司的协作流程的原因——成熟的机制并不适合所有情景。

还有些产品经理则矫枉过正，不喜欢标准化的思路，只喜欢解决眼下的问题。有了“坑”，要去想怎么“填”，而不是去想怎么用机制来解决掉，这样下次还是会犯同样的错误。

所以掌握该让协作流程化的时机，是需要产品经理的深入思考和尝试的。当你意识到很多问题正在重复出现，很多协作沟通的规范能带来显而易见的好处时，就应该是尝试制定规范的时候了。

我就遇到过一个印象深刻的例子，事情发生在跟业务部门协作时。起初我们提需求、安排需求的流程是空白的，也就是大家经常口头去提，甚至在哪天坐电梯碰上了，就随口一说，产品经理答应下来就着手去做。在刚开始需求不多、功能简单的情况下，倒没出什么大问题，但随着提的需求越来越复杂，参与协作的人越来越多，这么做就不合适了。经常出现我们做的功能他们不满意的情况，从他们的角度看，是我们产品部门不积极配合完成他们的需求，而从我们的角度看也很无辜，我们是按照他们的意思在按部就班地做。

后来针对跟业务部门的协作，我们制定了以下规范：

所有需求必须通过邮件提出。否则，不予理会。（目的：为了记录需求内容和明确责任人。）

业务方的需求提出者是固定的接口人，不接受其他人的需求。（目的：业务方过去经常在未达成内部一致的情况下提需求，造成麻烦。）

产品这边接收方也设立固定的接口人。（目的：防止需求重复设计、由一个人统筹外来的需求。）

需求的状态每周固定时间发布。（目的：让需求来源方放心，了解需求正在推进的状态。）

有延期的需求，发送邮件给相关需求方，告知原委。（目的：让需求方了解延期的原因。）

此后，虽然偶尔还是会发生少量的扯皮，但整体协作顺畅了很多，看似是多做了一些工作，但总的来说从实际上减轻了大家的负担。

减少手工劳动

很多产品经理意识不到有些手工劳动是可以想办法抵消的。最有代表的例子就是对工具的运用。

在最早做产品时，我经历过最简陋的需求管理是用Excel。大家用一张表传来传去，维护起来极不方便。更重要的是没有改动的记录，也没有提醒，很多工作都要人工完成，Excel表格实际只提供了单纯记录的作用。

后来我们开始用 Google Docs的表格做记录就好了很多。我们每个人可以在自己的电脑上对同一个表格编辑，这样就初步达到了协作的目的。但还是会有些问题，比如 Google Docs的网络不稳定、搜索筛选不太方便等。

再后来，我们发现有一款在线协作的产品能更好地解决需求管理的问题。不仅能协作，还能有更改记录和重要提醒，有不同的权限设置，以及各种各样的筛选搜索方法。最终，这款产品让我们大喜过望，在此后的工作中，需求管理比最初要高效不知多少倍。我们开玩笑说，果然技术是第一生产力。

在 iOS上有一个应用叫做 Workflow，推荐给大家使用。如果你能掌握用Workflow完成一系列手机操作的方法并理解它的精髓，那么你就能明白工具是如何通过减少手工劳动让工作变得高效起来的。

除了要学会发掘能够替代手工劳动的工具之外，还可以学习一些好用的脚本代码，在数据处理方面会有奇效。有很多计算机专业出身的产品经理经常自己快速处理数据，能节省很多工夫。在过去时间比较紧急的时候，我们的产品部门要修改文案，为了节省时间，产品经理甚至亲自去代码里做处理。

让一些工作可复用

在软件开发中可复用是极为重要的概念，在UI设计中可复用不仅意味着节省工作量，还意味着视觉逻辑的统一。产品的工作类似于后者，可以有一些参考。

例如，最简单的是在做原型或者交互时，可以有很多元素和模块做成可以重复利用的，不用每次都花时间考虑制作。再比如，在制定一些话术或者文案时，先考虑一套大概的逻辑，警告、提醒、解释说明等不同类别的文字应该怎么表述，有了一定的规范，后续再有新的设计就可以快速完成、不用从头考虑了。

避免重复犯错

前文提到了，在遇到问题时解决问题固然重要，但避免下次再犯同样的错误更加重要。在工作中，问题的出现意味着期望跟现实有脱节。虽然可以简单粗暴地说是“做得不够好”，但这并不是找到根本问题的方式。有时即使我们尽了最大努力，事情可能还是会出问题，可能存在于流程中、存在于其他环节。我们可以尝试先找出哪里出了问题。

第一，犯错是由于疏漏所致。疏漏是指并没有意识到、没有想到会出问题。比如逻辑不健全，比如应该跟谁确认的步骤没有去做等。疏漏在直觉上是要通过“以后多注意”来解决，但更多情况下的疏漏是需要去做些实际的改善去解决的。逻辑不健全可能需要分析没考虑到的原因，也许是逻辑链条的某一环根本没注意到，要把功能逻辑多做拆分，就会知道以后思考类似问题时，思路是怎么样的了。

而对于某些遗漏的环节，可能需要通过制度或者流程机制来解决。把整个流程步骤梳理出来以后，严格按照这个步骤的顺序去做，那么到了该跟谁确认的环节就肯定不会有遗漏了。

如果涉及比较严重的事故，那么可能需要参与的所有成员一起开一个复盘会议，大家共同商讨出现问题的原因、责任人，以便梳理出一个切实的解决方案。

第二，犯错是由于信息不全面、知识不完备所致，并不是意识不到，而是根本不知道这个问题的存在。很多产品经理会掉到这个坑里，尤其是在做涉及传统行业的产品，知识需要更新，不然就会按自己想当然的方法去做。

这样的错误想避免，当然不难，方法就是不断学习。产品经理不应该只关注需求本身、设计本身，更要关注信息的输入。功能只是输出，足够的输入才能带来良好的输出。

第三，犯错是由于没有责任心所致。原本可以做到不遗漏，也具备了相关的知识和信息，但仍然因为不够上心出了问题。这才是大家常说的“做得不够好”的情况，这时产品经理就需要提高自己的责任心了。这样的情况比较严峻，可能要自己做反省和检讨，看心态在哪里出了问题，是不是该做些调整。

第四，犯错是由于能力无法胜任所致。这种情况是许多产品经理忽略的，因为我们都会对自己有些盲目的自信。但很多任务我们完成不了，到处都是问题，则很有可能是因为我们的能力所限。在这种情况下，要积极配合团队，看如何做调整，比如考虑是否补充更多专家和有经验的人进入团队。不要贸然上阵、继续折腾，否则最后你得不到成长，对团队也产生不了价值。

三、个人管理

不懂对自己的事务进行管理的产品经理，绝不可能成为优秀的产品经理。有些人直到高中（有的人则是大学）都一直在被人管理，白天按照规定上课自习，晚上按照规定完成作业，每个阶段的学习都是老师规划好的内容，再按照规定参加考试。有的人失去别人的管理立刻就变成了无头苍蝇，不知该做什么。很多人表面上似乎在努力学习、工作，但最后却毫无收益。

产品经理的个人事务繁多，轻重缓急不一，更需要掌握良好的自我管理能力。清楚自己在做什么，并且了解未来一段时间内应该做什么。而那些没有时间观念、没有自我管理观念的人，就算天天熬夜、日日勤奋，也只能获得毫无意义的充实感。

任务管理

个人管理最基本的就是规划好未来要完成的任务并且做好记录，有需要提醒的任务，还可以用邮件或者手机通知等方式来设置提醒。

对需求的管理可以类比到个人任务的管理中来。对任何任务，心里要做一个优先级的排序及性价比的排序。它是最重要的吗？它有时间要求吗？心里有了分析，在自己的任务列表里体现出来，再按照排序去逐一完成。

这些方法很多人都懂，只不过我们经常会掉进一些陷阱。

1.把表现出来的焦急当成任务的紧急程度。

我们接到的任务或者自己给自己定的任务，经常会受到情绪上的影响。A每天催我们两三次，B一周才催我们一次，我们就习惯性地以为A更着急，把他给的任务当成更重要的。或者我们自己对任务甲的兴趣更大，潜意识里就给它比任务乙更重要找了很多借口。

2.把充实感当成完成任务。

在工作到我们身心疲惫的时候，总是会产生充实感，觉得我们做了很多事情。可是任务的完成并不以充实感为准，而是以真正产生的作用为准。做调研时分析了一整天报告，看得眼都花了、手都在抖，认为调研任务圆满完成了，但其实反思下来并没有看到几篇有价值的报告。要反省这么劳累还没有产生价值，是不是调研的方法有问题，而不是自我感觉良好。

3.眼光不够长远，只做半衰期短的事情。

用半衰期长短和收益大小一起来衡量事情的价值，是采铜在《精进》里提到的。半衰期长是指带来的收益可以持久地对我们产生影响，而半衰期短则是短暂、甚至一次性地对我们产生影响。

因此在衡量事务之间的重要程度时，不要只看它们带来收益的多寡，更要看这个收益的持续时间。比如遇到了问题时，读几本理论艰深的产品方面的书自己去考虑解决方法，当然不如直接找到前辈询问建议来得实惠。但长远来看，显然就不是这样了。

4.不设截止日期。

无论多么不紧急的事情，一定要设定截止日期。不然任何紧急的任务都可以插到前面，所有不紧急的任务都无限期地延后了。

对一个不紧急的任务设定了截止日期后，肯定不是马上开始动手做的。但快到它的截止日期时，这个任务就变成了紧急的、必须要完成的任务。我们都遇到过那种想学一个技能却拖来拖去发现最终干脆放弃了的经历，这就是因为我们根本没有规划、没有给截止日期造成的。

5.不检视效果。

除了把充实感当成任务完成的标志之外，还要不断反思、复盘每件任务完成的效果是不是达到了目的，或者以怎样的程度完成了设想。跟前文提到的工作流程中的复盘一样，对自己处理事务的方式、方法也要有把控，把任务拆解开来找出做得不够好的地方，然后判断如何做得更好。

知识管理

知识管理指的是要把很多知识、信息记录在案，方便以后查阅。这是基于一个假设：我们不能记住全部所学、所见的知识。这个假设在我接触到的产品经理中是广泛存在的，大家都很少有天才般的过目不忘的能力，那么把接触到的有价值的信息记录下来就是必要的。

所幸我们生活在信息时代。在用电子设备之后，我们处理信息最方便的一点不是能够快速复制，也不是能够大量存储，而是我们可以让信息结构化并且可快速检索。

过去用纸、笔记录内容，我们只能按照顺序来写。如果要分门别类，甚至有多级层次记录，那么只能拿一大堆本子分别来记。记完之后想要查询，也特别麻烦，可能会一时想不起记在了哪里。

现在我们可以把内容快速整理到不同的层次结构里，可以有富文本的格式，可以贴图贴表格。在检索的时候也能全文搜寻，快速定位到要找的内容。

图9-1就是使用Evernote中专门用来记录产品方面知识的笔记本，可以把不同的知识点和资料丢进对应的模块里。在定向复习和思考对应问题时，就能很快地找到辅助的材料了。

image.png

团队管理

每个产品经理在工作到一定阶段之后，都不可避免会要学着带人，成为团队leader。常见的关于团队管理有两种误解：领导就是专业技能更强的人、能力足以服众就行；领导只需要做好管理，没必要理解业务。

其实作为产品经理的团队领导，要做到的是在专业技能上服众的基础上，掌握一定的管理技能。

• 专业技能服众

《纸牌屋》里有句话“你得先学会划船，再去学掌舵”。作为船长，可以不去做水手的工作，但不能不理解水手的工作。

我熟知的产品经理主管很多都不会亲自写产品文档，但仍然会对团队里的产品经理撰写的文档进行审核。在这些主管中有自己写过几年文档的，就可以立刻看得出文档中的错漏。只要他们还能在产品文档中看得出问题，那就证明他们的专业技能是在能服众的状态。

如果一个领导每次都表示对下属的工作很满意，那他不会是一个合格的领导。至少对于这个下属来说，在这种没有成长的环境中，对自己不会有帮助。很有可能的情况是他很快就打算申请更换部门，或者干脆离职了。

• 管理技能

在《领导梯队》里，作者提到了作为领导应具备的三个管理能力为：领导技能、时间管理和工作理念。

领导技能是指一些要修习的专业技能，包括制定团队规划、对团队成员的工作进行评估、营造好的工作氛围、为团队获取必要的资源，等等。

时间管理在上一节就提到了，对领导来说在关注个人事务的同时，还要关心整个团队的任务，懂得怎样评判任务的优先级和时间规划，并且恰当地安排给合适的人。

工作理念则是最重要的。作为领导要转换思路，把团队的得失当成自己工作的得失，借由他人成功而不是自己成功。很典型的例子是当下属遇到问题时，不要自己冲上去说“还是我来吧”，而是要指导下属注意哪些事项，指导其把问题解决掉。作为领导，带出一个优秀的下属，比让自己优秀重要。

成长建议Ⅸ

本文所讲的都是产品经理日常工作中会忽视的，但却异常重要的地方。一个好的产品经理应当对自己正在做的事情有清晰的认知：我在做的事情是正确的吗？我在用好的方式做吗？我能用什么方法让它更高效吗？

对自己工作方式有了认知，就能有针对性地进行改善。要学习关心协作中的问题，以及个人工作中的问题。

要点反思

• 好的产品经理不仅要自己有执行力，还应推动团队提升执行力。

• 要始终避免浪费生命在无意义的劳动上。

• 出现了任何问题，避免以后再犯跟解决当下的问题同样重要。