如何做好一个产品经理及项目经理_产品经理VS项目经理的区别

本篇文章作者通过高效的思想和高效的实践两方面建立了自己的高效产品循环，给各位产品经理作参考。

记得有一篇文章写道：产品经理是一个很琐碎的岗位，没有两把刷子请不要随意入坑。

诚然，逻辑上并没有问题，产品经理工作琐碎的这个痛点肯定是存在的，那么我们的方案是什么？我想用自身的案例来和大家探讨：如何通过梳理和总结，让我们的工作走向高效？接下来我会分2部分：高效的思想；高效的实践。

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

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

举个例子来说：「让专业的人做专业的事」就是高效的指导思想，这句话让PM更多去思考产品上下游整体逻辑而不是沉迷在交互图里画一天。

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

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

所以想高效工作，我总结了5条指导思想如下，大家可以自己体会一下：1. 让专业的人做专业的事不要把时间浪费在自己不专业的事上，不专业只会带来更高的成本。

如果有同事不专业，请让领导重新调整架构，而不是随便干预别人的工作。

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

2. 没有解决不了的问题如果遇到一个困难，停滞不前，可能是你的思考没有到位。

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

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

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

3. 数据比道理更直接如果团队无法达成共识，请用严谨的数据向大家表明事实。

同时，自己提出决策的时候，也要有数据支撑，否则后续被别人挑战的时候，永远都会措手不及。

4. 先想好再做越紧急的项目，越要想好。

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

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

所以我认为，起码要用MVP思维把逻辑跑通，而不要急于向用户展现些什么。

这种挫败感对于整个团队都是很难消化的。

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

做事恰到好处，不仅仅在于程度，更在于时间。

时过境迁，很多时候你再回头看你的GTD列表，你会发现有些需求不必做了，有些事情本来不重要，现在紧急了。

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

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

二、高效的实践我是怎么做的呢？我想用时间线来展示一下我的日常。

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

比如下方是我在agenda创建的project，主要是总结我近期要研究的东西。

那么每一个小项目内部代表着我对这件事的疑问和研究重点。

这样可以保证我一闪而过的念头不会流逝。

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

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

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

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

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

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

大概长下面这个样子。

有了这个表，我可以一目了然看到我在做的需求点，有哪些环节没做。

这个可以保证我工作流程的完整性和条理性。

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

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

需求做好了，该写PRD落地了。

我会用尽量贴切于开发思维的语法来行文，而不是随心所欲的讲故事。

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

这里的语法，我是借用了cucumber的思想，这里简单介绍一下：cucumber是一种可以使用文本描述语言来执行自动测试用例的工具，使用的语言叫做Gherkin。

Gherkin用于描述软件的行为而不需要了解具体的实现，使用Gherkin主要有两个目的文档和自动测试用例（我们希望能够和手工测试用例也统一）。

Gherkin支持超过40种语言，包括英文、中文。

Gherkin可以在任何地方新增注释，注释以#开头，每一个文件都是已.feature结尾，在feature文件中输入功能描述、场景、步骤，当执行这个功能时每一个步骤都需要编写ruby代码块来实现具体的功能，当前cucumber支持多种语言，除了ruby还可以使用java、javascript来编写具体定义层的实现。

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

基本语法为：此处举例两种区别一看即知（1）简单一点ScenarioGivenWhenThen（2）复杂一点And（3）释义Feature：用来描述我们需要测试的模块，模块1，2，3……Scenario：用来概述功能测试点 如：add/deleteGiven：前置条件，比如用户在哪个页面进行 *** 作？When：描述用户 *** 作的执行动作，比如click/saveThen：断言 表示执行的结果But一个步骤中如果存在多个Then *** 作，第二个开始后面的Then可以用But替代（注意是可以，也可以用Then）。

这样我们大概形成的PRD会长下面这个样子：完成之后，我们就要跟进开发落地了，我会梳理出日程表、建立站会机制加到自己的日历中，定期碰头。

在闲暇的时候，就继续检视自己的GTD列表，来进行下一个事项。

如果遇到打断等情况，没关系，直接放下手头的工作去处理即可。

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

至此，我的高效产品循环就完成了。

请各位参照自己的情况来建立上述流程。

以上，感谢