遇到猪队友，该不该强势？

周末没发文，一来有事、二来牙疼。

不知道是上火还是牙神经出了问题，这几天后槽牙一抽一抽的疼，真实体验了一把牙疼不是病疼起来真要命的快感。

今天跟你们聊一个关于产品需求变更的案例，来自我星球的同学提问。

这位同学在需求评审会之后改了一个逻辑，他找技术经理单独沟通了这个调整并达成一致，事后修改了文档并在项目群里发了通知。

产品提测验收时，他发现这个变更的逻辑没有加上，于是在群里直接问研发。

此时技术经理直接在群里发作，不承认这个需求变更，并且强调在提测后的需求变更是不做的。

他有点不解，明明已经沟通过了，为啥现在不认账，于是跑到技术工位去对峙。

来到工位，技术经理和负责这个需求的研发没搭理他，于是他把文档拿出来跟技术经理核对，经理说这个方案不好。他让技术经理给个好点的方案，经理说没有。

于是，事态升级。

他非常强势地当着众人的面指责了技术经理，并给了一个新方案，然后让负责实施的研发同学改了。

虽然目的是达到了，但他对自己的做法产生了怀疑，问这种方式是不是有所不妥？

如果是你，你会怎么处理这种问题？

说说我的观点吧。

第一，需求变更时，需要明确告知项目参与者需求有变更，对研发计划做出调整。 

这个过程中，重点强调变更的原因和目的，而不是变更方案本身。

第二，沟通需求时，不仅要和技术经理沟通，还需要和具体负责这个需求实施的研发沟通，并且最好把三方拉到一起。

如果一个信息只有两方知道，那就不具备公信力。第三方甚至是多方在场的共识，能有效避免耍赖情况的出现。

第三，沟通达成共识后，需要对变更需求做沟通备忘，留存在文档、邮件、聊天记录里。 

所有涉及产品需求的关键信息和关键决策一定要书面化留档，不要口头承诺，吃过亏的都懂。

第四，凡事先不要先动情绪，而是讲逻辑、说事实、摆道理。当你用情绪去驱动一件事情的时候，失去的会是别人的信任。

在这个案例里，技术经理抵赖的原因可能有两个。一个是压根没有正确理解需求变更的具体情况，沟通时应付了事；另一个就是实实在在的耍赖。

不管是哪种原因，总之肯定有人的问题。

对于产品经理而言，要避免自己掉入这样的坑，就得把工作做到前面，而且尽可能做到滴水不漏。

这时候，经验发挥的作用就很重要了。要知道，优秀的产品经理都是从一个一个坑里爬出来的。

在我看来，做产品强势一点没什么不好，只要你能说得清逻辑、拿得出事实，那就挺直腰杆面对一切。

合理的强势，是一种策略。

今天就聊这些吧，牙疼实在没心情写太多，各位老铁多多理解。

················· 唐韧出品 ·················