工作当中需要好好说话

在工作中我觉得好好说话特别重要，给大家举个测试和开发例子。

测试想提个Bug，说我发现了一个Bug

开发立马否认：怎么可能，不存在！ 

测试：不信你过来看一下！ 

开发：不用看，好的呢~肯定你环境问题，动什么东西了吗？

测试：....... 你不看我已经提给你了吗？

开发：看不出来什么问题，你怎么操作的？

也重现不了啊，你想办法重现，重现了再叫我，我忙着呢

测试：…… 

经理问：什么时候能上线？

开发说：不知道，看测试什么时候能测完。

测试说：不知道，看开发什么时候能改完。

长期这样必定会互相心生不满，就在前两天某公司的产品经理与开发互殴的事情闹的满城风雨。产品经理了解技术，有助于和研发人员沟通。但了解技术后提需求时，会权衡需求和实现难度。有人说产品经理提需求时，只需要考虑用户需求，不应该考虑技术实现难度，这样做是否正确？

这个问题要从几个方面看：

1、从产品本身来看需要你确定这个需求的价值，可以从KANO模型，ROI投资回报率上来对需求重要性排序，优先做有价值的东西，时间来不来的及。

2、确定了价值，下面就是需求实现的问题，一般来说需求是有多种实现方式的。不仅仅是技术上的，还有其他表现形式上的。

打个比方，用户说要可乐，基本的需求是因为渴了，而你如果提供矿泉水其实一样能解决问题，这个需要你从本质上理解用户需求；

技术上，实现一个功能，可能写一个工厂方法就可以简化很多事情，而开发也可以己脑洞大开过度设计（这种对于入门没多久又有理想的程序员是比较常见的）。

这个在提需求的时候，提给开发的需求更应该说用户story，而不是描述解决方案：规定好他应该怎么做。同时尽量找开发领导提前沟通需求，这样有可能他会给你一种更加好的实现方案。

3、最后就是努力充实自己，面向对象的编程思维可以多了解了解。产品经理的UML工具其实就是面向对象的思考方式，你可以不用管这个方法具体是通过写了多少行代码实现的，只需要想通中间的逻辑是怎样的即可。

这样又可以反过来促进你了解：你的设计中有没有遗漏什么，下一版功能可以往哪拓展；从整体逻辑的复杂性推算功能的实现时间，对整体开发时间的估算越来越有把握，避免被开发忽悠。

每一个产品都是贝，提方案时强势的外表，却住着柔弱的内心。

每一个开发都是海，编程时安静的外表，却藏着波涛的汹涌。

总结一句话，退一步海阔天空，忍一时风平浪静！！

那么如果出现问题如何有效沟通，这就是我们为什么要求测试人员要懂一点开发设计思路。可以不用精通，只要懂就比不懂强。

最重要的就是工作当中好好说话。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31546605/viewspace-2187984/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31546605/viewspace-2187984/