以前也参与不少政府行业项目，很少做总结，近期又参与了某政府单位决策分析系统的构建，对报表设计中“繁”与“简”的博弈总结一下，希望大家一起探讨。
“繁”与“简”的博弈
一张报表集合了5+个业务需求，查询条件5+？这种设计合理性在项目各受益方是各执其词。
业务人员：“我这个需求你系统没给我实现？ ”
主导部门：“通过某某模块，条件选择1，2，3……，就可以实现了”
项目参与厂商：“……”
业务人员：“我需要的是三列，你这报表里我还得再加工，而且需要的某一列不没有”
主导部门：“少的那一列你可以从某个模块查询出来关联一下就好”
项目参与厂商：“……”
业务人员：“你这太复杂了，&……#￥%@#@￥@#%”
主导部门：“前期需求就是这样，这里有使用说明和帮助，你可以点击查看。&……￥%￥#%#￥%”
上面这个场景想必大家都熟悉。那到底报表的设计是要往复杂设计还是往简单了设计？
简！
首先，如果一张报表的设计能给满足多个业务需求，那这张报表的数据加工逻辑一定比较复杂，效率受到影响，采用简洁的设计能够在满足业务需求的同时极大的提升报表的可用性。
其次，对于此类项目我们要逐步遵从互联网产品的设计思维，让用户“一秒钟变白痴”（这句话好像是小马哥说的，绝对没有对业务人员的故意贬低，毕竟乙方在他们的“鄙视链”中是处于最底层的，怎敢贬低），至于项目为什么会多年得不到改变，系统之烂，以至于跳槽互联网公司只要一听你的工作经验是传统行业的，PASS几率飙升到接近满格。
最后，对于项目参与厂商，从简设计可能会造成工作量的翻倍，这个过程中你的话语权=0，以我的角度来看，不是因为甲方高高在上，而是因为现在太多的厂商做的本就是体力活，你怎么让人采纳你的“专业性意见”。
繁！
首先：报表功能强大。“你看我这一张报表满足了你们这么多需求，你以后再有类似的需求都可以通过条件组合来实现”，这确实是从繁设计的一大优点。这有点类似现在报表工具中的自定义报表功能甚至是OLAP查询，这两个功能诞生的初衷是美好的且强大的，但这一切的前提是业务人员有极高的IT素养，不然就显得很鸡肋了。
其次：减少系统模块的冗余。集合多项业务需求在一张报表会大大降低系统的冗余，不至于模块1和模块2就差在一两列数据上。
最后：会“相对”降低项目人员的工作量。
如何平衡“繁”与“简”
怎么平衡两者之间的关系，几点建议：
1.初次构建报表分析系统的话，建议从“简”设计。
2.改造或者新建报表分析系统时，建议对改造前原系统的日志进行一个全面的分析并对新系统建立完备的日志体系,能够定期对日志进行分析,合并查询条件,删减报表,逐渐对系统进行瘦身，这个工作很重要但很少有人做.
3.在系统中建几张通用性较强，涵盖查询条件和查询项相对较多的报表供有特殊需求的业务人员使用。其实这里我更建议在报表系统中对业务人员开放源数据查询与导出模块，尽可能多的包含全部数据项（数据权限一定要做好，保证数据安全性）。
总结：到底从“简”还是从“繁”，仁者见仁智者见智，主线是简单化，尽可能的降低复杂报表数量。
