​最近有人问产品经理最终的能力是什么，我说行业不一样，产品经理的工作会稍微不同，所需要的能力也会有偏向。

不过总体流程而言还是相同的。

也是机缘巧合，自己经历了中台产品、前端产品、SAAS产品，C端产品，有百万两级的也有扑街的产品，林林总总的经历多少有了些收获。

今天和大家分享下，与大家共勉。

就我个人的经验，一般拿到一个需求后，工作流程大概会分为需求沟通、需求整理、原型输出、UI设计、跟进开发、跟进测试、上线这个几个步骤。

当然，如果是小功能或者小迭代，中间的几个步骤也可以灵活的省略；看具体的项目而定，没有那么死板。

下面我就上述的几个步骤简要的说一说，各位可以参考着看。

1、需求沟通

这一步个人觉得是最重要的。

如果没有这一步，后面的流程也基本无从谈起。

面对业务流程和业务规则，业务人员或者说需求人员肯定是最熟悉的，项目的顺利进行，很大意义上由这一步决定。

有句话说得好，不怕你跑，就怕你跑错方向。

需求沟通的重要性绝对是产品经理能力中排名第一的能力，起码我是这样认为的。

一般在公司，产品经理80%的时间都是在沟通中度过。

需求提出时需要沟通，了解业务需求时需要沟通，需求整理的时候需要沟通。

因为我们需要确认业务提出的需求是正确的，而不是拍脑袋想的；

我们需要设身处地的了解需求产生的背景，需求达到的目的。

有了需求沟通，我们才有后续的流程。

所以，在这一步产品经理就是沟通、沟通、再沟通。

而这一步也是很烦人的一步，需要多次拉着业务人员理解他们的需求，黑脸总是常有，但拿这份工资，就要对得起自己的职业道德。

2、需求整理

需求整理，顾名思义，就是将我们获得的需求归纳总结，变成可以量化可以具体的功能点。

在这个步骤，更多的功课应该是要结合自身的业务和战略，打造产品。

不能用户说我要一匹可以跑的很快的马，就不假思索的给用户提供一匹快马。结果很快发现，用户真正的需求是想有快速的交通工具。

请在需求沟通后，用我们产品的思维，将客户的需求深挖出来，明确了解客户的真正的需求是什么。

需求整理出来后，请在此拉着业务沟通确认，确保双方对于方案的一致性，避免经过产品经理加工后，导致需求理解错误，白做工作。

同上，这一步骤也都都是在沟通中度过的，但需要注意的是在当前步骤时，不要和你们的技术讨论，避免因为技术原因影响到你整理产品的思路。

3、原型输出

有了完整和确认的需求，原型是一个很直观的东西。

而它也是我们和业务第一时间可以再次确认需求的正确性的文档，在输出原型后，拿着它让业务帮你揪一揪错误。

需要注意的是：请整理好你的规则和交互，一一和业务确认。

你要学会借力。

借着更专业的人，完成自己的任务。

等确认规则、交互是业务确认并沟通的，先别高兴急忙拿着原型给业务。

此时你要认认真真的梳理梳理你的流程。

虽说已经和业务做了确认，但你要知道，人在说话下决定的时候，有时候脑子不会多想，不会过多的对整个流程有全局的把控。

更别说没有产品思维的业务了。

安安心心的拿着你的原型图和流程图，自己盯着每个步骤，顺一遍。

所有的正向和反向、异常流程，应该都要体现在你的流程和原型中。

如果没有，此时就是一个可以弥补的机会。

而这也是自己在业务面前树立专业性的机会。

别犹豫，发现有问题直接找业务确认，别自个儿憋着。

那后果你担不起，即使是你发现的。

4、UI设计

有了确认过的原型，接下来就是需要让UI设计师给披一件外衣打扮漂亮了。

年轻刚入行设计师的脑回路感觉是艺术家的脑回路，设计出来的东西，如果你不盯着，总会设计成让人看不懂的东西，美其名曰艺术设计。

但还好，基本上大多数UI设计师会按照原型来设计。

但对于UI设计师的发散发挥，我是支持的。

因为这对产品经理来说，也是学习的好机会；

和你的UI设计师处好关系，对你测试时也是有好处的。

前端开发时，总会出一些我们肉眼看不见的bug——像素差，颜色差。

产品经理对色彩的感觉，明显比设计差，所以有时候前端出现的一些明显UI 的问题，你就可以推UI上去，帮你测试。

5、跟进开发、跟进测试

这两步基本上是一致的；

有任何需求不明确的或者有问题的，需要反复和他们聊，解释。

直到在程序员的脑海里没有bug而言为止。

但我希望，专业的测试人员测试完成后，产品经理一定要测测。

自己的孩子自己要知道和了解。

7、上线

上线前，作为产品经理，会将整个流程自己在测试环境跑一遍，验证出来的功能是否与需求匹配，有问题及时改正。

简单写了些，其实产品经理的过程很乏味，基本都是在沟通和被人怼的过程中，所以要了解一个产品经理的工作，不如自己实际去做一回产品经理。

END····