说说数据分析类项目

前言

            今年的下半年，由于RP原因被分配到了部门一个关于数据分析类的项目中，一个能通过配置规则，实现对原始数据进行各种加工后，输出成特定报表的通用平台。说起来也挺牛气哄哄的，但实际上由于各种原因，这个平台并没有使用很多前沿的技术，因此尽管是我工作以来参与的最大的项目（当然是针对业务来说的），但技术上的收获却是最少的。

        正因为如此，这篇文章不谈技术，却谈谈项目管理，这个项目带给我的体验更对是项目管理上的感悟。由于我仅仅是这个项目的码农，很多的时候并不主动从全局的角度考虑项目的管理，也往往没有足够的信息考虑全局的项目管理，这些感悟更多是当感到工作得不畅快的时候，自己琢磨如果我来管理，我会怎么做，所以提到的点会略微零散，仅仅是经验的总结，而不是知识。

让持续集成成为原子操作

        持续集成是一个我很推崇的概念，在我之前的文章中已经被多次提及了，这次也不免继续啰嗦，因为这次项目中我们也尝试应用了持续集成的初级阶段——每日构建。总体来说做得不是很成功，原因几乎可以另写一篇文章来分析了，所以这里的重点不是这个，而是我觉得持续集成应该是一个原子过程，要么彻底执行下去，要么从一开始就不要开始。

        持续集成对于提高软件集成效率、提高软件质量是由莫大的好处的。但是在一个项目中从零开始建立起持续集成，在初期需要付出相当大的成本，包括技术支撑平台的建立和项目管理制度的建立，这个在《持续交付》一书中是被反复强调的，如果对持续集成半途而废，不仅白白浪费了项目成员的精力，打击团队成员的士气，更有可能为维护持续集成相关输出物而付出额外的代价，而实际上它们已经没有价值了。

        就像已经踏上战场的士兵一样，实施持续集成的团队应该是坚定的，无论发生什么样的意外情况，都不应该打破持续集成的规则。对此不要存在侥幸心理，就像堤坝一样，一个小小的缺口，都可能让洪水冲毁。因此在实施持续集成之前，好好想一想，是否有如此决心，是否能克服可预见或不可预见的各种困难等等。如果犹豫了，那么从一开始就不要执行。

悲观地思考

        我从来不是一个悲观的人，但每当项目经理问我要任务的预估完成时间时，我都尽可能地悲观预测，因为我不是神，无法预测未来的所有情况，我可不想因为一个未能被预测到的意外导致我只能匆忙交货。实际上我觉得团队中的每一个人都应该用悲观的心态去思考问题，当然对项目的前景还是应该抱着乐观的心态的。

        项目经理应该用悲观的心态去制定项目计划，这样项目才有足够的时间去思考和应付各种可能出现的意外。如果项目计划得太紧凑，团队就只能为基本功能疲于奔命，对意外的预防措施都会被认为是优先级低的任务而被押后甚至是忽略。造成软件不可用的原因往往不是核心功能不可用，这个已经是常识了。随着软件的完成度越高，优化的成本越大，如果从一开始就把项目进程放缓一点，让团队成员有更多的思考时间，效果往往会大不相同。

        产品经理应该用悲观的心态去思考功能。如果觉得一个想法已经定型了，请尝试把这个想法再在脑袋中停留5秒。像我们这种为客户定制服务的产品经理，如果误解了客户的需求，导致的后果可能是灾难性的。因此产品经理对需求的理解应该是无歧义的，把想法在脑袋中停留5秒，就是要想想需求是否还有另一种理解，不要自以为是地为需求敲定解释。欣喜地是，我身边的产品经理貌似都没有怎么犯这种错误。

        程序员应该用悲观的心态面对每一个设计。需求变更、沟通不畅，在项目进程中都是常见现象，因此设计的方案或多或少都应该保持适度的扩展性和适应性，比如尽管某些信息比较稳定，但能设计成变量就不要设计成常量；面对一个需求，多想想有没有更抽象的实现方案等等。多思考几十秒，换来的可能是以后运营量能减少20%，或者当产品经理说需要新增需求时，能自信满满地说我写的程序能轻易适应这种变化的。

        软件工程界有一个流传很广的话：“你能想到的意外，它都会发生的。”从大学学编程的异常处理开始，计算机科学的每一个领域都鼓励我们尽可能悲观地思考问题，但现实中有多少人能真正做到。

测试数据管理的学问

        和流程类系统不一样，数据类系统对测试数据的管理要更严格，因为它需要使用的测试数据更多、数据之间的关联关系更复杂，最重要的是获取一次理想测试数据的成本很大。尽管我们的项目对数据的管理没有达到灾难的程度，但实际上是可以做得更好的。

        首先，测试数据应该专人负责，对测试数据的修改，要么只能经此人之手，要么必须知会此人。只有存在一个人清晰地知道测试数据地全局状态，才有可能有效评估测试数据的质量，减少由于数据质量原因导致项目延误。此人同时也可以负责测试数据的备份与版本控制。

        测试数据应该通过应用程序接口导入数据库，而不是直接导入数据库，并且接口使用的业务逻辑程序与被测系统的业务逻辑程序是一致的。这一点在《持续交付》的数据管理章节有被强调，遗憾的是我是事后才看到。为什么这点很重要？因为数据之间的关联往往依赖于数据库的状态，比如自增ID。直接把数据导入到数据库，容易割裂数据与数据之间的关系。对于Oracle数据库，这个问题相对容易控制，因为Oracle数据库没有自增字段，对于有自增字段的数据库，保证数据之间的关系就变得相对复杂。使用应用程序导入数据，可以很好地控制数据之间的关系，也能减少数据导入时受数据库当前状态的影响。

让测试真正融入项目

        带上测试一起沟通需求，一起设计系统，这个已经是老生长谈了，我看到有些团队是做得很不错的，但我们做得真的不怎么样。当觉得测试无法保证系统质量的时候，我们有让测试参与沟通需求吗？我们有让测试参与系统设计吗？如果没有，我们有什么资格要求测试能正确评估系统质量、负责测试数据管理及UAT管理。对测试的重视程度应该与开发、需求相当的，这样能有效减少产品经理和开发人员的压力。

数据核对是一种需求

        对于数据分析类项目，结果数据的很多是一件枯燥但无可避免的事情，而且消耗的成本异常巨大。持续交付的理念中，有一个很重要的思想，就是让容易出问题的地方尽早暴露问题，关于数据核对的处理也一样，从需求分析阶段就开始关注这个问题，把它当作需求的一部分纳入管理。

        这种处理方式的好处是显而易见的。提前考虑数据核对的问题，能有助于系统设计能适应数据核对，毕竟有时候数据核对对系统架构的影响是颠覆性的。

        另一个比较不容易发现的好处是，能提高团队对数据核对任务的积极性。对开发来说，从来开发任务都是比测试任务有趣的，如果数据核对任务是系统完成后的才考虑，自然而然它就成了一项测试任务。但是如果从一开始便把数据核对看作需求管理，它便成了开发任务。尽管最终需要做的工作都差不多，但做的心态会大不相同。不要小看这一点点的区别，下文就会提到它重要的作用。对于测试，任务会变得相对容易，因为他们需要做的工作从核对数据本身的正确性变成了验证数据核对程序的正确性就可以了。

不要挑战团队士气

         写了这么多，这个点是最虚的，但我觉得是最重要的。脑力密集型的劳动应该是最难控制的劳动，哪怕是喜欢的球队输球了，都有可能影响工作效率。如果一个团队士气低下，我前面说的所有东西都是废话；但士气高涨的团队，上面说的所有问题都不是问题，方法总是比问题多的。

        《人件》一书用了大半本数来阐述如何维持并提高团队的士气，可以说是不遗余力。但打击团队士气却是一件轻而易举的事情，过分紧迫的项目计划、无休止的加班、反复地无意义工作、办公室政治，甚至是一句简单的一句：“这不是应该很简单的吗？”，都有可能打击成员的士气。因此团队成员，特别是项目管理人员，做每件事情都应该考虑事情对团队士气的影响，解决问题永远不要立马选择会打击团队士气的方法。当无可奈何时，要想一下用另外的手段振作一下团队士气。

后记

        我承认这其实是一篇马后炮的文章，也仅仅是一篇纸上谈兵的文章。工作两年，加上平时阅读各种经典著作，我对项目管理也渐渐形成了一些自己的看法，上面提到的内容也是这些看法的体现。项目管理本没有对错，也受个人的经验和知识体系的影响，我的想法必定不是最优的，也略显理想化，但我还是衷心希望自己有一天能遇到一个我能为之全力以赴的团队。