项目经验分享(上)

╄→гoц情女王★ 提交于 2020-01-03 03:29:45


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

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

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

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

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

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

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

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

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

           如果你的网站涉及到多语言,那么为了让所有不同国家的用户不至于看到乱码,那么需要为网页设置字符集。
           方法很简单,但如果没有设置而被别人发现了此问题,那么别人同样也会认为你不专业。
           <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
   

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

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

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

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

    3 :学会自己解决问题

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

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

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

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

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

      3):。。。。。。

 

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

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

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

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

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

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

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

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

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

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

           如果你的网站涉及到多语言,那么为了让所有不同国家的用户不至于看到乱码,那么需要为网页设置字符集。
           方法很简单,但如果没有设置而被别人发现了此问题,那么别人同样也会认为你不专业。
           <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
   

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

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

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

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

    3 :学会自己解决问题

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

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

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

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

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

      3):。。。。。。

 

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

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!