何解？书籍多得像海洋一般，什么方面的都有，以人的精力，不能全部都读到，只需要找那些想要学习的来读。所以“想”这一需求很重要，但只停留在“想”的基础上还远远不够。所以清代小说家蒲松龄在短篇文言文《阿宝》中明确点明：
性痴则其志凝。故书痴者文必工，艺痴者技必良。世之落拓而无成者，皆自谓不痴者也。
又何解？性情痴的人他的意志十分专注，所以“书痴”一定善于文辞，“艺痴”技艺一定精良。世上那些落拓无成的人，都是那些自谓聪明,既想要.....又想要.........还想要........（不专、不痴）的人。
01
需求分析之Brown Cow模型
以体现业务过程的数仓开发为例，可以参考Kimball的《数据仓库生命周期工具箱》方法论，前面我也简单写了类似的文章。对于需求调研而言，调研方法论、风控方法都类似，即找专业的调研对象调研、梳理主需求、聚焦核心、风险收窄，这块并非只有技术流的风控，其实经营管理的人性弱点金博尔也有明确说明。实际上大多数中小公司各个业务部门的负责人数据素养会比较差，拎不清看问题的视角，当然更度量不清问题的尺度，但他们都会体现出来既想...........又想.............还想...........的特征，提不出来问题，但希望你先堆砌概念模型、逻辑模型，后面他们在点评这不是他们想要的，接着推翻自己的需求，循环往复，无穷无尽。当然也可以理解，能够有明确看问题的视野，有足够专业的度量尺度，就是很厉害的大营运高手了，大多数还是在帕累托分析的80%长尾部分，说是非者多，明确深度见解者寥寥无几。那么需求调研如何聚焦，如何解决上面的各种问题呢？
可以看到坐标系上明确的关键词“What(什么)”、“How(如何)”、"Now(现在)"、“Future(未来)”。信息视图为业务分析师、利益相关者提供了一些信息，用于明确需求发展过程中的不同阶段。
Now&How展示了当下整体业务架构、业务过程逻辑。What-Now是当前工作的本质，目前实际在做什么，这点很重要，能够把这块Battle清楚，将来的规划才好有比较。接着我们把视角转到Future What上面来，这里并没有提什么技术，让我可以无边的构思将来的业务蓝图，将来我们可能是什么样的业务状态。主要利益相关者需要充分探讨将来想做什么，而不用担心技术的实现问题。
Future How 除了体现将来的业务策略，还需要加上业务和技术实现，Future What是窗外的花，Future How是锅里的米。看窗外的花时也需要具备工程化的能力谋锅的米。
这个象限图不能孤立出现，否则成了空中楼阁，脱离了实现便无法洞察真实的业务真相，更不可能实现集成和创新。
在任何需求调研和规划当中，一定要把当前做事方式明确呈现出来，What-Now 能不能供需双方共同明确下来，需求方毫无保留地呈现自己目前的故事线、证据链，尤其在当前用户很难、或者没有能力描述清现状时，这很重要，也就是我们重点要看看将来有多少要保留现有的，尽管现有的工作链条可能有各种恶劣的坏名声，我们都要重点看看它的闪光点和贡献情况。这些必须呈现在将来的系统中，我们可以用不同的技术、不同的方式实现它。但底层的业务策略几乎未变，那么这里有一个核心，对当前的业务工作建模，必须确认哪些部分需要保留。否则除非老板们愿意学IBM那套管理理论，削足适履，否则大概率会推翻一切后来的原型图。
但这有个悖论，就是这个模型是来帮助理解工作的，可你不理解工作又做不出这个模型，那么就涉及到反复碰撞和对焦。
至于利益相关者访谈不做过多介绍，就是字面意思。这重点提一下可复用的需求，很多产品都是交付类的，工作调研就是观察和解释，我们需要把业务过程抽象出来变成一个模型，我们可以忽略主题事务而关注业务过程本身，这里注意是一个动词而非名词解释，比方产销协同的部门，比方成品流通的企业，我们都要在观察、解释业务过程时能够抽象出价值链模型，而且能够快速调用、迁移之前的项目经验，这要求我们寻找相似处，求同，而非找不同之处。
对业务架构抽象出模型时，不需要解释具体的技术，我们其实只需要一种工作类模型来诠释用户的理解，站在用户角度来看待业务结构。否则循环往复，无穷无尽。
回到前面的信息视图上面来，接着我们就是要做快而不完美的建模，加速自己，加速用户/需求方理解当前正在进行的工作，并达成一致性意见。那么用户/需求方会很快理解这种动态模型，并配合后续的工作。
交付类项目出现最多的高频词是“原型图/草图”，可以理解为需求诱饵，这是不是你们想要的？是的话其实就回归到了逆向工程，从原型图推导出需求，解决这些问题：
以前没有这个需求，根本没有想象过；
需求方/利益相关者，对这种技术实现没有经验；
利益相关者/需求方做过哪些工作，但卡住了？
需求相关者说不出他们的具体需求，这里唐僧都要叨叨叨了“你说呀，你说呀，你不说，我哪里知道你要什么呢？”；
需求分析师，调研方也很难理解需求到底是什么；
原型图的可行性存在疑问；
当然为了降低成本，也让需求方/利益相关者看清楚、理解清楚原型图，其实可以采取低保真的形式——第一张原型图一般是草稿纸，直接在纸上画出来。
在各种不同形式的公司调研卡壳时都可以回到上面的信息视图中来，但交付类项目重交付，其实会变形很多，有甲方需求的业务素养低，也有乙方软件公司急着交付，该搭建数仓的用ODS，该用ODS直接ETL实现，后续模型健壮性会有一定风险，当然维度层次更细时也会难以实现，这里面涉及到成本和性能的平衡。
02
不能兼收尽取。但得春所欲求者尔
业务需求方既想............又想...........还想............的心理状态其实是一种常态，不过多少预算，都是希望把原料全部堆上去，性能追到最高。
目前我们在做一个敏捷开发项目，真实的目的其实是迭代式交付能工作的产品，但本质得实现上文我提到的。核心思想其实是避免Inmon那套严格的瀑布式开发说明书，于迭代中构建产品，于产品开发的同时发现需求，目的是定期以增量的方式交付产品。
为了避免各种海到无边的需求，但又需要遵循我之前说的矩阵模型方法论，循环迭代，小步快跑是一种方法，先解决Future How 最核心的主线，当然这里面又有一个悖论就是很多交付类项目乙方营运部门期望的是快速交付，跑通，甲方不专业时工期当然会有影响，另外怕被乙方骗，被钝刀割肉，就会反复狐疑，迟迟不能定下来原型图，当然逆向工程也无从谈起。
真做到我提到的矩阵模型方法论的交付类项目很少，若是兼带着咨询性质时，情况会有所改善，我想这应该也是很多交付类软件公司在反思的点，他们带来了什么价值，对用户有没有用，用户使用度，活跃度如何？
03
丙涛说
行文至此，刚好看到有技术流朋友问简历如何写，如何体现自己数据的业务价值，Null兄说“降低成本，增加效率，增加收入，提升体验，创新业务”，而又有小伙伴说“价值体现这个东西，是要看你从什么角度去衡量，在公司内部，你就得去证明部门价值，至于怎么去核算部门价值，怎么定规则，是有说法的，眼光只放在给领导看的几个bi报表的话，那就凉了”。
这些都是我们所有交付类项目的核心会遇到的问题，也是我们自己成长或者在不同公司跳槽时会遇到的不同追求/质疑。
需求方须明白自己的现状，构思自己的心中蓝图，未来想如何，如何实现，乙方/技术部门也需要具备模型思维来动态建模以承载业务架构，否则项目的上马、交付都会成为“走马观花”之举——鼻子有缺陷拿大花，腿部有缺陷骑大马。
身在局中的你我，都须深思之、明辨之、笃行之（痴）。公司也好、人也好，差距往往体现在规划差距、眼界差距和方法的差距上面~~
