思思想想,我的看法

 1. 业务重于技术(从毕业到现在一直在做ERP)
      1.1 记得刚进公司时，一个同事让我去修改一个作业。说是那个作业有错误！
      我仔细认真地测试了一下，没有异常。再仔细地看了他们的代码，还是没有错误发现！！！
      最后,我实在忍不住了。直接告诉同事说没有错啊！同事大惊！说，“这么明显的错你都没有发现，
      这个数据计算错了，最后，告诉我按照这个业务应该怎样计算.”当时，我晕菜了!
      刚进公司什么都不知道,就开始考我业务了!!!我服了！
      后来，买了些公司财务方面的书，没事翻翻。明白了许多。到现在知道业务怎么做，
      对比金蝶,用友我们应该怎么实现,为什么要这么做,都理解了.
      1.2 去年领导提出了,由于业务需要，我们需要一个XXXX系统，理由是金蝶，用友，SAP都有
      我们也需要一个。但不知道需要那些功能！当然我们听了就茫然!幸好我们PM是业务大牛.
      花了两周的时间把系统功能,业务描述，静态图全搞出来了。并且对比金蝶，用友，SAP给领导分析，
      我们应该怎么实现。靠,我真服了。
      总结:项目开发，业务先行。没有业务，技术没有意义！(纯技术的除外O(∩_∩)O~)
     

   2. 追求技术应该有广度(个人的兴趣,爱好)与深度(目前公司所用技术)
       .............................................................................  
  
   3. 需求文档
      目前我们需求主要关注以下几个方面
      1.用例编号
      2.用例描述
      3.优先级
      4.涉众利益
      5.前置条件
      6.后置条件
      7.基本路径
      8.分支路径
      9.设计约束
      10.字段列表
      11.业务规则
      12.非功能性需求
      13.待解决问题
      14.编码规则
   4. 程序设计
       目前程序设计主要就画静态图(主要是实体关系图)。
       其他的由于时间比较紧，人员也不多，就没有做了。
   5. 测试
      在项目开始时，很规范。测试用例，文档都有。
      到后来，项目紧了，就功能测试及同事之间相互测试.

   6. "斯人无罪,怀璧其罪" 应该把握好这个度.(人际关系处理)
       工作中的体会，也不知道我的理解到底对不对！举个实例来说吧，
       同样一个简单问题(领导不懂技术,对于技术人员来说很简单)，
       领导问你的PM能不能解决，你的PM说不能或需要很大的努力才能完成！
       然后再问你：“小李，你觉得这个问题可以解决吗？！(还特意强调,从你的角度!)”
       （当然,领导看得起你或认为你有能力，才来主动问你）
       你应该怎么回答！？我当然跟我们PM站一起了！
       知道这将是我们PM的功劳，但我不能拿他的功劳,这样做才是对的。
       如果你的回答是可以解决！！！那么...............
   7. "政治的最高境界--妥协!"
        不是我所经历过的，而是我所看到的!一言难尽！不说了！
         仔细观察自己身边！O(∩_∩)O哈哈~