好久没有体会到这种不言自喻的快事了，特别是在有些话又不得不说，却又不是那么好说的情况下。
就如同前面说过的，产品经理的思维和程序员的思维是不一致，产品经理更多从产品功能，使用体验方面去理解产品画面，而程序员则看到的是界面信息所对应的数据来源与走向，如果你曾经没有做过程序员，那对于这句话的理解还得需要几次案例的尝试才行体会。
在产品经理的工作时间规划中，前期最重要的步骤就是梳理整个模块的流程，画出流程图。这里面其实就是对应“整体数据块”的走向，而且在平常的工作中，这种大的数据块也是很容易被考虑到对应的数据来源问题，真正容易忽略出错的反而是在绘制完原型后，对于实际的异常业务情况和小字段中的数据来源是否清晰可查。如果你在绘制原型时不能考虑完全到，那么恭喜你，又到了不逼逼自己，都不知道自己有多牛的时刻了，绘制时考虑不周全的地方将不得不在同程序员进行需求对接时去临场想出解决方案。
对于产品助理和初级产品经理来说，这种事情是经常容易发生的。此阶段主要还是在于客观原因方面：比如对于实际的业务操作流程不是太了解，有些产品坑还没有经历过，对所在做的功能模块与其他模块的关联认知度不太深刻，技术底子不够扎实数据存储过于理想化等。这些客观上的原因在短期内是难以完全更改过来的，必须要经历一些雷区和做过一段时间才能体会和总结到的教训。所以当产品小白们在遇到这样的情况时，不要怀疑自己，记住这次为什么没有考虑到这种情况下的深层原因，保证下次少犯和不犯是最关键的。通常情况下，在大的流程走向没有问题的情况下，这些小的问题对于全局的影响将是有限的，只是让产品看上去不是太完美而已。
另外一点，正确地向程序员传达对应字段的意思也是需要时间和案例的煅炼。
因为产品经理在思考和绘制原型时是根据需求将功能合理地展示出来，因而也更容易将功能的作用向程序员去讲解，但实际上，这对于他们来说只是明白了你所绘制的原型满足了什么样的需求，能看懂你画的不再是个按键而是有实用的东西。但是对于他们程序开发起的作用相当有限，甚至，如果你说这个按键的功能没有表达完美，反而更容易让他们产生误解。
如何在产品对接关键的这一步骤中说该说的话，隐去没必要的言谈呢？
经过这两月里间的构思与询问上司意见后对比实际工作效果来看，方法很简单，那就是抓住数据源头。
对于任何一个功能模块，他的数据来源是非常清晰的，要么人为地通过各种创建，添加，新增，导入等方式输入源数据，要么关联其他功能模块，将其他功能模块间的表格，信息，字段等转移过来。那将你所绘制的功能模块最开始需要展示和操作的源数据来自于哪里，把这个交行清楚，整个功能模块后面的数据走向就都是按部就班地像正常使用过程一样看着数据在原型上流动般自然。这不仅会让对接会议变得更多高效，而且也非常适合程序员的开发思维，那些相同的，没有什么变化的字段就直接跳过不用讲解，就介绍操作了某功能后哪些数据需要变化，变化成什么，展示在什么位置。针对每一个界面，按照正常地使用流程去讲解对接，就会特别自然和轻巧，而且，这种方式程序员也会很少地打断你的讲解。
产品经理对于讲话有着较高的要求，特别是将功能向程序员传达时，说的话的好坏直接影响功能的体验度和未来可迭代的空间大小。如果你在小妹妹或小姐姐，你做这一行将有很大的优势。如果你是小弟弟或者小哥哥，那就老老实实地把话说的漂亮点，客气点吧。
总之，产品经理无论在与用户或项目经理对接需求还是与程序员对接开发需求时，说话和讲话的方式和侧重点都有所差异，但是，他们都将有技可寻，了解背后他们想知道的和我们想要他们知道的东西，按这种方式去讲该讲的内容，多煅炼几次和看自己以前对接过的原型图，想象如果现在你再来说，你又会怎么说，能讲到重点吗？
