全文共 2520 字 4 图，阅读需要 5 分钟

———— / BEGIN / ————

记得有一篇文章写道：

诚然，逻辑上并没有问题，产品经理工作琐碎的这个痛点肯定是存在的，那么我们的方案是什么？

我想用自身的案例来和大家探讨：如何通过梳理和总结，让我们的工作走向高效？

接下来我会分2部分：

1. 高效的思想

2. 高效的实践

那不废话了，我们开始吧。

高效的思想，是指能让我们工作变得高效的指导思想。

举个例子来说：

「让专业的人做专业的事」

这句话让PM更多去思考产品上下游整体逻辑，而不是沉迷在交互图里画一天。

如果你把这句话套用在工作中，你就会发现很多人因为团队合作不到位，免不了去参与他人的工作，但往往这样下去都会让团队更乱。

我们要做的是培养每个岗位的专业性，把精力用在刀刃上，这是一种分工协作的高效方式。

所以想高效工作，我总结了5条指导思想如下，大家可以自己体会一下：

1. 让专业的人做专业的事

不要把时间浪费在自己不专业的事上，不专业只会带来更高的成本。如果有同事不专业，请让领导重新调整架构，而不是随便干预别人的工作。

术业有专攻，不但要给与别人专业性的尊重，也要珍惜自己的专业性。

2. 没有解决不了的问题

如果遇到一个困难，停滞不前，可能是你的思考没有到位。

任何事情都是性价比和优先级的衡量，这个世界没有不可能。

任何困难都是可以量化的，请用量化来检验自己是否清楚认识了困难。

比如，你可以跟领导汇报，这个需求需要开发1年，但尽量不要说这个需求做不了。

3. 数据比道理更直接

如果团队无法达成共识，请用严谨的数据向大家表明事实。同时，自己提出决策的时候，也要有数据支撑，否则后续被别人挑战的时候，永远都会措手不及。

4. 先想好再做

越紧急的项目，越要想好。

紧急项目之所以紧急，就是因为之前规划的时候没有想好。

我曾经急急忙忙上线过一个项目，1个月后，项目下线了，原因并不在我，而是领导改变了方向。

所以我认为，起码要用MVP思维把逻辑跑通，而不要急于向用户展现些什么。这种挫败感对于整个团队都是很难消化的。

5. 时刻检视优先级

完成一件事之后，坐下一件事之前，请务必检视优先级。

做事恰到好处，不仅仅在于程度，更在于时间——时过境迁，很多时候你再回头看你的GTD列表，你会发现有些需求不必做了，有些事情本来不重要，现在紧急了。

这就是动态调整的必要性，不要无脑做事。

下面我们看看我是怎么实践的。

我是怎么做的呢？我想用时间线来展示一下我的日常。

首先，当我接到一个需求、或产生一个想法的时候，我会大概评估一下这件事的优先级、我大概什么时候做，然后把它记录在我的GTD工具上。

比如下方是我在agenda创建的project，主要是总结我近期要研究的东西。那么每一个小项目内部代表着我对这件事的疑问和研究重点。这样可以保证我一闪而过的念头不会流逝。

当我评估完毕准备开始做事时，我会把当前要做的东西放进我的需求池，跟进进度。

需求池这个东西用很多工具都可以实现，只要适合自己就行。

比如我个人而言，需求点比较多，容易忘记汇报、通知，所以我需要当前状态字段来帮我一目了然看清楚进度。

同时因为对接业务部门，为防止扯皮，我也会记录下来初次沟通的时间，来避免背锅。

最方便的是：总结、周报、通报的时候，你直接可以把需求池略作修改粘贴上去，会很有条理。

需求池展示如下：

当我开始做需求的时候，我会掏出我的备忘表，这个表是根据项目要求不断优化的。

大概长下面这个样子：

有了这个表，我可以一目了然看到我在做的需求点，有哪些环节没做，这个可以保证我工作流程的完整性和条理性。

同样，对于不同层次的需求，可以进行酌情处理。

但有这样一份备忘给我指引方向，让我不至于陷入不知道该做什么的状态。

需求做好了，该写PRD落地了。我会用尽量贴切于开发思维的语法来行文，而不是随心所欲的讲故事。

开发并不想看故事，讲完背景之后，请直接告诉人家需要做什么。

这里的语法，我是借用了cucumber的思想，这里简单介绍一下：

总而言之，这就是一种描述框架，他建议我们把场景分清楚，然后用given、when、then的方式来梳理案例，让开发、测试一目了然我们的需求。

基本语法为：此处举例两种区别一看即知->

这样我们大概形成的PRD会长下面这个样子：

完成之后，我们就要跟进开发落地了，我会梳理出日程表、建立站会机制加到自己的日历中，定期碰头。

在闲暇的时候，就继续检视自己的GTD列表，来进行下一个事项；如果遇到打断等情况，没关系，直接放下手头的工作去处理即可。

因为我们有这一套工具和方法，足以让我们可以随时继续且高效不迷茫。

至此，我的高效产品循环就完成了。请各位参照自己的情况来建立上述流程。

以上，感谢。

———— / END / ————