项目经验分享(上)

    最近三个月，我非常荣幸的做为TeamLeader带领几个小组成员做了一个国外项目，这里想为大家分享一些小经验,尽管我佣有六年多的项目经验，但我一直的方向是架构师。大家知道架构师一般情况是偏向技术方向，我也不例外，前三年，主要精力都花在技术架构上，挖空心思在通用平台上做出自己的东西，体现个人价值。但最近一年也想在项目管理上有所突破，有人可能认为方向走偏了，但我不这样认为，在中国的软件环境下，在很大程度上，公司更希望全才，或者说有些公司并不仅仅希望架构师只懂技术。而架构师如果一味的只走技术路线，在某些方面会存在缺陷：

    1：与人沟通
    这个很容易理解，技术人员一般情况下不会和太多的人沟通，大部分情况也就局限于自己所属的Team，但是做为一个PM，你有可能会和产品经理，客户经理等人合作，这是普通程序员不太方便接触的人群。而往往人与人之间的沟通非常重要，沟通的顺畅可以让大家做事都比较顺利，反之，累死但结果并不太好。
    所以我认为，如果做为一个沟通能力非常强的架构师，那么会让他非常容易的被大家接受。

    2：每个公司对架构师的理解不一样
    有些公司比较注意架构师的技术水平，所以这类架构师会负责技术部的所有技术难题(比如一些B2C网站，他们也许注重的是架构师能够解决可扩展，性能，平台通用的问题)，但有一部分公司对技术要求并不太强烈，他们也许会要求架构师更多的懂业务，或者能够带领团队完成代表公司标志性的项目。
    尽管往一个方向走下去是最佳方法，但是能够在某一方向做的出类拔萃的人毕竟是少数，何不给自己多些选择呢。

     3：如何快速在团队中建立自己的地位
    每个人都想在公司表现自己，但如何让大家认可你，不同的人不同的项目，需要用不同的方式去体现。我个人认为，既然我的方向是架构师，而且我也想将自己以往自己认为不错的项目经验分享给大家，那也许最好的方法就是自己亲自带领团队做项目，并在项目是慢慢应用自己的经验。让一个成功的项目去说服大家。
    
    下面来分享一些项目中的心得：
    1:英语很重要
    由于是国外项目，所以对英语有非常高的要求，由于本人英语太差，口语基本没有与人对话过，需要一个懂英语的高级经理为我们团队做名誉上的PM。平时负责带领我和外国客户开电话会议，以及对外的邮件沟通。实际上这种方法是没有办法的办法，最好是自己懂英语，直接和外国客户沟通，少一级的沟通会顺畅很多，也不会因此消费更多的人力资源。
    2：小的技术细节很重要

    我们有一个微软MVP的架构师，水平相当资深，但他对技术细节要求非常严格，这里分享一些我们遇到的问题：    

           1>:对于web项目，图片不能过大。

          实际上应该说，整个页面的大小不能太大，这里我认为一般不超过300K,如果太大，加载过慢也许是所有用户不能接受的，毕竟大家的时间都非常宝贵呀。

         我们的问题在于，有一张背景图达到了400K，当项目功能研发完成后，我当时也发现了这个问题，因为我一直对web性能非常关注，所以我马上对图片进行了优化，由400K 下调到110K，但不巧的是，我们理所当然的认为他应该在测试环境上做测试，没成想，他到了另外一个环境做测试，而我并没有将此次变更同步到两个环境，所以发现了此问题，让他认为我们非常不专业。
   

           2>:网页的charset设置很重要

           如果你的网站涉及到多语言，那么为了让所有不同国家的用户不至于看到乱码，那么需要为网页设置字符集。
           方法很简单，但如果没有设置而被别人发现了此问题，那么别人同样也会认为你不专业。
          
   

          3>:第三方组件的版本问题
          我这里所指的第三方组件，就是指你的项目是引用的别人开发的组件，比如jquery,log4net之类，但是有人也许非常注重你所引用的组件版本，比如jquery,他更加希望你的项目中引用的是最新版本，因为事物总是进步的，新版本也许有更多的优势。至于这点，你可以认为是多此一举，也许你能列出N多种不同意的观点，起码我自己也认为够用就行，但我们需要根据公司架构的要求来，否则会影响最终的项目上线。

          4>:TeamLeader需要更多时间来检查项目质量

          这里所指的项目质量包含如下方面：  

              1):项目进度
                   是否有按预期的进度在发展,一旦偏离大方向，以后就越来越控制。
              2):每个功能完成的质量
                  尽管从功能上讲没有问题，但从技术实施的手段也许存在一定问题，也许会为以后的重构带来隐患。我们不能说完成功能就行，需要在一定程序上考虑到你的代码的可维护性，可扩展性。比如项目在第一期交付成功了，当以后客户再提出部分变动时，由于我们的代码可扩展性太差，需要花很多时间去完成，客户就会认为他们的成本太高，我们团队的效率太差。
             3):需要花时间从整个技术角度来审查
               比如我在功能研发完成之后，以我自己的经验，我也发现了背景图片过大问题，但由于我也有相当大的业务功能编码任务，故导致此问题发现的比较晚，以至于架构师发现了此问题，尽管他没有按我们的要求去指定环境做测试。
              所以teamleader不能将自己大部分时间花在具体的业务功能了，需要更多的去关注项目的进展，完成质量，整体的架构以及于客户的沟通。
       

    3 ：学会自己解决问题

     有人会说，这不是费话吗，但我想表达的，有时候，有些问题别人无法帮助你，或者公司无法给你提供即时的资源帮助时，如果你想让项目顺利上线，你需要自己想办法解决你不擅长的问题。

      1):我们需要自己优化图片

       一般情况下，每个项目都会有美工，比如她设计的页面的背景图过大，那么需要她自己去优化，但如果此时正好美工在其它项目中工作，无法为你即时提供帮助时，你需要自己想办法去做优化。

      2):teamleader需要设计项目原型

      这在某些公司是由产品经理来完成的，但如果没有产品经理，那么teamleader就是产品经理。

      3):。。。。。。

 

    下篇我再和大家分享几个具体的技术难点，也不能说是难点，只不过我以前没有遇到过，没有类似的项目经验罢了。
    
   

转载于:https://www.cnblogs.com/ASPNET2008/archive/2012/06/16/2552261.html