昨天晚上做了个梦，梦见作为一个业务分析师突然被拉到台上演讲。作为一个从小就害怕演讲的人，没想到有一天也要靠“嘴”吃饭。
对，很多人对业务分析师的印象都是靠嘴吃饭，毕竟我们每天的工作内容不是把话说出来，就是把话写下来。从业务专家或者用户嘴里听到一堆需求，再将需求进行逻辑化的解读分析形成方案，向技术宣讲方案，保证与技术理解一致后，进入到开发实践。整个过程，感觉自己是一个“信息中介”。
既然自诩为“中介”，不由得想到中介这个职位，不是一开始就有的，而是在行业形成规模化效应后，才产生的一种服务。那么业务分析师是怎么出现的呢？是不是也有类似的过程？
不知道还有多少人记得Flappy bird，就是下图这个蠢蠢的鸟。
这个风靡全球的游戏，从构想到实现，都由一个人完成。一般我们习惯用一个人的主要技能来定义他的角色，所以这时候团队中只有Dev（开发）一个角色。但是试想一下如果这个游戏开始有了投资，投资者期待更多的收益，游戏需要不断迭代更新，创造新的玩法，同时为了抢占市场，也开始有了上线时间的压力。于是团队开始扩张，首先当然会加入更多的Dev，Dev作为核心生产力，投资者希望他们只专注在开发上，这时候就需要其他角色去分担原来一个人做的事情，这种职能分工加速了产品的规模化作业，从职能分工角度，也就出现了QA（质量保证），BA（业务分析），UX（用户交互）和PM（项目经理）的角色定义。
记得大学的时候，老师总感慨以前的知识工作者多厉害，从硬件到软件，没有不懂的领域。那时候的知识工作者是极少的，他们富集了丰富的复合技能，才能完成他们想要做的事情。那是因为当时的情况下，市场还没有形成规模，代表没有对应的人才培养机构，去应对市场培养出不同知识领域需要的人才和专家。但是如今的市场中都有几十万甚至百万的人工作在其中，这样的规模化效应导致信息大爆炸，知识开始按照领域不断细分，专业和工作能力也越分越细。我们从原来培养“八级钳工”转为培养“八级技工”。
在能力和专业越分越细的过程中，人才结构也越来越清晰。博采众长的人依然站在了知识和能力的顶端，成为了引领时代的佼佼者，像是“赤壁”中的诸葛亮，凡事儿都略懂一点。
说回业务分析师，刚才说了那么多，其实就讲了两件事，第一，业务分析师是怎么来的；第二，人才市场的细分过程中，业务分析师的工作领域和能力逐渐有了清晰的定义。那作为“信息中介”的业务分析师到底要具备什么样的能力，最终给市场输出了什么价值呢？
我们来看看软件的发展过程。软件一开始的时候，是对真实世界的结果性数据进行保存和计算，慢慢随着计算能力的发展，软件开始辅助完成现实工作流程，到依靠网络的集群效应，软件消除了真实世界的限制，实现工作流程的线上化，数字化和规模化，到现在不同行业间的数字化产品，产生大量的共学和互通，用数字化能力赋能真实世界。软件的发展过程，是与现实世界不断产生联系的过程。而现实世界是依靠商业进行交流和发展的，商业的本质就是等价物品的交换，是价值流的流动。
那么业务分析师在加速价值流动的数字化进程中，需要做什么呢？可能只有两件事，“挖掘”和“翻译”。
“挖掘”指的是对市场机会的了解，发现市场中潜在的价值流。这就包括你需要清楚在数字化缺乏的领域里，价值流是如何产生并且流动的，人和人是如何在市场中进行等价交换的。数字化产品如何对市场形成有效的帮助，是否可以让价值流被更多人发现，亦或是加速了整个流动和交换的过程。比如你可以通过数字化产品增强物品的生产效率，降低生产成本，也可以通过优化供应链，加速整个物品的市场交换过程，也可以构建自己的信息化渠道，让商品被更多人更多市场看见。
这种对市场信息化发展机会的挖掘能力，是业务分析师非常重要的能力。他需要你不仅仅关注在如何将数字化产品生产出来，更需要关注在数字化产品的价值定位。这种对产品价值定位的思考，让你的思维模式不局限在产品设计上，更多的是在产品和世界如何联系上。找准产品的价值定位，并且知道产品价值将通过什么样的数字化手段，与真实世界产生联系，是一个业务分析师在产业数字化发展进程中能够起到的重要作用。
“翻译”研究的就是信息交换。总是幻想有那么一天，我们可以对着电脑说出需求，电脑就直接按照我们的需求生成一个完整的产品，但这一刻暂时还没有到来。
既然这一刻还没有到来，那么电脑，作为一个方方正正的小可爱，就需要有人告诉他，你到底要他做什么。这时候“翻译”工作就变得尤为重要。
很多人会说，诗是没法翻译的，翻译过程就是信息流失过程。这说明自然语言是一种意象化的语言，他不仅包含本身的字面意义，还会在字面意义背后蕴藏一堆引申含义。这就是小时候为什么一提到要理解文章的中心思想就让人头疼的原因。所以翻译本身就是一种再创作。软件领域也是一样，不断衍生的各种管理方法，需求分析方法，应用架构方法和软件语言进化都是为了让“翻译”过程尽量减少信息损耗。
这时候需求分析师就承担了很重要的，对自然语言的翻译工作，并且在工作中发展出了很多有效的工具。比如设计思维方法，通过对用户需求的探索发现，收敛归纳出有效的数字化方案解决用户痛点。比如DDD，对数字化方案进行事件风暴分解，厘清方案中涉及到的业务语言，业务领域，业务事件，再将业务事件进行领域划分，形成基础的微服务架构，通过事件同步，API命令和分层的代码结构进行实现，最终慢慢实现成用户手中的产品。这就要求业务分析师不仅要有逻辑化的思维方式，还需要了解最新的数字化发展方向，然后通过有效的“翻译工具”链接用户需求和数字化手段，将构想变成实现。
所以“挖掘”和“翻译”，如果你是一个业务分析师，你觉得你都做到了吗？
