不用撕逼，这6点可以让问题和平解决

　　有人认为，你在通过各种方式增加他们的工作量；而你却感觉，他们做的总不能如你所愿。抛开个人因素，这可能就是程序猿与产品汪撕逼的大部分原因。如果都能做下自我批评，便可以省去交流中的很多困扰，毕竟吵架需要两个人，而停止吵架只需要一个人。
　　一、所有交流的基础需求文档
　　写过传统的需求文档，“说明”与“原型”不能在一个层次上展现，编写的人需要经常用些代词，比如简单一句说明“当没有售后信息时，售后项目列表为空，并显示提示语”，程序猿便要上下滑动的查看“售后信息页”与“这句说明”，造成视觉与思维的跳跃，不易阅读。最近直接在原型上进行标注，自认为效果会更好一点。
　　不管需求文档演变成什么形式，都不能省去重要的三个要素：内容、规则、交互。想起大话西游中唐僧对至尊宝说的话：你想要你就说嘛，你不说我怎么知道。不要感觉有些地方是常识，所以就不用在原型上标注，你没写，程序员可能就不做，或者做错。
　　小学考卷上的“现代文阅读”，答案各领风骚，每个人因为性格，态度，眼光不一样，理解也会出现偏差，所以我们关于原型的说明要尽可能的通俗易懂。
　　二、沟通要及时
　　沟通可以让信息对称，从而在做决定时保证一致性。比如：甲和乙约明天出去玩，甲知道明天有雨，所以建议去一个咖啡馆聊聊天，而乙不知道下雨，所以想去户外晒晒太阳。我想如果乙也知道明天的天气，应该会和甲有一样的想法。
　　沟通可以避免更多问题的产生，一个项目很多时候是协作完成的，当你想要改动某个地方时，你要想是否会影响到其他人负责的部分，并告知他们。
　　开发过程中要主动的询问程序猿是否有什么疑问，如果他们对需求理解错了，防止他们在错误的道路上越走越远
　　三、创建自己的控件标准
　　最近的一个项目，负责后台系统的设计，因为开发时间紧张，且后台界面自古以来不受领导重视，便跳过UI让程序猿直接看着原型写界面。因此三个程序猿在三个页面做出了三个风格的搜索框，如下：
　　增加修改的次数就是在增加撕逼的概率，我们要尽量避免修改这种小问题。因此我想有的地方我们能不能放弃“个性”，也做一个想教科书一样的规范，总结控件可能会存在什么场景中，在某个场景里它的样子是什么。
　　四、态度要端正
　　态度决定你对一个事物的看法，比如：早上到公司发现大家的工位都被收拾的比较整洁，你心想这是谁啊，这么好。当你知道是你特别厌恶的一个同事做的，你可能会想Ta又在这假惺惺的显摆。因此我想到了关于对程序猿的态度。
　　1、如果程序猿抱怨“太复杂”“没必要”，除了他们想偷懒之外，是不是我们在设计时没有考虑开发成本，可不可以再想一想要实现同样的效果，有没有其他的方式？用最小的开发成本实现最大的用户体验，真是一件善事啊。
　　2、金无足赤，人无完人。一旦因为你设计上的错误需要修改需求，大胆的说：抱歉，是我们的错，想的不够周全，辛苦了。承认错误是可以获得原谅的最好方法。
　　五、第一批用户，尊重他们的意见
　　做产品最经常提到的就是”用户体验“，我们想要跳出产品思维，经常闭上眼睛，把自己YY成产品小白去体验，可是再怎么YY，也不是正宗小白。在产品上线之前，程序猿便是第一批用户，他们不会陷入产品思维，在开发时与产品直接接触，除去想要”偷懒“的意见，有态度的程序猿总能给我们带来惊喜。
　　一个课程学习平台，最初设计的流程中是这样的：上传审核发布观看学习（页面中有举报功能），在跟程序猿讲解需求时，其中一个人就说既然后台审核通过了，为什么还会出现举报的情况呢？想想确实如此。
　　人人都是产品经理，人人都要培养自己的产品思维，人人都能够对产品提出一些意见，所以程序猿的意见也应该受到尊重。
　　六、有些问题确实是开发时才能发现问题
　　实践出真理这句话说得不错，不管原型的保真程度有多高，交互效果总不能和使用的程序一样，那么对着原型去感受使用的效果，有些问题就体现不出来（经验丰富的前辈除外），我们努力减少修改需求的次数，但不能保证完全正确，以此安慰菜鸟的我和同在菜鸟路上的他人。
　　总结：
　　我害怕孤单，但不能没有孤单，因为在孤单的时候可以去思考，去沉淀。我们看待一件事要往对自己好的方面去想，对自己好不是去否定别人都是错的，自己全是对的，对自己好是能让自己进步的。