2007年秋，一次PD交流会上，一位同事聊了PD如何与工程师合作的话题，很有共鸣，所以也整理了一下自己的想法，并且通过一个需求采集的练习，让各位开发、测试、PD、UI把对合作沟通的期望提了上来，整理如下。
第一，综合大家的需求，权重最高的居然是一个很大的话题：“流程”,但仔细想想就一点都不奇怪，一群超级理性的人很明白“没有规矩，不成方圆”的道理，会喜欢被规则管理而不是被人管理，当事情由人来控制的时候，总给人一种不安全、不稳定的感觉，而有流程可依的时候，心里就比较踏实。（人治和法治的区别也就在此）
具体到实施方面，大家再次认同，需求确认的时候相关人员一定要都参加，以免后期再发生测试、开发对需求理解的脱节；如时间允许，开发应该尽早参与到需求评审中；……
另外有一点提到非常多的就是需求变更的流程，说明大家对“需求总是在变”这件事情已经是深恶痛绝并且有些恐惧了，但同时又意识到需求的本性就是“总在变”，所以非常希望有一个流程化的规定来严格控制这件事情。
但好的流程是需要执行的，感觉在实施的时候还是有些困难，网店现有的发布流程不能说完善，但很简单实用，如果能做到严格执行，相信已经可以减少很多问题了。
第二大的问题就是“沟通”，团队合作必不可少的一个环节。站在PD的立场上，我们会把自己作为产品的中心，这个角色注定要和各种各样的人交流，客户、老板、开发、运营、测试、客服、合作部门等等。
开发们提出了很有意思的一点，希望大家在交流的过程中避免情绪化。人性的弱点决定了在争论的过程中每个人都希望自己得到认同的，而这点往往导致思路的变形，不再是考虑产品怎么做更好，而是去想如何说服对方。我自己是觉得沟通中还有一点重要的就是每个人都要主动一点，这样才能形成互动的氛围，也可以减少信息不畅引起的问题。
（iamsujie补：经常发现，有同学会把对人的反感转移到对人的观点的反对上，这很可怕。）
第三点是PD要不断提高自我修养，大家希望PD给出的文档在质量再更进一步，准确、全面、简洁，即时更新、保持最新。我自己觉得还有另外几点也是需要PD自己不断努力的，比如考虑问题的全面性，有空多了解一点技术等等。
（iamsujie补：一定要懂一点技术，有的工程师你可以和他讲商业价值，而另外一些你与他讨论一些技术实现更有效，当然不是技术细节。此外，获得认同的最好办法不是自己反复的解释某个观点，而是引导对方说出你想说的观点。）
该文章出自《iamsujie的产品设计》,原文链接：http://iamsujie.com/page/38/
