今天网上发的程序员和产品经理因为「根据用户手机壳颜色来改变软件主题颜色」的需求问题打架的视频，大家肯定都看到了吧。
不知道你做何感想？
中午我和开发聊起这个事情时，他们倒是很较真的讨论起网上的一些解决方案来，什么图像识别啦，脑电波啦，瞳孔反光啦，看，先不说能否落实，但这才是解决问题的态度嘛，就喜欢和这样的开发合作。
然后看看网上一些产品经理对这个事件的质疑，觉得事件中的产品经理不可能会提出这么「无理」的需求，并且指出了需求中的明显不符合产品思维的点，看，这才是有产品思维的产品嘛，就喜欢和这样的产品合作。
如果从测试角度来说呢，一般和开发杠起来，他们都会说「行了，我代码保证」，和产品杠起来，他们会说「我确认就这么实现，出了问题算我的」，得，当爷的感觉真好。
不过说到底，这件事给我的感觉就一个：一个巴掌拍不响。
或者说就是沟通的问题。
就截图这样的对话方式，就算今天不因为这个事打起来，明天也肯定会因为另一件事打起来。
关注我的同学都知道，我的主业是做测试，而说到沟通方式，作为测试，每天都要保持着同开发和产品的战斗激情，还要保证项目顺利上线，我们是积攒了不少战斗技巧和经验的。
下面就具体说说我对于沟通上面的一些具体建议：
1.说话时尽量避免使用反问句。
这个建议最开始是我老大提给我的，之前一直没咋注意，听到时一惊，回头想想，反问真的比陈述句的语气要强烈的多，来几句你听听。
「你难道不觉得这个设计有点反人类？」
「你难道不觉得最近提测质量有点差？」
好吧，本来我是想探讨的，但是听的人一琢磨，其实我已经是表达了非常肯定的意思：
「这个设计真 TMD 反人类。」
「最近提测质量真 TMD 差。」
其实直接换成陈述句，语气会好很多，比如：
「我觉得这个设计有点反人类，我建议这么改一下。」
「我觉得最近提测质量有点差，你我建议这么优化一下流程。」
是不是让人容易接受的多了？
2.沟通问题时，不要不假思索的否定别人。
想象下这么个场景。
产品经理火急火燎的拉上开发和测试，说老板要求明天紧急上线一个需求，大概是这么这么样的。
开发一听，头就大了，这至少需要两天时间开发，不行，搞不了。
测试一听，开发需要两天，那最少也要测试一天吧，还要留时间走发布流程，不行，绝对搞不了。
产品：再想想办法呗，这个确实需要明天发。
开发：不行。
测试：搞不了。
得，开发和测试这时候倒是统一战线了，但是已经决定要做了，这时候去讨论搞了搞不了已经没有任何意义了，甚至是继续在浪费本来就很宝贵的时间。
那换个思路呢？
比如开发说，你这个设计的有点冗余，开发量比较大，既然你的需求目的是这样，那么有部分无足轻重的需求建议延期，这样我可以试试。
测试说，既然定了明天发，那么建议按照明天早上可以提测的方案来，最好今天下班前确定最终方案，这样我们加班把用例准备好，明天来了直接可以测，尽量往前赶时间。
产品说，行，我现在就去把这个方案同老板过一下，确定方案后立马通知大家。
看，各方也都充分表达了自己的观点，并被各方认可和接受，最后事情也做成了，皆大欢喜。
3.就事论事，说话不带情绪。
眼瞅着产品走过来，就知道准又没啥好事，果然，又变更需求了。
开发说，「到底能行不？这一个地方我今天都改 TM 十回了，还让不让人活了？」
测试说，「我昨天都给你说了，这样改肯定不行，看吧，又改回来了，每次都这样，这不是折腾人么？」
要是新手产品，已经空血倒地了，但是既然要改需求，肯定有他的原因吧，我们可以听听这次的原因，然后一起总结下下次怎么避免同样的事情再发生。
开发可以说：幸亏我之前的代码还在，我先回滚下，不过这已经是今天第十次变更需求了哈，后面建议需求考虑清楚些，以后每天我只接收五次以内的需求变更。
测试可以说，本次这个需求，前面我们提过建议，这次还是返工了，我建议我们一起开会讨论下最终的需求方案，每个人都发表下自己的看法，充分讨论一次，达成一个共识的结果，项目结束前大目标就不再变了。
看，大家都是朝着解决问题的方向去考虑，事情就容易的多了，当然，我这例子举的有点偏袒产品了，就当卖产品个人情了哈。
好了，再回头看看本次的掐架事件，我觉得没必要去确认真假，从这个事情上能学到我们不必亲身去经历就能得到的经验，才是最主要的。
最后，
愿产品永不变更需求；
愿开发永不出低级错误；
愿测试永不漏出任何问题。
你所在的项目中，是否也存在各种各样类似的问题？欢迎留言讨论。
网友评论