这个题目笔者改了又改，最终还是感觉这样写更具有可读性，毕竟一篇文章最终还是以能够读懂为初衷的，现阶段，各个公司里科技开发、数据编制成为必不可少的岗位，技术和业务的沟通也日益频繁。于是，一对相爱相杀的欢喜冤家见面了~
作为一个非资深但工作有几年的程序员，工作中听到最多的，可能就是需求沟通了。业务有了一个新的方案，技术合作落地，原本珠联璧合的伙伴，却因为所掌握知识储备不同导致难以沟通。
写这篇文章之前，笔者也沟通了一些小伙伴，聊一聊沟通中遇到的那些问题，结果，话题一打开，苦水便随口而来了，笔者做了一些简单的总结：
一个做了多年技术的程序员小哥哥是这么说的：
一个词我说的是这个意思，他理解的是另外一个意思；
技术思维和业务思维不一样，实现上技术懂得多，业务不明白怎么实现，讲半天也还是不懂；
业务非要实现本来没有必要的功能，而这个功能在开发看来可以替代，而且耗时很长，不愿意开发；
业务在理解需求的时候不能确定，导致随时变更需求，引起重复劳动。
从程序员的角度看，这似乎满是道理，但是在业务眼里，却又是另外一番天地了，我们来听一下业务的心声：
我不是做技术的，怎么实现不是我的职责范围了吧；
说我理解不清楚需求，我认为不合适，毕竟如果看不到数据，我也不知道对错对吧，看到结果我才能调整啊；
有些数据我一眼就看出偏差，程序员却发现不了，提供了一个差异在100倍的数据；
有一个可能实现不了的想法：就是我希望程序员能了解我的取数目的，一起讨论怎么完成更合理；
和技术之间有明显的gap，我以为很简单的东西，没想到实现起来却如此复杂；
两边各执一词，于是，沟通成本出现了，一个简单的需求沟通半天，最后还是免不了反复调整的命运。
笔者认为，如果结合业务和技术的角色定位，或许就可以理解一二了。
对于运营和营销来讲，最重要的是如何提高月活？如果获取利润？至于怎么证明月活？怎么证明利润？却不是第一位的职责。
对于技术而言，最重要的是如何实现功能？如何提高性能？至于实现什么样的功能？却是需求说了算的。
一时沟通起来，像是不同语言在交流，两头雾水~
一位不愿意透露姓名的资深人士讲到：需求沟通的问题，要么是缺少职能，要么是缺少能力。着眼这两方面，gap也就产生了。
对于这一问题，笔者请教了一些能够在技术和业务间顺畅沟通的人士，总结了一些需求沟通的小技巧，只是提出一些数据需求的思考方法，未必能覆盖所有的场景，供大家参考，希望有些许帮助。
一、需求包含背景
对于数据需求而言，需求背景的描述是非常重要的，一方面能协助自己理清楚提数的思路，另一方面也可以让那个“拉SQL的”快速的了解到有哪些字段能够匹配当下的需求；
此处笔者想描述一下程序员接到需求时的一个心理反应，或许未必准确，权当是抛砖引玉吧，欢迎大家分享提需求和接需求时的心理逻辑：
遇到一个需求，程序员心理往往是：
他在讲什么？
他讲的东西在哪张表里？
这些表里的字段口径是否一致？
所以，遇到一个反应缓慢的程序员，请见谅，毕竟，他想的挺多的~
我们用一个案例来分析需求的背景问题吧：
“我们前两周针对持续三十天未登录口袋的客户做了一场促活的活动，想了解一下这两周时间里用户新增有多少？”
在笔者看来，这应该是一个比较全面的需求了，我们来具体分析一下：
（1）需求背景是“前两周做了一场促活的活动”。
锁定了时间指标和统计的功能范围，这样的背景描述可以协助程序员了解这次需求的全貌，也只有在这样的基础上，一些有思想的程序员才能够提出一些建设性的意见，也有助于了解这场促活活动的全貌。
（2）需求客群是“持续三十天未登录口袋的客户”。
客群是数据统计、数据分析过程中非常重要的一方面，不同的客群针对同一指标可能会有天壤之别，比如统计客户的投资兴趣时如果圈出的客群是“资产为零的客户”和“五百万以上资产的客户”，统计出来的结论一定是不一致的，除非需求就是要看一下他们有多么不一致，就另当别论了。
（3）统计指标是“两周时间里用户新增有多少”。
需求的目的就是要了解一些指标，那么，提需求时最重要的当然也就是说清楚这些指标是什么了，统计时间是“两周”，统计指标是“用户新增”，基本上可以判断是计算UV了，至于什么样的字段来计算UV，估计程序员会非常主动的去沟通了。
总结一下的话，一个较为合理的需求往往需要解决一句话：我们在什么时间，针对什么人，做了一件什么事情，需要了解什么指标？
当然，我们在处理需求时未必如上文一样简单，本文也是想给大家提供一些思路而已，让大家在分析需求时能够有的放矢，欢迎大家沟通。
二、梳理需求逻辑
另一个需要大家关注的点就在于逻辑，笔者在接需求的时候经常会遇到一些逻辑较为复杂的需求。
比如：“我想统计一下看得见顶部XX按钮的客户，对理财、转账等多个常规tab的点击和浏览情况，而后计算近两周点击过理财、转账等多个常规tab的人在8月份每天对相应tab的访问PV和UV，最后按照各tab分组呈现。”需求表达也可以做一下相应的调整：
“统计人群：客户号为偶数的人群。
统计指标：
看得见顶部XX按钮的客户，对理财、转账等多个常规tab的点击和浏览；
计算近两周点击过理财、转账等多个常规tab的人在8月份每天对相应tab的访问PV和UV；”
这样的表达怎么样呢？
这是一个相对复杂的需求，他不仅多次圈定人群，还存在多次计算以及运算场景的转换（一个是计算每天的点击情况，另一个是计算不同时间段的点击值并比较）。
如果是一些较为简单的需求，上面的描述几乎可以说是完美了，一个偏向业务，描述了需求逻辑，一个偏向于技术，也描述了数据逻辑，足以看出“提需求的”人的功底，但是如果是较为复杂的需求呢？
我们试想一下，如果沟通过程中仅仅告诉程序员上面一句话，程序员最大可能会“根据这一句话”+“自己对这一需求目的的理解”整理出SQL语句，如此取出的数据准确性是很难保证的；
“俗话”说的好：在看到数据表之前“拉SQL的”都不知道该怎么写语句合适，更何况不经常接触表的人呢。
我们可以将上面的需求做一下调整：
统计背景：
我们正在做一个对比实验，客户号为偶数的人群能够看到顶部XX按钮，客户号为奇数的客户看不到，看得到顶部XX按钮的客户转账、理财等常见tab显示在首页最高位置，想了解一下顶部XX按钮对客户行为的影响。
统计思路：
统计看得见顶部XX按钮的客户，对理财、转账等多个常规tab的点击和浏览情况，目的是了解一下客户在新环境下主要点击哪些按钮；
结合历史数据做对比，统计一下实验之前看不见顶部XX按钮的客户对理财、转账等多个常规tab的点击与实验之后的点击差异，即：计算近两周点击过常规tab的人在8月份每天对常规tab的访问PV和UV，最后按照常规tab分组呈现。这样调整是不是可以清楚一点呢？
“背景”+“目的”+“统计思路”
一个较为清晰的数据方案就会在“提需求的”和“拉SQL的”人头脑中形成，中间的一些细节问题才能较为顺畅的沟通，程序员也可发挥自己的主观能动性提一些思路，而不是简单的做个取数的人。
需求背景和目的的重要性就跃然于纸上了~
另外，还有一个需要注意的小细节，就是：需求落在纸上，我想大家都很难想象上面的需求通过电话或者聊天就能清晰的让人理解吧？
需求落在纸上的两个好处主要是：
协助“提需求的”整理思路，编辑需求的过程实际上也是整理思路的过程，能写出来的需求基本上就能解决一半了；
协助“拉SQL的”翻译逻辑和理解需求，上面的需求全程语言沟通估计会事倍功半吧。
三、常用的模型聊口径
上面的两个思路基本上可以解决大部分需求了，不过很多读者可能会疑惑了：“大佬，上面是散打吧？有没有套餐啊，也方便我们系统的了解提需求的思路？”
系统提需求的思路其实有很多的，大多是工作中的真大佬沟通过程中总结出的经验教训，下面我们来介绍两个比较常用的：
1. 5W2H模型整理思路
这个模型可以协助提需求的人在整理需求时有思路可寻，提出的需求能有一个完整的思维逻辑，而不是漫天撒花，当然了，很多人可能看到这个模型瞬间原地爆炸，“我就提个需求而已，这模型这么多元素，岂不麻烦，增加工作成本”，其实我想说的是两点：
增加的是学习成本，但是减少的是沟通成本，整体核算下来，利大于弊；
针对不同的需求，可以选择部分元素，未必一定照本宣科；
但凡提炼成文字的解决思路，大多不是按部就班的，研究一下模型的思路，找合适的部分融合到自己的需求里面，或许，你提出的一句话需求也可以让程序员秒懂。
我们来具体介绍一下：
WHAT（什么需求）：即统计什么指标，需求的主题部分，讲清楚要什么，例如：“需要PV还是UV，还是转化率”等；
WHY（何因）：需求的背景和目的，为什么要统计这些指标，例如：“在做AB测试，需要查看一下AB两个方案的差异”；
WHEN（何时）：需求的时间要求，即统计什么时间段？统计的时间频率是多少？每月？每天？还是每周？。
WHERE（何地）：需求的位置要求，即统计哪些页面？或者页面上哪些tab，协助程序员定位分析的流程和统计的目标。
WHO（什么客户）：需求统计的是哪些客户，这个是非常重要的一个指标，即客群定位，客群清晰是分析的基础，否则容易南辕北辙，试想一下，如果我们在青少年中统计贷款情况，估计很难得到好的效果。
HOW（怎么做）：需求的逻辑要求，这一元素可以将前面的几点串联起来，告诉程序员具体要怎么分析数据，例如：计算“近两周点击过底部其他tab的人在8月份每天对底部tab的访问PV和UV”。
HOW MUCH（开发成本）：预计花多少时间，提需求的人对开发周期是会有一个预估的，统计一个指标搞一个月和统计十几个指标搞两天都是不合理的，可以根据需求的大小与程序员做相应的沟通。正如前面所说，模型是固定的，但需求是灵活的，上面的模型也仅仅是为大家思考需求提出了一个思路，让大家能够有迹可循，平时工作中用到哪些指标还需要具体需求具体分析的~
2. 口径颗粒度对齐字段逻辑
颗粒度是针对统计的字段而言的，主要是查看统计的字段之间口径是否一致，是否会有错位等，我相信这一问题几乎困扰了大半的“提需求的”和“拉SQL的”，都曾为口径聊得口干舌燥；
笔者介绍一个较为常用的方法——“流程图分层”。即将不同层级的字段从上到下串起来，思路是否会清晰好多。
我们可以先看一个案例：新活动上线数据统计：
统计口径为：
统计背景是开展行员推送新活动给500万资产的客户，以促进客户新增和活跃。
统计目的是为了查看行员每次推送是否达到了预期的价值。
我们可以把上面的需求做一些分解，整理出需求中颗粒度由粗到细的流程图：
（1）行员推送活动的流程：
这一流程可以统计出行员推送多少活动给到客户，从推送级别定位口径，行员和活动之间是多对多的关系，即：每个行员推送多个活动给到客户，每个活动也会被多个行员推送。
（2）客户接收活动信息的流程：
这一流程可以显示出多少客户访问和转发了活动，从访问级别定位口径，直接访问即从行员处直接获取到的活动信息，间接访问即从客户转载中获取到的访问信息，两次访问单独计算，又是一个多对多的关系，整个逻辑还是有一定复杂度的。
（3）活动引发订单的流程：
AUM是一个比较难处理的流程，首先AUM订单是从活动级别的口径，分析整个分享活动带来的所有AUM订单，其次AUM余额又是客户级别的口径，分析客户最新的AUM余额是多少，原则上是多对多和一对一的关系。
四、验证结果很重要
在程序员的眼里，或许只有“NULL”、“空值”、“乱码”才会意识为错误数据，这些基本上都是技术性报错。而在业务眼里，结合自己的业务逻辑不同范围的数据也是明显的报错。
比如：统计百分比的数据得到的是1.01，整理年龄字段时发现有200岁，这些算是比较明显的错误，或许程序员也可以发现，那么，再细致一点呢？
比如，推广一个活动查看PV值是100000，UV值是1000；客户登录银行设备平均数是100，这些是否就这么明显呢？
我想就未必了吧，所以，在验数阶段，最好的方式是“提需求的”与“拉SQL的”相互沟通验数标准：“提需求的”告诉“拉SQL的”因为什么删除了哪些技术上错误的字段？“拉SQL的”告诉“提需求的”在什么范围内的数据是合理的？
经过反复的沟通，才能得出一个相对合理的数据分析结果。
总结
上面说了这么多，我们做一下总结吧～相爱相杀的小冤家们，我们开始画重点了：
我们在什么时间，针对什么人，做了一件什么事情，需要了解什么指标？
“背景”+“目的”+“统计思路”；
需求落在纸上；
“流程图分层”协助对齐数据口径；
通过流程图来整理思路可以协助大家在沟通需求时保证口径的准确性和一致性，可视化的手段解决逻辑沟通的问题，减少了提需求和拉SQL的人的沟通障碍，毕竟流程是大家都熟悉的东西。
文章写到这里就告一段落了，主要是对常见的一些需求沟通问题做了总结，未必适合所有的需求，但可以覆盖一部分沟通，笔者也会持续总结，希望能找到更简单的沟通方式，搭建“提需求的”与“拉SQL的”之间的鹊桥。还是那句话：欢迎大家沟通~
