>>>背景
2015年6月刚到平安社交金融平台产品天下通时，通过和产品经理和开发工程师沟通，发现在版本开发的过程中存在一些问题，产品经理比较困惑的是不管提什么需求，让开发人员进行评估，开发人员都给出了一个非常大的工作量，后续版本进度也经常延期。
开发人员更是一肚子怨气，产品经理给出的都是一句话需求，无法进行分析和评估，逼得紧了，就随便给出一个工作量估计。
这些归根到底都是是产品和开发人员之间沟通的问题，产品经理没有想办法让开发人员“听懂”自己的需求，有效沟通首先要求产品经理能将需求描述清楚，其次要能准确无误地将信息传递到开发人员并确保开发人员正确理解。
>>>基于场景组织产品策划案
平安科技原来是一个传统的金融IT公司，很多产品经理在组织策划文案时，按照原来的模板来进行，基本上是按照功能来进行罗列，Android和IOS前端开发人员看了后，还是不知道界面要开发成什么样子。
对于移动App，针对某个的功能，都是有一个特定的使用场景的。如对于天下通“问理财”应用，用户在碰到股票或保险的问题时，需要咨询某位专家，他会打开天下通App，点“专家”tab页，查找到某位专家后，开始对话咨询。
如果所有的策划文案按照场景进行组织，配以交互图，讲解起来就会顺畅很多。经过实践后，开发人员反馈，这种按照场景的组织方式比按照功能进行组织的方式要好。
>>>反串讲
在组织策划案集中评审时，产品经理在费力的讲解，给开发测试工程师传递自己想要什么。但开会时，与会者带电脑的情况非常普遍，很多人埋头盯着屏幕，不知道到底有没有在倾听，有没有理解。散会后，到估工作量时，发现很多细节还是不清楚。
为了改变这种现状，采用了“反串讲”的形式，产品经理在讲解完后，让开发人员来再讲解一遍，产品经理作为评判方，看开发人员所理解的是不是自己所想要的。
为了确保信息传递效果，反串讲这种能获取信息接收方积极反馈的双向沟通效果较好，可以应用到有比较多复杂细节的产品需求讲解中。
>>>工作量分解
原来的工作量估计的粒度很大，一方面是产品经理没有能将需求澄清清楚，另外一个很重要的原因，开发工程师没有对需求进行分解。粒度太大，不利于制定工作计划以及后续的计划监控。
因此，强制要求开发工程师必须对工作量进行分解，细化到2~3人天的粒度并具体到开发责任人。
分解的过程实际上也是对需求进行深入研究的过程，过程中肯定会碰到一些疑问，产品经理负责答疑，工作量拆解完后，对整个的需求也基本上理解清楚了，可以正式进入到开发的过程中。
>>>测试用例评审二次确认
需求澄清完后，测试工程师开始准备测试用例，完成后就召集产品经理、开发人员对测试用例进行集中评审。
测试用例是产品完成标准的细化描述，在评审过程中，产品经理对有偏差的测试用例进行纠偏，最终通过二次确认，让产品经理、开发工程师和测试工程师在产品完成标准上达成一致。
>>>后记
在平安天下通V3.5.0版本中实践后，产品经理、开发和测试工程师反馈较好，整个过程规范清晰了很多，进度也第一次实现了零偏差。
（本资讯于2016-08-09首次发布）
