该帖子同步发自：(铁托的博客  访问该博客)

　　大型ERP厂商都有自己的自定义报表开发工具，它用来满足客户自定义取数生成报表的需求，用户既可通过它写一个SQL语句生成一张报表，也可通过它组合某几张单据的资料生成一张报表，还可直接更改某张单据的表结构生成另外一张报表。这段时间我也在重构我一年前在公司写的自定义报表开发工具，通过这次重构我对程序员的价值，软件工程，项目管理的认识更加深刻了：

　　一、需求分析：企划给出的需求很简单，即可以让用户通过如上几种方式新增一张报表，然后挂到主菜单上。受限于知识面我们的用户(即企划)不能提供更多的说明了，不像业务功能他们可以想得很清楚，所以能根据他们的大概想法做出让他们满意的东西就是我们最有价值的地方了，其实软件开发就是这样，很多时候用户只能给你一个大概的想法，有些他们可能还想不清楚，这时候作为一个项目经理或者是设计者你要做的就是先帮他们理清思路，然后做出他们想要的东西，这才你的价值所在，试想如果一个东西别人什么都帮你想好了，你的价值怎么体现?

　　二、系统分析：一开始看到这个功能我粗略地评估了一下，没什么难度，就是定义一个结构，让用户选择一些表，然后设置关联方式，查询字段，排序分组，过滤等条件就OK啦，所以我预计一个月绰绰有余，但是最后做下来我花了两个多月的时间(截止目前还有几个功能未实现，当然有些需求也是陆陆续续提出来的)，系统分析出现这么大的偏差我觉得主要有以下几个原因：

　　A、方向有错：因为这里面涉及将自定义报表的这份描述结构转化为机制已有结构(这样自定义的报表的取数，排版，权限控制，挂接菜单就能与现有功能完美结合，非常统一)，但我将这份描述结构理解错了，导致最后利用SQLBuilder产生语法的时候才发现自己搞错了，导致重工，所以现在指导别人或自己做的时候我都会先将整个思路理清楚，有疑问一起讨论，而不是盲目动工，始终相信磨刀不误砍材工。

　　B、细节太多：能用跟好用是有很大差别的，只有做出来的东西好用，易用才能得到别人的认可，否则就是劈天盖地的口水(最常见的就是“哇，这什么垃圾啊，这么难用”)，如果你辛辛苦苦做一个东西被别人骂你心理肯定不是滋味，但从用户的角度看你没有做出他想要的东西，他不认同你是理所当然的。但是要做好一个东西也没那么容易，很多地方你需要精雕细琢，精益求精，也就是我们平常所说的追求完美，而这些都是很耗时间的，所以这里面就涉及沟通的问题了，作为管理者我们应该知道组员时间花在哪里，为什么花那么多时间，做出了什么成果，碰到了什么问题，如何解决，是否需要协调行程，作为组员呢我们就是在适当的时机反馈这些问题，最后达到有效沟通，公司利益最大化。

　　C、沟通协调：行程紧，当时看到这个功能DELAY了好久，自己也着急，作为资深人士一直DELAY我觉得面子上过不去(其实只要能给出合理的解释这些都不是问题，品质才是最重要的)，所以将一个半成品给提交上去了，结果可想而知。其实这里面涉及到一个沟通协调的问题，如果资源不足或预计哪里有出问题，应该及时跟主管及相关负责人沟通，提出自己碰到什么问题，要DELAY多久，是否需要支援，而不是将所有重担都自己扛着，真的没必要，我们是一个团队，通过借助团队的力量来解决问题是才是最好的解决方式。

　　三、编码测试：相对来讲只要前期将系统分析做好了，编码测试就是按部就班，当然实际开发过程中肯定会碰到一些奇奇怪怪的问题，如果这些问题影响项目进度或自己不确定方案则应及时跟相关负责人商讨，而不是按自己的想法搞下去，如果一个人搞下去到最后出问题了你就是“罪人”(到时候别人会说你当时没反馈过这个问题啊)，没出问题呢大家也不知道你是功臣(别人还以为你碰到什么难题)，最重要的是通过通过团队的力量可以想到很多我们没想到的东西，也可以学到更多东西，提高自己的影响力，所以说沟通贯穿软件开发的整个生命周期，我们一定要做到及时沟通，有效沟通，与团队共成长。

　　四、感悟：自定义报表产生语法的过程中用到SQLBuilder这个组件，是HS写的，太强大了，不用不知道，一方面可以组合出强大的关联语法，另一方面可以解析复杂的表达式，要写出这么复杂的东西非得有深厚的功力才行，这有力地证明了程序员不是吃青春饭的。另外就是对完美的追求，我们是做产品的，我们需要的是最好的解决方案而不是能解决问题的方案，有些时候自己立场不坚定或受外界因素干扰就很难坚持这个原则，但是我们还是要做到始终坚持这个原则，因为只要做出用户最想要的东西我们才能得到认同，才能体现我们作为程序员的价值。