項目經驗分享(上)


    最近三個月,我非常榮幸的做為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):。。。。。。

 

    下篇我再和大家分享幾個具體的技術難點,也不能說是難點,只不過我以前沒有遇到過,沒有類似的項目經驗罷了。
    
   


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM