问题（一）数据开发要不要写测试报告
昨天在项目上，有位项目中的年轻数据开发者向我提了一个问题：他认为写测试报告只会增加他们的工作量，其实对开发工作本身并未有实际帮助，这是不是管理者对开发人员的一种过渡的压榨？尤其是在项目工期这么紧张的情况下。
我开始其实是不理解这位年轻的数据开发者为什么会有这种质疑，尤其还是这么具有挑衅口气的问题。就像你给一个在马路上嬉戏小朋友说：不要在马路上嬉戏。反而遭到了嘲笑：我在这里玩的好着呢，你是不是有问题？
第一个问题：软件开发，要不要做测试？
在这个问题的场景下，但凡是正经上过计算机学科专业课的同学都会毫不犹豫的做出肯定的回答。但是为什么又会有人问出这种问题？所以，以此判断核心原因是不想写测试报告。理由也过得去，毕竟写个文档也是要花不少时间的。所以，这个问题就演化成，项目进度紧张的时候是不是可以把测试省略掉？或者是把写测试报告的事情省略掉？后面再补。
如果是这个问题，会有截然不同的回答。其实越是进度紧张，作为管理者越难做出省去测试直接上线的决策。因为上线只是一个动作，上线代表了投产，如何能确定开发动作的质量达到上线标准呢？必然是测试。那怎么证明我们做了严谨的测试呢？必然是测试报告。在这里，我就是做了这样的决策。所以，如果一个开发人员质疑管理人员做的开发要测试，编写测试报告的时候，必然会遭到管理者的痛批。差不多就是你小子还想不想在这个行业干了，不干就快走，之前发的工资我都想要回来，以前一定是错付了。
但是现实工作中，不做测试就上线的情况，大家都会遇到。大多还是因为时间进度的问题，或者就是跳过了单元测试、集成测试，直接到了业务测试。其实这位年轻的开发者，要表达的是：是不是直接进行业务测试，把中间的环节都省略掉。因为他体验到的实际情况就是这样，前面这些工作是没意义的，最后一把测试对了，就完事了。刚好这个项目在集成测试和业务测试环节，没有要求写测试报告。从严谨的软件工程来看，这几个环节都需要测试，也都需要写测试报告。所以，答案就是其实测试是不可以省略的，但是根据项目的实际要求，有些环节和文档是可以适当裁剪的。
在这个项目，经历了单元测试、集成测试、业务测试三个环境。但是只要求了单元测试报告，集成测试和业务测试环节，通过缺陷管理系统去管理了测试和BUG修复的过程，所以，没有写对应的报告，项目组也是相当于在系统中有这么一份过程文档留下了。
如果想什么都不写，不项目交付过程留痕，作为一个稍有规模的公司或者客户，应该不会允许这种情况出现，建议从事这个行业的新人还是要有这个心里准备。
第二个问题：既然已经是裁剪了的测试工作和文档工作，为什么还会对这仅存的测试文档工作有质疑？
我相信搞技术的同学不会只为不想写文档就故意诋毁这项工作的重要性，更何况过程文档是日常项目交付中一个重要的产出物。既然提出了这个观点，一定是这个观点是有事实支撑的。
这个事实我们其实都知道，在上一个阶段的需求一直没确定，前期花了不少时间做的开发在后面都被修改和推翻了。也就是说，前期需求都没有搞清楚，做的很多工作都是白做的。自然这个单元测试和写测试报告的工作确实就是没有意义的了。
这其实是另外一个课题了，在国内这个环境，好好的做出一份需求和设计，并能保证这个需求是符合最终业务需求是何其难（时间与人员）。业务人员很多时候是需要我们先做出来，然后再去迭代思考。所以，我们以这个前提去做的很多工作，就需要足够敏捷。在这个场景，更适合的方法是要跟业务反复去快速开发迭代，等到一切设计都完成，再去做这个单元测试的工作。而不是在反复迭代的过程中去做严格的单元测试工作，这样确实代价和成本都太高了。
所以，作为一个做软件服务的公司，在遇到一个新的客户的时候，在需求阶段要尽早判断我们遇到的客户是什么样的客户。我早年在服务银行业客户的时候，还是传统的流程，需求定了就做开发，开发完成就测试，测试通过就上线了。即便业务后续有需求调整，也是下一个版本的事情，不会这么随意。但是这个流程是非常长的，时间会很久。所以，软件行业在一直强调敏捷。因此我不去强调对错与否，大多时候我们与客户第一次合作的时候，大都只能先尊重客户之前的工作方式。所以，我们要选的是我们应该与不同的客户如何去合作，遇到不同的模式采用不同的策略。
说到了这里，我其实应该表达的差不多了，大概就是跟年轻的同学们讲个道理：测试是一个必要的软件开发的环节，但是怎么做，做多少，在什么阶段做，跟实际的项目情况由项目管理者（it`s me）来决定。
问题（二）要不要构建公共层
在项目上，有位项目中的年轻数据开发者向我提了一个问题：感觉公共层没有必要做，并没有减轻反而增加了工作量。对此，我提出了我的观点：
第一，我们项目开发有两个阶段，现在是第二阶段，我们是否发现我们在第二阶段在公共层投入的开发工作会少很多？如果没有公共层，我们是不是要做一些重复性的工作？或者我们其实还是要在应用层实现公共层的逻辑，也就是共用应用层的一张基础表？
第二，我们做到这个阶段发现最大的困难是什么？是统一的公共维度。我们发现A部门有A部门的维度表，B部门有B部门的维度表，即便这是同一个名字的维度，也很难统一。这也是维度建模最核心的一致性维度的问题，这是开始实施数据中台模型开发的遇到的最大的困难。为什么之前没有遇到这个问题？如果我们公共层最后把这些问题都解决了，后面再用我们公共层的人是否就没有我们现在这么困难了？是不是就很容易实现企业级的数据的分析了？
对于第一个问题，回答是肯定的，前人栽树后人乘凉。现在刚开始的时候，就是栽树的时候，感受不到乘凉的快感，反而会感觉不栽树更轻松。我们要看到现在在做的工作的长期意义，就自然就理解我们现在的困难是有必要的。
对于第二个问题，公共层解决了什么问题。就是企业级的标准化的问题，之前都是在部门级视角来分析问题，各业务人员都是独立且割裂的。对于同一个问题的解释必然存在多种正确又不同的回答，但是数据中台是否就是应该是要解决这个问题？必然是。
所以，回答是必须要做，而且这才是我们对客户宣传的中台的根本意义。不是在于当下，而是在于远期，不是部门级的视角，而是企业级的全局视角。
建议对数据分层架构不了解的同学，可以看下我的这篇《数据仓库的分层架构与演进》文章。（https://developer.aliyun.com/article/892787）
问题（三）没有人能继续交付数据中台
在项目上，我服务的客户甲方负责人向我描述了我们项目交付结束后，因为没有足够的人，他们部门后续数据开发还是由各个应用开发自己做。我们卖了一个中台项目给客户，客户并没设置独立的职能单元搞中台，还是要把数据开发交给各个业务线自己搞，目前与我们合作的组织只是从技术上对业务线进行管理和支撑。
去年早些时候，我写过一篇文章来表述自己对组织对数据中台的影响《构建数据中台的组织架构》（https://developer.aliyun.com/article/996978）。在我的观点里，构建数据中台的第一步必然是构建适应中台的组织架构。我之所以写这篇文章，也正是希望各企业对数据中台的事情不能只是说说而已，以为买了阿里的平台就拥有了数据中台，进而最终失败后又认为是阿里的问题。数据中台是一种企业架构，是要有对应的组织和活动来落地这套架构的。
为此我是不赞成目前客户这种组织工作安排的，但是我也能理解这种安排。毕竟组织架构对一个组织来说是如此的重要，面对新新事物，必然会经历“观察-尝试-再观察-再尝试”这种阶段。客户迈出的第一步，就是购买了我们的产品和服务。但是，后续要怎么做？是徘徊的。继续按照我们现在的方式来做，还是还保持企业原来自己的方式。要是按照我们现在交付的方式来做，就需要专门的人员来持续的开发和维护这个大数据平台。要是按照原来的方式来做，对企业来说就是多了一个报表开发工具而已，把产品给各个业务部门继续用就好了。自然也不需要对组织做什么调整，更不需要新增什么人员了，这样对企业来说是更轻松的选择。
简单的说，就是没有足够的驱动力来做这种变革。
从个人的角度来看观察这个企业。这个企业之前是没有数据仓库的，各个业务部门自己的系统开发人员是各自按照需要去做数据开发的。所以，以前是没有一个统一的企业级视角的。企业内部的绩效部门其实是有对企业统一视角是有明确的需求的，绩效部门管理了上千个绩效指标，但是绩效部门只能管理这些指标的名义口径，具体实现还是业务部门自己定义和实现的。我们交付的平台是能解决这个问题的，之前的数据和业务都是分散在不同系统和不同团队的，但是现在这些都统一到云平台了。不需要过多调整，只需要按照我们现在的模式继续搞下去，自然就会趋近企业的统一视角的数据这个目标。但是，现在显然决策层不能立即做出调整，还是希望继续维持以前的模式。
我并不认为这个决策能维持太久，新的思潮已经渗透到了这个组织。我们向IT管理层介绍了数据公共层的意义，也得到了管理层的重视。如果没有一个统一专业的团队去对这个数据公共层去开发和管理，要靠各个业务部门的业务系统开发人员兼职去做，我们如何能做到人员技能的专业化和内部管理协调的一致性？
既然这样，我也就给些我的建议。希望管理者去思考上面我提到的专业化和统一的企业视角的问题，要构建一个有效的公共层去支撑企业数据分析需求，这是必不可少的。接下来，第一个困难是如何让之前直接在应用系统上做数据开发的应用系统开发人员掌握使用阿里云大数据平台做数据开发的能力。第二个困难是现有的大数据平台管理团队如何去协调和管理这些与其平行的团队和人员。第三个困难是研发效率。从效率的角度，职业化分工代表了专业和效率的提升，从而提升了生产效率。软件行业虽然是一个复杂的行业，也是遵循这种规律的。
如上图左，汽车制造业目前普遍采取的流水线生产模式，专业化分工带来了劳动生产率的大幅提升，让小汽车深入了千家万户。如上图右，纯手工打造和调教的劳斯莱斯，导致其成本极其高，只能作为豪车进行小批量生产和销售。
讲了这么多，其实还是希望企业在应对数字化转型这个大课题上，不论是拥抱数据中台还是怎么做，都要知道需要达成的业务目标是需要与其配合的组织结构来支撑的。我们可以审慎而又小心，可以多做一些尝试后再做出决策，但是希望我们能看到先进生产力的好处，尽快迈出坚定的一步。
