机会任何有过IT项目交付经验的朋友，都深刻地知道产品经理和开发人员之间的吵架究竟有多“恐怖”。这种情况，也时长发生在很多数字化实施项目中，项目经理和IT支持人员之间 ...
经常，产品经理刚开始说一个需求，前两句话还没讲清楚，开发人员马上怼一句，做不了... 再或者，前一天产品经理刚布置下来的需求，开发人员才想好怎么做，第二天就变成另外一个需求... 双方立马干架 ...
“产品经理朝令夕改，废话连篇，表述不清，异想天开 ... 技术人员不懂变通，词不达意，纠结细节，顽固强硬 ... ”
产品方和技术方彼此的和谐，永远都是一种奢望，归咎其原因，主要是两个方面：大家的出发点不同。
产品经理考虑的是业务目标，技术方考虑的是实现手段。二者本来就天然存在矛盾。产品经理要满足客户的需求，首先客户的需求就是混乱的，易变的，再经过产品经理的消化和转达，波动性就更大。
而技术方面对的需求则要尽可能的清晰和稳定。
同时，技术本身的能力边界，反过来也制约着需求不可以是肆意妄为的，有些业务目标难以实现，有些业务目标可能不必在技术产品的维度来实现。
除了立场不同，还有一个更大的沟通间隙——话术体系。
从事技术工作的程序开发者，采用的是面对机器的沟通话术，必须逻辑严谨、结构清晰，然而也有一个很大的缺点，一般“普通人”难以理解。这就凭空造成了很大沟通障碍。
客户首先并不具备用这种语言和开发人员沟通需求的技能，那么这个翻译的“担子”自然就落到了产品经理身上。
即便大多数产品经理在入职的时候，会接受一些相关的基础IT培训，但是仍有大量的技术逻辑难以让他们理解。很多时候，产品经理的半吊子IT基础并不能让他们完全理解IT人员的“难言之隐”。
从产品经理的角度，他们由于要全面把握需求和客户的偏好，也不能让自己过于沉迷于枯燥的技术逻辑、技术规范里面。
这会让他们天然地给自己设限，从而影响对业务目标的总体判断，也难以做到真正对客户负责。
作为产品，要“懂一点”技术名词，但不能“太懂”技术人员的难 ... 产品经理要把握现实需求与客观约束之间的均衡点。
从客户提出一个需求，到最后形成代码，这个价值链路是非常长的。
首先，业务需求要转换为产品需求;其次，产品需求要转换为开发需求;最后，开发需求才形成代码 ...
经历这三个翻译环节，很多东西都可能变了味。
当然，需求实现的偏差尽管不能完全消除，但是最终如果想让代码效果真的做到让客户满意，也只有同为中间翻译职责的产品经理、技术经理彼此协调努力，理念互靠，才是唯一的现实出路 ...
