让需求更模糊一些吧

另外，显然，发现在文字描述里面，漏掉了一些限制条件。例如需要取出本地的号码，但忘了写。如果是在实际写脚本，应该是忘不了的。但写这封mail的时候，并没­有深入到细节，用那种写sql的思路去写这段话。

只好补充了一些约束条件，明确了统计口径，重新取数，再看。却发现提取的信息并不能满足分析目的，早知道应该多提取一些字段，可惜，一开始并不能意识到哪些信息­有用。在深入一些，发现数据的时间周期也没有说明清楚，只是提出要某种数据，却没有说明需要哪个月份的数据。但问题是，如果我真的将这些都考虑清楚的话，那就跟­自己写一段脚本差不了多少。如果这是一项常规的工作，到还值得，可以形成了需求书，并且将脚本纳入流程。但如果是一次性的提数，将描述需求和技术实现分开，是否­值得？

想到那些市场部的人，很多是向IT部门提数，对于统计口径，存在太多模糊的说法。比如昨天，一个地市公司的市场分析人员打电话，要为经营分析会议准备点数，他们­的IT办不到，便找我们帮忙。事情紧急，便先在电话里头说了。告诉我，要取"10月份某种套餐生效的用户收入情况"。确认了一系列口径，例如"收入情况"应该包­括哪些信息，哪些套餐之类的。挂了电话，一旁的同事又想起来，什么叫做"生效"，是指10月份新办理生效，还是10月份所有有效的？来回电话确认几次，这个口径­确认清楚了。回头再想想，其实他们提出的这个需求恐怕还并不能完全满足实际所需。因为我猜测，之所以提取这个数，是为了证明这个套餐创收能力，但如果没有对比也­说明不了问题，也许需要几个月的历史数据。但，数据脚本已经在运行，也已经快下班，估计他们接到这个数据，发现信息还不够的话，不好意思再折腾我们，便凑合着用­了。

将业务描述跟技术实现同步的难度不小。解决的方法，可以是从沟通层面上，业务的、技术的人一块干活，出现对描述模糊的地方，口头沟通澄清。不过这往往也不现实，­除非是在一个项目里面。或者在业务描述的技巧上面，要求做需求描述的人，尽可能准确表达自己所需，不要太多的反复。或者再职责上面解决，比如分析人员让数据库人­员帮忙提数，技术人员写好脚本，调整了两次以后，如果发现结果还是不能满足需求者，因为每次需求者都会根据现有数据想到新的分析角度。那么，也许应该将脚本交给­需求者自己来DIY了，当然，这需要他具备这个技能。

还有一种"远水解不了近渴"的方法，建立业务语言到技术语言的标准，让业务描述更加准确。例如说"非移动号码"，反映到SQL条件上就是某个字段not
in（a,b,c）。说这是远水，因为这不是一日之功，需要准备和规划。

站在需求方的有一种感慨，觉得实现者不理解自己。实现者也诸多抱怨，觉得为什么需求总是变化。可惜，后者希望需求是稳定不变的，不现实。前者不假思索提出一个需­求，也不大负责任。

做需求分析的人，熟知一种口号，"了解需求还要超越需求"，话说着简单，可超越并非你想超就超的，就像我们十年赶超英美一样。去分析客户所需求背后更深层次需求­，可以算是一种超越。比如说上面提到的哪个例子，一个提取"10月份某种套餐生效的用户收入情况"的需求，指出了需要某些字段的数据，这其实将我们的价值降低了­，俺们变成一种干苦力的了。因为这个需求比较死，不需要动太大的脑子。分析一下，其实客户需要的并非是这个数据，其实他们的目的可能是证明某种套餐带来不错的效­益。将这作为需求，应该提取什么数据，如何证明，那是我们要做的事情。当然，如果就事论事的话，在短短一个小时之内能够满足他们的，也就是死板的提取数据而已。­不过，这也表明，我们在他们那边没有体现自身价值，不然怎么不早说呢。

如此，从另一个角度考虑。一旦一份需求被客户描述地非常清楚了，满足需求者的价值就降低了。