业务流程，就是将业务逻辑以功能的形式，具象化的体现在产品中。对于 B 端产品来说，要能理解业务、找准问题的本质，将问题转化为需求，并给出可落地的方案。
紧接着就是跟设计、开发、测试协同推进，直到功能上线。
这也是初级产品经理积累经验的过程，不断提高思维，进而提升产出的质量。
当然，我在这个阶段还是踩了不少坑，接着回顾做下复盘，希望能给你一些启发。
一、从被动接受到主动思考
刚入职场，我们还会带着校园学习时的那种被动思维。
上级怎么说，我们就怎么做。
虽然这很正常，但要寻求突破，主动跳出“依赖”的坑。
实践中一点点积累，等到阶段性复盘时会发现，之前做得好多东西都是“错的”。
最常见的，就是将客户或产品经理的“需求”直接转化成了方案，上线后发现压根没人用。
这就是缺乏主动思考的结果，对此我们该怎么办呢？
01、顺着问题，主动找到原因
之前做 PC 端迭代时，业务部门反馈过来说，客户期望在详情页能全部导出图片。
当我问业务人员原因时，她说对方现在 1 条任务下，存在 N 条子任务，而每条子任务又有 N 张图片要审核。
而当前的系统看图片不方便，所以对方说做个图片全部导出，操作上会方便很多。
基于业务人员描述的，我尝试着操作发现确实很麻烦。
这个问题是存在的，但我不会用她说的「导出图片」去解决。
要知道，任务详情里除了图片还有其他重要信息，比如门店名称、检查标准、员工反馈等等。
作为产品经理，要解决的是一个面，而非是一个点。
基于我的理解，我用的是滚动查看详情的方式，同时调大了缩略图的比例，如下图这种。
随后，我单独做了个小视频，与客户也确认过这种方式比他直接提出来的方案更好。
最后就是完善方案逻辑，推动开发并上线了。
通过这件事，我也总结了下经验，当面对业务人员带来的“需求”时我该怎么办。
（1）要求对方讲清楚业务背景、用户角色、遇到的问题、操作频率、当下如何解决，讲不清楚再着急都不做；
（2）基于业务已有信息，主动去跟客户交流，不做二手信息接受者；
（3）用直观的方式表达自己的意图，与客户二次确认是否真的能解决问题；
通过上面这 3 个步骤，能够保证之后业务流程的方向是对的。
02、从目的，倒推更优方案
这也是前几天跟一个产品小伙伴聊天，反思自己得出的一个结论。
B 端产品工作中，经常遇到上级或客户说要个某某功能，而且还很强势。
作为产品经理，我们照着做就真的可以了吗？
肯定是不行的，我们要有自己的思考和判断。
比如老板说要做个 A 功能，目的是要提升哪些指标？
拉新？留存？转化？
搞清楚目的后，基于你对业务、产品、运营的理解，A 这个功能是否真的能达到目的？
如果可以，当然是最好的，但你要明确上线后的预期指标。
如果不行，你要能提出 A1 方案或者是 B 方案，并给出合理的解释。
这样在后续的沟通探讨中，你们是基于目的去沟通的，也会更加的客观。
只要你的方案价值更高、成本更低、风险更小，老板没理由摆着吃亏还要去坚持。
毕竟谁会跟钱，或者是绩效过不去呢？
二、具象化的表达尤为重要
工作中我们都是追求效率的，要珍惜自己和同事的工时。
因此在交付产品方案时，要培养适合团队协作的方式，就比如：
1、用流程图表达思路，同时附上流转状态的说明。
B 端产品涉及的是不同角色的业务流，动态的信息很难通过描述清晰地表达。
而流程图却能够更好的体现这一点，便于产品、开发和测试的认知理解一致。
2、将逻辑逐条列举表达，沉淀沟通后的结论。
我们一直说 B 端产品经理要有很强的逻辑性，如果要体现在方案里，就是能一条条列举你想要效果。
对于开发而言，照着一条条做，碰到有问题的地方也能够及时沟通。
而不是写的模棱两可，东一句西一句的凭借他们的发挥。
3、对与你的决策，要能有客观的理由做支持。
这点虽然不用在方案里体现出来，但当面对开发质疑的时候，要能 hold 住。
不能总是“老板要求这么做”，“这个就是要这么做”。
如果真的回答不出来，就要想想这个方案在制定之初，是不是少了些主动思考？
写在最后
说起来，每次实践后的思考复盘，换来的都是经验积累，以及能力的提升。
等积累到一定程度，能明显看得到自己的天花板时，就要寻找新的机会。
可以是在原公司承担更多的工作，也可以尝试着迈向更高的平台。
总之，不要让自己过得太舒服了。
不断积累，不断强大，让我们一起加油~
