我们缺少什么？--项目之胡思乱想二

业务与技术

      作为管理信息系统，业务是驱动，技术是手段，应用是目的。

      我们的工作应该是从业务开始，动手开发前一定要搞清楚客户的业务现状是什么，业务需求是什么，对于用户描述的业务需求应该深入的分析，寻找最佳的解决方案，然后采取实现，而不是急急忙忙的投入实际的开发工作，这样做出来的系统整个是混乱的，割裂的，而且容易产生返工和无用劳动。用户可能会根据自身的情况和理解提出自己的解决方案，这个时候，我们应该分析方案的合理性和可行性，对于合理而不可行或者我们无法实现的方案，我们应该尽可能的提供等价的方案，实在无法解决的时候就需和用户协商是否可以降低业务需求或者另需处理办法，或者放弃。

      技术是实现方案的手段，我们需要根据我们的应用来选择合适的技术手段，并不是新的、高级的技术就是好的，应该采用最合适最成熟的技术。但是技术必须不断的提高，我们应该不停的钻研或者引入新的技术，来满足业务需求的增长，提高系统的技术含量，降低工作难度。毕竟技术可以带来生产力的提高，虽然短期可能会带来成本的增加，但总长远看，肯定会带来较高的效益。当我们的技术面临复杂的业务需求无法满足时因该引起足够的重视，对于技术的不足应该慎重考虑，是否有攻克的必要，不能总是绕过去，或者将技术无法实现而导致的工作量的增加转移给客户。当技术成为障碍的时候，不攻克技术的难点会给我们的工作带来负担的时候，我想我们应该想愚公移山一样攻克我们的难关。

     或许这些有些行而上学，说起来容易做起来难，或者在项目紧张的时候总是放弃这种原则，自己以前的时候也曾不以为然，那时作为一个小小Team的leader,在时间和压力下总是会急急忙忙的做事，其实走了很多冤枉路。这次在四川成都这个项目中，我真真实实地感觉到了我们业务规划能力的缺乏，和技术上的薄弱，同时也深深感觉到这些给我们的工作带来的混乱。

     我们的团队里几乎找不出一个能够完整地描述客户业务需求的人；我们的成员几乎很少的去分析客户的需求；我们的成员几乎没有人能够准确把握用户的需求，并深入分析，找出相应的解决方案。我们的团队成员总是习惯用技术的思维去思考问题，总是在拿到需求简单分析就进入开发工作，或者一个局部完整的业务都没分析清楚就从一个点上去做开发。或许他们可以给我一个理由：客户要得太紧，时间不允许你把问题搞清楚。然而事实是我们这么急急忙忙的赶着干活，却未能取得有效的进展，未能给出一个完整的哪怕是局部的成功模块。我们的开发是一堆泥巴，全部躺在地上，糊不到墙上去。因此我们的员工辛辛苦苦的赶时间所做出来的东西不停的被改动，甚至放弃。信心，情绪和激情在一点点的褪去。而且由于没有业务上的良好架构，我们的建筑很难经得起装修和改装。

     这是团队，乃至公司的不足，也是我个人的不足。

      另外，在实际的业务开发中发现，我们自己采用的，自己开发的工具无法满足目前业务的需求，但整体分析下来不攻克这些难点，我们势必会造成工作上大量的额外劳动，而且是我们的工具根本没有发挥其本身的优越性，没有实现我们采用或者开发这个工具的原始目的。然而我们丝毫没有解决这些难题的想法和行动，而是给提供乐一个极其复杂和危险的一种方案，而且有人竟然想出了我们无法实现的东西，把它转移到用户的手中去的想法，这真的是不可接受的。当然由于时间关系，当前没有办法解决，也是有情可原的。但真的不希望看到这个工具一两年后还是如此。那真的是伤心了。

     <未完待续>