在開始今天的話題之前，請允許先介紹一下我們項目的情況，我們的項目是汽車電子軟件開發(fā)的項目?？紤]到人員的技術(shù)問題，我們采用的是異地的分布式開發(fā)，在上海團隊有10人，印度的團隊5人，客戶有自己的相關(guān)的軟硬件團隊。此項目的最終客戶是國內(nèi)的OEM車廠。
磨刀不誤砍柴工，在項目開始之前我們仔細考慮了運用什么軟件開發(fā)模型和方法論。現(xiàn)有的方法有瀑布，v模型，敏捷開發(fā)等等。因為我們有過和國內(nèi)客戶的合作的經(jīng)驗，他們的需求變化總是很多很快。特別是我們的項目中有人機界面的部分。從最初拿到客戶的產(chǎn)品需求文檔就很籠統(tǒng)。人機界面部分缺少細節(jié)的描述。和客戶的溝通中了解到他們是期望我們做出來一定的界面后他們再提意見。另外客戶對項目的時間要求非常緊。
綜上考慮我們采用的是敏捷開發(fā)方法，來應(yīng)對這種頻繁的需求變化。由于篇幅所限，這里不打算對敏捷開發(fā)做詳細的描述。雖然我們的團隊有過敏捷開發(fā)經(jīng)驗，但是分布式的敏捷開發(fā)還是第一次。敏捷開發(fā)是一種以人為核心、迭代、循序漸進的開發(fā)方法。敏捷開發(fā)強調(diào)團隊之間要面對面的交流。但是我們的團隊組織不能滿足這個要求怎么辦。我們采用的方法是中國的team設(shè)定項目經(jīng)理總負責(zé)兩地的溝通和協(xié)調(diào)。印度team設(shè)定項目經(jīng)理負責(zé)印度團隊和中國的溝通。同時需求分析師放在中國這樣接近客戶了解需求。
異地分布軟件開發(fā)面臨的最大問題是交流問題。隨著人員距離的增加，交流效率將大大降低同時交流成本將極大提高。很多時候客戶一端團隊不能把正確的需求傳遞到異地的一端，這直接造成需求理解的偏差和產(chǎn)品質(zhì)量的下降。任何交流方式都比不上面對面的交流。異地開發(fā)時，異地一端很容易丟失客戶一端與客戶交流的信息。所以我們在項目需求和開發(fā)初期，印度團隊的一名成員來上海1-2個月來做需求和架構(gòu)分析。
為了保證溝通。中國的項目經(jīng)理和印度的interface每天的電話會議，不需要很長時間30分鐘就夠了。因為印度和中國的時差2.5小時。所以每天的電話會議安排在下午1點左右，這個時間可能是我們飯后比較犯困的時候，正好安排會議。雙方會介紹各自昨天的工作狀況和今天的計劃。印度的團隊的接口，會議結(jié)束后，中國的項目經(jīng)理會將雙方每日的開發(fā)狀態(tài)郵件匯總。發(fā)給團隊的成員。每個團隊自己進行每日例會，并由個項目的項目經(jīng)理和需求分析人員進行另外的會議以便協(xié)調(diào)工作。每天的定時會議將成為很重要的一個很重要的交流方式。另外每周的周會項目的所有成員會參加。我們會利用公司的視頻會議系統(tǒng)，進行可視會議，這樣雙方可以減少陌生感。增加信任感。
項目的管理工具方面：
1．配置管理方面在公司內(nèi)網(wǎng)建立SVN來使用。兩方的團隊可建立自己單獨的持續(xù)集成環(huán)境，但需要保持系統(tǒng)環(huán)境的一致。兩方的開發(fā)人員都應(yīng)該保證每日離開辦公室前的提交通過集成。這樣可以避免異地團隊開始開發(fā)不至于被失敗的集成所耽擱。
2．日常的項目管理工作中，在異地開發(fā)中，為了使得每個團隊都可以了解到團隊任務(wù)，可以采用在線工具幫助進行項目跟蹤，我們采用在線Wiki或Microsoft
SharePoint
總結(jié)：
我覺得作為一個項目整體的項目經(jīng)理，需要注意以下的事情
1）異地開發(fā)中最重要的部分還是客戶端。帶領(lǐng)團隊很好的作需求分析和概要設(shè)計。這部分做好了，異地的工作就好控制。
2）異地開發(fā)的團隊的負責(zé)項目經(jīng)理同樣非常的重要，必須具有很好的項目管理的經(jīng)驗。
3）本地團隊和異地團隊之間的最大的問題就是溝通的問題。本地的需求分析必須保證無誤的傳達給異地的團隊。本地項目經(jīng)理必須時刻了解異地團隊的狀況。郵件，電話會議，視頻會議都可以幫助我們來溝通。
4）項目經(jīng)理不要太多的涉足異地團隊的管理工作。這部分工作時異地團隊的項目經(jīng)理工作。但是，過程是非常重要的，這個需要異地的項目經(jīng)理提供相應(yīng)的項目過程狀況報告。并且及時地和客戶端的項目經(jīng)理保持溝通。
項目經(jīng)理勝任力免費測評PMQ上線啦！快來測測你排多少名吧~
http://m.opto-elec.com.cn/pmqhd/index.html
