B端产品推进过程中的项目管理思考

在产品推进过程中，遇见太多太多的大规划，但这些，在具体产品迭代过程中，用于限定需求范围可行，规划与实际计划不符却不可取。成熟的产品迭代团队，每一期迭代一般**有相对固定的周期。尊重时间周期和需求范围，做好当期需要实现的内容，不过于蔓延需求，机动时间合理，方可称不负韶光。

做B端产品的痛与苦

如果你跟一个负责B端产品的朋友喝下午茶的时候，他不小心走神了，请你大方的原谅他吧。

哪怕他人在你面前，他的脑子里与跟你唠嗑同时并行的事情，可能不下10项：

• 嗯，对面这人在问我奶茶好不好喝，咦，怎么又说到了熔断，熔断是啥？
• 后天这个产品版本上线，还有5个重要bug得改，不然不能上线。
• 下个版本里得做20个需求，数据权限下沉得涉及多个部门，该怎么推进呢？
• 某服务的供应商不是说今天上线这个功能嘛，都这个点了还不通知我们准备，今天还能上线吗？
• 完了，A项目和B项目**议时间冲突了，怎么办？
• C项目好像也要上线了，当时的需求是什么来着？
• 有个研发资源好像要被释放了，好几个产品线和项目在争抢，怎么才能让他来我们团队呢。
• ……

焦虑啊~

有人感叹，我有丰富的**知识和实践经验，在做下一个项目的时候，怎么还是不敢保证成功呢？

是呀，项目如流水，哪怕看上去很相似，下一个也不是这一个。知识和经验可做参考，却没法照本宣科。

没头绪啊~

不过有丰富的知识和经验，整个团队又身心投入地为产品和项目的推进付出的话，成功概率总**高些。

读过国内国外的产品项目书籍并做过对比的朋友应该能够感觉到，国内讲产品或项目的时候，**偏向于抽象**、拔高高度，比如著名的产品人梁宁老师**讲“宏观视野、中观套路、微观体感”，**之父****讲“Don’t Make Me Think”；而国外讲产品或项目的时候，**把一句话，写成一本书。

“Don’t Make Me Think”这句话，在国外的书里**写的时候，光目录可能就有下边这么多：

• 产品体验的最高境界是，用户不需要思考就能知道下一步怎么做；
• 为了实现这一点，作为某某某角色，要在第一步第二步第n步做到这个那个另一个；
• 实现了这些，基本能将产品体验做到多少分；
• 某一步没实现，**将产品体验降低多少分；
• 针对什么样的产品，可以应用哪些步骤来执行；
• 吧啦吧啦吧啦……

一个说的那么多，一个说的那么少，到底怎么实践啊~

解决B端产品推进的痛点

上边赘述的篇幅有点多，实在是亲身感受，痛之又痛，没忍住就唠叨多了。

汇总下做B端产品的痛点：

• B端产品业务复杂、定制化高，同阶段并行的产品和项目可能有很多个，资源有限的情况下，资源该怎么分配，产品该如何迭代？
• 项目管理过程中，进度、质量该怎么把控，已实现功能该怎么复用在其他项目中？
• 产品和项目上的知识和经验，怎么才能更好地体现在产品中？

在B端产品推进的过程中，大大小小的问题多到数不胜数，要行之有效的解决问题，还是需要知识和经验的积累和传递。

在推进产品进展的过程中，是有规则可遵循的，可总结为：识别相关方、主动学习、尊重流程、明确优先级。

在产品经理基本素养过关的情况下，将上述4点把控到位，产品推进中可能遇到的可预知或不可预知的问题，在解决的过程中，方向和边界基本可以保证不**偏离。

（1）识别相关方

个人认为这是最重要的一点，识别错相关方，所有努力都白费。

（2）主动学习

产品经理往往承担产品推进和项目管理等多方面的工作，主动学习各方面的知识是必要的。

了解与你沟通的人希望在你这里获得什么帮助并表述清楚，是很重要的一种能力。

一些做B端产品的公司，**拿业务领域的经验作为门槛设置招聘要求，想要进入B端发展的产品经理们，也常常因为业务知识及经验的不足望而却步。但实际上，业务知识及经验诚然重要，更重要的却是快速并合理使用业务知识及经验的能力。

（3）尊重流程

尊重流程，包括尊重流程中的人、组织以及流程本身的知识项，共同遵守规则，才能有效的保质保量完成任务。

每个公司，都有自己的项目管理或产品管理流程，这些流程，是公司团队间长时间磨合一点点积累下来的财富。

一般公司的项目管理流程，多遵循国际项目管理规范，根据自己公司业务及现状加以调整，对不同团队间如何协作、每个项目节点团队间该如何交接、交接哪些内容等进行说明。

总有人抱怨进度和质量不好把控，那有没有想过为什么呢？原因不外乎项目管理流程中的相关方之间的意见并未完全达成一致吧，想办法将颗粒度细化，并用各相关方能听懂的语言表述清楚，在流程的各节点，进度的质量的把控度总**提高。

项目管理规范主要内容

（4）明确优先级

一次产品迭代的过程，简直可以成为一场大戏上演的过程，从产品需求的收集到在生产环境如期上线产品，各种角色来来去去，各种声音纷纷扰扰，请问产品经理，你用什么来保守初心？只能是优先级。

那又怎么判断优先级的高低呢？用公司战略和产品规划，最符合公司战略和产品规划的需求，就是当前优先级最高的需求，可以参考四象限法则。

有人说我们公司没有战略，或者我不知道公司战略是什么。

• 首先，不管是什么产品，不可能没有战略和规划。
• 其次，如果没有人针对某个产品进行明确地战略沟通及产品规划，那么要么该产品在当前阶段不重要，投入资源有限；要么在公司业务里，确实需要这个产品，但是大家都没想明白该怎么去设定跟这个产品相关的战略和规划。

遇到这种情况的产品经理，有很大的主动权。从需求优先级管理到产品规划到战略设计，你若愿意并且有能力，可以尝试自己处理，将其变为公司核心产品，也不是没有可能。

最后，用“把握当下，不负韶光”收尾吧。

在产品推进过程中，遇见太多太多的大规划。年度、季度、不同版本的产品规划确实需要有，但这些，在具体产品迭代过程中，用于限定需求范围可行，规划与实际计划不符却不可取。

成熟的产品迭代团队，每一期迭代一般**有相对固定的周期，当期需要做的事情，根据上述4类原则也基本可确定。

尊重时间周期和需求范围，做好当期需要实现的内容，不过于蔓延需求，机动时间合理，方可称不负韶光。

好啦，内容有点多，感谢您耐心读完~

作者：一米；公众号：产品人儿

本文由 @一米 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议

给作者打赏，鼓励TA抓紧创作！

**赏

4人打赏