数据人的思维惯势与思维体系

数据人的思维惯势

每一名数据的从业者，都有一颗成为技术大牛的心。
自毕业起，我们就为自己贴上了“程序员”的标签，“ACM”、“BAT”、“Coder”…这些极具行业特色的词汇，对于每一位年轻人，都有着莫大的吸引力，“成为受人敬仰的大牛”，是每个年轻人心中潜在的梦想。在走上工作岗位之后，这些原生的梦想，依旧在驱动着每个人不断的学习与前进，即便是每天生活在“不会”、“不懂”、“不能”的残酷现实之下，依旧在持之以恒的努力，完成个人技术能力积累第一阶段。
正式因为技术积累的痛苦，加深了每个人对于自己“技术人”角色的身份认同。
带着这种思维惯势，在工作中，不论遇到怎样的需求场景，始终会将“Coding”作为自己工作的核心，编码规范、程序性能、实现技巧、研发效能这些才是“技术人”应该关心的。而与编码无关的东西，统统打成了影响效率的“糟粕”，将工作中的沟通与调研成本，惯性的推给产品或者是项目经理去承担。其实这种认知上的偏差，在成长的前几年中，并不会体现的那么明显，而随着职级序列的提升，技术人逐步感受到了“客观环境”对自己的要求，与自己“主观意识”认为的要求，产生了不匹配的情况，并因此产生焦虑。
只有这种矛盾，切实影响了自身的利益，它才会被重视起来。

思维惯势产生的原因

沉浸在过去的成长环境中，忽略了因为个人能力提升而带来的环境变化，是思维惯势产生的直接原因。
对于数据同学而言，不论是数据分析、数据仓库、还是数据架构，我们所面对的环境是什么？是“写一手漂亮的SQL代码”？还是“搭建一套自动化的算法”？其实都不是。技术只是我们日常工作的一部分，而我们的工作要求，应该是深入到业务过程中，用数据来描述业务的过程与现状，并预测未来可能发生的事情，也就是“帮助使用者实现业务的数字化”。从认识到这个情况开始，技术就不再只是我们唯一关心的内容了，而是要将自己的身份，定位到具体的业务方向，用自己的技术能力，去解决未知的业务问题。可以说，在这个阶段，“不懂业务，就别谈开发”。
你会逐渐的意识到：业务知识、需求分析、领域建模、项目管理、研发效能，这些东西在工作中的比重，会越来越高，远远的超过编码工作量。
技术人在日常工作中，通常会有一些特定的偏见，例如“产品只需要做好原型”、“运营只需要维护社群”，等等。这种意识，与“研发只需要写好代码”，是同样的思维惯势，如果写代码是必须的事情，而且不能被打断，那么这种思维方式，终究会受到环境的制约，影响到后续的职业发展。因为，晋升可不只是看你的代码水平。一个人的强，永远只是一个人，而一个团队的强，才是真正的强。不要再相信“1个熟练的程序员等于100个初级程序员了”，事实上，你往往不是那个熟练的程序员，而是属于初级的那个。

数据人应有的思维体系

简单说，数据人应该有属于自己的思维体系。
例如，数据仓库属于知识体系A，分析算法属于知识体系B，业务知识属于知识体系C，那么我们在碰到任何问题时，在大脑中快速的把A/B/C扫描一下，相关的知识提取出来，乘以新的问题，就是知识体系D。久而久之，我们的认知范围越来越大，理解问题，也就越来越“快速而深刻”。
以帮助业务方实现数字化为例，我们就需要关系如下几个方面的内容：

• 业务概念是什么？
• 业务存在的目的和应有的价值时什么？
• 业务会涉及哪些方面的内容，例如产品/运营/风控/项管都应该怎么做？
• 业务的生命周期是怎样的？
• 实现业务所需要的技术路径有哪些，在这个过程中，交互/前端/后端/数据/分析/产品，都应该承担怎样的职责？
• 作为技术一号位，应该考虑哪些内容，参与哪些会议，才能够获得最全的信息，从而保障业务顺利落地？

所以，业务就是知识体系A，本职的技术是知识体系B，合作方的技术是知识体系C，而项目立项的过程是知识体系D，业务的会议过程是知识体系E…… 多维叉乘，你的见识与理解，就超过了所有人。时间一长，你在团队中的地位，就会逐步的确立起来。

如何提升自己

“做业务”需要的知识，和“做技术”需要的知识，本质上没有区别。
现代人的知识体系，都是在前人经验总结（书本上的知识、业务方的讲解、行业会议的成果）的基础上，配合个人实践的经验，从而实现的知识叠加。数据人经常会讨论，如何权衡个人发展路线的深度与广度问题，例如是精通整套大数据架构的实现过程，还是精通Hadoop一个平台的技术原理。同理，在“业务学”上也有同样的情况，产品/运营等同学，天然的在业务上比我们积累要深厚，如果要快速积累自己的业务知识，就应该放下成见，多去跟他们聊，想他们面对的问题，掌握一个业务的全部环节，并参与其中。在自己负责的细分领域内做到全面的负责，就能够成为一个业务的技术一号位。
纸牌屋第一季的第一集，Frank讲解了自己的工作，就是疏通党内的淤塞环节。承担一些杂事，多做一些交流，试着去疏通团队中的淤塞环节，你会学到更多。