产品经理年终总结时，用得上的职场工作Tips

编辑导读：2020年转眼只剩下最后的10天了，大家又要开始忙着年终总结和明年计划了。辛苦了一年，年终总结该如何写？本文作者从实际工作出发，结合自身经验，分享了写好年终总结的几个Tips，供大家借鉴。

到了12月，每个公司都在做年终总结。回顾这一年的工作，分享3个我觉得不错的职场工作tips。

一、为你的下游提供清晰的工作界面

有人提出过：企业存在的意义是什么？

答案是：随着现代工作的复杂度增加，企业通过分工，可以创造出了比一个个单体更大的价值。

通过分工可以让单个个体专注所负责的工作，从而更专业，进而提高整体工作效率。

但分工也带来了上下游如何有效衔接的新问题？

在工业时代，一条流水线上可以定义好每个节点的产出物，从而有效地串联起上下游。

到了信息化时代，定义清楚上下游衔接的产出物，变得尤为关键。不同部门间，或者一个部门内的不同岗位间，如何将上游的工作成果有效地传递给下游，让下游可以清晰、高效地开展下一步的工作，是每个管理者思考的重点。

留心观察，会发现一名优秀的工作人员，通常TA会有全局观，TA除了会做好自己的节点的工作，还会考虑到下游如何顺利接过TA的工作。

以我从事的软件工作为例，一般常见的可划分为产品、UE、UI、前端开发、后端开发、测试这6类岗位。

一名高级产品经理，提供的原型会说明清楚业务流、功能列表、功能界面内容、业务规则等关键信息。

接手的UE人员可以通过产品经理的开会宣讲或原型文件，快速了解如何做好页面排版布局、页面交互。

如果你认真思考下，会发现为你的下游提供清晰的工作界面，同样适用于你自己的工作：

管理者需要为下属提供清晰的工作目标；

跨部门的协作，你需要为工作下游提供你负责的任务的工作完成清单。

做好这一点，一方面你自己会获得归纳、总结的结构化能力；另一方面你的下游接手起你的工作也会更游刃有余。这样双赢的事，何乐而不为呢？

二、凡讨论，就要有共识性的结论

可能是所从事的工作性质的原因，软件工作中不论是需求、设计、开发、测试任何一个环节都要有确定性的结论。这样的工作性质，也影响了从业者们对待每一次讨论，都要有个共识性的结论。

回到每个人的工作，为什么发起人要先拿出一个可视化的东西（如一份思维导图、PPT等），让参加人的讨论更聚焦？

因为参与讨论的每个人的思维习惯不同，有的人喜欢发散，有的人喜欢聚焦，有的人可以做到两者兼而有之。

一场讨论，如果发起人没有先拿出一个可视化的东西，讨论过程就容易失焦。讨论到最后，也往往没有共识性的结论。

为什么要特别指出“共识性”？

每个人的岗位不同，视角往往也不同。在讨论环节可以发散，每个人都从各自视角提出问题与建议。收集完大家的意见后，最终发起人得分类、归纳大家的意见，然后根据自己的问题从中寻找出可行的方案，向大家阐述自己的想法，与大家形成共识性的结论。

任何一场讨论，除非出现了不可控的因素，否则都应该达成共识性的结论。这个结论一般是经过讨论、博弈后相对的最优解。

否则，就相当于大家一起白忙活了一场。久而久之，大家对开会、讨论也会失去信心，没结论也就代表每个人前面的献计献策白忙活了。

三、每个作品都要有对象感

​从事产品经理岗位的这几年以来，我逐步形成了一个工作习惯：我现在要提供一份文档、做一场分享（统称为作品），我要先想清楚对方是谁？TA大概有什么知识结构？

不要小看这件事，回想下我们身边很多年龄大、经验丰富的人，都不一定会意识到这点。心理学领域，有个概念叫“知识的诅咒”。通俗地说，就是一旦你知道了一个信息（学会了一样东西），你就很难想象那些不知道该信息（没学会该东西）的人的困惑。因为你已经知道的那些信息“诅咒”了你。

前几天我找一家软件厂商提供一份关于项目进度的说明，告诉对方说财务年底要做账，需要知道当前项目的进度。

对方回复我ok。几天过去后，先提供了一个版本给我，内容大意是项目分为三个阶段，每个阶段有什么模块内容，现在完成了哪些？

我一看，文档有2个明显的问题：

如果你是一名项目成员，大概可以明白做了什么？但是不知道这些到底占总的进度的比例是多少？

文档中充斥大量系统的专业名词，会让非项目成员的其他读者觉得自己很傻，产生一堆困惑。

我给了对方一个建议：我们这个文档主要是看财务看，所以建议以项目进度比例来讲述。

比如：

项目分为3个阶段，每个阶段各占XX%比例的工作量

截止12月底完成了每个阶段的哪些重要里程碑节点，这些节点分别占本阶段的YY%比例

最终汇总起来，每个阶段的工作量占比*该阶段完整的比例，就是整个项目完成的进度比例。