对产品经理而言，有一种灾难叫 “老板说”

【文章摘要】世界上最可怕的人是什么?是老板。谁都有老板。但懂得和老板打交道的产品经理才能成功。

最近看到 PMCAFF 社区大家都在说 “老板说” 现象，那么作为一个产品经理如何正确的和老板进行沟通，来应对 “老板说” 呢？对产品经理来说，有一种灾难，叫 “老板说”。老板说不喜欢红色。老板说这产品是给老年人用的。老板说登录框放到左边很醒目，还有更多类似的事情，有的时候听完老板的话，我也会特别头疼，我相信产品们也都有同样的遭遇，那么最后你们是如何解决的呢？

世界上最可怕的人是什么?是老板。谁都有老板。但懂得和老板打交道的产品经理才能成功。 老板要面子，但老板更想赚钱。显而易见的是，你的产品不都是做给你老板用的，所以大多数产品经理在 “老板说” 之后，或者变了需求，或者偏了方向，或者改了进度，或者啥啥啥的。你要想当个成功的产品经理，学会怎么听从 “老板说”，或者学会怎么与老板打交道，是个非常重要的本领。

为什么会有 “老板说” 现象出现？

我个人总结了以下几点，供参考：

“老板说” 现象出现说明了什么问题？

如何解决 “老板说” 现象

可能大家觉得要解决 “老板说” 现象还是多和老板沟通、周旋，但是我确不这样认为，这种只能解决一时的问题，而无法从本质解决，我觉得要想根本解决还是要从流程规范、需求前期调研、完善的功能评审机制来解决。首先，我认为需求功能点的搜集源需要统一

在公司中，各个阶层、各个人员、各个部门、老板都会经常提出一些想法、诉求，为了避免他们的这些想法、诉求不被遗漏、能进行有效的记录和跟踪，我们需要一些项目管理工具进行统一管理。例如禅道、MantisBT 等。

我们现在使用的是自己做的一个小系统，支持用户发表自己的想法、采取投票来决定是否实现，以及在哪个版本实现，想法更改次数和时间来验证想法的有效性。投票中包括：认可、采纳、不采纳。（我本人技术出身，所以直接贴表结构了，有兴趣的可以看看）

其次，我认为需求功能澄清到移交到技术团队需要有规范的流程，任何人都应该遵守。

我只想强调需求功能实现在前期过程不能减少，在前期解决问题成本代价最小，下图则反映了此现象：

目前我们需求的流程如下：

大家提出的想法记录——-提出人讲解和说明——-投票表决及实现版本——产品输出原型设计——和 UI、老板第一次原型沟通——召集技术进行评审——修改评审结果及更新——移交技术团队实施

这里我重点说明下和技术团队的评审，一般我会提前 1 天发出版本的原型评审范围及时间，然后技术相关人员填写评审记录，正式评审的时候针对技术提出的问题进行解答和沟通。因为一切需求功能不管你设计的再好，再完美，技术不能实现都是天方夜谭，所以功能移交技术团队一定要达成一致。

下图是我们需求功能技术评审的模板，供参考：

这个我们在每一个功能实现完成后进行内部测试人员的测试之后，产品一定要再次测试，然后进行修复 BUG，解决 BUG 的循环，都解决后才正式发布上线。按照 TDD 的思想，在需求功能移交给技术团队的时候，这个需求功能就是一个 BUG，不断解决到这个功能无 BUG 的时候就可以发布了。

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!